Inclusivity is a big topic, and we’re diving in head first to help you create more experiences all of your users love. We’ll be talking more in the coming weeks about how you can prioritize inclusivity in your research and design processes from start to finish, from team alignment to research ops to the research insights that drive real change. Stay tuned!
Supporting inclusive experiences is one of AnswerLab’s core values so we know that creating them doesn't happen overnight. We hear from like-minded clients that they’re committed to getting on board, but often have a hard time creating team alignment on how to concretely implement inclusivity into their process. The path to solving these challenges starts with the seemingly simple task of using the same language and definitions across the board. While creating definitions isn’t the most enticing part of research and design, defining how teams consider different populations and getting everyone on the same page is an important first step to implementing inclusive design practices.
In my own research and interactions with stakeholders, I’ve discovered that one of the biggest obstacles to creating team definitions is determining the exact nature of inclusivity as opposed to accessibility. What do we mean by each of these terms? How are they different? Is one concept more important than the other? Which one makes sense to use in what context?
Over the last couple of months, AnswerLab has been conducting primary research to dig deeper into how research can be more inclusive. We spoke to clients, team members, and participants across the United States to better understand what makes people feel excluded and what makes products inclusive and accessible. We’ll be sharing more of these findings and best practices, but first, we want to start by defining our terms, when to use them, and how to socialize these concepts across your company and team to create maximum alignment.
Inclusivity is bigger than just accessibility.
Throughout our research, we noticed that many product teams, the UX community, and our own team members talk about inclusivity and accessibility in two ways.
The first revolves around the types of people you’re talking about.
Understanding this aspect will help your team align on who your product is made for. With inclusivity, this means looking at traits or identifications of participants, such as ethnicity, race, gender, or socioeconomic status. Including these populations in your research is important for diversity. With accessibility, on the other hand, you’re looking at varying degrees of ability. This can include participants who have mobility issues, low vision, or varying cognitive abilities.
The other way we talk about inclusivity and accessibility is how organizations incorporate inclusive or accessible practices into their processes.
Incorporating inclusivity means bringing in methods, processes, and practices into your overall product development lifecycle to help you create an experience that works for everyone in your user base. With accessibility, these practices are related to creating specific affordances for people with disabilities, setting guidelines around accessible text size or color, and implementing these guidelines and affordances into your products. With inclusive practices, this means ensuring you’re recruiting a diverse group of participants with varying degrees of ability and across different traits and characteristics to ensure the product speaks to everyone it is meant to speak to.
Why are these distinctions important?
The distinctions help teams understand (1) who they’re creating their experiences for and (2) how to think about developing the experience. If teams aren’t addressing both questions, they risk frustrating segments of the population they’re building the experience for or even completely leaving them out. For example, if you want to build products that include members of the LGBTQ community, but don't include them in your research process, you might miss out on valuable insights at an early stage of the design process. Having a simple checklist to review at the implementation stage may ensure you're reviewing pronouns, but it won't help you see bigger missteps or opportunities you could solve or improve in early stages.
Who are you creating an experience for?
In the early stages of product development, it’s important to understand who the product is for, not just what it does. Organizations need to make conscious decisions for exclusion - and sometimes that’s a good thing. For example, an app designed to help women network may not want to include men in their concept evaluation and early stage development. And that’s ok! However, this needs to be a conscious decision and conducting inclusive research allows your team to make that decision.
Teams can start by asking a variation of a simple question: “What would this product look like to someone who has a different context, a different point of view, or struggles with X?” One of our favorite tools is this website that asks us to imagine different segments of the population using a product. We recently tested a prototype on a TV screen where participants needed to use a remote control to interact with it. During one session, a participant mentioned that he wished he could navigate using voice instead of clicking the remote, suggesting that people with arthritis or physical limitations might struggle. Considering one of the goals of the research was to make the design more accessible and better for older consumers, this was a crucial piece of feedback.
Start designing with a wider population, rather than for a wider population.
Ideally, your team will be just as diverse as your customers to reflect the needs of your users. In addition to creating diversity in your organization, conduct research with a diverse group of participants at every stage of development. The methodologies you use at different stages of product development will still apply when talking to diverse sets of users. Incorporating diversity and inclusivity into your research doesn't have to mean conducting separate rounds of sessions. This is something you can embed into your standard research regardless of methodology or stage of the development lifecycle.
When starting on a new product, we recommend conducting concept evaluations to create user journeys. It can be as simple as putting a list of features in front of participants to see what resonates with them, creating a storyboard of stick figures, or asking participants to walk you through their day. Talking to a diverse population at this stage will give your team some concrete direction on which features or experiences to focus on. At a later stage of development, researching with a diverse population will allow you to design appropriate, inoffensive content and visuals that better represent your customer population.
In our research, we talked to a participant who was deaf and was studying for a board certification exam. She purchased a study program to help her prepare, but missed almost all of the content because it was not captioned. Obviously, this was not an accessible or inclusive experience, resulting from failing to consider this need during the development process. The exam company lost a valuable customer simply by not considering her needs. By building an inclusive practice, not just an accessible practice, you might find these hidden gems of insights that can make or break your ability to reach even more users.
Strategies to socialize your inclusivity goals and findings across your organization
Now that we’ve covered the difference between inclusivity and accessibility, how do you actually start implementing inclusive best practices? Getting everyone on the same page is hard, but as we mentioned above, the methodologies are the same for inclusivity, and so are the socialization tools. Here are some strategies to help socialize your inclusivity process.
Conduct a workshop in the product planning or exploratory stage
One of the most productive ways of getting stakeholder buy-in for UX research is by conducting a workshop on its benefits. However, this is also true for socializing inclusive best practices.
Create clear definitions
The first step is making sure you and your team are on the same page about which definition you’re talking about. The guide at the beginning of this post is a great starting point. Define terms such as inclusivity and accessibility in subsequent meetings or workshops to remind your team throughout the development process, and continue to refine and hone in on your definitions as you talk to more participants in your research. Working with participants at these different stages of research will help you expand your vocabulary and understand your user base even more. Create reference guides, like glossaries or knowledge bases that are easily accessible to help your team navigate definitions and new vocabulary.
As a starting point, have your team answer the questions below. We recommend doing this silently at first as a written activity, then collaborating together to refine answers and expectations. This helps prevent biases and ensures that everyone’s voice is heard. Because what better way to socialize inclusivity than building inclusivity into your inclusivity workshop!
- Where are you, as an organization, right now with respect to inclusivity and accessibility?
- Where would you like to be as an organization?
- What are some steps that you can take to get where you want to be?
- What are some barriers you might have to overcome to get your where you want to be?
This is a great exercise to see how your team’s goals align. We work with many teams who want to incorporate inclusive design practices, but don’t know how. By brainstorming before product creation, you can generate some ideas to implement in your final customer experience.
Collaborate with your team as you develop your research plan
As you begin to develop a research plan, get your team involved! Have your product team’s goals for the research written down and keep them somewhere you can easily refer back to. Now, take one more step. Ask and answer different iterations of the following question: “How would this product work for someone who has trouble with X”?
How would this product work with someone who has difficulty using their fingers?
How would this product work for someone who is afraid of walking home alone at night?
Then, you can create recruiting criteria based on the questions that you can't answer and talk to users who have those qualities or traits.
For example, a client came to us looking for feedback on a new fundraising tool. We spoke with a participant who was interested in creating a fundraiser on behalf of a friend in need, but the process required funds to be deposited into the creator’s bank account and then given to the friend. Ultimately, he was afraid to create a fundraiser because his bank account was subject to review for government social services and he could lose his benefits if his balance surpassed a certain amount. For the next iteration of the product, our clients had to answer this question: How might our product work for someone who is low income?
Encourage your stakeholders to observe the research
This may be the most time intensive way to socialize findings amongst your team, but it’s often one of the most effective ways of showing your team the power of using inclusive practices. If done right, designers, developers, and product managers will all walk away with a better understanding of your users and even get to witness these hidden gems of insight we’ve mentioned above.
Set up a back room for stakeholders to work together away from the moderator and participant. Having a strategy for your observation room will only increase the influence of your research, so ask stakeholders to take notes, write down questions, and keep in mind any goals and questions laid out while planning the research to see if you can answer them together.
Use personas and journeys to create empathy
Building personas and user journeys can be crucial in empathy building, especially for team members who aren’t able to observe research sessions. Use quotes or video clips from your research to help create personas and user journeys for different types of people, and ultimately build empathy amongst your team. As you conduct more research, continue “filling in” those journeys as you incorporate findings from users across the board. You’ll likely experience moments and discover insights that will build out your understanding of your users one story at a time.
We found this recently with one of our health-related clients. A participant we spoke to had struggled with an eating disorder and was using their product to make sure she was eating enough to stay healthy. The product made her feel like food was the enemy and that she had to lose weight. This was because our clients built the health related app with the mindset that their typical customers use health-related apps for that purpose. This insight helped designers make immediate product design decisions. But, more importantly, many stakeholders began having conversations about the company’s values and long-term stance on some of these issues. This participant’s story helped them learn to be a truly health forward company, rather than just focusing on dieting.
This is a complex topic and can be challenging for teams, but getting started can be as simple as creating clear definitions to inform your next steps. We’re all striving to be more inclusive in our teams, our products, and our experiences. We’ve found that this is the right place to start.