Are you thinking of running your inclusive research projects like all your others? You might need to think again. When teams begin making their research projects more inclusive, a number of pitfalls crop up again and again.
In this article, we’ll take a look at seven mistakes we often come across, and give you some tips and tricks to steer you down the right path. We know that there are many things to consider, as with any research project. But mistakes like these can be especially detrimental in an inclusive research context.
There are many variables that make us up as humans. Sex, gender, race, religion, ability status, and employment status, to mention just a few. Inclusive research is where we focus on minority groups or situations such as those with impairments, those of a specific market, or a niche location. Using this technique, we uncover their worlds, goals, needs, and wants when it comes to our designs.
Usually, conversations like these focus on accessibility. After all, there are only legal requirements to create accessible solutions, not ones that are localized or internationalized.
Accessibility is one part of inclusive design, with inclusive research expanding to encompass as many people as possible. Inclusive design incorporates strategies or non-functional requirements like localization, internationalization, or situational.
Accessibility focuses on impairments, localization, and internationalization focus on those from other cultures and situational research focuses on problems specific to circumstances and environments. Think of someone trying to use an app when shopping while one hand holds a basket and the other is occupied putting products into the basket.
Being inclusive during inclusive research starts before the user steps foot into your office or joins your online call. Being prepared for any research gets us off on the right foot for building rapport with users.
It is embarrassing both for you as an interviewer and for the person staring at you with a basic need they cannot change. If someone cannot participate, we as researchers have failed our users and the project. It is on us to ensure that the study is on track for success, which means setting up users for success.
Being unprepared is not asking users what needs they have to take part in the study. It is not understanding cultural context and knowing your accent may be too strong for non-natives. It’s something as basic as not screening which languages users can speak.
This issue usually arises when we’re too afraid to directly ask users about any impairments or reasons they would need support. Often it’s considered rude to be asked. Users are not always asked this question with their interests in mind.
But the key is to focus on the needs, not the problems. Most of the time, we don’t need to know what impairment someone has. What do they need to be best supported in our study? This question accommodates everyone and doesn’t just focus on impairments. Now you will know if someone needs guidance from reception, whether they need a translator or to bring their child along to the session.
We, as researchers and designers are more often than not the experts in such niche areas, and often experts are not consulted for projects. This problem usually stems from budget restraints or wanting to learn by yourselves. We’ve done research before, so how hard can this be?
Problems include things you cannot change, like applicable laws or accents and languages. Understanding a new set of laws in any country is a huge task. Not consulting expertise means you have to learn all the applicable laws of where your company is located and where your users are located. It also means you may be faced with languages or accents you’re unfamiliar with, even if you can speak the language.
Another problem when approaching completely new topics in an exploratory phase is that we have no sense of context or priority. We end up exploring something trivial because it sounded fascinating to us and not exploring something valuable.
The ideal situation is to collaborate with others who understand context, as they can predict what users will need and communicate with participants.
Budget permitting, using external consultants is the best choice. They should be local to a culture, or an expert in the niche you’re studying. They should have an understanding of working in that country or have the necessary environments for participants to successfully take part.
If your budget or time doesn’t allow for you to hire externals, ask around within your company to see if anyone can help with the study. Ask colleagues if anyone has experience with the minority you’re interviewing.
If possible, write a discussion guide for them to use in the sessions, train them to conduct the study, debrief with them after sessions, and/or include them during the analysis and presenting findings to keep things on track. At the very least they may be able to help you prepare for user needs to help make the project a success.
This problem stems from the prototyping tools in our industry. Their ease of use from uploading screenshots and adding hotspots over the images leaves a lot to be desired when it comes to inclusive testing. Especially with people who rely on assistive technologies.
Some prototyping tools offer these features but they have to be manually switched on. You either have to know they are there or go out of your way to research how to make accessible prototypes to discover the feature within well-known tools. Tools such as Figma, one of the most popular tools, used by huge companies, only offer screen-reader-compatible designs. There is so much more to inclusive design than screen readers.
Firstly, we as consumers of these tools need to put pressure on big players to prioritize accessibility. Laws demanding accessibility are decades old. America’s Section 508 was introduced in 1973 and the UK’s first Disability Act in 1995. The benefits of inclusive design have been both discussed and proven time again. So, why is it still a low priority to build inclusive solutions?
Meanwhile, prototyping in code is the best option. The use of design systems is making this easier for those of us who may not have coding knowledge. Ideally, we can piece together our interfaces using pre-defined components to create prototypes that are easier, quicker, and more suitable for inclusive research studies.
A lot of the time we find ourselves in our ‘typical’ user’s situations and environments for what we design. We have either been there ourselves, shopping, traveling, and banking; or we have seen user situations through media like TV and movies. However, many times, what we’ve come across, particularly in mainstream media is an ableist and western point of view. Researching online produces results that are personalized and show us what we expect to see. So, often we can’t solely rely on desk research depending on the questions we need to answer.
For inclusive research, not immersing ourselves in their environments is a huge missed opportunity. It’s a research best practice to observe what users do. Asking them what they think they do relies on users being observant of their own behaviors and accurately remembering said behaviors.
For accessibility research, you want to explore how people adapt their lives to suit their needs. Things that may seem so trivial to them but are eye-opening for us as researchers are often those sparking moments that trigger innovations. What assistive technologies are they using? What else in their environment is set up to help them achieve what they need to?
For cultural research, putting yourself in a completely new environment allows you to challenge what is normal for you. See first-hand what is different, what remains the same, and the ways in which people go about their lives.
For situational research, get out there and observe how users actually go about their daily tasks. If you’re designing for doctors, go to their workplaces, and see what technology they deal with or the environmental challenges they face. If you’re designing for parents, observe what it’s like to look after children and attempt to use technology.
The more diverse your user research, the richer the experience. Everyone will gain from your product.
It’s not uncommon for research or testing to be conducted late into the project life cycle, like just before or after launch. This can stem from websites needing to be released as soon as possible to start bringing in revenue or because of budget restraints.
The problem is inclusive research and design can be incredibly intricate depending on who you are building for. Depending on your team’s level of knowledge about user backgrounds, it can elongate the time it takes to build inclusive solutions. Understanding an entirely new market, for example, is tricky and takes time. Even if your company has a similar product or service in one country does not mean it will translate well for others.
Inclusive research, whether flying to another country or interviewing those with specific needs, can be expensive. It is not easy to conduct this type of research without buy-in and budget from stakeholders. So, how do we do the work necessary to drive these requirements? We do as much as we possibly can and carry those insights everywhere, in every relevant team discussion, in every design presented and developed feature built.
Start by asking participants in your current research sessions whether they have any requirements. Then start to explore those needs in further detail within the interview. Look for any communities near you which involve the users you need to see how you can begin to observe or ask questions.
As much as I have championed inclusive research throughout my career since 2015, I too have faced these challenges. I have been lucky and honored to have had opportunities but I have had to put myself out there, volunteering in the Jungle refugee camp when designing apps for refugees, dining in Dans le Noir, London restaurant on my own accord to ask blind people questions about their lives. Making your own luck is sometimes your only option to get started.
When accessibility or inclusive design is first prioritized on a project, the requirement almost always seems to be “just make it accessible”. People are still unaware of what accessibility or inclusive design means. So, projects tend to push back or ignore the requirement altogether because “just” making things inclusive is not a clear-cut action.
Many of us, researchers, designers, product owners, or developers don’t know where to start. Companies turn to the legal requirements as a checklist but the WCAG is purposefully vague and non-prescriptive. They can be difficult to read, even for those who are familiar with them. The resources that accompany becoming more inclusive aren’t all that accessible, so it’s easier to continue as before and not address anything.
Whether researcher, designer, or developer, the trick is to break down problems into manageable chunks and inclusive design is no exception. Survey your audience to see which needs or assistive technologies are the most requested. Look at analytics to see where the majority of your users are visiting from. Are your users mostly requesting screen-reader compatibility? Are they requesting more keyboard-only support? Use this data as a starting point for research and add focus to deliverables and time periods like sprints. This makes work easier to plan, implement and estimate and reduces the all-time favorite requirement ‘just make it accessible’. In turn, this makes it easier to request budget for the work.
It is eye-opening in many ways when you first start conducting inclusive research. Not only will you uncover the issues with your interface but also with yourself. If this is your first time around a particular impairment or cultural situation, you often won’t know what to expect or what is acceptable. For example, you may not realize how thick your accent is or how many colloquialisms you use until talking to someone not from your area. You may not realize how inappropriate a question is until you’ve asked.
At an accessibility hackathon that involved a number of blind people, I learned more about how to be an inclusive person than how to build inclusive software. I naively asked someone who is blind ‘can I watch how you use a computer?’.
I was aware of screen-readers, I had even used one multiple times. But this person did not rely on any screen visuals. This meant the size of the window was around 200px by 40px, it was not maximized and the tabbing through components was declared by the screen reader despite the window size. I could see the screen but I could not see anything that they were doing. Someone else in the same hackathon stood on stage and asked the audience to copy what they did, as an icebreaker. They did not narrate what they were doing which excluded a lot of people in that audience who could not see what the actions they had to imitate were.
Most learning comes from spending time with people who are not like us, whether from another culture or those with different needs. Start by researching what we can before inserting ourselves into these communities. Look at cultural norms, expectations, traditions, and etiquette. Research how to behave, learn what will be expected of you, and how to word questions so as not to be offensive. While accessibility and inclusive design in the tech industry have a long way to go, it has still come a long way and has a huge community and wealth of resources online to help you get started.
Overall, be as prepared as you possibly can, not only for usability insights or user understandings but to completely challenge the norm, your norm. The problems we’ve mentioned such as being unprepared for users’ needs or not exploring users’ situations are easy to overcome. Take each research project as it comes. You will learn so much about other worlds and yourself in research like this.
Remain humble and as respectful as possible while studying people in situations you don’t know. Users are still people, whether they have an impairment or are from a different country. There’s a fine line between researching and consuming them for our benefit and ‘enlightening’.
One thing is clear though, inclusive research and design only benefit everyone. It’s worth doing it as best as possible.
If you're interested in learning more about accessible research, make sure you check out our Masterclass series of webinars, featuring expert insight and advice on the hottest topics in the UX industry.
Join Amy Stone, Ph.D., Director Strategic Research Partner, and Jennifer Keus, Senior Director Participant Recruitment Operations, for a live discussion on diversity in research, industry trends, and best practices for recruitment.