Summary: Inclusion is critical as a concept because it is at the heart of all UX activities and intentions. Including user behaviors, needs, and desires in design decisions is core to good UX Design. Including users with disabilities when improving or designing for Accessibility is critical. Finally, including target users in regions your product is used is vital for localization UX. Inclusive design is important to understand because it starts with understanding what is important to your audience, not your company or organization alone.
What is the basis of excluding users from a product development process?
There is a stronger tradition in software engineering of excluding users than there is of including users in the design and product development process. This stems from a few root causes:
1. Historically engineers were responsible for user interface design. "We don't use designers let alone talk to users!"
2. UX/UI Design was seen as a secondary priority, with code as the highest value product. "Ship it and skin it later".
3. Designers had a traditionally minimized role in design, so they were considered reactive or "window dressers". Or today "wireframers".
4. As a result, Designers or UX professionals were relegated to "clean-up" crew in a software development process. "We're done, now test it".
5. Including users was considered inefficient, a waste of time, unpredictable and with relatively little value. "We have user stories, that's close enough".
So excluding users was the norm, and still is in many organizations as well as in Emerging Markets like China and India. Note: We are seeing the same problems in American organizations as well as globally.
Leaving users out of product or service design decisions comes with a whole range of beliefs and excuses. The most common are: Not Enough Time; Not Enough Money; Users are Lazy, Unpredictable, or lacking in training. The idea is that you went to school, you have experience in your industry and therefore you know your organization's business, rules, and procedures better than any user. As a result, decisions are not made with user data aka evidenced behavior, instead, design decisions are made internally, by meeting after meeting-- or Zoom/ Teams meetings.
Organizations that do not align design decisions against user behavior and insights play the risky organizational game called Inside-Out Design. The notable co-inventor of Design Thinking, Steve Blank, stated the solution clearly: GOOB-- or Get Out of the Building. What he urged organizations was to get out of your office-centric assumptions and learn from your customers or end-users in their (problem-solving) environments. We call this Outside-In Design strategy.
More areas where User Exclusion rules: Disability and Localization
Digital Accessibility (making digital technology accessible for people with disabilities) has taken a long time to be noticed, and these days is evangelized by Google, Apple, IBM, and Microsoft. These companies represent the high performers in accessibility efforts, with senior-level roles prioritizing accessibility compliance. But these players are the exception....when was the last time you conducted an Accessibility Audit or discussed improving the accessibility of your mobile app or site, web application or your Augmented Reality product? Probably never, or not very often. If you did the conversation ended abruptly or was taken on as a pet project by the lone wolf advocate in your group.
Worse, the exclusion of users with disabilities in accessibility efforts seems to be the norm. Much of this comes down to unspoken stigma and lack of familiarity with how to approach UX design for Accessibility let alone users with disabilities. Most, if not all approaches to digital accessibility consist of using automated checker tools and W3 (WCAG 2.2) guidelines. For some reason, leaving users with disabilities out of the testing and optimizing process became the standard, from a case study Alison Gavine and I are presenting next week at the HCI 2020 conference:
Most approaches to accessibility follow a guideline, checklist or algorithmic approach to compliance checking. Software tools for testing accessibility continue to be developed to meet the demand. The problem with this technology-centric approach, is that users are rarely included in the testing process. As a result, assessing software defects with users with disabilities (Accessibility Testing) is rarely done.
Worse, trying to understand and design to user needs before beginning the design or optimization of accessibility, is even less frequently performed. User needs analysis, or ethnographic study, offers an opportunity for designers and developers to develop an advocacy approach to disability requirements. Field studies provide the ability to empathize as well as understand the context-of-use of a feature while using, for example a screen reader or magnifier. Understanding context-of-use in the accessibility user experience is rarely seen as a worthwhile effort. Official guidelines (e.g. W3C’s WCAG) fail to suggest its value and instead promote the technology-centric model to accessibility.
Yet we are told by some of the biggest voices in our field (Donald Norman) that empathy is over-rated or the wrong approach. Users with disabilities are always left out of these empathy battle discussions, yet it seems critical to understand how users with mobility, hearing, vision or cognitive impairments are interacting with Assistive Technology using sites, apps, and experiences. Note that on the empathy debate, Tim Brown (IDEO) believes empathy is a means to an end or vehicle for understanding user needs, not the solution itself.
Embracing Inclusive Design with User Advocacy is the key
- User Advocacy: Acknowledging users have active needs and should be heard and understood. Fighting for those needs where required. e.g. Doing research-based personas instead of making up personas for your project.
- Disability Advocacy: Including users with disabilities in Accessibility efforts, to validate and vet any gaps that checker tools or guidelines miss (Hint: it's a huge gap). Designing or optimizing for users with disabilities specific needs, usage scenarios, or Assistive Technology issues is needed. e.g. Fight for ALT tags on images so blind users can access icons and images.
- Localization Advocacy: Conducting global user research and basing a UX strategy from a Localization UX perspective means you are considering the impact of cultural sensitivity and fit. Translation is important but it is only 50% of localization. Observing cultural conditions, attitudes, and behaviors can illuminate the problem space. e.g. In Korea, there are two subway mapping apps, one for locals and one for foreigners or Korean-American users. Korean mobile apps emphasize time-saving (a Korean cultural value). Koreans say they are impatient, compared to Japanese who are demonstrably extremely patient and who’s culture emphasizes “kata”: the correct order, timing, sequence, and process to do something. The app for local Koreans had this cultural pattern reflected in the UI. Example from our global UX research on mobile payment systems...
Including users in your development process will lead to more inclusive design approaches over time. Start with regular contact with your users making sure to include users with disabilities, especially if optimizing digital accessibility. Whether your users are local (to your country) or in a region or 'locale' your product or service is serving, you have to start including them in your process. Designing by assumptions can hurt a quality UX effort as can technology-dependent solutions that leave out users. Starting by being more active with your advocacy and taking special positions on disability and localization will help you be a better UX champion.