Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | RSS
In this episode, the Product Outsiders welcome Derek Featherstone, internationally-known speaker, author, and Chief eXperience Officer at Level Access. Derek walks the Product Outsiders through the difference between accessibility and inclusive design, how Product discovery can be used to improve your success in this realm, and how all companies can take steps to make positive progress in making products that work for everyone.
This episode goes over our normal times because we all lost track of time as the conversation was that good y’all.
Find Derek on Twitter or LinkedIn, and keep an eye out early in 2022 for another chat with Derek!
Transcript
Amber Hansford: Welcome to product outsiders, a podcast for unconventional product people.
In a world awash in MBAs and fancy suits, we’re the people standing on the outside, our sleeves rolled up, ready to get some stuff done. Coming from many different backgrounds, we may not be exactly what you picture when you hear the term “product manager”, but we’re passionate about solving problems for real people in ways that create real value, building great collaborative teams, and making incredible products together. We are the Product Outsiders
And today, we are so happy to be chatting with Derek Featherstone, the Chief experience Officer at Level Access all about inclusive and accessible design.
I’m Amber Hansford. I’m a UX design manager, a former Product Manager.
Will Sansbury: And I’m Will Sansbury. I lead Product Management for a supply chain software company.
Tammy Bulson: I am Tammy Bulson. I’m an Agile Practitioner and very interested in how teams work together nicely.
Amber Hansford: And we are so happy to welcome here, Derek Featherstone. He’s an internationally renowned speaker, teacher and author on all things accessibility, inclusive design. Welcome, Derek.
Derek Featherstone: Thank you so much for having me. This is exciting. I’m very, very excited to talk with all of you today.
Amber Hansford: We are so excited to talk to you too. I really would love to start out with a question about how accessibility and inclusive design factor into discovery. We love talking about discovery around here. If you’ve heard any of our prior podcasts.
Derek Featherstone: So let’s dive right in. I think the first thing I want to do is just kind of frame up the difference between accessibility and inclusive design. And then we’ll dig into that. A lot of people ask me about the two things, because they hear the terms often in the work that they’re doing and they hear about accessibility, and they hear about inclusive design and they often hear them used interchangeably, including like literally saying “I’m a big fan of accessibility” and then saying “I’m a big fan of inclusive design”. It’s like the two things are the same, but they’re not, they’re actually different. I like to think of accessibility as one of the outcomes that we’re trying to achieve.
And I think of inclusive design as the process that we use to get there. It’s not the only process that leads to accessibility as an outcome and then positive accessibility outcomes. But it’s definitely one of the most sustainable repeatable responsible and ethical ways of achieving accessibility as an outcome.
So if you think of accessibility as a measure of how easily somebody with a disability can use the thing that we have created for them, you can achieve that outcome by never even talking to or engaging with, or interviewing or asking any questions of a person with a disability. You could still achieve accessibility as an outcome without doing any of that, but you can’t practice inclusive design and not talk to, and not invite, and not interview, and not involve people with disabilities in the process. It’s like literally to do so is the antithesis of practicing inclusive design. So I like to think of the two things as separate; one is definitely the, you know, my focus on it is the process that leads to a really great outcome when it comes to accessibility.
I also like to think that it’s not quite that simple. I know we talk about this is an inclusive design. In other words, it’s a design that we have created that includes people and it doesn’t exclude people. So I know there’s that way of thinking about inclusive design, but that’s like inclusion via the product, and I like to think mostly of inclusion via the process itself. And so while we can create an inclusive product, we should be doing that in as many ways as possible by practicing the process of inclusive design and rethinking how we’re doing that. That’s kind of the difference between the two or the way that I think of the difference between the two.
In terms of discovery, the untapped beauty of inclusive design, when I say untapped, it’s because it doesn’t happen nearly enough. What we see in most organizations and their process, if they include people with disabilities at all in the process, we tend to include them at the end. And we are doing an evaluative summary or an evaluative study of how well we met the mark.
We are looking for people with disabilities to tell us that we did it right, we’re looking for their acceptance. But if we truly practice inclusive design and not just think about including people with disabilities at the end to get their acceptance, but actually think about inviting them in and engaging with people with disabilities as co-designers, then that changes the game. Because what we ended up finding out from talking with people and working with people with disabilities throughout the entire process, whatever that process is, we get those insights that not just tell us about what we need to design, then check to see if it’s right. We can check to see if we’re designing the right thing.
I mean, it ties directly into discovery. I’ve worked with lots of different companies over the last 20 years, and almost all of them are they’re bought into accessibility. They, they get it, they understand the value of it. But what a lot of organizations don’t understand yet is the value of inclusion and the value of inclusive design as a practice.
What we actually find out, if we talk with people with disabilities…I’ll give you a going-to-the movies example. When we talk with people with disabilities upfront, we might find out that from talking with say 20 or 30 people with a variety of different disabilities, that somebody that’s using a wheelchair or a mobility scooter might base some of their decisions on what movie they want to see, not on the movie that they actually want to see, but on the way that they can schedule and arrange for accessible transportation to, and from the theater.
They might actually make decisions on which theater to go to based on the location of the accessible entrance if the main entrance is not accessible for some reason. So if the accessible entrance to a theater is around the side and 400 feet away from the main door versus the accessible entrance, being the main door and just going in the same door as everybody else, they might actually choose to drive farther or arrange for transportation to go to a theater that is further away simply because of the location of the accessible entrance. When we know that information upfront and we start to get that, and we find out more about, you know, people that are deaf or hard of hearing and their need for captioning, they might actually choose the movie not because that’s the movie that they want to see. It might be that they choose that simply because it’s the only one in the theater that has captions.
When we understand the decision-making processes that people with disabilities use and how that might or might not differ from the decisions that people that don’t have disabilities make, we get a better picture and a better understanding of what needs we might actually need to build into that product.
If we understand those needs, we might make different decisions. So instead of the design showing whether or not captions are available on a movie, when you drill down into the movie details if we know that that’s an important decision making factor, we might show that in the search results and have that bubble up that information up to the top level, rather than requiring somebody to drill down into the specific movie.
So if we know it’s an important decision-making factor, for someone with a disability in a way that’s maybe not as important for someone without a disability, we might bubble that up higher and that would change our design. That would change the way that we’re envisioning the product. We might, even after interviewing 20 or 30 people with different disabilities, come up with something completely different than we’d never even thought of before.
And we might come up with a product that is actually entirely dedicated to accessible cinema experiences. And we would never maybe come up with that idea if we hadn’t talked with, or engaged with people with disabilities in the process. They might actually want, I’m saying “they” because I don’t actually know who they are, but some people with disabilities might actually find it ridiculously useful to have an app that only shows accessible performances.
And that might be something that builds incredible loyalty from a group of people with disabilities to a particular company that goes to the effort of actually understanding that that would be really important and, and allowing for that to be a big part of what drives the creation of that product. So, yeah, it fits really well with that concept of discovery and figuring out what problems we’re even trying to solve before we fall in love with solutions. We want to fall in love with those problems. And I think of the work that Indi Young has done on problem space versus solution space, and I talk with Ind fairly regularly about this. I love that framing of it and not enough work gets done with people with disabilities in the problem space.
Amber Hansford: We need to make sure that it’s there at the beginning of the discovery process, as we’re working on our hypothesis, and yeah, we could be completely off base, but that’s the whole reason why we use hypothesis and we validate or reject them.
Derek Featherstone: Absolutely. It’s gotta be part of everything I say this, and it’s totally a soundbite, but people come to us for testing of their product, whatever it may be. They come to us at the last minute. Once.
Amber Hansford: Yup.
Derek Featherstone: And they generally don’t do it again because they realize, wow, we really missed the boat here. They say, “we’re launching in two weeks”. Like maybe you’re not actually, because I can pretty much guarantee you that we’re going to find hundreds of things. If the first time you’re talking about it or thinking about it is two weeks before launch, you can almost guarantee there are going to be hundreds of accessibility issues, right? So it’s critical to have it built into everything from the very beginning, throughout the entire process, from like, you know, the initial concept and discovery, all the way through to its design and ideation, design iteration, development, and development iteration, and all those different prototypes and functional version of it. Accessibility has to be part of it at all, or should be part of it all, in like an ideal world and in a non-ideal world. Okay, let’s maybe not have it at every single stage if we can’t manage to make that happen, but please let’s not make it so that the first time we’re thinking about it is two weeks before we’re launching it. We’ve got to do something earlier than that, anything.
Amber Hansford: And honestly it needs to be a team sport. All of the different disciplines need to be taking it into account. I’ve seen it before where it’s all on development’s shoulders, or it’s all on design’s shoulders. It’s very rarely on product’s shoulders, from what I’ve experienced.
Derek Featherstone: I will make a controversial statement: It should be on product shoulders an awful lot more than it is. I think that Product Managers and Product Owners taking more responsibility for accessibility will lead to a much better outcome in the long run. Because who has influence over the product direction and roadmap and vision and strategy? Product managers in many ways are extensions of the people that are writing the checks and, and that are connected well to the stakeholders for that product, whether they’re internal, like business stakeholders or customer stakeholders, the more that product is on board with accessibility, the better outcome we will have when it comes to creating a product that is actually accessible and meets the needs of people with disabilities. It has to happen. It doesn’t happen enough though. It just doesn’t. Accessibility has traditionally been the domain of the engineer. And if we’re lucky we have design-related conversations to it. Most people, when they think of accessibility in the design side of things, they think of color contrast, and they think of color contrast. And oh, they think of color contrast as well.
Amber Hansford: [Laughing.] Yeah, that’s about it.
Derek Featherstone: But, there’s so much more to it. They’re thinking of the visual design side of it. And you know, there’s other, other pieces to it, like using color to convey meaning and, and choosing, you know, typography styles and implementing focus styles. And I get that. They’re all important parts, but one of the most important things that designers miss is they’re not thinking about accessibility as it relates to interaction design, they’re only thinking about visual design. So I’m a big believer that keyboard behaviors, for example, should be designed and not purely engineered, right. They need to be designed, and when the designer says, “Yeah, I need more time to work on this because I really need to map out how we’re going to handle keyboard navigation in this particular thing that we’re building”, the Product Manager needs to know how valuable that is and why it’s important. And even though it’s going to take that designer six extra hours to work through that, it’s going to save them 38 hours down the road, because they won’t have to deal with those accessibility bugs that are going to eventually get logged. They’re not going to have to go back and now think about it. And it’s going to save on the time that goes between the designer and the developer where they’re arguing about or don’t agree on, or are simply just trying to work through what the keyboard interaction should be. You know, that six hours up front, even though it seems like, oh, that’s preventing us from doing something else. It’s actually critical to do that so that you have more time later for all of the other things that you need to do. Those six hours are really well-spent because they’re going to save you 32 hours of rework and pain down the road.
The more on board that product is with understanding accessibility, the better. I even teach product managers and product owners, how to do simple things like keyboard testing, because they should be able to know and be able to determine whether or not their team is hitting the mark. And we’ve got a definition of done that says this thing is accessible as part of it, whatever in whatever level of detail is in there. A Product Manager should be able to, or should have the ability to, check on some of these things. And so I teach Product Managers, Product Owners, how to do basic keyboard testing, how to do basic form field testing so that they know whether or not the form fields were done right. So that they know whether the error messages are correctly associated with the field.
We’re great at putting error messages right underneath the field so that visually they are in proximity to the field that they’re connected to, but we have to make that programmatic connection too, and if you don’t do that, we miss out big time on accessibility. So, Product Managers and Product Owners need to know this stuff and they need to be able to check it really quickly too, to know whether or not something is slipping through the cracks or whether or not the team has done the work.
Did we even meet the definition of done? If it’s not keyboard accessible, we didn’t meet the definition of done. And I don’t know why you would ever have something not keyboard accessible meet the definition of done, but ultimately nothing should make it to production or be released that has major keyboard blockages or things that you just can’t do with the keyboard in it. Product Owners and Product managers need to know that stuff has to happen.
Tammy Bulson: So Derek, we’re hearing you say that, “Hey, we shouldn’t wait until the thing is ready to roll out to get it tested”. So on the podcast, we talk a lot about when we do discovery and we fall in love with the problem that we want to have user personas that we empathize with to help make sure we’re building the right solution. Should companies have user personas that represent people with disabilities?
Derek Featherstone: I have seen personas that represent people with disabilities actually fail spectacularly because the focus then is on the disability and more on the disability than what those disabilities mean from a functional need perspective.
So the distinction that I’ll make is when we create a persona, we would not want to create “Here is Raja, and the person that is blind and uses a screen reader.” It’s going to be, “Here’s Raja, a marketing campaign manager, that happens to be blind and his functional needs are things like this. Here’s the way that he’s thinking about problems”.
It has to be about any of the disability related things that create specific functional needs for it to actually be useful when it exists as this is the blind persona, this is the whatever persona, the deaf persona. This is the person that uses a mouth wand. It all becomes suddenly about their technology and the things that they’re using to do the work and not about the things that they’re actually trying to do using that technology.
So when we’re incorporating accessibility needs into personas, we tend to make it so that it’s actually one of the contributing factors to that overall persona, not the entire purpose of the persona. Because what ends up happening when it’s the entire purpose of the persona, we ended up with here’s eight personas. Well, based on population, we’re going to have one of those eight personas, be somebody with a disability, that now becomes a thing where it’s really easy, just like a story in the backlog, it becomes really easy to just deprioritize that persona. What I think is more radical and most effective; I believe that, in many ways we should only do usability studies with people with disabilities.
We don’t need to do usability studies with people without disabilities. And here’s why…this is a hypothesis that I would love to test at some point. But when we have done usability work with people with disabilities and people without disabilities, every person with a disability found the same general usability related issues as the people without disabilities found, except they found them faster. They were much more pronounced and easy for us as facilitators to key into and to see. And they were more vocal about being blocked on some things. If you think of disability as an amplifier of usability related issues, we might see something that slows. And again, I have, well, I have my reading glasses on, but generally speaking, I don’t have what you would consider a visual impairment.
I’m not blind or have low vision, so I can generally use something visual, no problem. And it might, some particular usability issue, might slow me down by two seconds on a task and therefore, because it was only two seconds, I might not think anything of it at all. But for someone with a disability, that might actually slow them down by 30 seconds or 90 seconds or five minutes, and might actually be, you know, much more significant.
So that’s part of what I mean by it’s easier to recognize. And sometimes those things are pure accessibility issues, but in many cases it’s straight up usability issues that impact people without disabilities as well. And that was all part of my hypothesis to say it would be really useful and maybe even interesting to only do usability studies that include people with disabilities.
The second part of that is, I wonder how useful it would be if we only had personas and all of them incorporated functional needs of people with disabilities in them. And we just built that into everything. I don’t think it’s disingenuous to include power keyboard usage as a functional need on a data entry clerk persona. I don’t think it would be a stretch to say that somebody that is an insurance agent that is taking an application over the phone and collecting all that information. It is entirely fair to say that they need really good keyboard access to that application that they’re working on. Well, it just so happens that that keyboard access need is a functional need of almost every person that’s blind that I know that happens to use a screen reader. So those functional needs are what needs to be represented in those personas.
I pushed back on people when they say things like, oh, we should have personas of people with disabilities. You don’t necessarily need that. Yes, people with disabilities should be represented in your personas. A hundred percent. But we don’t want to make it about the disability. We want to make it about the needs that they specifically express when we’re interviewing them and how that shapes their functional needs and their thought process and their decision-making process and incorporate those things into the personas.
Tammy Bulson: That makes perfect sense.
Will Sansbury: It’s interesting to me to think about the way we got to personas as a design tool in the beginning, right? We went through this great awakening recognizing we need to be human centered in the way we approach things. And so therefore we talked to a bunch of people, we’d understand them, and then we’d reduce them down to this one pager.
And one of the things I hear you saying that is the call of inclusive design is recognizing that humanity doesn’t fit on a one pager. There’s so much diversity out there that the fear I would have is if we tried to go and spot disabilities and two different personas, we’ll hit a tiny, tiny, tiny fraction of the reality we need to be looking at.
How do you, especially when you’ve got teams that maybe aren’t as accustomed, maybe they don’t know anybody who’s blind, maybe they’ve never been around anyone who had mobility impairments of any sort, how do you get teams to be aware of this? How do you get people to pay attention? How do you get people to see it? How do you get people to recognize that the world is a lot bigger than their experience of it?
Derek Featherstone: Really, really good data. And I don’t mean data as in numbers. I mean, here is somebody with this disability. Here is this autistic person, here is this deaf woman or a blind gentlemen or a somebody that uses dragon naturally speaking, because they’ve got really bad carpal tunnel syndrome and so they’re using voice control. Here’s a video of them struggling with other products that aren’t accessible. Here’s them using our competitor’s product. Here’s them using our version two from two years ago. And here’s them using version three from one year ago. And here’s video of them using the version that we’re about to release next month.
Look at this change, that kind of data and storytelling, I’ll call it what it is, like that’s storytelling, and that is powerful and useful and transformative. And for many people emotional and uncomfortable. I’m really comfortable with that discomfort, like really comfortable with that discomfort, letting that sit and percolate as you’re working with the team and seeing their reaction to what the experience is like. There’s a very fine line here too, between empathy and sympathy. So we’d want to obviously be on the empathy side rather than the sympathy side. So I’ve had a lot of people that talk with me after they see a screen reader demo and they’re like, well, that experience is just horrible. They should re redesign the entire screen reader experience. I’m like, that’s not the purpose of what we’re doing here. Right. That is shocking to you because you’ve never heard a screen reader go at full pace before, or you’ve never heard a screen reader at all before, so it’s shocking to you, but that is the regular everyday experience and people with disabilities, people that are blind that use screen readers use that all the time don’t pity them because they have to listen to that. That’s how they get their work done. So let’s focus on that. This is a tool that they’re using. That line between empathy and sympathy is really, really fine. So there’s a lot of things you need to do in the presentation of some of these things, a lot of framing up of the conversation before you just go and show videos.
And that’s the main reason I mentioned that is, I just, I don’t want people to say, “Oh, Derek said go get a bunch of data. Here’s some videos of people with disabilities using our competitor stuff and our stuff”. You have to do the work before that, to set that up so that they’re taking from it, the things that they should, that lead them in the direction of empathy rather than sympathy. Data.
Will Sansbury: Yeah, that makes a ton of sense. The other thing I’m thinking about is other place in the business world that we hear inclusion is in the realm of diversity, equity and inclusion. And I’m curious from, from your perspective, working with companies and helping them to be better at inclusive design, do you see any correlation between companies who have diverse workforces and workforces that include people with disabilities and their ability to produce inclusive design and doing inclusive design well?
Derek Featherstone: Oh, here’s an interesting thing. This is fun. I’m glad you’re asking these tough, tough, tough questions. So first lots of orgs that are saying, you know, we believe in the Eni diversity, equity and inclusion. Lots. Lots. You will also see many of those, not all, but many of those organizations not even mentioned disability as part of that diversity. They tend to be thinking, when they’re thinking diversity, equity and inclusion, most of it comes from an HR perspective, which tends to be about racial diversity and ethnicity, gender, and gender identity. Occasionally we’ll see something represented in terms of inclusion or diversity with respect to age and ageism. We don’t see a lot of that, but it’s there in some cases, but there’s still lots of places that don’t even think about disability as part of that diversity equity and inclusion aspect.
So a lot of our work and the work, the advocacy work too, to some extent, but a lot of that education work too, that we do is encouraging teams to diversify what they mean by diversity. Because we take this incredibly, and I’ll backup even here for a second, I’ve done this. Like, I’ll put my hand up. You get in your mind of what we mean by diversity. And you have a picture in your mind of what that is. You are going to forget somebody. It’s going to happen, right? That’s common. It’s natural. It’s going to happen. And that’s why it’s called work. We have to work to include people that we are often forgetting or not thinking of, or have unintentionally or intentionally excluded.
We see people with disabilities left out of that discussion a lot. Now I’ve done such a good job of giving you the preamble to the answer, to the question I’ve forgotten what the actual question is. What was the other part of it?
Will Sansbury: [Laughter}. It’s good stuff. So that’s okay.
Derek Featherstone: What was the follow up to that? Cause I remember I wanted to answer something else, but I’ve forgotten what it is.
Will Sansbury: So I’m really curious. So you see the teams that have diversity with folks with disabilities in their actual team. So they do inclusive design better.
Derek Featherstone: Yeah. That’s an incredible question. I haven’t seen a lot of teams that have a lot of diversity in their teams to begin with that include people with disabilities.
So sure there are some teams out there, but here’s what tends to happen. And I’m going to say this, and this is going to sound like a condemnation. It’s not in any way, shape or form. This is natural. This is common. This is what happens. We see somebody with a disability that gets hired by an organization, right? And they happened to be technical there some way shape or form, very digitally literate. And it’s a, mostly a digital age that we’re in any way. So that’s very natural. Then what happens in many cases is diversity means we have made this work for that particular disability, that, that one person that we hired has.
So we hire somebody that uses a wheelchair and maybe uses a switch device to operate things. Our understanding of accessibility becomes, make things work for Jim that happens to sit in a wheelchair and has a switch device mounted on the head rest of his wheelchair. It could work, but it tends not to because what ends up happening, where we have one or even two people in the organization or whatever number it is, I know we’re talking about different scales of organizations too. Like in an organization that has a hundred thousand employees, we would expect like, you know, thousands of people with disabilities. So it’s not going to be just one or two, but I’m talking small for a moment. We have two people with disabilities that are represented on the team, we’re very likely to become more in tune with those disabilities that they represent or that they can speak for because of their lived experience.
So I don’t know that teams that are diverse and that include people with disabilities by default, produce better and are more inclusive. I see a lot of people advocating to make inclusive design better, we need to hire more people with disabilities. How about you need to hire more people with disabilities that is independent of whether or not we’re practicing inclusive design.
In fact, I have like different measures of depth in terms of inclusive design. And so like the very surface level is we included people with disabilities at the end to do some testing and get their feedback and make adjustments based on that. There’s varying degrees of depth, that at the most depth that we get to, we actually start talking about inviting, not just feedback, but inviting people into the process from the beginning and engaging as co-creators and co-designers.
That’s like the depth that we want to get to. And there’s all kinds of variation in between. Somebody said on LinkedIn the other day to me, and the next level of depth is hire people with disabilities. Like. I get what you’re saying, but those two things are separate. You should absolutely hire more people with disabilities.
You should not just hire designers with disabilities and testers with disabilities or, and the default position for most, ends up being, we’re going to hire some testers with disabilities. We should hire managers with disabilities. We should hire VPs with disabilities. We should hire interns with disabilities.
We should hire every possible position, more people with disabilities to make an actual impact. Part of the reason that I’m saying all of that is… I don’t know that having a more diverse workforce definitely equates to a better inclusive design process. In some cases, if I was a designer, I’d practice inclusive design, I do my own little things every once in a while that I’m engaging in a particular topic or subject, and I have a disability.
Most people can’t see my disability. I always say this too. I was born with a club foot. I actually still have it. Right. I don’t know why I say I was born with it. Like I don’t have it anymore. I have a club foot. Now I had surgery at three to release that club foot and make my leg mostly straight to my foot, mostly toes pointing forward. I’m only getting to the point now as I’m 50 years old, where my leg starts to hurt a lot more now than it used to. It’s weaker than the other one. It’s always been weaker, but I’ve always been active enough that it didn’t really bother me. But now as I’m 50, my ankle is less fact flexible. That works its way up into my knee, into my hip, into my then and into my back and my shoulders. And so now, as I’m 50 years old, it’s actually starting to bug me a lot more than it used to. And sometimes it’s actually quite painful. I understand that disability. That doesn’t mean that I am good at understanding the lived experience of anybody else’s disability.
And so the notion that somehow, including other people with disabilities, as part of the design team, that doesn’t necessarily guarantee inclusive or more inclusive designs. And it’s impractical to think that we’re going to have a design team that has 150 people with different disabilities on it. So that we’re well-represented.
So I think, you know, to make a very short story actually quite long, I don’t know that it actually correlates. I’d like to think that it does to a certain extent, but I don’t think we can stop there. I think we have to see that if we have people with disabilities as part of the team in any organization, whether they’re part of the design team or they’re somewhere else in the organization, that’s still only gives us that lived experience.
And doesn’t give us what I would say is all of the lived experience that we need in order to create something that is more broadly inclusive from a disability perspective. So those are my very long thoughts on that. I love that question. I’ve been kind of aching to answer that for a little while because the thoughts have been percolating around in my head.
Even if we have a designer who happens to be color blind, right, or has some other disability. Cool. That’s one little tiny aspect of lived experience. They might be more open to, and considering other people’s lived experience, but it certainly doesn’t guarantee it. I know lots of teams that have people with disabilities on them that still don’t practice inclusive design.
And that’s still don’t produce things that are really broadly accessible and inclusive. I’d love to think that it would help, but even if it doesn’t, we should just hire more people with disabilities in general anyway. So long rambling thoughts, hopefully coherent and cohesive.
Will Sansbury: It’s good stuff man.
Amber Hansford: We as human beings have a bad habit of caricature versus actually listening and that practicing of active listening takes that caricature and makes it real.
It’s always been a problem that I’ve seen with some times of trying to get product people and others within the product teams to empathize versus that fine line of that sympathize versus empathize. It’s very easy to jump into caricature of the people that you’re trying to actually help with solving their problems.
There’s no easy solution. I’m going to completely crib off of you from now on Derek. Of, you got to do the work and it’s not going to be easy no matter what to get past that.
Derek Featherstone: A hundred percent. That’s literally it. Like it’s hard and that’s the point. Like that’s actually the point, is that this is hard to do.
Amber Hansford: No magic wands out there. Yeah. No magic wands out there at all.
Derek Featherstone: Yeah. There are none. There are none. And that’s also part of the reason that I, there’s a natural inclination for most product teams that I’ve worked with. They feel like the first thing that they should do is go out and hire 10 disabled testers. Nope. And we see people with disabilities all the time and people advocate like, oh, we should go and talk to so-and-so who’s on this team or that team that has a disability and get their input on it.
Like, Nope, stop it. You can do that as part of your interviewing process. Maybe. Especially if it’s an internal employee facing product or problem that you’re trying to solve or dig into. You got to go outside. It has to be customer facing whatever those customers are. Your people inside have: A. They have too much domain knowledge already to be a good, useful interview to get the right perspective and B: Stop putting the work on them.
They are a manager or they are a, an accountant or they are a whatever they are. They are not here to be part of your group of testers. That’s not what they were hired for. Now, there’s some people with disabilities that are super excited to be accessibility testers. And so that’s not to say we should never have people internally doing accessibility testing with people with disabilities. But for many people, that’s not what they’re up for. They are not there to do the work that you’re supposed to be doing.
Amber Hansford: I love this. I usually call that the curse of knowledge for that insider. Most of my team gets sick of me talking about, no we’re suffering from curse of knowledge. We need to move outside.
Derek Featherstone: Totally. Totally.
Will Sansbury: This is interesting because I think one of the things that you’re hitting on with inclusive design here is, I think people run that risk of, if you take a step and you miss the mark, then you’ve certainly done something morally evil by excluding someone. It’s practicing the same discipline we have as Product Managers. It’s being open to being wrong so that you can learn from it and be right next time. If we just follow that process, let that kind of agile iteration, inspect and adapt, be there to drive us, then we can get something good for everybody.
Derek Featherstone: A number of years ago, I did a talk called Where Accessibility Lives. And if I were doing that talk now I would think of it differently. But one of the things that I brought up in that talk was that accessibility within the tech industry has for a long, long time been expecting perfection.
When really what we should be thinking about is better, rather than perfection. So that simple framing of even to the point where I’ve talked with teams, where they have said, literally, we only get one shot at this. I’m like, nope, you actually have a lot of shots at it. And so when you’re looking at it with that approach, we only get one shot at it, you tried to solve all of accessibility at once and you overwhelm the people that need to do the actual work to execute on it. But if you take a much more agile lean type approach, we’re going to implement some things. We’re going to inspect. We’re going to adapt. We are going to continue that in cycles and continually get better.
It feels so much lighter, right? Accessibility feels lighter. And you know what the cool thing is when, when accessibility is like all or nothing, there’s a 99.999% chance that you’re going to fail, right? When accessibility is about getting better than we were before, both in the product and in the process that we’re using, your 99.999% sure that you are going to succeed. Because small increments of improvement are really easy to envision and to execute on.
So that whole concept of, like you said, the misstep that equals morally evil status is entirely based on the mindset of, we only get one shot at this and if we don’t do it right, we are bad people. And that, I mean, that’s got to change. Right?That, that has to change.
Will Sansbury: We just can’t break that waterfall thinking it’s going to haunt us for decades I think.
Derek Featherstone: It will. It absolutely will. One of the biggest mindset shifts that we work with product teams on is getting them to understand that they should apply agile principles to accessibility. They intuitively get it because it makes sense. They don’t know how to execute on that though. They don’t understand that a definition of done for accessibility for right now might be different than our definition of done for accessibility 18 months from now.
And as the team continues to learn more, that definition of done might change again three years from now, right? That concept hasn’t crossed most people’s mind because they are thinking of accessibility as like, it’s accessible or it’s not. And it doesn’t work like that. There’s a continuum. So a definition of done for right now might be that as we’re learning and getting started with it, nothing with a seven or higher severity level for an accessibility issue gets released.
And that’s part of our definition of done. That’s not the entire definition of done from an accessibility perspective. But, that’s now. And in 18 months, when we’re getting better, we might change that number to a six or higher. And as we get better three years down the road, maybe it’s changed to be four and higher. That can change over time and applying those ways of thinking to accessibility is really, really useful.
It gives you permission to start in the middle. It gives you permission to fail. But it encourages you to make progress, to get better than you were before. So even though you’re not hitting, and of course we wouldn’t want to release something that is missing, like some really key parts.
We would say like, there’s nothing of a severity level of seven or higher that makes it into the release. And there’s no automated errors that show up in our reporting. And there are no keyboard related issues at all. And we might say something like, when we do, maybe this is down the road, like 18 months from now, where we adjust that definition of done to also say, all key task flows, scored a 3.5 or higher out of five when we did the usability study with people with disabilities as part of it. And that kind of stuff gets built into our definition of done. So that we can look at this product carefully and say, does it meet these requirements or not? Can this be released building those things in? I know that takes time and effort and it’s new and people will say things like, “You mean accessibility can block a launch?”
Like, yup. It can. It could. Depends on how you want to take it. And so for right now, you might have only a true accessibility blocker will block a release right now. Well, we have to define what that is and the definition of what that is, might change over time. It also might not. Part of the key to it, to me, is if we’re applying agile principles to accessibility and how we operationalize that through the work that we’re doing.
It’s that same constant implement inspect and adapt cycle. People should be revisiting their definition of done every three months in light of the things that they’ve learned about accessibility over the last three months. And they might say, Nope, we don’t need to make changes. We’re actually good with the definition of done as it is.
Or they might say, wow, we released a thing. This part was horribly inaccessible and we completely missed it. That actually does require or should necessitate a change.
Amber Hansford: I will say that I absolutely adored our conversation, Derek. It has been so amazing, not just to see all of the touchstone points that we talk about on a regular basis, being displayed for inclusive design and accessibility.
But also, I feel like we have found a kindred spirit. Thank you so much for coming out.
Derek Featherstone: Well, thank you. And let me say, as you can imagine, I can talk about this for a long, long time and would love to do so. If you ever want to have me back on again and dive deeper, let’s do that. I’m all in.
Amber Hansford: I love it. I love it. We will definitely be talking more about when we can get together again and chat more cause this has been an amazing conversation. Before we go, where can folks find you online?
Derek Featherstone: So the two best places are Twitter, I am @feather on Twitter and LinkedIn, find me there, Derek Featherstone on LinkedIn. I’ve been publishing a lot more there these days, because it’s a little bit easier to go a little bit longer form content there that then I can in 280 characters on Twitter, pretty active in both places, having to connect with people there and they can see the things that I’m working on and the things that I’m thinking about if they’re interested in and I hope they are. It’s fun. I have fun talking about the things that I, that I talk about. So thank you.
Amber Hansford: You are one of us. We love to geek out about this. It’s just, it makes our heart happy. I mean, we created a whole podcast just so we could geek out about and stuff like this.
Derek Featherstone: Indeed. Indeed.
Amber Hansford: Well, thank you so much again, Derek.
And thank you so much for listening to us out here on the podcast. If you are interested in hearing more, or you have a topic that you’d like for us to cover, check us [email protected] and find us on any podcast provider. Stay gold outsiders.
Will Sansbury: Stay gold.
Tammy Bulson: Stay gold.
