Inclusive Design Principles Require Inclusive User Testing and Empathy
Everyone is different. Yet so often, our personal challenges overlap. They become interwoven with others who are attempting to do the same things: buy a shirt online, get the local weather forecast, send money to a friend. In this way, we’re all the same, until the ability to do these things becomes basic privileges for some, and exclusionary for others. It’s at this juncture that empathy presents a path to inclusivity — and where software firms have the opportunity to implement inclusive design principles that unite instead of isolate.
Inclusive design principles stem from "nothing about us without us"
In his book “Nothing About Us Without Us,” James Charlton expresses the point that people with disabilities (PwD) know what’s best for them. This concept of including the people for whom decisions are being made in the process of making the decisions is not new. It has been traced back to politics in the 1500s in Europe, and is illustrated as a core component to the start of the American Revolutionary War - “No taxation without representation.” It’s a fundamental human desire — and should be a right — to be involved with the construction of inclusivity issues that affect us. If you’re interested in more on the chronology of persons with disabilities rights, check out this New York Times article, "‘Nothing About Us Without Us’: 16 Moments in the Fight for Disability Rights.”
But here’s the interesting thing. If we realize how similar we are in terms of our needs, we empathize. Suddenly we’re connected: I can’t see my phone in this bright daylight, maybe this is how a person with low vision feels when they look at their phone, or how an elderly person who just had eye surgery feels when working on her computer.
Inclusive design principles for software development organizations must spring from empathy
So what is inclusive design? It's a human-centric approach to how software development organizations approach design, a methodology. It begins with targeted PwD users in mind — not as an afterthought — from which you create personas that understand the needs and challenges of individuals. It’s much more than adhering to accessibility guidelines and checking off WCAG requirements, QA testing and dusting off your hands once. Most important, it’s an adherence to direct experience and feedback from PwD. It’s only through this direct contact with users where empathy is born. And this empathy can go a long way in creating truly exceptional experiences for everyone.
In the world of software design, every designer should create products that can be used by the broadest range of people. Yet all too often, designers lose their way; it’s understandable. Deadlines to get products out the door take precedence over high-quality inclusive products. But it’s not just pressure to release that creates hurdles for software designers. Too often, designers are isolated. They work in a vacuum, with little contact with the people they’re designing for. How could they possibly design a high-quality product for a living person about whom they know next to nothing? That’s why personas for PwD are a great starting point, but they can miss the mark.
Involve the targeted person with disabilities in design — early
What’s the best way to get to know someone? You bet, it’s sitting down with them and learning who they are firsthand. Inclusive user testing is a key component within inclusive design principles. To do this, first you must clear the slate of preconceived notions of who users are. Instead, based on direct contact, designers move away from what is “typical” and toward what is personal. Then, in time, global needs, gaps and solutions surface. Just as in any user research.
Any of us who have been fortunate enough to work in digital product design groups that begin the design process by engaging directly with persons with disabilities has seen the magic — and subsequent innovation — that emerges from this process. It’s truly inspirational. And once a designer knows a person, understands what pitfalls lead to frustration, embarrassment or the inability to complete what should be a simple task, there’s little room for developing a product that doesn’t address these issues. It becomes personal for the designer and their sense of integrity and honestly. A cycle of excellence follows. Here's an example of how the road to inclusive design principles begins with empathy:
My client had the goal of using inclusivity as a product differentiator. We set up an inclusivity/accessibility training bringing in one of our testers - a person with blindness. She reviewed an app my client was developing and found five issues that made it impossible or difficult for her to perform certain tasks. The engineers and designers witnessed firsthand how a person experienced difficulties with their apps: This made the issue real for the designers and engineers. Now, designers do accessibility annotations to aid in design hand-off to engineers. We have shifted left, involving PwD personas representatives early in the inclusive design process, not as an afterthought. This will in theory lead to fewer bugs because engineers are clearly informed of inclusive design specifications.
The inclusive design checklist
It's important to connect accessibility with people and usability heuristics. These are the key ingredients to inclusive design principles. In my work, we have five PwD personas: blindness; low vision; deafness & hard of hearing; upper body mobility; cognitive.
Let me illustrate the key areas of our inclusive design checklist as they relate to these various PwD personas. I just mention a few things in each group — the full list is much more extensive.
Visibility of system status
Heading and subheadings used to provide an information hierarchy to structure screen content semantically and visually. Benefiting PwD profiles: blindness, low vision and cognitive.
Radio buttons and checkbox groupings have semantic and visual heading text immediately before the first button/checkbox for context. Benefiting PwD profiles: blindness, low vision and cognitive.
Match between system and real world
All content is communicated by text and/or by accessible alternative text. Benefiting PwD profiles: blindness, low vision and cognitive.
Avoid interaction patterns that flow up and or left. Benefiting PwD profiles: blindness & low vision.
User control and freedom
Interactions with time limitations provide accessible ways to request more time. Benefiting PwD profiles: upper body mobility, blindness, low vision and cognitive.
CAPTCHAs designed to be fully accessible for all common assisted technologies. Benefiting PwD profiles: blindness & cognitive.
Consistency of standards
All screens are designed for touch. Benefiting PwD profiles: upper body mobility, blindness, low vision and cognitive.
Text links should be consistently styled for focus, hover, inactive, etc. Benefiting PwD profiles: upper body mobility, low vision and cognitive.
Error prevention
Call to action buttons touch targets are a minimum of 44 pixels by 44 css pixels. Benefiting PwD profiles: upper body mobility, blindness, low vision and cognitive
User focus does not change automatically or on hover. Benefiting PwD profiles: blindness, low vision and cognitive.
Recognition rather than recall
Color is not the only means of communication. Text and/or shape are used with color to communicate. Benefiting PwD profiles: low vision (color blindness) and cognitive.
Icons are paired with visible text. Benefiting PwD profiles: low vision and cognitive.
Flexibility and efficiency of use
Complex content is simplified or presented logically in tables. Benefiting PwD profiles: blindness and cognitive.
Button, link, heading, and subheading text are unique, meaningful and concise. Benefiting PwD profiles: blindness, low vision and cognitive.
Aesthetic and minimalist design
Animations when used are planned to avoid inducing seizures. Benefiting PwD profile: cognitive.
Nothing blinks or flashes. Benefiting PwD profile: cognitive.
Recognize, diagnose and recover from errors
Error messages include the word "error" or start with "X". Benefiting PwD profiles: blindness, low vision (color blindness) and cognitive.
Help and documentation
Ensure contextual help is provided. Benefiting PwD profiles: all profiles.
Putting it all together: package inclusive design principles into a process
I’ve covered the concept of “nothing about us without us,” the difference between inclusive design principles and accessibility principle, a “light” version of the inclusive design checklist and how — at the heart of all of this — empathy is what drives top-notch, truly innovative digital products efforts.
To wrap up, I’d like to add another list that will help you when working on inclusive design projects. These components are needed, and if you don’t have the know-how available in house, then it’s key to find a partner that does. In my inclusivity design work, we repeatedly focus on these core areas:
Regular vertical training - Bring in specific persons with disabilities to train your designers and engineers. This is key to creating the empathy I’ve discussed. It’s critical to have this in-person or live-online exchange, and base training on the team’s own products.
Weekly designer office hours - It’s key that designers can consult with an inclusivity design and accessibility front-end development expert team as they work throughout the week. I have seen this in action over the years and it makes a tremendous difference in efficiency and helps designers avoid unneeded dead ends.
Do UX research workshops - These are great for subject matter expert tips and iterative exercises around understanding user profiles.
Create a self-service intranet knowledge base - Not only can you store training documents, list FAQs and the like, but a knowledge base becomes the single source of truth for inclusive design. Simplifying, in time, the complex nature of inclusive design and accessibility.
Interested in more information on inclusive design principles and process? Visit our accessibility testing page.
