The first step to designing a solution is understanding whom we’re designing for and what problem we’re solving. In a Human-Centered Design (HCD) approach, this means research, personas, and journey maps. We’re gathering knowledge about users’ goals, frustrations, preferences, responsibilities, and expertise.
Documentation about users often includes things like their name, age, gender, and marital status. But these can introduce stereotypes that keep us from creating an inclusive user-centered solution. Here are three easy ways to avoid introducing unnecessary stereotypes to your next project.
Use Genderless Names
If I must name a persona (which is a representation of many people), I aim for genderless names like:
- Taylor 😉
But why not just use the name of the archetype? For example:
- The Collaborator
- The Early Adopter
- The Eagle Eye
- The Human Computer
Using archetype names brings their superpower to the forefront. It also gets everyone in the mindset of the user when you say things like, “For the Eagle Eye, we need to design features that…”
2. Use Genderless Images
Sketches are common early in the design process, and they present a great opportunity to show (genderless) people performing tasks that are important to design for.
Images speak a thousand words and — for this reason — should be selected carefully. Ideally, we can capture photos during research that demonstrate the environment and tools a user is working in/with. (If that’s not an option, consider stock images that might illustrate the same.) When looking for portraits of people, consider the potential biases that might exist (about a given age, gender, race, etc.), and choose carefully.
3. Use Genderless Language
When we refer to personas and archetypes, it is easier to use they/them pronouns. However, when we drill down into a journey map or the process step-by-step, we often default back to gendered pronouns.
Instead of: “His job responsibilities include…” use “Job responsibilities include…” or “Their job responsibilities include…”
As an example, let’s imagine we’re building a health portal for patients to communicate with their doctors and see test results. One persona example could be:
- Charlie, Retired
- Goals: To be proactive with their health (avoid injuries, doctor visits, hospitalizations) and to compare test results against their previous numbers
- Frustrations: Needing to be a health expert to understand test results, tracking down billing status with insurance
- Preferences: Prefers email communication vs. phone
- Responsibilities: Daycare for grandchildren, Board Advisor for company they retired from, sharing health results with partner
In this example, the persona’s age, gender, and marital status are not needed. Designers will still get a sense of the needs and behaviors of the people they are designing for. Ultimately, if this persona was shown to a user that it represents, they could see themselves (partly) represented in this narrative.
Is Our Solution Inclusive?
These examples are merely a guide for the early stages of a project where work is being discussed, captured by sticky notes, and quickly sketched to convey ideas. The early phase is so critical to building alignment and shared ownership of the problem space. For this reason, it’s important to build from a foundation of inclusivity, empathy, and focus.
Ultimately, we need to frequently ask ourselves: “Are we sure our solution is inclusive?” Have an open dialogue with teammates on this topic. Invite different perspectives.
Here are a few related resources I’ve found helpful: