Supporting accessibility design at IBM

Summary 6 interns (including me) explored how we might provide IBMers with the support they need in order to create accessible products. After 7.5 weeks, we delivered hi-fi prototypes, curated content (part of which is live on Carbon Design System 🎉), social campaign plans, and a project road map. Certain details omitted on purpose.

Contributions As a UX intern, I worked on both research (user interviewing and surveying) + design (journey mapping and prototyping) part of the process. I also took the lead on creating team presentation materials.

Affiliation IBM Design

Team Members Kate Moon, Steven Parker, Josefina Mancilla, Gene Hu, Ajay Rayasam. Special thanks to Bo Campbell, Mary Jo Mueller, and Charu Pandhi.

1: Introduction. The state of accessibility design at IBM

IBM offerings serve users worldwide; the sheer scale and impact mean that every detail matters. However, as it stands, roughly half the offerings do not meet accessibility standards. To better understand how these standards integrate into the design cycle of product teams, we set down some questions:

Our process
Our methodologically messy approach. Everything was iterative.

Before diving in further, the above chart illustrates our process. Naturally, we adopted the IBM design thinking framework. Throughout the research and design process, each phase comprised of observing, making, and reflecting (not in that particular order). For example, prototyping involved making the screens, reflecting on how we could improve them, and observing how people engaged with our artifacts.

2: Empathizing with the product teams. How does accessibility design get (de)prioritized?

To get up-to-speed with the accessibility design space, we spent 2 days reading through the 8 resources that IBMers use; some internal, some external. Once we felt comfortable with the basics, we started scheduling user interviews. Kate compiled some topics to help us guide the conversations, which all centered around their work experience with regards to accessibility. 14 interviews led to the following findings:

We consolidated the findings into the following statement: the current methodology of accessibility design used by design practitioners is not sustainable. Accessibility requirements are not always prioritized by product teams, leading to negligence or afterthought thereof. This is problematic from two perspectives:

  1. By releasing products and services that are not accessible, IBM is excluding people with various abilities, in various situations, to enjoy and use them. The financial and humanitarian implications are huge.
  2. By not incorporating accessibility design early on in the process, product teams may suffer when accessible features have to be included. This often leads to last-minute reworks, which are costly.

How might we design a framework that supports IBMers to create beautiful, inclusive, and accessible products?

3: Establishing the baseline. The utilities of existing resources

One of our main interview findings was intriguing: that people regard information on accessibility design as hard to find and not digestible. We knew that there were plenty of resources; the question then, was: how are people actually utilizing them? Our first reaction was to check out if there were any analytics data. Turned out, they weren't available. So, we had to work around this by surveying. Kate and I crafted a survey, distributed it via Slack, and got over 120 responses. I analyzed them and compiled a report.

One finding is that very few survey respondents knew about or ever used the available resources. Lack of awareness surfaced as an issue. Most answered that they "did not know it existed" or "heard of it, never used it": these responses added up to 85.6%, 92.7%, 71.9%, and 79.2 for resources A, B, C, and D respectively (anonymized on purpose). Here's a snapshot:

Pie chart

4: Ideating + journey mapping. Thinking about how we could improve the experience

Based on our research, we created a persona and her journey map, brainstormed solutions that would elevate the as-is to the to-be.

Narrative summary:
Debra is a designer at IBM. She first learned about accessibility design when she joined the company, although whether or not she can put it in practice hugely depends on her team. One day, she walks into the office and finds out that the recently planned release is failing the accessibility conformance report. They have to fix it fast and fix it right. She doesn't know what to do.

You can't unsee or unknow that accessibility is an issue once you’re aware of it... [in practice,] everyone thinks I know what I'm doing, but there's so very little guidance.
- Designer at IBM

After iterating on the user journey with feedback, we started brainstorming how the experience moments could be bettered.

We identified 9 solution directions then filtered them down based on the following considerations: 1. how feasible is it for us to deliver something working and functional at the end of the internship? 2. how seamlessly will the solution integrate with the designers' current workflow? Point (2) was especially important, as our user interviews uncovered the finding that for something that has been long seen as "optional" and an "after-thought", related solutions have to meet people where they work.

Ultimately, we decided to leverage the Carbon Design System that many IBM product teams already use. Many components in this design library are already accessible; how they are used, however, can make or break whether the final product passes the standards. Our goal, then, was to support designers who use Carbon by including more related, tailored, and informative content, such that they could confidently use Carbon without having to parse through the dense materials which they perceived as daunting.

Everything started with stickies, markers, and whiteboards

5: Iterations. Building on Carbon

The first task was to decide what content to include. To start, we did a comparison of the top go-to current resources; this was so that we had some baseline. We extracted 8 criteria based on the user interviews and looked at how each resource passed or failed. Looking at this, our goal was to tick off more marks while acknowledging that certain elements (soft skills and empathy-building) didn't belong in this wiki-styled site.

Comparison of existing resources along with our goal

Once the goals were established, we went through the accessibility design resources that our sponsor lead, Bo Campbell, had given us. We pulled out the content relevant to Carbon (so that the information is curated) and Steven created visual examples (so that our users could see how accessibility design guidelines are applied in action). Then, Steven and I explored how we could visually structure and present the content. We started with paper prototypes and gradually increased the fidelity based on feedback.

Steven and I made prototypes of varying fidelity and tested different layouts

6: What's next? Concluding thoughts and reflection.

We presented the deliverables to our sponsor leads and those working on the Carbon Design System. The iterations resulted in something that is now live on the website, which feels surreal. Aside from learning about enterprise design thinking and improving my skills as a UXer, here are some reflections:

The prototyping process. Teamwork makes the dream work

← back to portfolio