Virtual Empathy Experience
UX Design Internship | IBM
Introduction
My Role
UX Designer collaborating with 3 UX Designers and 1 UX Researcher
My Skills
-
User Research
-
UX Strategy
-
Wireframing
-
Prototyping
Team Dynamics
-
3 UX Designers
-
1 UX Researcher
-
Cohort Coach
-
Stakeholders
My Timeline
Ongoing- Summer 2021 (6 weeks)
What's the problem?
The IBM Accessibility team enables the rest of IBM to create digital products that are usable by all individuals. They have outdated demo websites that do not reflect modern websites and therefore do not showcase the value of the IBM Accessibility Checker.
The objectives were:
-
Create an open and public digital experience that is current and can demonstrate the value of accessibility as it pertains to universal experiences
-
Highlight the MVP Design items that need to be considered for accessibility
-
Demonstrate the value of the IBM Accessibility checker and IBM's Equal Access Toolkit.
Problem Statement
How might we show off the IBM Accessibility Checker in a way that appeals to potential users in a glance?
Research Approach
First we questioned and delved deeper into what exactly is the IBM Accessibility Checker?
IBM Accessibility Checker: a tool within the IBM Equal Access Toolkit that determines the accessibility of a website. It can be downloaded as a Chrome extension.
Then we asked how IBM is currently showcasing the checker?
IBM used a website called Altoro Mutual to demonstrate the ability of the checker to detect accessibility vulnerabilities and defects.
Next we asked ourselves what exactly appeals to users? What do they need? And who are our users?
These questions and many like it strongly based our research methodologies.
Research Summary
12 users
17 interviews
3 competitor analyses
Phase 1: What is the current state of accessibility?
7 Sponsor Users (“Accessibility Advocates”)=
2 developers + 5 marketers
Phase 2: What is the experience of typical developers?
6 More Developers= 3 “average” developers +
3 “advocate” developers
Phase 3: What are the current pain-points?
2 Advocate developers + 2 marketers
Who are our users?
-
Developers like Alex- An “average developer” not well versed in accessibility. Wants to develop for a11y, but prioritizes timeline
-
Marketers like Andie- IBM marketers who face external middle-management level clients. They promote the use of the checker & IBM a11y services to clients.
But how did we find out who our users were?
Before we began our user interviews we created our empathy maps based on our assumptions of our two original users, which were the developers and accessibility champions. We mapped our their everyday workflows as it related to accessibility.
Doing this exercise helped with framing our questions for our interviews. We didn't have an exact idea of our users' frustrations but we were determined to create somewhere to start.
Empathy Maps- Developers and Accessibility Champions
Although when we started interviewing, we soon realized that the developers we were given as sponsor users, were very much accessibility champions themselves. They described the accessibility need in development in a great context and were very knowledgeable about accessibility issues.
This is when we questioned who exactly our users were. In the end, we ended up pivoting to focusing on average developers (those who weren't too knowledgeable about accessibility) and accessibility champions.
From this epiphany, we decided to create an As-Is Scenario that helped us understand where best to focus our attention in the journey. It also indicated where we need to gather more information.
As a result of using this exercise, we discovered that the average developer experienced several pain points in their workflow when trying to implement accessibility standards. The flow was so impactful that we found a negative feedback loop the average developers were experiencing. While for the accessibility champions we discovered that we didn't know that much about their journey which meant we had to go back and do more interviews for the ACs.
From the interviews, we decided to address the ACs specifically marketers because they presented the IBM Accessibility Checker to IBM clients. Therefore we simultaneously used the terms "Accessibility Champion" and "Marketer" throughout the project.
As-Is Scenarios-
Average Developers and
Accessibility Champions
What do our users need?
After we felt solid in our user research, we started to consolidate our quotes and insights in our user interview highlights document. This summarized information from each of our user types' interviews.
Developer Quotes and Insights
Existing tools do not simulate the experiences of using assistive technology well enough.
Accessibility errors come from not knowing what it’s like to use assistive technology.
Lack of incentives, not lack of interest, inhibits developers from learning about and implementing accessibility. They just want to get the job done fast.
“I’d definitely say it’s important in my mind, but it’s not something that [I] really budget time for or test.”- Front End Developer at IBM
“…wants to move as quickly as possible. It’s not that I don’t care about it, but I’ve never used a screen reader tester.”
- Front End Developer at IBM
“A lot of [meeting disabled users’ expectation] … is deeply understanding the tools that the users use like screen readers [and] sip ‘n’ puff.”
- IBM Accessibility Advocate
“Most of us tend to be well-sighted. We can understand things very clearly. … we make certain assumptions about [disabled users’ perspective] be that maybe don’t reflect reality.”
- Front End Developer at IBM
Accessibility Champion Quotes and Insights
Marketers often talk to high level executives who are more interested in high level overviews.
Empathy is built through experience.
“Seeing [accessibility] firsthand really drives it home.”
- IBM Accessibility Advocate
“[The checker] is great for developers and testers. It’s a little bit harder if you’re trying to write a high level overview. Just a high level overview page would be great, because that would be something that I could then put in my presentation and hand to a client.”
- IBM Accessibility Advocate
As a result of the user interviews and the quotes and insights gathered from them, we were able to create our needs statements. Here we could clearly identify what each user type needed within the problem statement.
We also created hills, to clearly identify what the end result should encompass for the user types.
Needs Statements
-
Marketers need a way to help clients understand the importance of accessibility so they can implement accessible design on their products & develop a culture of accessibility in their org.
-
Developers and clients need a way to understand what it’s like to use assistive technology so they can empathize with users & understand how they can build experiences that are accessible to everyone.
Hills
-
Developers can visualize the impact of accessibility features on their digital products so they can implement accessibility earlier in their workflow.
-
Marketers can communicate the impact of accessibility, inspiring clients to engage IBM to help them maximize resources and reduce legal risks, extend market reach, and ensure product longevity.
Explore and Define
After finishing up our needs statements and hills, as a team we started to ideating. We engaged in several ideation exercises such as Crazy 8s, Franken prototyping (each intern team pair would create a prototype for the other team), and a brainstorming session with the cohort coaches. But all of them availed to no clear path in where to go for the solution.
My prototype
Therefore as a team, we decided to create our own prototypes and come back together to talk about them. After realizing that some of our ideas were similar to each other we split into 2 groups, based on similarity. Another UX designer and I grouped together based on our gamification concept, while the rest grouped together based on the demonstration of the checker which used the Altoro Mutual site.
Gamification concept
After each of our concepts were solidified and we received feedback from our stakeholders, it was decided that we would combine our ideas into one. The result is showing the value of the IBM Accessibility checker through a game experience.
With this in mind, the solution entailed 4 keys items...
-
Redesigned site
-
Help users experience using assistive technology
-
Simplify checker results for clients
-
Promote IBM Accessibility Checker to potential users
Due to the newly designed site Alex and Andie's clients can use different assistive technology to get a glimpse of how people with different disabilities navigate an everyday site. They can use different color blindness filters, light sensitivity, magnification, screen reader view, or try keyboard navigation.
Alex and Ande get to experience how a seemingly simple task like checking their bank account can take much longer than it needs to because the site is inaccessible.
Therefore Alex can...
-
Understand the impact of the inaccessibility in their present workflow
-
Look at what each violation entails and why its an issue
-
Look at additional resources they can press fixed selected issues to see what it would
Andie can...
-
Better push why accessible design is important
-
Send a more digestible information summary to their clients
-
Push for their clients to cultivate more of an accessible culture within their company
Developer and Marketer To-Be Scenarios
Test and Iterate
After we completed the to-be scenarios, we all pitched in to create the prototype. I personally worked on sketching the game experience, and prototyping the game recap page and the entire screenreader flow using Figma. Although while we were working on the prototype we conducted usability testing to constantly iterate on what we created.
The game experience would mainly be driven by a side bar on the right that would include information about the challenge and the list if items they need to complete. Next after each challenge a mini recap would appear. In the very last challenge the user would be prompted to enter their own website to check for inaccessibility and how to fix it. Then final recap game page would encapsulate the summaries of all 3 web experiences the user experienced. It would also tell them what lessons they learned and the resources they can access.
When we started to move onto the prototyping phase I started to prototype the game experience by focusing on the final game recap page. Then based on usability feedback we updated the page to remove the PDF option because downloading materials wasn't seen as an effective learning method. Also instead of checking the user's own website as a challenge it was presented as an option in the very end to not force the user to check a site they may not have ready to check.
Then as I was working on the game reccap page, my teammates were struggling in what exactly to present on each of the other view. Therefore, I created tables for the three views to showcase the clear correlation between the diffferent use cases, technical probems, and resuts. This helped direct everyone's attention so they could understand the intersections of the designs.
Screen reader View
Futhermore, I worked on creating the screenreader views, and started by doing something similar to the table before in dividing the sections by accessibility status, the specific issue being resolved, and website visibility resulting in prototyping 16 screens.
By creating this user flow, I simulated the experience of using a screen reader for developers and marketers' clients so they can start to empathize with their end users.
Prototype Video
Now let's go back to the beginning, with the problem statement
With our solutions, developers and clients are able to experience how users feel navigating 🗺 inaccessible websites.
More specifically developers are more knowledgeable 🧠 about resolving accessibility coding issues 💻 and clients are more empathetic ❤️ to their end-user.
How might we show off the IBM Accessibility Checker in a way that appeals to potential users in a glance?
Objectives and Lessons
Since our incubator project was only 6 weeks long, we were only able to get so far into the project. Although we created "cakes" for the team to look into for the longevity of our solution.
Short-Term
Expanding the features of the existing site
-
Think 40 credit- incentivize internal users
-
FAQ section- To help implement accessibility into workflow
-
Screen mode game- additional game mode
-
More violations- i.e. small click targets
Long-Term
Customizable experience
-
Adding additional views- i.e. cognitive disabilities
-
Being able to use the views with any URL- Using AI to autogenerate & provide options for solutions to user site violations
Lessons Learned and Knowledge Gained
1. Gained more knowledge of research methodologies 🔬
2. Experienced what it was like working with other (UX) designers 🎨
3. Familiar with facilitating stakeholder presentations/ playbacks 📈
© 2023 by Brandi Nichols