Reaching audiences of the future through empathy and inclusion
Imagine it’s sometime in the future. Covid-19 has been somewhat contained where you are, and many people have decided to go back to the office on some days, and you’re one of them. Imagine that part of your commute to work involves a walk, and your walk takes you through various neighborhoods.
You pass a bus stop on your walk, and hear one person asking another how to find out when the next bus is coming using the app. Neither of them can figure out how it works. But someone else shows them how to text the bus route number to a number on the bus stop sign to find out how long they’ll need to wait.
You keep walking and you pass another person talking on the phone with someone, telling them they’ve just hailed a cab with an app and will meet them shortly. You hear them mention how even though the service isn’t a new one, they’re still struck by how convenient it is to hail and pay for a cab with an app.
Really picture all of these people.
You pass a café that just has window service. Some people are lining up to order and pay for their coffee, and you notice other patrons skipping the line and simply picking up their completed orders that they made earlier through an app.
A postal service van stops nearby and you watch the driver get out, open up the back of the van, and you see all of the packages with an Amazon logo. Or in India, you’d see the Flipkart logo. Or in Europe, maybe you’d see an Otto logo. You smile and think of all of the people who will be happy to get the packages they ordered that day.
You’re almost at work now, and you’re passing a big grocery store. You see some employees of a grocery delivery service coming out holding people’s online grocery orders. You notice one of the bags they’re carrying has one of your favorite snacks that you’ve run out of at home, and you make a mental note to order some yourself later. You find yourself imagining the person who ordered those groceries, and how they’re in for a treat later!
You get to your office, make your way to your team’s project area, and see the faces of your team members. You reflect that it’s collaboration with these team members that makes the experiences you work on great. You pause and consider a few of the people whose collaboration has taught you the most. Really think of them now.
Finally, you consider how you and your colleagues may have helped to make or influence the online experiences that you witnessed being used by people on your commute today. You think of those people, and I want you to really try to imagine them now:
- The people at the bus stop.
- The person hailing a cab with an app.
- The people picking up their coffees that they ordered.
- The people who would receive packages in the mail that they ordered.
- The person who ordered your favorite snack along with their groceries.
Really picture them. Now answer this question: Were any of the people you imagined elderly, or did any of them have a temporary or permanent disability?
While you’re considering that, also ask yourself this: When you thought of team members whose collaboration has taught you the most, did you think of anyone in a different discipline?
Impacts of unconscious bias in the creation of online experiences
I bet that for many of you, when you unconsciously imagine the people who use the digital experiences that we create at companies like Publicis Sapient, they don’t have disabilities and they’re not elderly. That’s a problem. It can be hard not to have this unconscious bias.
But meanwhile, 1 billion people worldwide have some kind of permanent disability¹ that would impact how they must access content and services online. They could be affected by anything from low vision, to someone who has a tremor in their hand and can’t use a mouse, to someone who is completely paralyzed and uses a puff and suck device to navigate online. It could be a member of the world’s aging population who doesn’t self-identify as needing an accessible website. So many people.
And yet research shows that less than 1% of websites are accessible² for this huge population of people with disabilities, and the even larger population which would include the elderly.
The elderly population is increasing³, by the way — the median age of the world is increasing. This population of seniors and instances of age-related disability is only going to get larger.
Statistics show that by 2050, the number of individuals older than 60 years will be approximately 2 billion and will account for 22% of the world’s population. As a contrast, today only about 9% of the world is over 60⁴.
And that group of seniors is going to be us. Today, if a website doesn’t work, my dad assumes it’s his fault. But we are internet-savvy, and we are not going to just take it if experiences stop working for us, because the way we need to navigate changes over time.
As people whose job it is to create online experiences, our unconscious bias of what our users are like means that we aren’t considering these groups up front in our experience design and development. So not only are we excluding people (over a billion people), when we don’t consider people’s diverse needs, we are not exploring the full potential of what our experiences could be.
Now is a pivotal moment
We already know that diversity makes for more creative solutions and can solve problems better. Diverse teams have been shown to have better ideas, better conversations, and more innovative outcomes. The benefits come both from having diverse teams, and designing for a diverse audience.
Politician and civil rights activist Jesse Jackson says, Inclusion is not a matter of political correctness. It is the key to growth. We’re actually in the midst of a pivotal moment in the world. I’m sure you can feel it. It feels like a reckoning.
Trends in society are not only giving us permission, but are also demanding that we be more inclusive.
Fighting gender discrimination. #TogetherWeRise. #MeToo. When we witness injustice, we’re gaining more of a vocabulary to say “this is not right,” we’re more comfortable being allies and raising our voices. It’s becoming part of our culture.
There’s a constant reminder that we don’t know what we don’t know and that’s okay. But there’s an imperative now to ask, and to be open to hearing an answer we didn’t expect.
There’s more empathy for people who have not been included in the past, and a renewed urgency to make things right. As there should be.
Disability rights are being named a major campaign issue for the US election this year. Not that any of the candidates had accessible websites.
We’re also in the middle of a global pandemic that’s isolating people in their homes, and worse, exacerbating the issue of accessibility to online content and services for people with disabilities and the elderly⁵.
I’m sure we’ve all ordered something online recently to avoid being exposed to Covid-19. How would you feel if none of the websites worked for the way you navigated? How do you feel, if you’re a designer, developer, or otherwise contribute to the creation of online experiences, and you directly have the power to influence the accessibility of online experiences? We have a huge responsibility.
This is a time when we’re under duress and we need to reinvent ourselves and how we work. This is a difficult time, but also an opportunity to awake collectively on the planet. We always should have been focusing on creating inclusive experiences, but forces in the world are combining to make the present an excellent time to refocus on this endeavour.
I am writing this blog post to tell you how we can finally solve this problem of equal access to online content and services for everyone.
The key to creating inclusive experiences is having empathy for our users and empathy for each other across creative and technology disciplines.
What it means to have empathy for our users
How do we get to a place where we’re feeling what our users feel when they navigate our experiences? Donald Norman, who was the first Experience Architect in 1993 at Apple, and the first to use the term “experience design”, said this: We are designing things for people, so we need to understand both technology and people.
Empathy for our users starts with understanding how they use the experiences we create, which requires an understanding of native browser controls, custom controls, and common interaction paradigms. These are our tools, this is our machine that we have to work with and I’m going to keep calling it “our machine.”
Would it surprise you if I suggested that your conceptual model of how Our Machine works is incomplete?
Would you ask someone who has only ever driven a car to design the perfect bike? Of course not. You wouldn’t ask them because they wouldn’t be qualified. But that’s what we’re asking designers and developers to do, when they have never used Our Machine the same way that many of our users do, who are people with disabilities, or the elderly.
So what’s a way that people use Our Machine that you may not have considered?
How about navigating with a keyboard alone? Most of us are accustomed to navigating with a mouse pointing device, so we create experiences that work really well for a mouse user. But a mouse user can access content in any order. A huge cursor is highlighted on the mouse user’s screen in the image below. We all know how a mouse works. You can move that cursor wherever you want and access whatever content you want in whatever order.
A keyboard user, on the other hand, has to navigate in a linear way through the content, unless we build shortcuts into our design. You can probably imagine that the keyboard user’s experience would be vastly different than a mouse user’s just due to how they must navigate.
This is just one small difference of many in navigation paradigms that most designers and developers don’t consider, or test. But the design must account for these use cases, which are all part of Our Machine.
Many skilled people from our spectrum of disciplines who can deliver complex experiences still aren’t aware of the basic functionalities of our machine, like these common HTML5 semantic elements:
- What heading levels actually mean and how they should be used.
- Why radio buttons and checkboxes must be grouped with a fieldset legend.
- Why we need to programmatically associate labels with text fields.
- Even something as straightforward as a list.
The way these things are coded affects the experience, but usually, coding decisions are made by a developer alone, with no input from an experience designer.
White light is a 90s web designer
I called it “our spectrum of disciplines” and I like that analogy, because it explains how we got to this point. We probably all know how a prism works. I was looking at this recently in my son’s grade 4 summer school science class. White light enters a prism, and it’s refracted into all of the colours of the rainbow on the other side.
Think of white light as a 90s web designer. Those of us who were working in the 90s and the mid-2000s remember being hired as web designers or, my favourite title, “web masters,” back when a single person was expected to perform all of the functions to create web experiences.
That’s back when all you needed to know to be awesome was some HTML, some tables for layout, a little bit of JavaScript once it came out, and how to make an animated gif in Photoshop.
The complexity of the modern web needs a spectrum of roles
But as the years passed, our roles narrowed and split. Think of the prism as Web 2.0. Experiences became more dynamic and more complicated.
Frontend developers focused on the changing versions of HTML, JavaScript, and CSS, different version control systems, some things we don’t even use anymore like Flash, the development of JavaScript and CSS frameworks that we had to learn, different ones for each project.
Meanwhile, the design discipline took its own journey, with people becoming visual designers or experience designers, coming from diverse fields of human factors and psychology, learning their own ever-changing toolset for wireframing and graphic production. Always having to consider usability and evolving interaction patterns. Then came responsive design and design systems.
This narrow specialization has led to us forgetting some of the basics of our craft. Jeffrey Zeldman, Father of Web Standards from back when web designers were white light, saw this coming and said,
“When we focus so much on mastering an ever-changing torrent of tools and frameworks, we risk forgetting that the purpose of design is to help people.”
— Jeffrey Zeldman, “Father of Web Standards”
We need to come back to the machine, to Our Machine, and complete our conceptual model of how it works for diverse groups. This is critically important because, the way a developer codes something changes the experience. With the increased complexity of our machine, we’ve gotten to a place where the experience designer doesn’t know code, and the developer doesn’t know experience.
So what can go wrong?
A quick example would be all the things that can go wrong in the implementation of an “edit address” button. Here’s an interface with icon buttons to allow a user to edit each of their saved addresses. The requirement is that when a user activates the button, they can edit a particular address inline on the same page.
The first thing that can go wrong is that the descriptive label for the edit button, the one the screen reader announces, doesn’t get defined in the requirements, so the developer leaves it empty. Now, when the user’s focus is on the button, the screen reader will announce only, “Button,” because no label has been defined.
People won’t know what this button does, unless they can see. This issue happens because people capturing the requirements forget to define a text label when there’s no visible text label in the design. In this case, content creators are not being empathetic with screen reader users.
There are variations on this issue. Depending on how we code it, sometimes the image filename can get announced when there’s no other label defined. “Button, pencil.png” is not much more helpful than “button”.
The second thing that can go wrong is, let’s say there was a label defined, but the developer decides to code this icon button as a link. The screen reader will announce, “Link, edit”.
Did you know that links, by definition, take users to another destination? An experienced user, hearing that this is a link, will assume the edit function will take them to a different page, just because it’s coded as a link. When it doesn’t take them to a new page, this will be confusing. The developer needs to code this as a button, because by definition, buttons perform scripted actions on the same page. This is a relevant way that our machine works. But it’s rarely ever discussed or captured in requirements.
The last thing that can happen, if proper requirements are gathered, is the button can be coded correctly with a unique, descriptive label, so that the screen reader would announce something like, “Button, edit address 1.” But this hardly ever happens unless it is purposeful, unless everyone involved knows the deeper aspects of our machine.
Think back to the last requirements you wrote, or were given, and ask yourselves if they were complete. If we don’t capture the keyboard focus event, if nobody thinks about interaction roles, and screen reader labels aren’t explicitly defined, the full requirements have not been captured.
The hardest part of design is getting the requirements right.
— Donald Norman
Back to our friend Donald Norman. He says that the hardest part of design is getting the requirements right⁷. And I get it that it’s really tough to know enough about our machine to understand what all of its capabilities even are. That’s where the next part of empathy comes in — empathy for people of other disciplines, who can help round out our knowledge of the machine, and ensure each others’ voices are heard.
What it means to have empathy across creative and technology disciplines
At Publicis Sapient, one of our core values is Inclusive Collaboration. Our teams demonstrate a range of abilities, specialties, life stages, situations, and ages to lend a variety of perspectives to our thinking up front. And we also need people to have a deep interest and curiosity in adjacent disciplines. We must consider our disciplines as overlapping.
How many times have you heard a developer say, after she has built a strange experience that the client immediately wants to change, “I thought it seemed odd, but the user experience is none of my business.”?
How many times have you heard an experience designer say, “That’s not how I wanted it to work,” or “I didn’t know that side effect would occur if we designed it this way.”?
Depending what project you’re on, the project can be led a bit more by design, or a bit more by engineering. Without purposefully seeking collaboration with another discipline, things can get siloed. Of course, this is further complicated if another agency is doing the design or development, which happens sometimes.
We need both the experience design and experience technology points of view to create good experiences because Our Machine has become so complex that nobody can know everything.
If giving voice to people from other disciplines has not been enabled by our project’s processes, we need to make it happen ourselves, and we need to explain the urgency to our delivery leads.
We need to be allies for other disciplines and not be afraid to ask each other questions about the WHY and the HOW of our experiences. The key to making this happen is not wondering how it can happen, the key is just to do it from now on in your own work.
We must challenge our own assumptions about our roles within our disciplines.
What can I decide about the user experience as a developer? What should I decide? Is it up to me if a user experiences content as a list, a menu, a footer, or a complimentary section? It kind of is right now, because as a developer, I’m making the coding decisions, mostly unchecked.
- Some developers would use all non-semantic elements.
- Other developers would go as far as to mark up an e-commerce product tile with an article tag.
- But what does the article tag even mean, or do, and is that how an experience designer would describe the content?
These aren’t meaningless questions. They affect the experience. They’ll spark conversations that make our work better.
The “Whose job is it anyway?” question and answer section
Question 1: Is it the job of a designer or developer to design how the navigation will work for a keyboard and screen reader user?
Answer 1: Both. Different markup will affect the experience. It should be purposeful, and that needs an experience designer’s point of view, combined with a frontend developer’s knowledge of HTML.
Question 2: What if the style guide describes heading styles by HTML heading level, implying, for example, that H3 headings will always have the same visual style? As a developer, I know in practice that’s never true. After all, for a componentized website, the content for each page has not even been written yet. There’s no way we could guarantee that all headings that look a certain way in a particular component would always represent a level 3 heading within a page’s content hierarchy. Should I explain this to the designer and ask them to amend the nomenclature in the style guide?
Answer 2: Yes. Our style guide should be accurate.
Question 3: What if the requirements refer to all interactive elements on the site as “buttons” because they look like the designer’s idea of a button? Should I code them all as buttons, or should I ask how each one is meant to behave? Should I let the designer know there’s a difference so they can use the right language in the style guide?
Answer 3: Yes. Ask how things are meant to work. Explain the options and what they mean.
Question 4: What if there’s a glaring accessibility mistake in the design, but it’s technically feasible for me to build it that way? Do I say something, or do I say, “the design is not my job.”?
Answer 4: It’s all of our job. These are areas where we must collaborate.
We need to stop assuming and start asking each other questions and challenging each other. If you see something that’s wrong, then share what the problem is, and get it fixed.
Developers, ask the designer about the “why” of an experience. Designers, ask the developer “how.” In the long run, stopping to ask these questions will make us faster and our experiences better.
Collaboration misconceptions
But people tell me that although they’d love to stop and ask these questions, unfortunately, they don’t have time.
It’s a misconception that when we collaborate more, things take longer overall. This was an idea that was blown out of the water in an industry much older than ours, the automotive industry, when companies transitioned from mass production to lean production. It’s worth it to take a minute and look at some of the parallels, and take some learnings from history.
Historical proof that collaboration increases productivity and quality
In the early 1900s, Henry Ford implemented a manufacturing process that came to be known as mass production to increase the productivity of his factories. Some of the facets of the mass production model included:
- Narrowing people’s skillsets so that different people could do more specific things faster.
- Focusing on the speed of getting to the next step, and never “stopping the assembly line” to fix a problem.
- It got so that workers were less likely to even find mistakes early because they no longer knew enough about other parts of the system to recognize and fix them.
- Workers who DID notice problems held back their knowledge to avoid stopping the line.
- Mass production relied on checkers to find mistakes at the end, and errors were compounded as they moved down the line, and ended up taking way longer to fix.
Sounds familiar? Separation of labor and a lack of teamwork led to the failures of mass production. How did the auto industry evolve to overcome these issues? Process improvements made much later by Toyota created the Lean Production model⁸.
- Lean production called for workers to broaden their skills, not narrow them. It was more important to know about teamwork than it was to know a narrow specialty.
- Lean production had skilled workers who could recognize issues early, and who felt empowered to “stop the line” when issues were found. Then the entire team gathered to understand and fix the issue. This led to so much continuous improvement in skills for everyone that soon the line no longer had to stop.
- Lean production mindset promotes sharing knowledge, asking questions, and proactively initiating improvements.
- …And it’s faster. Implementing lean production methods required much less rework and steadily improved the quality.
In our industry, as in the auto industry, having empathy for each other across disciplines will allow our work to be informed by a larger context, and it’s the second piece of the puzzle to ensuring the experiences we deliver are inclusive.
What you can do now:
- Learn as much as you can about Our Machine, the native browser toolset and what semantic elements are meant to do.
- Learn how to use a screen reader and understand how some people with disabilities navigate online. Watch a screen reader user on YouTube.
- Start by just trying to navigate with your keyboard.
- Consider the elderly and people with disabilities up front in your design — they should be included in personas. This is the audience of now and the future.
- Don’t make assumptions. Instead, ask questions.
- Ask “why” and “how.” Run your idea past someone of a different discipline and see what happens.
We have had the tools to make inclusive experiences for a long time, but not the processes, and not necessarily the mindset. Now’s the time. An old saying from another design discipline, the field of architecture, is that the best time to plant a tree is 20 years ago. The next best time is today.
About the author:
Alison Walden is a Senior Director of Technology at Publicis Sapient’s Toronto office, and Accessibility Service Lead. She helps our clients transform their organizations by empowering them with the knowledge and tools they need to support their ongoing creation of accessible experiences. Alison has been building and expanding Publicis Sapient’s accessibility capabilities for over 15 years through internal and external training, hackathons, road shows and public speaking opportunities.
References:
- [1] https://www.worldbank.org/en/topic/disability
- [2] https://www.abilitynet.org.uk/news-blogs/less-1-website-home-pages-are-likely-meet-accessibility-standards
- [3] https://ourworldindata.org/age-structure
- [4] https://www.statista.com/statistics/265759/world-population-by-age-and-region/
- [5] https://www.worldbank.org/en/topic/disability
- [6] https://www.creativeboom.com/features/jeffrey-zeldman-on-agency-life-the-changing-web-and-why-he-had-to-get-back-to-his-roots/
- [7] Donald Norman, The Design of Everyday Things
- [8] https://sloanreview.mit.edu/article/manufacturing-innovation-lessons-from-the-japanese-auto-industry/
