We used a survey screener to define our user base and to find users that we could interview to gain more insight into what their needs really were and what key features they wanted/needed. We conducted 6, 20-30 minute interviews with known chronic headache or migraine sufferers. We gathered a bunch of useful information from our interviewees leading to ideas we never thought of.
Research Plan
aura
Research
Summary
My Role
The primary goal of this project was to create an app or website that solves a common problem. We found that many people suffer from migraines and headaches and could all benefit from preventative treatment. The goal was to create an app that tracks the weather and pressure shifts to help identify triggers for chronic headache sufferers. We then created the app Aura.
UX Designer - UX Researcher - UI Designer
Our Process
Interview Takeaways
User Persona
User Scenario
Tools Used
Research - Define - Ideate - Prototype & Test
Migraine sufferers whose symptoms are affected by the weather need ways to monitor large changes in humidity or temperature as well as pressure.
Migraine sufferers often have nausea along with other symptoms. In addition, when people have migraines consistently, their mental health is often impacted. They need uplifting messaging and positivity in their day.
Some migraine sufferers are able to prevent the majority of their symptoms if they seize the headache in the early states. These people, and others who don't know how to prevent their migraines early, need a warning when they might have a flare up so they can prepare.
Meet Mandy, our user persona we conceptualized from our user interviews.
define
User Journey Map
Based on our research we wanted to prioritize what features were most important to our target user base. We came up with a long list of different features using the I like, I wish, I wonder process. We then prioritized them below and used this prioritization matrix to decide what features we would include in our app.
aura
Ideate
We came up with a real life scenario where someone who suffers from headaches/migraines might start using our app, Aura. We created a user journey map, a UX scenario, and storyboard different ways of how this scenario might take place. Let's look at how Mandy begins her journey with Aura.
Storyboard
Feature Prioritization
Early Wireframes
Figma - Adobe Illustrator - Figjam - Google Surveys
Here are our very early wireframes where we were trying to get an idea of where we wanted all the information we thought we needed would live. This of course changed over multiple iterations from usability testing.
User Flow
Sitemap
Style Tile
Then we moved on to creating the look and feel of Aura.
We wanted Mandy to feel uplifted and empowered by our app, both in our wording, her interactions with the app, and our chosen style.
We landed on a soft, pastel color pallet to convey a sense of peace and an airy, almost sunset-like look.
Many of the users we interviewed told us that they experience light sensitivity while having an attack, so we chose to keep the background dark to make it easy for them to engage with while having a migraine.
Prototype & Testing
Here are some important early wireframes that we tested during our first usability test. This first test provided a ton of user feedback that helped us make some pertinent changes so that our users could be successful when using Aura.
Wireframes V1
Our first round of tests gave us a lot of useful feedback.
While the majority of the tasks could be completed by users, we found that the first task caused difficulty.
When we asked them to tell us what pressure change had the potential to give them a headache, we were met with confusion, frustration, and a success rate of 50%.
Since this feature was the basis of our app, we knew that we had to make some major changes to help users succeed.
We created the Pressure Threshold property. We standardized the wording across all pages, and then gave the feature a prominent place on the home screen and added a mention of the property in our onboarding. We also added a definition to the report screens, ensuring users would be able to find an explanation.
Usability Testing - Test 1
Iterations - Test 1
After our first initial testing, we continued to make iterations to our wireframes. We stated what a user's pressure threshold was on the home screen, and added an information icon for users who may be confused by this metric.
We then removed the graph from the reports page, as users found it unnecessary and would rather it be nested inside the Pressure Threshold widget.
Updated graphs were added to the homepage to show more concrete measurements of pressure instead of abstracted graphics. This allowed users to focus on one element of visual data instead of multiple graphics.
Wireframes V2
AB Testing
Before moving into a higher fidelity prototyping, we ran another round of tests with our new wireframes.
In this round of testing, we tweaked one or two tasks to fit with our new prototype, but kept the same essential ideas at the heart of all our tasks.
And with this new prototype we found that our task completion went up…35%!
Usability Testing - Test 2
Almost every user was able to complete the tasks we gave them with no trouble. However, they did have some suggestions for things they would want to see, such as:
A way to end an ongoing attack. Which shot to the top of our Issue Log.
We still saw some unfamiliarity with the meaning of pressure threshold. So we really wanted to hammer home this concept. And a distinction between which widgets you could or could not click on the Reports page.
Our A/B testing on this round of users allowed us to see how they preferred to log an attack from a passed pressure change.
Test A took users straight into the attack flow after they confirmed that a previous shift had caused an attack.
Test B let users confirm the attack and then add the details at their leisure.
We found that the vast majority of users preferred the B flow. Even if they wanted to add the details right away, the additional step of confirming they would be doing this, saved from the confusion of moving directly into the attack flow.
Prototype