As UX designers it is our job to bring the human element into a digital product. We design for inclusivity, we consider our audience and are directly informed by what they have to say. Being the advocate of the user, empathising with their unique circumstances and needs and giving them a voice is what has led many of us, including me, to pursue this career.
But we have to admit an uncomfortable truth. With aggressive deadlines, the need to push out MVPs, and small startups developing products without the input of a product designer/ user representative at those early stages, a lot slips through the net. Sometimes it’s on our watch. Sometimes it’s a legacy we inherit. Sometimes it bypasses us altogether and suddenly it’s there. Either way, when it hits the customer, things can start to unravel.
As our day to day responsibilities sometimes mean we cannot see the wood for the trees, a lot of tools in our arsenal can help us zoom out a bit and look at things with fresh eyes, and even force us to roleplay a bit and foresee potential issues that we didn’t anticipate at first. Here’s a broad checklist that covers some of the areas we need to review prior to releasing something to the public. Some of these tips may also be useful to your front end dev and/or QA engineer.
Mini disclaimer: This is not by any means an exhaustive list and there is a lot of material out there on how to make your product more inclusive, thanks to our great community.
Accessibility is at the core of inclusive design. It’s our responsibility to create digital products for all to use, no matter what difficulties they may be facing. After all, it’s highly likely that this will be us at some point in our lives, especially as better standards of living allow us to reach beyond the age of 70. The task may seem complex, but if we’re not too sure where to start, there is a plethora of guidelines to help us gain a better understanding of the spectrum of disability and how we can provide tools to enhance the online experience for everyone.
One of the beautiful things about accessible design, be it digital products or every day objects we interact with, is that it provides benefits to everyone (in varying degrees), not just people with disabilities. For example, a wheelchair ramp is essential when using a wheelchair or mobility scooter to move around, but it’s also handy when pushing a buggy, or wheeling a suitcase. The OXO potato peeler allows someone with arthritis to hold a comfortable and steady grip while peeling, but it’s also ergonomic, allowing kitchen staff to avoid repetitive strain injury. Subtitles in films are essential for those who are hard of hearing, but they’re also great if you’re learning a new language and want to keep up with the action while exercising your brain to understand what is said. The examples are endless!
I can barely do this subject justice in a few paragraphs, but here is a little selection of resources to look at:
- The Web Content Accessibility Guidelines: Your content needs to be perceivable, operable, understandable and robust.
- Guides and examples of web accessibility techniques for designers provided by the centre for excellence in Universal Design. Be sure to check out their 7 principles!
- My web my way by the BBC, containing tailored guides on how to make the web easier to use depending on your needs.
- Some great suggestions on how to experience first hand ‘the impact of digital accessibility’ by GAAD (Global Accessibility Awareness day).
- This comprehensive article by the Interaction Design Foundation, providing useful terminology definitions, listing guidelines and giving tangible examples of accessible design.
- Various studies, resources and articles provided by the NN Group.
- Colour contrast checkers, such as this one by Webaim, which also provides a wide range of resources on the subject.
Beyond following guidelines and ticking boxes, accessibility needs to be achieved through representation. After all, it would be quite absurd to ignore such a huge segment of the population, which also includes the ageing population and people who face temporary disabilities. Make sure that you interview users with particular needs, incorporate these into your personas, and do usability tests with said users. A little exercise I do to broaden my understanding is to reach out to family, friends and acquaintances with a disability. I chat with them about the issues they face, their day to day, their frustrations. I observe how they interact with their environment and technology. This, alongside the exercises listed by GAAD (linked above) provide a tangible and more intimate understanding of issues faced and the transformative value of accessible design.
Sometimes it can be hard to avoid the tendency to design for ourselves before considering different perspectives. Of course, as UX designers we have plenty of tools to broaden that perspective, through extensive user research, contextual analysis, and building personas and empathy maps to represent diverse customer segments. But we can still have blind spots.
When thinking about inclusivity of this type, I remember an anecdote from a brilliant mentor I had, who was describing the product team at a luxury travel company he worked for. Initially, it comprised of young singles. As it started to grow and include people with families, they realised their family holiday offering was extremely poor, as their product was centred around excursions for adults and didn’t account for families with children. The product team was so caught up in their own unique perspective, that they missed a huge (and extremely profitable) customer segment. Thankfully they managed to rectify this, but only when the team started to diversify.
It’s easy to think that if we follow certain steps we will capture the full spectrum of users and recruit the right kind of participants. For example, that if we send out a screener survey we will find the right people to talk to. But if we only rely on friends and connections on social media, we may receive results that are biased towards certain age groups/ cultural backgrounds/ religious beliefs etc. We may get lost in the echo chamber.
An example of this that I go back to, is during my days as a UX instructor associate. One group of students was designing a health app for a pharmacy chain. They had sent out a survey, generated personas and were building an affinity map of their interview findings, but were a little stuck on next steps. At a critique, they described their primary persona to me, an able bodied, active woman in her early thirties. I questioned whether this user type should have been selected as their primary persona considering the nature of the app.
So how do we avoid blind spots? The answer (hilariously) is more pairs of eyes, ideally early on in the process. This is where internal stakeholders and domain experts are an extremely valuable resource. They are usually extremely happy to share their insights, provide different perspectives, and challenge our assumptions through tangible experiences and entertaining anecdotes. If you can, reach out to the rest of your company through a forum of choice (such as a Slack channel) and start a conversation, or schedule some interviews to pick people’s brains and gather suggestions on where it’s best to source candidates for interviews and testing.
Of course, there are times where this is irrelevant, such as if your application is already targeting a particularly niche group. But to enhance inclusivity, consider any unique needs depending on race, ethnicity, gender, age, education, profession, occupation, income level, and marital status. You may discover new and surprising things, and you will definitely become a better designer.
As designers and developers, we usually get to work with up to date software and hardware in order to produce our work. And, of course, it makes sense, as we need to do the thing properly without the frustrations of unreliable equipment and clunky OS. However this leads us to make a very easy assumption: everyone else is using the same equipment, OS, software, browsers, and has a decent connection speed (ah, the dream) . Unfortunately the reality can be very different, and I’m not even referring to developing countries here. Until recently, in the UK, a large portion of the NHS was running on Windows XP, long after Microsoft stopped releasing bug fixes. Many organisations are relying on technology we don’t account for when designing/ developing.
This may not be a huge issue when it comes to mobile based applications and B2C products, but it is definitely something to consider for web based B2B applications, where you cannot guarantee that your product is being accessed on up to date machines/OS/browsers.
Thankfully we can easily diagnose whether this is something we need to account for: your customers will probably tell you, as will your analytics data.
- If you have a support team that logs bugs and technical issues, look for any patterns when it comes to particular devices, browsers and operating systems.
- When you capture feedback from your users, make sure to ask a quick question about the tech they use to access your product.
- When looking at analytics, find out what percentage of your customers access your product on which browser: if there’s a relatively high amount of Internet Explorer users, you need to check that your product runs smoothly on IE.
Worry not! there are plenty of tools to help you out, such as places to check if certain components are supported by a particular browser ( like caniuse.com ) or cross browser testing services ( like Browserstack ). Here’s a fab article with some guidance on how to go about ensuring good browser support for your users by the gov.uk blog. If numbers are your thing and you’d like to check things like browser usage in your country, I quite like statcounter.com.
In recent years we have witnessed the emergence of a new UX discipline: UX writing. It almost feels like it should have been sooner, but it’s great nonetheless to see that more and more companies are understanding the gravity of language when it comes to digital products. Interfaces, after all, are not purely comprised of visual elements; they also contain copy: labels, descriptions, instructions, greetings, updates, calls to action.
I will not delve too deep into the ins and outs of UX writing, however inclusive language is something for all UXers to consider. Monzo has an amazing article on their tone of voice that is essential reading when it comes to this. As a new product in the fintech space, they are often competing with large banking organisations that use language in a very specific (and rigid) way. Their approach is to use conversational English and simple, honest, unambiguous wording.
Some things to keep in mind when it comes to the language used in your product:
- Not all users are fluent in the language used in your app
- Not all users are technical
- Not all users will understand jargon or slang
- Some users may be dyslexic
- Some users may respond more to visual instructions and cues
Usability testing with a diverse audience will really help eliminate any kinks in the language used by your app. See if they find any wording confusing or ambiguous, and if the descriptions and labelling of actions meet their expectations. See how they fare as they navigate through your app and try to complete a task. In some cases, pairing text and visual cues can really help get the point across. It also creates an interface that looks manageable and not too text heavy, so win win!
This may sound a bit harsh, but to badly paraphrase Einstein’s iconic quote: if you can’t explain how to perform an action or use an application in simple language, it may not be that easy to use in the first place.
As UX designers, we need to consider the broad spectrum of users that are accessing our product, as well as their unique needs and circumstances. To make our designs more inclusive we need to make sure they’re accessible to all no matter their abilities, that we’re catering to all relevant population groups, we’re accounting for different levels of access to technology, and we’re also expressing ourselves through clear, unambiguous language.