A presentation at IIBA Speaker Series in in Toronto, ON, Canada by Hala Anwar
Today, we will be talking about how to build inclusive products, how our unconscious biases can impact the product development life cycle, and what we can do as BAs or PMs to counteract bias in our product.
We will begin with an interactive exercise, followed by examining some examples of why inclusive thinking is important. We will then dive into each stage of the product life cycle and talk about what you can do to add an inclusive touch along the way.
What you will see today is not an exhaustive list of techniques you can implement. I’ll share with you some best practices that have worked for my team and I’ve seen similar versions from our colleagues over at TPG, Adobe, etc.
The slides will be available to download and I will of course be verbally describing any diagrams that are on screen.
Just to set the stage, with a show of hands, do you mind sharing who here considers themselves a:
Designer?
Developer?
Business Analyst?
Product Manager?
Project Manager?
QA?
Anyone else?
Thank you for sharing! Over the course of my career, I feel like I have had the opportunity to try out a lot of those roles.
A: My journey began in undergrad as a software developer. When I graduated, I realized studying SW nurtured a lot of my critical thinking skills, which would later be ‘critical’ for my role as a product manager. At that time though, I felt two things were missing: 1. client interaction, 2. decision-making power.
B: I took a hard right turn into my job as a BA for a NATO contractor.
C: At the same time, I was teaching graphic design at a local university; it had always been something I dabbled in on the side and felt like an outlet for creativity.
D: Finally when I had enough of a daily 4 hour commute in Dubai, I applied to study Human-Computer Interaction at the University of Waterloo, which was an amalgamation of my interests hitherto. I worked as a UX researcher at the university for 3 years, really sharpening my design thinking skills.
E: I then joined Consulting when I moved to Toronto where I have been able to try out this spectrum of roles. Since I was predominantly working with a government clients, I came across ‘accessibility’ which was part of everyone’s job, but no one knew anything about it and it was just considered this ‘black box’ of regulation.
I have an amazing mentor, Jan Richards, who helped shaped the one big realization, that I’m here to share with your today…
Whether we realize it or not, our products decide who participates, who benefits, and who counts in society.
We have a tendency to build products for ourselves or the people around us. We use our own abilities and experiences as a baseline for our designs.
We tend to think of product design as:
We may even say “People with disabilities are not in our intended audience or userbase.”
We think of these special features as costing too much, for which we don’t have the time or resources. If push comes to shove, we say “Lets get this MVP out. We’ll add those features in Phase 2.”
Many of these misconceptions stem from a lack of knowledge about accessible and inclusive product development. Where in our education do we learn inclusive skills? Most of the people who are in leadership roles now did not learn about it from any of their engineering, design, or business courses. Accessibility or psychology weren’t required curricula for learning how to develop technology.
As a result, many people just don’t know what it entails or where to start.
If they work in Banks, Governments, or Universities, or have clients that do so, they may have heard horror stories about accessibility being a requirement or legal mandate. They know they HAVE to do it. But since they don’t have sufficient knowledge about inclusive design, it is rarely baked into the project plan. So projects will try to get away by tacking it on at the end of the project and doing the bare minimum to be ‘compliant’ in order to satisfy a loud stakeholder.
As we’ll see later on in this presentation, that will come back to haunt them.
So why don’t projects consider accessible and inclusive development?
The people in charge either don’t know about it so it doesn’t get factored into the project timeline or budget, expect the designers to take care of it, think it costs too much, or don’t think it is necessary for their user base.
I want to pause here to get input from you on some of the excuses you may have heard from your stakeholders or project managers.
[Input from audience]
Thank you for sharing. My goal with this presentation today is to help dispel some of these misconceptions around accessible and inclusive design.
On the screen right now, I have an early version of the Xbox 360 controller, used to play video games.
I’d like you now to think of some of the issues an elderly relative (like your mother or grandmother) might have trying to play a game on the Xbox.
Possible issues:
Low color contrast, colorblind
Black controls on black base
Indistinguishable letters on buttons, small font size => effectively using colors to identify buttons, placement of buttons can be used to identify buttons but some games will tell you to press the ‘A’ key
Mobility/Dexterity impairment: Challenges with fine motor control, low strength, single-handedness
Voice Control: Difficult for someone with a stutter, or who doesn’t speak the language
Cognitive Difficulty: So many buttons! Hulk smash!
Less obvious one: People with low internet bandwidth may have trouble connecting to Xbox online if low res options aren’t provided
Please note: Even though I used the Xbox360 controller as an example, I want to note that Microsoft is doing stellar inclusive design work. You will see a lot of good resources from them throughout the talk today. They have acknowledged the shortcomings of the original controller and have released an adaptive controller to mitigate that.
I think it is very important to say here that the lesson isn’t to release an extra product on top of your current product. That is expensive for the user and the company. And in terms of UX, being the only one with a different controller in a group of gamers would very much make me feel ‘different’.
The lesson today is to acknowledge the importance of inclusive thinking from the very start of the project and the benefits it brings.
When assistive technologies benefit everyone, it is known as the ‘Curb Cut Effect’. The term was coined based on the slopes that you see on sidewalks. These were originally introduced for veterans coming home from World War 2 in wheelchairs. People quickly realized their enormous benefit to the larger community, whether it was a family with a stroller, a skateboarder, someone lugging along groceries, etc.
Similarly, captions were originally introduced to help the hard of hearing; however, I benefit from them everyday when I’m watching news clips on my phone while waiting for the bus without headphones, or on the tv at Real Sports bar.
Likewise, think of Live Chat. Its so convenient. Being overcharged on your monthly bill sucks. Thanks to Live Chat, you (almost) never have to wait on hold for hours with your service provider anymore. It’s a feature that has made life so much easier for us. But for those that cannot hear, it makes it possible for them to complain to their telecom provider about their bill.
Accessibility can be the difference between people being able to use your product. There are a lot of misconceptions surrounding accessibility, but really it is simply ‘making your product available to use’.
Accessibility is the foundation of usability, which is ‘making your product easier to use’. The more accessible your product, the more usable it will be, but you can also make further enhancements to make it more usable. e.g. having a more efficient checkout process with less steps.
Accessibility, Usability, and Diversity intertwine to give us the Inclusive Design Method, which is the process of designing your products to be easier to use for more people. Designing inclusively doesn’t mean you’re making one thing for all people. You’re designing a diversity of ways for everyone to participate in an experience with a sense of belonging.
In this presentation today, we’ve already seen an example of how a product such as the Xbox Controller can benefit from being more accessible. I also wanted to share a few examples of how diversity can make a big difference.
On the screen, we have a photo of an Asian woman taking a selfie on her camera. The camera prompts her to retake the photo with a message “Did someone blink?”. This photo was posted with the title “Racist Camera! No, I did not blink… I’m just Asian!”
In another notorious example, we have a group of photos shown in Google Photos. The photos have been auto-tagged with the following titles: skyscrapers, airplanes, cars, bikes, etc. There is a photo of an African-American man and woman which were auto-tagged as ‘Gorillas’. The tweet author wrote “Google Photos, y’all effed up. My friend’s not a gorilla.”
Now both of these products were presumably tested on a homogenous sample. Only 1-2% of Google’s workforce is African-American. Not having a diverse user group in the design process for these products resulted in these users not being treated with respect and dignity.
Racist Soap Dispenser
Names such as ‘Hu’ not being accepted on your product. Indigenous names such as Creepingbear not accepted on Facebook.
Even worse, user diversity in some product development process could make the difference between life and death. The team who developed the original air-bags in cars was all-male. The airbags they built and tested used measurements for a standard man. The unintended and tragic consequence was that women and children were killed when those early airbags were deployed.
In all the scenarios we just discussed, the users were all able-bodied in the traditional sense. Yet, they were not able to use the product to disastrous effect. People aren’t disabled, its the environment and products that are disabling when you design for the “average” user. Inclusive design emphasizes our responsibility to solve for mismatches between humans and their products, environments, and social structures.
So how can you help make products that work for as many people as possible? We’ll take a look at the product life cycle and explore adding inclusive touches at each stage.
Accessible and inclusive thinking starts in the Discovery stage with research that considers diverse user groups. It continues on as the team channels this user research into creating representative personas.
BAs and Product Managers will use these personas to create requirements and user stories, making sure to capture accessibility acceptance criteria.
In the ideation phase, the designer sketches out wireframes with accessibility annotations.
It is very important to lay the groundwork in considering and capturing this information in these early stages.
Since a lot of the BA and PM work happens upfront, we’ll be focusing on the Discovery and Definition stage in today’s talk.
BABOK Mapping: Business Analysis Planning & Monitoring
Everyone on the team needs to play their part to develop an inclusive experience for the end user.
The Product Manager plays a huge part as they regularly decide what the priorities are (must-haves vs nice-to-haves), which features go forward, which are “parked”, and keep the team accountable. The Product Manager needs to set the expectation that the Designers, Developers, and Testers are responsible for their parts.
In addition, the Product Manager needs to be the champion and the voice for the users when talking to the business or sponsor. And its tough because there is going to be pushback. But they need to be the ones to make the case for inclusive design and get buy-in from all the stakeholders.
Fortunately for us, WebAIM has done a lot of the work for us in listing out six different ways to motivate your stakeholders.
If your stakeholders aren’t readily on board with inclusive design, find out what your stakeholders do want to improve. It could be improving revenues, increasing the number of new customers, increasing the sales from existing customers, or increasing shareholder value. Once you start talking about what the stakeholders are already convinced of, it becomes easier to get them to make investments. You’re no longer trying to get them to change their focus. You’re playing directly into their main field of attention.
The low hanging fruit is to use the AODA to motivate your stakeholders. However, this is most likely only going to motivate them to do the minimum amount possible to avoid a lawsuit. With this route, you also run the risk of painting people with disabilities as enemies or antagonists to the project budget and timeline.
If you’re not familiar with the AODA, it stands for the Accessibility for Ontarians with Disabilities Act.
It was established in 2005 with a goal of creating a fully accessible province by 2025. Looking at digital accessibility specifically, this applies to websites, videos, apps, and pdfs.
After 2014, new public websites, refreshed websites and any new web content must meet WCAG 2.0 Level A
After 2021, All public websites and web content must meet WCAG 2.0 Level AA*
WCAG: Web Content Accessibility Guidelines (WCAG) 2.0, now WCAG 2.1
WCAG 2.0 has three levels, each with a list of testable success criteria:
Level A addresses basic accessibility issues, such as providing text alternatives for non-text content, such as images.
Level AA goes further, addressing the major, most common accessibility issues.
Level AAA is the highest standard
1+ billion disabled people globally
Spending power = $6+ trillion
Designing for a disability (e.g. one arm) extends the benefits to those with a temporary impairment (e.g. wrist injury) or situational circumstance (e.g. new parent with a baby).
Higher Search Engine Ranking
The later a change is introduced into a design, the more costly that change is to delivery.
Similar to retrofitting a building for accessibility, retrofitting a product for accessibility can be tough and time-consuming.
For example: You may design a complex workflow to complete a task. If you haven’t considered accessibility up front, you could discover that some of the elements are not compliant.
=> You could end up having to redesign and rebuild the entire workflow from scratch or with bandaid solutions that aren’t great in the long term. E.g. disabled buttons
=> You’ll lose users in the process: first, those who could not use your product in the first place, and second, those who resent that you changed a workflow they had become accustomed to as you roll out your “fixes.”
Accessibility features in products and services often solve unanticipated problems.
Enhance Your Brand (e.g. Diversity and inclusion efforts)
Minimize Legal Risk
In 2017, 22% of Canadians had at least one disability. This represents 6.2 million people.
Some of the main categories of disabilities, limitations, or constraints that affect how people use digital services:
Mobility problems (hand tremors, physical deformities or amputations)
Vision disabilities (blindness and low vision, color blindness)
Hearing disabilities (deafness and low hearing, tinnitus)
Cognitive disorders (dyslexia, dementia, or being sleep deprived)
Designing for our future selves
People are living longer and having fewer children, resulting in an aging population that is expected to be a key factor in the doubling of the number of people with disabilities in the next two decades.
Available in different ways
Accessible experiences are not just for users with disabilities – they’re good for any user who wants to access content when they want, wherever they want, via the interfaces, inputs and outputs they want.
Almost everyone experiences some type of disability in their lifetime, either permanently, temporarily, or situationally.
As an example: having only one arm is a permanent condition, having an arm in a cast is temporary, and holding a baby in one arm is situational – but in each case you’re restricted to completing tasks with one arm. When I get home from work and have a plate of food in one hand and a drink in the other, I will use my Google Home and Chromecast to cue up an episode. Voice Control is assistive technology.
Designing for extreme use cases / outliers results in a design process that leads to greater success in developing products that are more easily used by everyone. This is captured really well in this spectrum for the Microsoft Inclusive Design toolkit. It’s a quick tool to help foster empathy and to show how a solution scales to a broader audience.
How have you benefited from solutions that were originally designed for someone with different abilities?
[Input from audience]
Examples of situational limitations include using the Web on a mobile phone when your eyes are busy (such as driving), in bright sunlight, in a dark room, when your hands are full, in a quiet environment (where you don’t want it to make noise), in a noisy environment (where you can’t hear well), and in an emergency (when you may not be thinking clearly).
BABOK Mapping: Elicitation & Collaboration
I was first introduced to accessible and inclusive design while researching the work practices and challenges of Live Action Roleplayers (LARP) at the University of Waterloo. For those not familiar with LARPing, it is a form of role-playing where the participants interact with each other, make choices, and act out storylines while remaining fully immersed in character.
For the game organizers, this entailed tracking a lot of information on pieces of paper (the overall storyline, each plot twist, player arsenal and XP, etc.). The organizers couldn’t be everywhere at once so sometimes the players would need to relay story progress to them after the fact for tracking purposes. Our goal then was to identify opportunities where technology could be seamlessly introduced to make the organizers’ lives easier.
We initially thought “How great would it be if both the players and storytellers had an app, where they could track all this information from the palm of their hands?” It sounded so convenient, but we quickly realized:
LARPers hail from a variety of backgrounds with different abilities, and even income level. You could have tech savvy participants from Google alongside the homeless guy from down the street who doesn’t even own a phone. We could make this app accessible by coding it right, but it would not be inclusive.
The use of phones and other technology is often frowned upon during LARPing events as it can break the players out of the fantasy setting. Do you really want to be engaged in a battle with a knight in a medieval era, who pauses the fight to take a selfie?
We are so quick to make technology the answer for everything, without considering who it may be leaving out.
User Research should reflect the diverse abilities, circumstances, and backgrounds of your actual users. Include a range of ages, races, locations, devices, interests, abilities, languages, English proficiency, gender identities, sexual orientations, and access to reliable internet. Include people who aren’t using the product but would like to; e.g. review complaints.
Sources of information when developing user group profiles for a new product include: general market research customers of competitors’ products focus group sessions interviews with and observations of prospective users.
User group profiles for an enhancement of an existing product might be based on: surveys focus groups contextual interviews, and usability tests of the current version of the product.
Fictional characterization of a user Help us gain a better understanding of our customers’ needs and anticipate how they might act in situations “What do you think Trevor would feel about this design decision?” Amalgamation of attributes that we imagine our average customer has (often unconscious stereotypes), but actually represent no one. e.g. creating a persona for a Republican
In addition to potential visual, hearing, motor, and cognitive disabilities, it is important to consider language literacy, digital literacy, finances, and digital access of your users.
Is your product accessible to someone with a low internet bandwidth?
A lot of new users are now coming online from Emerging markets such as India, Indonesia, Brazil, and Nigeria. They do so primarily with an older Android phone on a slow unreliable connection.
86% Android, 13% iOS, 1% Blackberry, Windows Phone, Nokia, etc This is a good example of the number of users you’re liable to miss out on if you create an iOS-only app.
By designing with the Next Billion Users in mind, you open your product up to older users, those with lower literacy or those who aren’t fluent in the language used by your product, people with slow internet connections or those without the financial means to upgrade to the latest technologies.
At this stage, you’ve got your stakeholders on board and done extensive research with a diverse user group. What’s next?
Based on your elicitation results from the diverse user group, you’re going to start writing requirements or user stories.
Your role is crucial in determining what the users actually need from the product. On the screen right now, I have a map of different clinic locations in Toronto with little pins on it. Next to the map is a list of the clinics and phone numbers. You as the BA or Product Manager are responsible for determining what content is displayed here. This page could be technically accessible, but if the patients are spending a lot of time circling the building trying to find the wheelchair ramp entrance, then it is not inclusive.
Shared understanding of the need, the solution, and the value for the user. Contains just enough information so that developers can produce a reasonable estimate of the effort to implement it and tests can be written to validate it. To ensure accessibility is implemented properly, make sure to write accessibility criteria into every user story.
Common Questions:
Depends on the strengths and weaknesses of your developers and testers
Yes, but in the same way automated testing makes stories take longer to build. It is a part of building quality software and speeds the team up in the long run.
For example: story passes the functional acceptance criteria (I click the button and it does what I expect) but fails the accessibility criteria (I tab to the button, but the screen reader doesn’t read the label correctly) It is incredibly tempting to accept the story but “split out the accessibility stuff for the next iteration”. Don’t do this. If you, as the product manager, won’t take these requirements seriously, your development team likely won’t either. This will result in many accessibility requirements being “deferred”, and before long you have a big backlog of accessibility debt to tackle and users who can’t use your product. In addition: if you try to separate out the accessibility criteria from the core story, you may find that you have designed yourself into a corner that can’t be built in an accessible way, and end up requiring rework.
Acceptance Criteria:
Not an exhaustive list. Get to know your designers’ and developers’ strengths and weaknesses, and modify the acceptance criteria accordingly. Ideally done in tandem with Diverse Personas and Accessibility Specification document.
Create reusable templates for user stories and high-level requirements. More reusable if represented in a general manner, without direct ties to a particular tool or feature. Remember to update templates as new guidelines are rolled out to ensure they remain valid over time.
Inclusive Design is the process of designing your products to be easier to use for more people. Designing inclusively doesn’t mean you’re making one thing for all people. You’re designing a diversity of ways for everyone to participate in an experience with a sense of belonging.
When a new accessibility issue arises that you may have missed, prioritize those issues appropriately against other development concerns.
Inclusive Design can make the difference in creating a world that works for everyone, as opposed to one that works for only a few. It deserves dedicated thinking and planning, and should be integrated into your organization’s processes (e.g. criteria for Project Sign-Off)
Many of us are only temporarily able-bodied. At any given moment, we could be juggling multiple tasks that take an eye, ear, or finger away. We could be preoccupied, sick, or stressed. Our need for an accessible web might last a minute, a day, or the rest of our lives. We never know. When it’s our turn, we will want the web to work for us.
Twitter: @halathinkeths
Email: hello@halaanwar.com
Slides: www.halaanwar.com
I’ll leave you with some feels..
https://www.youtube.com/watch?v=CM2QJO2IDFo&t=1s
Accessibility bugs have long been thorns in the development team’s side since accessibility testing traditionally only took place as an afterthought near the end of the product life cycle. However, inclusive thinking really starts long before the first wireframe is sketched out or a single line of code is ever written.
Business Analysts have traditionally been trained to emphasize Business and Enterprise Change. However, with the introduction of Agile Methodologies, the focus has changed from ‘Deliverables’ to ‘Customer Collaboration and User Experience’. BAs and Product Managers need to be user-centric to build great products, but they often stop short and focus only on generic use cases.
This interactive talk will provide examples of how business analysts, and product owners can incorporate inclusive thinking into their existing toolkit (e.g. diverse personas, user stories) and start designing usable experiences that reduce the impact on the development team’s velocity.
The following resources were mentioned during the presentation or are useful additional information.
for free. You
can too.