Making Inclusive Design the Norm
Jutta Treviranus, director and founder of the Inclusive Design Research Centre and the Inclusive Design Institute, hosting Adobe’s first Design led accessibility training in San Francisco.
Inclusive design as a movement has benefited an immense surge in visibility in design circles. Now that it is receiving the attention it deserves, the design community needs to know how to put inclusive design to work. Today, on Global Accessibility Awareness Day, I’m proud to make a two-part announcement: firstly, we’ve launched a live inclusive design training program that all Adobe designers will be required to take by the end of 2019. And secondly, we will be releasing the program to the public in early 2020.
In 2014, Adobe launched an accessibility training program called Blue Belt, meant to teach our engineers and testers what they needed to know in order to build accessibility hooks into our desktop, mobile and web products. Hundreds of our technical staff took the online training, and over the next few years, hundreds more received a live version at one of our offices, from San Francisco to Basel to Bangalore.
However, there are limits to what problems developers can solve. In my experience, the majority of the issues that lead to exclusion in the end product are caused by decisions that may have happened before anyone started writing code. Often, engineers are called upon to build systems they can’t, for example, make accessible enough on their own, because the design didn’t account for accessibility in the first place.
Disability is not the only source of exclusion. Researchers like Prof. Margaret Burnett at Oregon State University are also finding evidence that decisions made in software design can contain unexamined biases that disadvantage users by their gender. There’s no reason to believe the same isn’t true for any other form of human difference as well. Decisions made at the prototyping or design exploration phases, even at the very conception of an idea, can and do enshrine exclusion in the final product.
Inclusive design needs inclusive designers
We have long known that what designers need to face this challenge is different from developers or testers. Design professionals are faced with the challenge of simplifying hundreds of complex tasks, and guiding people to their destinations not just efficiently, but easily. Handing a designer a set of guidelines, many of which are intended to inform a final product that’s constructed by someone else, doesn’t work. We need to give designers a look at all of the ways their work can go wrong when it’s implemented and give them tools to define a more robust set of requirements for product teams to build.
This week, we began to show designers that path. On Tuesday, a group of 35 designers in our headquarters in San Francisco attended the first inclusive design workshop, led by me and Jutta Treviranus—a pioneer in accessibility and inclusive design. The full-day training orients designers to how human differences—not just along lines of disability, but also race, gender, LGBTQIA+ identity, age, language and reading proficiency, economic status, and cultural and religious identity—are all factors of exclusion in our work. It then provides concrete steps we can take to help correct that exclusion, from inclusive hiring and consultation to documenting the structural and non-visual aspects of our designs in what we deliver to product teams.
This is the first of eleven training sessions we’re planning to deliver in the Bay Area, Seattle, Utah, New York, Hamburg, Bucharest, our two offices in India, and online. By the end of 2019, every member of our design team will be trained to not only to recognize exclusion in our products, but to call it out to product teams, and take steps to account for the true diversity of the people using what we make.
Sharing what we’ve learned
In early 2020, Adobe Design will release our own inclusive design program materials to the public. This will include slides, workbooks, teaching materials, and guides for small-group activities to aid understanding, as well as a hands-on introduction to evaluating and documenting accessibility in design deliverables such as wireframes. We will take the time to validate our approach with the designers who take the class and continue working with advocates to ensure that our lessons adequately reflect true inclusion, before releasing a final product.
We will not stop there. Next week, we begin a new project to uncover what tools and training are necessary for inclusive design research. We can never fully observe or interpret the needs of test participants if our experiments enshrine bias from the start, or don’t account for the use of accessible technology to complete the task.
When I started in Adobe Design, I was asked how many inclusive designers I wanted on my team. I asked how many designers we had, and when I got the answer—hundreds, worldwide—I said that should just about be enough. Inclusion is not just something designers should be thinking about, it is an aspect of professionalism, just as it is with the engineers and testers we originally focused on. Designers must be well-versed in all the ways in which humans are different, and be empowered to ask questions and explore, but above all, to advocate for the most inclusive end product that can be achieved. Starting now, we are giving our designers the tools they need to be advocates for inclusion.