accesSOS:
Reducing User's Time On Task By Improving Information Architecture
About
accesSOS is a 501(c)(3) nonprofit that made a mobile app that makes calling 911 more accessible for the Deaf and Hard of Hearing and people in compromising situations.
Project Background
Goal
-
Explore ways to make the native app more "usable".
Roles
-
UX Designer - Me
-
PM - Olya
-
Engineer - Phaneendra
Step 1: Understanding The User
Research Design
Goal: Make the native app more "usable".
Method: Task-based usability test through the app's 4 main scenarios.
Operational Definition:
Usable = Low ToT, Error Rate, Less Clicks
Key Audiences
Primary
Secondary
The Deaf & Hard Of Hearing
-
Should find the app efficient, easy, and safe to use in an emergency.
Emergency First Responders
-
Should find the app's output detailed enough to respond to an emergency reported through the app.
People Without Visible Disabilities (i.e., everyone else)
-
Should find the app as a convenient alternative to calling 911 in an emergency.
Tertiary
Accessibility Research Considerations
Interview guides must not use "think out loud protocol" because Participants who are Deaf & Hard of Hearing cannot participate in the process.
Interview guides must be economical in length due to the high cost of ASL interpreters and therefore should be piloted repeatedly before execution to weed out unnecessary questions.
Allotted research session time must be increased by 25% in accordance with government guidelines
I conducted a total of 22 tests
-
6 Deaf & Hard of Hearing
-
8 First Responders
-
8 With Non-Visible Disabilities
I brought the lead engineer with me to sessions with the Deaf and Hard of Hearing to build up organizational empathy.
Execution
Step 2: Define
Analysis
I analyzed my findings with the Product Manager to discover emerging themes and pain points.
Step 3: Ideate
Sketching
Here I ask...
-
How might we make a subcategories page that is thematically relevant not overwhelming?
The Problem: Subcategories
The subcategories page is where users experienced the most pain.
I found that outside of optional text field inputs, users spent anywhere from 8-12 seconds on this screen searching for an option.
Here is an example from a live user research session >>>
Why was this happening?
Thematically
Inconsistent
"If I am asking for medical help, why am I still being asked if my house is on fire?"
-Participant 11
The subcategory options display the same 8 options no matter what help is needed. So if someone is having a mental health crisis they will still be asked if their house is on fire
Confusing
Affordances
An animated floating down caret icon appears clickable to users when it really isn't, causing users to frustratedly click it several times.
An users have to scroll to find the next button.
Step 4: Design
Hi-Fi Prototype
Learning from the research I conducted, I created a solution that answered how we might make something easy to navigate but somehow more detailed and also intuitive to interact with.
Wireframing
-
How might we use affordances that signal to users that they can scroll to see more options and ensure its safe from critical errors?
Help Specific
Subcategories
I created subcategories based on the type of help the user requests.
The subcategories were chosen based on secondary reporting of common emergency calls.
While this screen shows less options it shows more relevant information, efficient for our primary audience and more detailed for 1st responders. This reduces clutter for 70% of use cases.
Dyanamic
Use Cases
In the 30% of instances where users click more than one help icon, we will show them options relevant to both types of help that they requested. This will show a total quantity of 8, similar to before.
To avoid one subcategory from burying the other, I designed the order of the categories to stack vertically next to each other so that relevant information for each help is seen instantly.
Intuitive
Affordances
I removed the confusing down carrot and instead hid the overflow behind the buttons while allowing remaining options to peak above the buttons. This also ensure users don't have to scroll to find buttons.
Step 5: Retesting
Execution
I conducted a total of 18 tests
-
5 Deaf & Hard of Hearing
-
5 First Responders
-
8 With Non-Visible Disabilities
I repeated all conditions of the previous test except using a prototype that incorperated the new subcategories page.
This design doesn't allow for 3+ general help categories to be chosen to avoid displaying 12+ subcategories.
This trade-off was made based on 70+ sessions I've held where I observed 70%~ of users select one option and 30%~ choose two.
Trade Offs
What happens when an outlier case selects 3+ general help categories? I assessed that if this were to happen, the user will almost certainely be rendered proper help due to optional text descriptions being available in other parts of the user flow and 1st repsonders being able to ask for more detail.
What If We're Wrong?
Launch
Lasting Impact
While dynamic subcategories were ultimately shelved for other priorities the visual design and composition lived on with over flow content peaking above the buttons at the bottom.
Updates were incorperated in our Atlassian based design system.
Results
Time On Task
Organizational
Empathy
This design showed a reduction in user time on task by 13%.
The new screen was saving 5-7 seconds on average for first-time users.
These were the first sessions conducted with communities with disabilities and it helped recenter the importance of accessibility research in the company and improved their process for conducting research with them.
Erroneous Clicks
Erroneous clicks on the subcategory screen were virtually nonexistent in the test environment.
The as-is app typically would see a rate of 2-3 errors.
User Journey Map
To prioritize the most nagging pain points I made a user journey map to show where in the interface users took the longest time on task.