It’s extremely important when talking about inclusive design to talk about implementation. Once you’ve gained an understanding of what inclusive design truly is (and isn’t), the task becomes making it a driving force to create products for everyone. So far in our series we’ve covered the lines between accessibility and inclusive design, along with the aspects of inclusive design across such differences as age, race, and gender. Now, let’s talk about the important part — how to practice inclusive design and inclusion, in general, in our working lives.
I’ve spent the better part of my career advocating for more accessible products and processes, first as an engineer, then as an evangelist, and now as a manager. Over that time, I’ve had my share of opportunities to warm people up to at least one aspect of inclusion. While our work is and always will be ongoing, over time I’ve found some things have certainly changed situations for the better. Here they are.
Make inclusion a priority
How does the practice of inclusion take hold? Is it from the top down, or from the grassroots? Nearly everyone I’ve talked with about inclusive design asks this question first. What they’re really asking is this: What kind of difference can I make as an individual contributor, without knowing if the boss approves?
We read stories all the time about how an executive came to see diversity and inclusion as an asset. But those conversions don’t happen in a vacuum. In most if not all of those cases, there was someone already there, raising the issue, asking questions, and amplifying the voices of others. Be that person, to the greatest extent you can. This is the hardest work to do, because it requires a lot of preparation and discomfort, but all that is necessary to challenge the status quo.
Effective advocates make progress in the same way, whether or not they’re the boss. They ask questions as they encounter issues. They help people find their way toward solutions, even when the answer isn’t something they’re fluent in. And they’re prepared to transmit a message:
This way isn’t working, and I am willing to help us move in another way that will.
You may hear a response akin to “We don’t care about that.” That’s fine. A spoken bias against inclusion is easier to counter than an unspoken one. It’s a sign that you still need to find enough support to overcome inertia. You may hit the jackpot and find that champion that turns the whole organization around on a dime, and you may not, but being a persistent, visible advocate increases the chances that when that new ally appears, you will be there to greet them.
As I mentioned in my last post, “D&I,” or diversity and inclusion, are being emphasized in organizations of all sizes and shapes. But that’s just the beginning. An organization that can cite, for example, the percentage of employees they’ve hired by race, but can’t articulate how people in racial minorities are empowered in their work environment, has not thought through its inclusion efforts thoroughly enough.
As inclusion advocate Vernā Myers said, “Diversity is being invited to the party, inclusion is being asked to dance.” Numbers are only a part of the story. True inclusion recognizes a qualitative improvement in the organization as a result of a more diverse workforce, and recognizing that requires organizations to put diverse voices front and center where decisions are made. Recent research demonstrates that inclusive teams make better decisions up to 87 percent of the time.
Having a diversity of backgrounds and points of view is an asset to any team. It makes for better meetings, better decisions, and better products — but only if you value it.
Recruit diverse user testing/focus groups
It stands to reason that the consumers of your product are even more diverse than its producers. And the advice here is the same: involve a diverse set of users as early and as frequently as possible, and give weight to their feedback.
One approach is to say, “Hey, we have all these personas for this product. What if one of them is Latinx, or uses a wheelchair?” In my experience, this is fairly common, and it may come from a genuine place, but relying on it as a form of inclusion is misguided.
Personas are meant to form a kind of shorthand for different types of users and, at that, they can be useful. It’s important to remember, though, that slapping a diverse-looking image on a persona is not inclusive design. At best, contemplating inclusion issues through a persona may only address them in a way that extends to that one story. A more comprehensive approach is required.
An inclusive approach to personas would recognize that, in the vast majority of cases, someone matching a given persona could be any gender, come from any ethnic background, be older or younger, and so on. Personas can help you zero in on what different users like, but inclusive design focuses on what different users need.
Make inclusion a part of the job
In my last post, I mentioned the Inclusive Design Exchange, a group we formed to advance inclusive design in our process. The IDX is composed of more than a dozen Adobe Design employees, each spending several hours a week studying, building training materials, using their design skills, or otherwise contributing to inclusive design work.
The IDX is not a volunteer group. That’s by design. Adobe Design managers nominated and assigned high-performing members of their teams to this group because it is important to the organization that this effort succeeds.
There’s nothing wrong with supporting employees who want to learn more on their own (and it’s always good to reward them, both publicly and materially, for doing so), but it’s either a part of the job, or it’s not. Allocating resources to inclusive design and development sends a message that your organization places measurable value in achieving a specific goal.
I am strongly in favor of the concept that inclusive design is a discipline that everyone practices at every level of the organization. Experts and specialists in inclusive design are great, but they can’t be in every meeting room, Slack, or email thread, and they can’t be masters at marketing, design, engineering, and product management at the same time. We need a few people who know a lot about inclusive design, but we need a lot of people who know a little.
There are two main ways for a management team to undermine efforts at inclusion:
- Not rewarding people for doing the right thing, and
- Not holding people accountable for doing the wrong thing — or nothing at all.
If a team shows off its work to its management, and management doesn’t ask any questions about the product’s accessibility, or about the diversity of its personas, or its focus groups, then the impression the team will get is that they are off the hook. Why would a product manager spend precious time and resources on work they aren’t being asked to do, at the expense of any number of things they are clearly expected to do?
Just about everyone agrees that accessibility in a software product is a good thing — analogous to security, privacy, and internationalization, which are all disciplines that require work to be done in all phases of the software development process. If security bugs are showstoppers but accessibility bugs can be deferred, if privacy or security compliance is required but Web Content Accessibility Guidelines conformance is not, nobody is left to wonder whether it really needs to get done.
It’s this simple, in my experience — teams that are expected to produce inclusive experiences from their management end up creating inclusive experiences. Teams that aren’t, don’t.
If you’re the person in charge — or even have a modicum of influence — the most productive thing you can do is simple: ask at least one question related to inclusion (including about accessibility, bias, diversity, etc.) in every meeting. Making people accountable to these lines of questioning reinforces the message that this is, in fact, everyone’s job.
Continuing education is the key
Here’s my last bit of advice: treat the practice of inclusion as a permanent addition to your shared organizational goals and values, not as a bug to be fixed. One way to do this is to introduce new aspects of inclusion on a regular basis. We are building a monthly program that will consist of hour-long training sessions, lightning talks by internal speakers, and invited guests.
If you happen to work somewhere that has an existing continuing education program, these sessions should be presented regularly, and on par with other types of programming. Some organizations have a culture of “lunch and learn” sessions, but I tend to avoid them because it makes people volunteer their lunchtimes. If it’s worth teaching, it’s worth participants learning on company time.
Where we go from here
I’ve discussed some of the inclusive design work underway within Adobe Design. We’re working on both educational and practical projects that we think will help, and we will share what we can as we go. Our greatest asset to contribute is in the form of hundreds of design professionals, each with their own strengths, all of whom are dedicated to removing barriers between people and the creativity they want to express. Inclusive design is an integral part of that journey.