I think it's time we admitted that talking about accessibility tends to make us uncomfortable.
In a product context, we tend to prioritize features with the biggest impact to the largest percentage of users.
So when we talk about building for accessibility, it feels like a loaded topic.
Where on the roadmap do we fit in features that make a big impact for a relatively small percentage of users?
How do we know what accessibility should look like for our product when accessible means different things to different people?
And how do we do all of this without making assumptions or inadvertently offending the users we're trying to support.
My guest today is Purna Ramachandra, Principal Product Manager at Yahoo.
Prior to joining Yahoo, Purna was a Senior Product Manager at Slack, where she was instrumental in auditing and developing accessible features for the product's diverse user base.
What you're about to hear is part case study, part playbook on the business case for accessibility, and the most efficient and ethical ways to make your product more welcoming to everyone.
Let's jump in. welcome back to the product manager podcast we are here today with krana rajandra krana thank you so much for making time in your busy schedule to join us today thank you so much for having me it's great to be here can you tell us a little bit about your background and how you got to
where you are today so i'm currently a principal product manager at yahoo i've been here for about a year and a half now and prior to yahoo i was working at slack and i was at slack right before they got acquired by Salesforce and then through the Salesforce acquisition.
And at Slack, I was primarily leading the accessibility and design systems team before I transitioned over to working on their core desktop experiences app.
My work from one team to the other kind of, they both bled into each other, which I'd love to dive into later today.
And then prior to Slack, I was working at the Washington Post where I led the redesign of their homepage and the replatform of their article page experience.
So I've had some media experience, some big tech experience, and I like to say that my interest in product specifically aligns with the intersection of product technology and storytelling and the ways in which people use stories to communicate with one another and how tech can be an effective tool to
do that. Which is so perfect since you're here today telling your story.
Obviously it's something where we're both passionate about storytelling and today we're going to be focusing on something that's maybe a little bit more niche but definitely an issue that I think we don't talk about enough which is accessibility and specifically the intersection of accessibility and user
onboarding. So just to kick us off, why would you say, like, in your experience working in this field and in this space, why does accessibility often get treated like an afterthought?
And what's the business case for baking it in from the beginning?
Definitely. So I'd like to just start by speaking to a statement that I truly, truly believe in my heart, which is we live in a day and age when I don't believe technology is a luxury anymore.
I grew up in the 90s, dating myself a bit here, where technology was still a novelty.
The Internet was still a novelty.
Not everyone had access to it, nor did everyone need to.
But we live in a day and age where every one of our essential services is in some way, shape or form digitized.
And that means that every single person in the world should be able to use it easily.
And people with disabilities are generally treated as an afterthought in our society.
I think so many of our services are not as accessible.
but technology is uniquely positioned to actually quite easily bake in accessibility into what it does and technology is also uniquely positioned to make the lives of everyone including people with disabilities a lot easier and so I think this is one of the main reasons like a moral and ethical standpoint
I think it's really important to prioritize why it gets treated as an afterthought quite frankly is because I don't think most organizations fully understand the business case for it that's number one and number two i think it's because people feel like accessibility requires some really deep technical
expertise and so they don't always feel like they have that expertise or they don't always think about it it's not baked into our processes and as a result we just ignore it until someone is worried that they're going to get sued or that they're going to lose a customer that has accessibility requirements
and all of a sudden your teams are scrambling to try to figure out what's wrong and how to build it in.
To answer the second part of your question, which is like, what is the business case for accessibility?
And I did touch on this in my first point.
The reality is that for technology to succeed, you want to have more users, right?
And for most of us, we get paid the more our product gets used.
And the way more people use it is if they can access it.
So at a core level, accessibility is just really important because more people can use your products.
And when more people use your products, you just make more money.
The flip side of it is you don't want to get sued.
And if you get sued, there's a chance you're going to have to pay out a lot of money.
And so from both standpoints, there's like a business case to be made for accessibility.
And the other thing I want to add, and I'll dive into this more in detail, and something that I'm personally very passionate about within the field of accessibility, which is we always limit the idea of accessibility to ensure that it's usable by screen readers, ensure that you can do keyboard navigation.
but I think we need to move beyond that definition of accessibility and really think about how do you ensure that everyone in every circumstance like your users in every circumstance can use that product because oftentimes we don't think about accessibility as something that can be situational and conditional
so one example I always like to give is voice commands or using voice to use your product we always think it's something that's easier if you have low eyesight like my dad he's like much older he might not be able to see small text on his screen so he He likes using his voice to control a lot of things
on his phone. But if you're driving, you don't have use of your hands either.
You don't have use of your eyes in the same way.
So you could still use voice commands.
And so when you think about accessibility, you can think about it as encompassing a situation rather than an individual or an individual problem.
And that actually expands your definition and makes you realize you're actually leaving on the table a huge use case and a huge user base, which is probably not good for your business.
And so there is like a practical business case to be made for why this is important to prioritize from the very beginning.
I think that that's so resonant.
I think that applies to accessibility in digital products, as well as physical products and physical spaces.
I really love the framing of being accessible to a situation rather than a specific use case.
I experienced that myself when I was pushing around a stroller and I noticed how many spaces were designed for, you know, a single pedestrian, you know, single file kind of thing.
And you realize that there are so many different contexts in which someone might require an accessibility feature or accommodation or have something designed with accessibility in mind because that is so cross applicable to many ages and stages and phases of life.
So, yeah, I really like that way of thinking about it.
And I'd love to dig a little bit deeper into that in a moment.
You mentioned that you want to talk a little bit more about your experience at Slack.
And I would really like to dig into some of the projects that you worked on during that time and particularly accessibility onboarding workflows through a lens of accessibility walk me through a little bit how did you approach like a state of affairs analysis to evaluate what the product's current accessibility status
was and how did you move forward from that definitely so when I started at slack one of the first projects that I worked on was actually figuring out how accessible the product was and what we could do to exactly what you said how What kind of frameworks did we have to do a state of product analysis?
And we didn't have anything.
When I joined, Slack was at a point where it was really going after big enterprise customers.
It had kind of done really well in the small to medium business market.
And as it was going after these big enterprise customers, it was realizing that there were a very strict set of regulations for their vendors in terms of accessibility.
And so the first thing I did was actually develop an internal set of standards, which we call the Slack Accessibility Standards, which used pre -existing standards like WCAG, but also took into account Slack's unique products and what accessibility would mean for those products.
And we put together a framework that allowed you to go through the product and analyze whether it met certain criteria.
And as a result of that analysis, we assigned a grade like A, B, or C to different features within the product to analyze how accessible they were and this was very much a quantitative plus qualitative analysis so we had the list of criteria some of it was based on just like very simple like task management
like is everything keyboard accessible is everything screen reader accessible and then other things would be something that were a little bit more intangible so for example snap slack is a communications product and one thing it does really well is notifications.
You need to be notified.
But this was during the pandemic.
So a lot of people were working from home.
A lot of people were working remotely.
And so we did hear from customers that there was notification overload.
And it specifically impacted anyone who identified as neurodivergent because they would feel really overwhelmed and they wouldn't be able to do their task properly.
So that was a little bit more intangible.
It's not something that you really see in a lot of accessibility guidelines out there.
So we incorporated all of that to create this framework.
They use this framework to assign grades to each of the feature areas.
And the grades were purely based on, can they do the task and how quickly can they do it?
So it helped mark a sense of urgency to the issues and what was most important and what was not.
So that was the first thing we did.
We used that to do a state of product analysis.
And then we went to leadership and said, OK, this is the entire product.
This is how it falls into the range.
And these are the issues we believe need to be fixed immediately because they're actually fundamentally the product is broken for a group of customers as a result of this not being done.
The cool thing about this framework was also that it wasn't just applied to existing products, but if you were developing new products, you could very well apply that framework in order to understand what you need to check off before you can launch this.
So it was also something that you could use, be future thinking, and you could use for future products as well.
So that was the first thing we did.
And then we did a lot of work, I did a lot of work to specifically work with individual teams in order to help them know what to prioritize based on this framework.
Because everyone has a roadmap.
No one wants to blow up their roadmap in order to meet something new that's coming up.
Everyone has like a set of things they've committed to.
So I worked with these individual teams so that they knew exactly what the critical items were for them.
So that when we went to leadership as a collective and said, this is what needs to be prioritized.
This is what needs to be fixed.
We could go to them with a very clear plan and we could also tell them what the trade -offs were.
So what would be the level of effort to fix each of these items and what would get pushed out of the roadmap if we had to accommodate this and what would the impact be?
So I always believe that when it comes to accessibility, this is true for a lot of things within product, but with accessibility, I saw specifically, you have to understand the balance between working with the individual team that is responsible for the feature area, as well as navigating how do you work
with leadership to get buy -in to prioritize this work.
And I was very fortunate that the leadership at Slack was very committed to prioritizing this work and doing it right.
What they really needed from us was the clear information.
Okay, what's the level of effort?
What's the timeline?
What are the trade -offs?
and what's the impact.
So that's what we were able to go to them with.
So it was a lot of work in people management and also a lot of work with your engineers technically to provide the analysis that they needed.
This is so critically important.
I think that the buy -in, there's nothing more critical to making sure that these features get shipped than to actually get the buy -in.
And like you said, to do it right.
I would really like to get a little bit more granular as far as you mentioned the trade -off.
So what would a trade -off look like?
Like how exactly would you, you know, if you were to kind of, give it an anecdote or like an example of how that might be presented.
How would you phrase that in order to kind of put everything in context and kind of explain the scope of the project and how, you know, where it falls on the critical items list?
The team that I would say was most impacted by the work that we did was a team that was working on the core messaging part of, of the app.
And it's because they had, they owned the largest surface area.
They owned everything from the experience of like someone typing a message and sending it to receiving a message in that entire message portal.
They had members on their team who own channels.
If you use Slack, you just know this is the core of the Slack experience.
So it made sense that they would have the largest number of items they had to tackle because not only did they own the largest surface area, it was also the most critical surface area.
Slack exists because people send and receive messages.
So it was the most critical surface area.
It had the most high -impact issues within accessibility that they had to handle.
So to give you a very specific example, when we went to them with this list of issues, I'm not going to give specific numbers here, but I'm going to give some hypotheticals.
I'm going to use 100 just because it's easier to like do percentages.
So I went into them with, let's say, a list of 100 issues and said this is all that needs to be tackled in order to ensure that your product is at minimal usable for every single person who uses a screen reader, uses keyboard navigation, who identifies as someone with a disability.
So the first thing I did was sat down with the PM and said, this is a list of issues that we've identified based on this framework we have.
This was actually a very critical step, but that PM was able to work with me to say, okay, I understand why you said these 100 items are critical, but I actually only think 80 percent of this is critical because this is the user data we have and the user information we have on how people are using this.
So if you think this particular workflow is really critical, they are actually doing it differently.
There's actually workarounds and solutions for this.
So that first analysis was really important because we were able to then cut down that 100 to 80.
And I think anyone who has an accessibility, central accessibility org, it's really important to have that conversation with the product manager of the product itself, because they actually know their users the best.
And so we were able to cut down that list quite a bit.
Then the second thing we did was, okay, look at the issues and see which of them are in product areas or feature areas that are going to be either redesigned or deprecated soon.
so that helped us say okay if this particular area feature is being redesigned then let's just make sure it's accessible in the redesign and we don't have to fix this issue right now right if this particular area is going to be deprecated we don't have to fix this issue right now so that got rid of let's
say another like 10 issues so then we had about 70 that we had to tackle with the team we sat down with their engineers this is where it's really important to have an at least one in -house accessibility expert we were really lucky we had a really really solid engineer with that expertise.
He was able to come in and work with their engineering team to help them understand and do like a level of effort analysis for each of those 70 issues.
We then sat down with the product manager and said, OK, how many of these 70 issues can you just prioritize in your current sprint or your upcoming sprint within this quarter without worrying about anything slipping?
How much of it can you just fit it in?
Most teams usually tend to have some buffer, especially if you're a team that's working on a product that's already released to manage like incoming bugs and issues like that.
So this kind of got pulled into that workflow and they said, okay, we could probably do like 20 of these without having severe roadmap impacts.
So we didn't even need to worry about that with leadership.
So then we were left with maybe half of that.
So we were able to really cut it down.
And then with the remaining, let's say 50 issues, that's where we had to say, okay, what are some big product areas this quarter that could potentially get pushed out or delayed if all of these issues were prioritized?
And that is the moment where we needed leadership to step in and like help us navigate and negotiate on what to do.
And so there was a feature area.
There was a feature that the team was set to release within that quarter that was really important for a big customer.
But the same big customer was also the one that was asking us to fix these accessibility issues within a certain time frame.
And so then we were able to sort of go to leadership and say, this is the tradeoff.
This is what we're working with.
And then we were able to use their help.
We were able to work with the account manager.
for that customer. Go to the customer and say, OK, this is where we're at.
Like, what would you like to see?
And so I think the most important thing here is to do as much work as you can do at your level, at the individual contributor level, at the senior PM, principal PM, group PM level to ensure that you have done as much as you can to prioritize all the work you can do creatively within your team.
And you bring in leadership only when they're going to be like big areas.
And in this case, what was helpful was that it was the same customer that was being impacted by both sets of issues.
And so we were able to work with them to negotiate which one they wanted first and which ones could come later.
And then based on that, we were able to say, OK, let's fix these 10 issues in this quarter that would not delay the other feature so much.
Let's fix these 10 issues in the next quarter.
And then this was really the first quarter that we did all this.
And then in subsequent quarters, what we were able to do was actually in the quarterly planning cycle itself, work with the teams to just carve out dedicated time where they would just do accessibility.
And this is where it's really important to get the full organization involved, because what we were able to do was do these like accessibility sprint weeks.
We used to coincide them with Global Accessibility Awareness Day whenever the quarter fell there.
So everyone on the team, all the different engineering squads were working together to just work on accessibility issues for that sprint.
And it also was like a nice community environment.
We also had some workshops where we tell teams about accessibility.
So it was like, it worked out really well.
Like I said, there's a lot of hard work in the beginning.
And especially when there are those big trade -offs between features, that is where you have to loop in leadership in order to help you negotiate and navigate what to prioritize and when.
This is really cool.
And I really love to hear about, you know, organization coming together specifically to prioritize and make time for accessibility and that it turned out to be such a positive working experience as well.
That sounds so awesome.
But now that we're on the topic of collaboration and kind of working as a team across different kinds of teams, I'm wondering how this all works out when you're working with an organization that's got maybe several products in the portfolio and there's multiple teams that are trying to address accessibility
issues across those different, you know, different products and features.
So how do you collaborate between product teams in order to, you know, work in lockstep and kind of minimize the amount of effort and communication that's involved in order to ship these products?
Yeah, that's a great question.
So I think there are two different ways or two pillars, I would like to say, to tackle this problem.
The first pillar is like structural.
If the organization has a central accessibility org, and I think most organizations today do in some capacity, like where do they sit within the organization, right?
Like if they sit within a single vertical, then it's going to be very hard to break through organizational silos to work with other teams.
So you really have to ensure that your team is positioned in the right place.
And if it's not, then you as the product manager has to do the work to reach out to all these other teams to like understand their roadmaps, get to know them so you can work well together.
I think that's the first thing.
The second piece is ensuring that, and this is also a twofold, both for the person managing and leading the central accessibility org and then the individual feature team PMs, which is ensuring that you are both in constant communication about your roadmaps.
If you know what's coming up, this was the biggest, I guess this was one of the biggest challenges for our team and also the biggest area of opportunity when I was working on accessibility at Slack.
And later, when I started working on the desktop product, I suddenly went from being in the central accessibility team to being one of those feature teams myself.
The most important thing is to ensure that when you're doing roadmap planning at the beginning, you are looping in the accessibility experts you need to loop in.
And it starts right from the planning process through the design process.
I like to say that accessibility actually doesn't start with the engineers, even though it requires engineering expertise.
Sometimes it starts with the designer.
One of the things we got into, and if you're using tools like Figma, they have a great tool set to actually do accessibility designs or like an accessibility specific workflow within your design.
So our designer would be involved from the very beginning of the product development and design process to say, okay, how do you ensure the designs you're creating are accessible?
Are there things that are working?
Are there things that are not working?
So this is for anything future thinking.
For anything that's an existing issue, right?
Like if you're already identified a set of accessibility issues within your product, that is where that framework came in very handy.
So it's like much as I tried my best when I was in the central org, I couldn't keep track of every single change, every single roadmap change, everything that the team was doing.
But because we had this centralized set of frameworks that everyone was aware of, as a feature team product manager, they could just refer to it and like hand it to the designer, hand it to their engineer, look at it themselves and say, okay, this accessibility bug came in based on this framework.
This is critical, medium or low priority.
And then I can use that to determine whether or not I need to prioritize it immediately.
I can prioritize it later.
So having that central standards was really helpful because it ensured that someone who doesn't have that expertise still had something to refer to when these bugs came in and they can help prioritize.
And that also ensured that there's not one single person in charge of trying to sort of herd the cats, for lack of a better word, and say, okay, are you doing it or are you not?
Because what I really wanted to ensure when I was working on accessibility was I don't want to be like a school principal trying to tell you what to do.
And I don't think anyone wants that.
We're all adults here.
And I also like to believe that every single person involved actually does care about this.
Like nobody I talked to said, oh, I don't want to do this.
Everyone was like, I really care about this.
I want to make sure our product is accessible.
I either don't know how or I don't know if we're going to be given the authority to prioritize this or we're going to have the time to do it.
And that's what we were really trying to solve for.
And so I would say if you're a feature PM who's trying to make your product accessible, see if you can develop a framework or work with someone in your org to develop a framework that you and other people can refer to.
So you're not constantly having to wait for someone to respond to you as to whether something is important or not.
You'll know yourself and you'll be empowered.
And then you're creating something new and you're building a new product ensure that you can reach out to the people with the right expertise and bake in accessibility into the design process from the very beginning because then that avoids a problem where these bugs come in in the future and suddenly
are scrambling to prioritize it you know it's going to be accessible from launch.
This is really interesting and I want to talk a little bit more on the level of implementation and iteration because it's one thing to kind of analyze the features that you have and prioritize and implement changes and improvements to the existing version of the product or whatever your enterprise clients
are asking for. But as time goes on, new features are introduced, features become antiquated or replaced with, you know, updates.
How do you integrate that analysis process or what's like the proactive approach in order to ensure that future features that are introduced into the roadmap are accessible from the day one as well?
Yes, it's a great question too.
So I'll give a very specific example.
And since you talked about user onboarding specifically in the beginning, as I said, the first thing when you're creating your roadmap is to look at every feature, everything that you have going on, anything new that you're building and know that you have to think about accessibility.
I think that is something as a PM you have to keep in mind every single time.
The other thing I would say is knowing when, and this is a little bit of PM intuition that develops over time and a little bit of like looking at actual data.
It's knowing who in your customer base can actually help you ensure that something is accessible or something is not accessible.
Because I think as PMs, we rely a lot on user research to help us know what to build.
But we often forget that there are actually customers and people out there who are using our product in a way that requires, like who are, you you know, users with disabilities who use these accessibility features.
So ensure that you have ways to incorporate them right from the beginning into like your user research process.
So when you're thinking about that future thing.
So the example, as I said, I was going to give was user onboarding.
So another feature area we found when we were doing our initial analysis within Slack was the onboarding experience had accessibility gaps that we wanted to address.
But we also knew that the onboarding team at Slack was going through making some big redesigns to the onboarding experience.
because the product had evolved and grown since the first time they did this and they needed, they wanted to make sure they incorporated everything.
So we were actually able to work with that team from the very beginning to ensure that the core onboarding flow that they were redesigning was accessible.
And so the way we did that was we were intimately involved in their roadmap planning from the very beginning.
And this is a very big project.
So whenever you have these major projects is I think when it's really important to get the right experts involved.
And our designer was actually involved throughout the design process.
So when they did user research, when they were doing user testing, when they were creating their designs in Figma, he was creating the accessibility spec for those designs side by side along with them to make sure that things were accessible from the very beginning.
It was the same process used at Slack when we were redesigning the desktop app.
But secondly, what we found was there was a real opportunity here to have an onboarding experience specifically centered around accessibility for the users who needed it.
I think the best example of this is Mac's, is Apple.
So Apple's products, I think, are really, really solid when it comes to accessibility.
And so when you buy a new Mac, you can actually choose to go through an onboarding workflow that specifically shows you where the different accessibility features are, how to use them, et cetera, et cetera.
So we actually, our team, the accessibility team actually built out that core onboarding experience right from when you enter the app, when you enter the regular onboarding floor, we ask you, do you care about accessibility?
If you say yes, we take you through a step -by -step workflow that shows you where the different tools are, the different how to use keyboard navigation, what the different commands are, et cetera.
And then the other thing we were able to do was use the data.
So when someone tells us they're interested in accessibility, we take them through the workflow.
We were able to show them strategically different tool tips within the product that allowed them to continue that accessibility journey.
And the reason that all of this was possible is because when one when we realized there were issues, when we were actually outlining all the issues with the existing workflow, we saw that there was like a huge gap because there was no accessibility onboarding experience.
And then the second thing was we talked to a lot of customers.
So we talked to customers who were sending in these accessibility bug tickets to us who were helping us figure out how accessible the product was.
A lot of them said, you know, there was nothing to help me figure out how to navigate Slack.
I had to figure it out myself.
and most of them are used to doing that unfortunately because a lot of our products don't do that for them but it's still not like you know in my opinion it's not the ideal workflow and so i would say that when you're thinking about you know future thinking what are the products i want to build how
is my product looking i think rely a lot on user research like i don't know why it's not being talked about in our industry as much but you have to talk to your customers like nothing replaces that i don't think ai is going to tell you what to build it's the people who are using it who are going to
tell you what to build.
So you have to talk to them.
And today, there are companies and tools that help you do that.
So if you're a big enterprise company, for example, and your customers are enterprise clients, I guarantee you they will have an ERG, like an employee resource group of some sort that has employees with disabilities who would, I am quite certain, will be very active in ensuring they vet their vendors.
So that's a resource you can tap into.
The other resource are, there's a company we used to work with called Fable that specifically recruited users with disabilities to do accessibility user testing.
So it's like usertesting .com, but specifically for accessibility.
So like work with those entities, work with those organizations to kind of help you understand like what you're building, how you're building.
And then the second thing I would say is as you're starting the design process and the iteration process, include someone, either have your designer take a course to understand designing for accessibility or have someone with expertise in accessibility be involved in the process, right from the design
process. Make sure that your designs have accessibility specs, because that is what your engineers are going to refer to when deciding and figuring out how to build something.
Make sure that those designers and those accessibility experts are involved in text testing.
That's how you sort of ensure that everything you're building is going to be accessible moving forward, rather than having to, again, as I said, scramble and then redoing it later.
Anyone who's listened to the show for a long time knows I love prescriptive advice that's very specific in detail.
So thank you for offering these very specific recommendations just to kind of put a bow on things because we'll be wrapping up shortly.
But I do want to make sure that we touch on analytics.
We brought up data not too long ago.
And I want to bring this back around to how we're going to measure success of our accessibility features and the things that we've implemented and put so much effort into working together to create.
Naturally, I imagine, you know, when you're measuring activation rate or some of those other kinds of really key adoption metrics when we're thinking about the general populace, we're looking at a very different or possibly somewhat different process for segmenting how effective your accessibility features
are, whether that's from an onboarding standpoint or any other accessibility feature throughout.
It's a multiple part question.
First of all, how do you segment what you're measuring to ensure that you're measuring the success of the accessibility features that you've built rather than just the product at large, are there any tools that you would use for that?
And do you have any other tips or tricks for ensuring that you're able to integrate that kind of data into future iterations?
Definitely. So I'm going to give an answer that is probably going to make a lot of PMs uncomfortable.
And it's also something that I'm uncomfortable with, which is you cannot rely on quantitative data to understand whether your accessibility features are working and whether your product is accessible.
And some of it is because morally and ethically, you cannot really segment users based on accessibility because you're trying to make assumptions about whether or not someone has a disability.
And even if you use data like measuring how many users are using keyboard navigation or how many users have turned on screen reader commands, that still can potentially exclude a large group of the population.
Like, for example, I mentioned neurodivergence, like are people with neurodivergence are able to use your product or is it too overwhelming?
There are certain specific features around that.
For example, it's Slack and a lot of any product that has any sort of form of animation, you have the ability to turn off that animation because for some folks, it can cause seizures.
So that's another thing that's kind of hard to measure.
So there's only so much you can get from your quantitative measurement because it's really hard to segment users in the way that you would normally segment your user base because you're making a lot of assumptions about someone that you generally don't want to do.
And also, it's probably not going to be very effective, right?
There's a lot of things around like hidden disabilities.
And also, it fails to take into account the situational thing that I was talking about at the beginning of the episode.
What I've found works the best for accessibility and measuring whether or not your product is accessible and whether or not features that are specifically around accessibility are working is going back to your users and just like asking them.
So qualitative research is the best way to measure the success of accessibility, in my opinion.
And also it's based on a lot of what I've seen working on accessibility in the past and now.
I'll give another very specific example.
So another accessibility feature that we built at Slack was essentially an API that a lot of different teams could leverage to easily build keyboard navigation into their products.
So like a keyboard nav API, because a lot of teams didn't really, it does require specialized expert knowledge.
So the API was supposed to make it easier for teams.
So the way we measured success in that case was actually seeing how many teams were leveraging that API, because it wasn't something that was required, teams could try to build it on their own.
So we were like, okay, if your team is leveraging this API means we as an accessibility team were successful in building something that you were able to leverage because we know it works really well.
So that was less of a user measure and more of like an internal team measure.
The way we measure success for our users, as I said, was really just asking.
So when we launched the onboarding workflow, we got some quantitative data in terms of how many users were opting into the accessibility onboarding experience.
But for the most part, we had worked very hard to assemble together teams of users who we would talk to about accessibility.
But also generally, whenever you launch something, I'm assuming you're going to do some qualitative research to understand the impact.
We made sure that those groups included users who had asked about accessibility, were using accessibility features, etc.
And it was a lot of like conversation, qualitative measurement, qualitative research, because not only do you want to know whether someone's using your product, but you want to know whether someone's able to use it properly in order to complete the tasks they want to complete.
So quantitatively, if your product is doing very well with the majority of users, that's already giving you directional indication of the fact that whether or not your product is accessible.
But if you're wanting to talk to those specific users about accessibility, you're going to have to find those users and you have to like specifically do the qualitative research and analysis to make sure that it's like working the way you want it to work.
And I know that's not a great answer because as a PM, You're really looking for the numbers and the data.
But I also think part of the job of PM is to be OK with that level of uncertainty.
And I will say this, which is, again, probably not going to be the best answer, but you're never going to be perfect.
No product is ever going to perfectly check off every single box when it comes to accessibility, because, again, like a lot of this is situational, which is, again, why it's really important to continue to have those conversations with your users.
And I will say, especially users who care about accessibility are going to be very vocal because they're not used to getting the things they need to just do their jobs.
So they have to be vocal in order to just survive and like do their jobs properly.
And so I think that you have a huge resource there.
And like something I had to learn more than ever in my career as a PM, it was when I worked on accessibility that I really truly understood the importance of talking and listening to your users because they could give you the best information of what you need to hear about how your product is doing.
And people are not talking about how important that qualitative research is and a human to human connection is.
But I think that's truly going to tell you whether your product is working.
And when it comes to accessibility, it's really important to make sure you talk to people.
Couldn't agree more.
Yeah, this is a very pro -user research show.
We did an episode a while back with Steve Borgal on how to interview users.
That's like one of our favorite of all times because it's all about just talking to people, letting people really tell you their authentic experience and not trying to guide the conversation, eliminating your own bias.
so important for a product development process.
Well, thank you so much, Prana.
This has been like such a fun conversation.
I really appreciate your perspective on this matter and what such specific stories to tell around and such a well -known product so we can all really understand and get behind how these features kind of come to life.
So I really appreciate this.
Where can people follow your work online or connect with you?
I'm going to be on LinkedIn.
It's just my first name, last name, Prana Ramachandra.
You can also reach out to me through my website.
is just pranaramachandra .me.
Fabulous. Well, thank you so much for being here.
Thank you so much, Hannah.
This was great. Thanks for listening in.
For more great insights, how -to guides, and tool reviews, subscribe to our newsletter at theproductmanager .com slash subscribe.
You can hear more conversations like this by subscribing to the Product Manager wherever you get your podcasts.
