In order to help our clients build great products for their users and to meet their business goals, our crew has to be informed about industry changes, trends, talking points, and innovations. One subject we're most excited about is the push for greater accessibility and inclusivity in product design.
In Part 2 of our internal training on inclusive design and accessibility, we look at one of our own mobile applications and how these principles can be used in everyday app development to build better products.
We've broken down this internal training presented by our own UX/product design expert and Mapping Lead, Kelli Lucas, into 2 parts (check out Part 1 here). But if you're in a hurry to scan key talking points, we also have the transcript below our 10-minute video. Enjoy!
https://vimeo.com/507590191
Transcript for Inclusive UX Design & Accessibility: Part 2
All right, so I said we were going to talk about an actual app of our own. So I chose Made, based on a thought experiment that our Shipwright team did while we were reading an excellent book called Mismatch. You can see on your screen, this is Patrick Anderson. He is considered the best wheelchair basketball player in the whole wide world. At the age of nine, he was struck by a drunk driver and lost both of his legs below the knee.
So we're going to put on our imagination hats and pretend that we are him. And you are training for the Paralympics, and you know you need to lose some weight. So you're are going to start checking your BMI, but you're at the gym, and you hear somebody talking about this great new app called Made. And how does this impact him? Before I even go on the next screen, how do you think that experience is going to go? Good? Bad? OK. We'll see.
I think it's going to go poorly, because BMI is taking into effect the average height of an individual, and basing that calculation and the fact that he doesn't have legs is going to distort his weight and his height calculation. And he's probably not going to get an accurate reading, and he can definitely tell it's not going to be meant for him.
Yeah, so I'm not going to go through the actual process of trying to scan an image of Patrick. But I wanted to just look at some of the screens that we built and see, even without adding budget, what exactly could we have done for someone like Patrick, who downloads the app and is ready to use it?
So on the very first screen, if I'm him, all right. I want to take a scan. Camera at waist height-- well, that's going to be interesting, because I'm in a wheelchair. Wear tight clothes. OK. Feet together-- well, that's a problem. No shoes. Nothing on my head, hair pulled back, OK. Entire body in frame.
All right. Well, I am already feeling like this is not an app for me, right? I am going to have trouble standing up. The instructions on the picture itself, it's like, arms by your sides, standing up, feet together, and I already don't know how I'm going to do that. So we had some kind of painful conversations in our Shipwright team talking about this, because we're like, all right, how could you actually still use this as Patrick?
So I think Tyler or Chris-- I can't remember who mentioned it-- but they were like, all right, well, you could lie down. You could lie down on the floor, and somebody could hold the camera up and take it. And, well, that's degrading, so that already doesn't really feel great. I have to lay on the floor in order to use this. That's unfortunate. Maybe could be done.
I don't actually know what would happen in that circumstance. If I do not have legs below my knees, is the app going to throw an error that's going to offend me? Is it going to be like, we don't recognize this human being. Try again. What kinds of error messages are we using? Just being cognizant of that stuff.
And then what happens with the actual scan-- can I-- is there another way to have input a picture? Is there-- are there any ways we could mitigate this? I don't know that there are solid solutions for this at the moment, but like I said, it's more of thought exercise to think, if we had to consider this at the very beginning, could we have just been cognizant of the language that we use?
Can you think of any other apps at Airship that would have benefited from the same thing?
I would say going-- taking this example a step further, it'd be interesting to hear how you would go about talking to a client about this, because after working on this project, the client was very, very specific and picky about the images and the assets that are used in this and also the verbiage. And so everything that's in the app was very much so combed over by them and, essentially, the words straight out of their mouth. And so I'd be interested to hear how you'd go about changing their mind about what to put in the app.
Yeah, that's a great question, Luke. And I don't want to overstate the impact that clients have on the things that we build. These are not our products. We are building them for other people. So all I ask of Airship is that we're bringing these conversations to the table when we first start talking to the clients, and it's throughout that process. Hey, what about this circumstance? Have we considered that? What if it's in bright light? What if it's raining? What if I have limited cognitive abilities?
And it's more just helping other people empathize with the strategies that we have at Airship in building better software. They're not always going to agree. If it comes down to budget, and we say, you really need closed captioning, and they say no, OK, well, that's still their decision. So I'm not, in any stretch of the imagination, saying that we should override what our clients ask for and want. Like I said, it's more of illustrating the possibilities and the market share that they can then get into, because from our conversation a couple of weeks ago, they wanted to start including elite athletes.
Well, Patrick's an elite athlete. So if you're marketing it to them, then he's going to have the assumption that this is also built for him. Well, maybe Patrick wouldn't, because I'm sure that he's been excluded from lots of things due to this. But I think it's mostly an educational opportunity for us. Does that help, Luke?
Yeah, for sure.
Anyone else?
I will say I was part of this mapping. It was like my first day. I shadowed this mapping with Danielle and the guys from Made, and we did have these conversations in our mapping.
That's great.
And so some of that was-- because, well, for one thing, I asked these kinds of questions, because my sister-in-law has a prosthetic leg. So I was thinking of that exact thing. I was like, what would she do? Like, her weight is very off balance, because she only has one leg. So I was thinking of some of those things, and we did have that discussion. This is kind of related.
This was where I was heading with that question I put in the chat about MVP was, for one thing, their algorithm that supports this doesn't support. It's built on the map that they gave us, and it doesn't support differently-abled or people with prosthetics or like your example. So that was one limitation that we had, and we talked about it as basically a limitation of MVP that they want to expand. So I will say it was-- I just wanted to throw out that it was discussed. It wasn't ignored but was more not feasible for MVP.
And yeah, I'm glad you brought that, Meg. I think it's very important that we have the discussions. We can lead a horse to water. We can illustrate to people that they are excluding by making decisions like this. I think as long as they're aware of the business impact of those decisions, I think that's all we can ask for.
We can certainly push. We can help people empathize, but ultimately, it is their decision. So I'm not, in any way, saying everybody is accountable to ensuring that this happens. It's more part of our process, part of our method of getting to a better solution. So we can only do our best.
I agree. I think this app was a really-- had a lot of interesting consultation points, because we had to ask questions like, OK, we're asking for biological gender. What do we do with people that are transgender? What do we do with children? We want people of a certain age to use this but not influence the body image that a young child might have.
So this app, because it has to do so much about your body, which is so personal, and everybody's bodies are so different, that it raised a ton of interesting conversations. And our client was really open to having all of them. If we pointed something out, they were like, oh, we did not think of that, but we should rethink it. So I felt like it was really-- a lot of times, it was a fun thinking exercise.
Yeah. I think that's what I like about this. It doesn't require us to do any extra work, just to think. So we can talk about-- there's actually part of the Microsoft Inclusive Design Activity Book. It's a PDF you can print. And there's a really nice page. I don't have it in front of me, but it just illustrates a few different temporary, situational, or permanent situations that people can have.
So even just having those visual references in the mapping kind of helps, oh, well, it's somebody with a new baby. They might need it one-handed. Just having those conversations is free. They can then decide where their budget needs to be spent, or it can be, yeah, that'd be great to have. Really important, but it's version two. But we can put it in the backlog for them.
So if anyone wants to see what those barriers are, so Kelly had a great graphic that she took from the Microsoft Inclusive Design Packages, and I put it in the UI/UX folder that we have in Quip. So if anyone's interested to see what the different types of barriers are and the different examples that we may include those barriers in whatever it is we produce or build, you guys can view that there.
Yeah. Thanks, Crystal. All right. All right. So last thing-- let me check time. We got three minutes. Perfect. This is a high level list of things that I would love for us to start doing. The full list is in the URL. It's in Quip, Inclusive Design Plan. But at a really high level, all mappings from now on will include one inclusive design activity. That's very related to what Crystal just said. She did one for the YM360 mapping. I included one in the groundworks mappings, so we're 100% on that OKR right now.
But like I said, it's free to include awareness and education as part of our mapping, so that is not costing us anything. The second bullet point-- all of our Airship team members are going to undergo some inclusive design training. Today was our number one. You can check this against your training for the week in Harvest.
Builders are going to be trained on writing accessible code. By no stretch of the imagination do I imagine that we're going to flip a switch tomorrow, and everything we build is going to be accessible. It is a goal. It's a long term North Star to get to, but please don't hear me say, tomorrow, guys, we're going to be checking for this, OK?
And then QA-- trained to identify and test accessibility issues. Like I said, that is a piece of the pie, but it's not everything that we're focused on. And then HR is going to focus on more inclusive and diverse hiring practices.
So those are the high level pieces of the plan. If you all have any recommendations, you feel like we've missed anything, please bring them up. Drop them in Slack. Send them to me, whatever you think.
