Design needs inclusive research
Your UX designs can only be as inclusive as the research that supports them.
When I was working for Uber, conducting research on the travel experiences of blind and visually impaired people, I met Marie (not her real name). Marie invited me into her home and, around her kitchen table, told me stories of all the transportation challenges she deals with: finding the bus stop and getting on the right bus, getting off at her stop when the announcements are broken, finding a specific car on a busy street, figuring out how to navigate the Uber app without being able to see it. Marie articulated one of the most important insights in all my work:
“I understand, you know. [Uber is] not designed for people who have a vision problem.”
Marie, trying not to hurt my feelings, did not want to be too critical of Uber. But clearly, from her perspective, the company left much to be desired. And she recognized that the problem she has in using Uber is not a problem with her vision, but a problem about Uber’s design.
Indeed, during the course of my research, I learned about all sorts of design flaws and defects that make it challenging, if not impossible, for blind people to use Uber’s app and service. Things like defects in the way VoiceOver (Apple’s native screen reader) interacts with the app, elements that were not properly coded for accessibility, challenges in the real world finding a car and navigating to a destination, and the ever-present difficulty of drivers illegally denying rides to people with service dogs.
Uber’s product was a real mishmash of accessibility flaws and defects, but how did it get to be that way? Neither the company as a whole nor any individuals set out to exclude blind people from using Uber. But equally clearly, there was no real effort to make Uber inclusive and usable by people with diverse abilities.
Building an inclusive design requires buy-in from people throughout the design process, from executives defining accessibility as a priority, to designers who create designs that can be used by a broad variety of individuals, to developers who know how to properly code accessible software. But inclusive design must start with UX research, because UX researchers are the people who best understand the needs of users. And for UX researchers to effectively represent the needs of blind people, or Deaf people, or people in wheelchairs, or anyone else, they must include those people in their research.
Said simply: Inclusive design should be everyone’s goal, and inclusive design demands inclusive research.
Inclusive Design and the “Mismatch”
Inclusive design rests on the notion that disability is very often a design problem. By no means always — we should not diminish the very personal impacts of both physical and cognitive impairments — but there are a huge number of times in which “disability,” far from a personal impairment, is a “mismatch” between a person and their environment.
Kat Holmes describes a mismatches as “barriers to interacting with the world around us. They are a byproduct of how our world is designed.” When a person in a wheelchair encounters a building with stairs at the entrance; when a blind person tries to order a pizza on a website that is not accessible to screen readers; when a sighted person tries to use their smartphone in bright sunlight and cannot see the screen — these are all examples of mismatches. In each of these cases, the problem lies not in the person, but in a designed environment (a building, a website, a phone) that excludes the person from using it.
Potential mismatches are all around us, and they go unremarked upon by the majority of people for whom the built environment does not create a mismatch. A person who can climb stairs might not realize that their workplace is not equally accessible to everyone; a sighted person ordering from Domino’s would have no reason to suspect that blind people cannot use the site.
At the same time, mismatches like the smartphone in sunlight seem to get much more attention (the iPhone’s adaptive contrast feature) because they are problems for a lot of non-disabled people. And this is the business problem with addressing mismatches: when they affect a large number of people, they are easy for companies to find and fix, but when a smaller number of people are impacted by them, they are written off as “edge cases” without much relevance to the company’s bottom line.
(Of course, this is absolute nonsense. The CDC estimates that 26% of Americans live with a disability, and a 2018 study estimated that those 61 million people have a collective disposable income of almost $500 billion. This is not a small group of “edge cases”; this is a substantial group of potential consumers who are being systematically excluded from spending their money by companies who don’t make inclusive products and services. To wit: Domino’s reportedly estimated that it would cost $38,000 to make their website accessible, but instead, they undoubtedly spent many times that amount arguing before the U.S. Supreme Court that they’re not interested in getting the money of disabled would-be customers.)
Thus, designs are driven towards being inclusive only to the extent that they include the core users that companies consider “normal” — which is to say, they are not inclusive at all.
Inclusive Research
Jutta Treviranus, in an insightful discussion of inclusive design, places users into three categories: those for whom a design works, at the core; those for whom a design is hard to use, in the middle ring; and those who can’t use a design at all in the outermost ring. She notes that for a design to be “inclusive” it must include the users in those outer rings . I argue that in order to include those users, companies need to do a much better job of including their perspectives in their UX research.
The UX research operations at many large companies are superb at learning about the needs and challenges of their users. The problem is that they tend to focus only on the core users, those for whom a design already works fairly well. Think about the iPhone users who had trouble seeing their screens in sunlight: these are sighted people who already could use their phones. A mismatch arose in one very specific situation for these people, and it surfaced for Apple because it affected a large core group of customers. (To address the problem, Apple introduced auto-brightness in iOS 11.)
Unfortunately, working in this way will not result in an inclusive design. Sure, it is important to address user challenges like the screen brightness, but there are almost certainly much bigger issues lurking in your designs, if only you dig a little bit deeper.
For instance, when I was interviewing blind and visually impaired people about how they use Uber’s services, I learned that the Uber app’s VoiceOver coding was remarkably inconsistent. Images were missing alt texts (which results in the image file name being read aloud); the focus order was not always intuitive; and occasionally things were not accessible to the screen reader at all. These sorts of defects make their way into a product because of inadequate procedures for designing, coding, and testing accessibility features — but that lack comes from inadequate user testing. The defects I found would have surfaced in any number of other contexts if only the company had made more of an effort to include blind users in research and testing.
Conversely, inclusive research can lead you to inclusive solutions — solutions that make a design work for people with disabilities and, very often, for all your users. For example, one consistent pain point I observed with blind Uber users is that they have difficulty locating their ride when it arrives to pick them up. One reason for this difficulty is that Uber’s app does not provide enough useful information to people who can’t see the screen. Sighted people can learn about the driver and car that will pick them up, see the car’s route updated in real time, and see the estimated arrival time.
However, a blind user with VoiceOver enabled only gets the ETA. (Actually, that’s not strictly true: VoiceOver will read out information about the car, like the license plate and color. But since the user cannot see the car, the information is useless to them.) But there is an easy and inclusive fix: code VoiceOver to provide the distance of the car from the pickup and tell the rider which direction the car will arrive from. These two pieces of information were consistently requested by the people I interviewed, and it would be remarkably simple to add them to the app design. And, most importantly for inclusive design skeptics, you can add this information and make the app accessible without changing the visual design at all.
Inclusive Design from Above and Below
Making a UX research process more inclusive is not an easy challenge to solve. Researchers work on short time frames and need to deliver insights on tight deadlines. At a company without procedures for recruiting participants with disabilities, these time pressures make inclusive recruiting almost impossible, and researchers who do care deeply about the exclusiveness of designs are nonetheless strongly pushed away from inclusive research practices.
Then there is the challenge of how to find disabled participants to interview and observe. Often this demands a specially tailored recruiting process, since companies typically don’t have this information in their databases of users (and for good reason, since it can lead to discrimination). At Uber, I worked with a colleague in research operations to approach local organizations that provide advocacy and assistance to people with visual impairments. This worked well because I knew I needed people with a specific disability for my research. However, I am currently working on a more general accessibility assessment, and that sort of method would be unwieldy. So instead, I am using a more process-oriented approach, using a screener to learn about how potential participants use various technologies (both assistive technologies and more ubiquitous tools).
Therefore, for a company to work towards inclusive design, its executives need to define inclusion as a corporate value and actively promote its integration into design, production, and research processes. It is not enough to say that a company values inclusion or accessibility — every company says this. It is important that companies take positive action to promote inclusion in the day-to-day work of people throughout the organization. For accessibility, this means that
- developers need to be trained in how to code accessibility features and given time to make accessibility part of their regular work;
- designers need to understand the principles of inclusive design, which includes not only visual design but also sound, writing, and other modalities that can potentially include or exclude users;
- and researchers need to understand the needs of diverse users and be given the time and support to develop research that represents truly diverse populations.
Ultimately, UX researchers are the people in an organization who must take the lead in promoting inclusive design by making their research practices inclusive. Researchers are the people who are most closely connected to a company’s users and who best understand their needs, their desires, and their obstacles. Researchers are empathetic by nature and by training. They feel the frustration and pain of people who are not able to use a product or participate in an experience, and they are best equipped to advocate strongly and convincingly for designs that include rather than exclude.
