Prioritizing Inclusion
As an agile and lean user-centered design consultant, I’ve come across my fair share of enterprise and startup teams who want to make software development a core competency. I’ve seen how lean and agile practices can enable teams to tap into the power of collaboration and leverage their expertise to autonomously solve problems. As companies transform to adopt the highly collaborative lean methodologies, a few really exciting things happen. The teams take on more ownership, leverage their expertise, and open themselves up to rapid experimentation. Over time, these characteristics are woven into the fabric of the broader team, which becomes an efficient prioritizing machine, learning to pay attention to the ideas that have the most value.
However, there’s often a costly and exclusionary side effect that can result from the ruthless prioritization of lean and agile. In an attempt to get the MVP out quickly, the team prioritizes just enough features to satisfy the target user. Here’s where the problems start.
Who is the “target user” exactly? Often, it’s a persona based on normative assumptions. This is to say, we assume that everyone else is just like us. For example, if you have perfect eyesight and you’re designing a digital product, you’re likely to design your product for someone with perfect eyesight. These normative assumptions can get us in trouble because most of us designers tend towards normalcy when we build products. In lean, we often use personas—an avatar of a type of person we’re designing a product for. And these personas are often riddled with bias towards ability, disposable income, specific language, race, age, and gender. Other users with different abilities might have to expend additional effort to interact with our products, and at some point, that effort reaches critical mass and creates a complete barrier to access.
One billion people worldwide have a disability; with the older adult population capable of a spending power of 15 trillion dollars. About 1 in 8 people in the US have a disability, and those are just the people we know about. However, most of the internet and products we create are inaccessible and at the same time, we’re becoming increasingly dependent on technology. This is creating a technological barrier that not only creates a social divide—but an economic one too. You can see the manifestation of our society’s bias towards the abled reflected in employment rates. According to Cornell University, 79.4 percent of people without disability are employed versus 37.3 percent of people with disability.
If lean’s goal is to minimize risk and add value, then we need to address the negative economic impact of exclusionary design and begin retrofitting our teams and process for accessibility.
So What Can We Do?
As designers and technologists, we’re creating a new world in a digital medium and we need to minimize the chance of creating more problems than we are trying to solve.
It’s an exciting time for design. The demand to build products that reflect the needs of our diverse population is redefining how we evaluate our designs. With amazing research coming out of OCAD University and the work of Kat Holmes, currently the Director of User Experience Design at Google, more and more designers are beginning to embark on the valuable journey of building inclusive products that are accessible to more people.
However, this is a topic that’s still mysterious for most people building products. The evidence is reflected in the sea of inaccessible products and websites.. As people, tend to build without regard for disability, blind spots are formed that go unchecked, and ultimately leave accessibility issues to be addressed long after the product is built.
I wanted to find ways to assess my design that challenges my assumptions so I began to experiment with building inclusivity checkpoints and ways to incorporate inclusivity into my everyday design activities. I shared one of these frameworks at a workshop I facilitated in Seattle for Interaction 2019 and now I want to share it with you!
Make Accessibility Accessible To Your Teams
We can do this by expanding our knowledge. The most common accessibility issues can be avoided during the design creation process. If we bake inclusion into our process by training our team of designers and developers in basic accessibility, we won’t need to then try to make a case for it to be prioritized in the backlog.
Be Aware of Your Assumption Blind Spots
Declaring and evaluating our assumptions is the cornerstone of Lean. It gives the team confidence that what they’re building is, in fact, the right product. But what happens when our assumptions are based on our world view? How might we ensure we include assumptions that might not even be on our radar?
One effective way is to challenge your assumptions about your target user and the scenarios that you are optimizing your product for. You can use this information to get clear on your product intent. This will give you clarity about the diversity of the needs of your users. A great resource is the Microsoft persona spectrum by Kat Holmes.
Build Inclusivity Into Your Design Activities
It will take time and attention to train new accessibility muscles. We are so used to designing products for people like us. One method that I’ve been experimenting with is an inclusive customer journey. I’ve been using it as a diagnostic tool to identify the ways we leverage abilities that we aren't consciously aware of. You can also use it to dive deeper into assessing the accessibility of your designs. You may use parts or all of this to evaluate your designs through the lens of human limitations. Using this method and others like the Microsoft toolkit will get you more comfortable with thinking outside of our own abilities.
Step 1
Map out all the steps a user has to take to complete the task.
Step 2
Now for each of the steps mark the required abilities that a user needs to complete each task. This can either be colored in or checked off.
Step 3
Once you’re finished you’ll see a clear pattern for the most critical abilities needing to be taken into account to remove the barriers to access. For most applications, you will notice “see,” “touch,” and “think” are the most common patterns for required interactions.
*Tip: Designing for “think” or cognitive accessibility is not as obvious as other abilities. Considering the fundamentals of good user experience is a good start. You can review the principles for cognitive accessibility here.
For most digital products, core interactions will center around sight and touch. This particular experimental framework is focused on evaluating all the visual limitations that needs to be taken into account in your designs. There are a lot of ways to build accessibility into our designs and this framework can help us to practice designing with accessibility in mind.
Step 4
In the next two swim lanes, brainstorm temporary and contextual limitations that any user can experience when interacting with your designs. This can help you to think about all of the scenarios that may create limitations for your user. It also calls attention to the fluid nature of our abilities.
- Temporary = an injury or illness that results in periods of temporary disability
- Contextual = environmental conditions that result in limitations that are similar to a person experiencing a disability
Step 5
Now we want to dive deeper into the most common types of visual limitations. You will notice there are five swim lanes, each with an empty circle for each task.
You’ll use these swim lanes to test each step the user takes in your product.
Step 6
To get a better understanding of what users with different visual abilities will experience you can download Funkify. This is one of my favorite Chrome extensions because it allows you to simulate different disabilities. I want to call out: this does not replace the need to test with real users. Funkify is a tool for you to double-check your work– it helps you ensure your designs don’t fail the most fundamental accessibility considerations.
-
‘Blurry Bianca’ – view a web page through a foggy filter, similar to several visual impairments.
-
‘Color Carl’ – adds different color filters, conveying several types of color vision deficiency (the correct term for ‘color blindness’).
-
‘Elderly Ellen’ – combines blurred vision and trembling navigation.
-
‘Sunshine Sue’ – view your screen as if you were outside in bright light – without the possibility to go inside.
-
‘Tunnel Toby’ – simulates partial vision loss on the screen.
One by one, test each visual limitation for each step in the journey. Fill in the circle for each step that you can easily interact and see the information. Repeat this for all visual abilities.
Step 7
You’ll quickly see which parts of your designs you need to iterate on to allow for more access. As you go through each step you can write down any ideas that can improve the user experience.
By the end of your customer journey, you’ll see areas where your designs were inaccessible and need to improve. Once you become accustomed to looking at your designs under this new lens, you’ll learn to do build these considerations all on your own.
Redefine Good Design
As designers we are advocates for human needs. We have the power to break the cycle of exclusion and redefine what the world thinks of as “good” design. This will help us to shape the future of technology by creating an inclusive digital world.
Here are some resources that could help you start your journey today:
