Project Overview
Role: user researcher and designer
Methods: interviews, storyboards, prototyping
Deliverables: internal report, presentations, mockups, publication
Tools: Invision app, pen and paper, Figma
Client: Sage Bionetworks
How can we get people to track symptoms for a progressive disease?
Parkinson’s Disease gets worse over time, but the rate at which symptoms change varies quite a bit. To study symptom progression, Sage Bionetworks researchers wanted to create a mobile app that people with Parkinson’s could use to measure their symptoms over time.
To get good data, the Sage team needed an app that would provide value back to users, to keep them using it. My job was to figure out what the app needed to do to provide value to users.
Research Goals
I needed to understand:
What is the value to users in tracking symptoms for a progressive disease?
What drives people away from tracking symptoms for a progressive disease?
What obstacles do people face in trying to track their symptoms?
The process
After discussions with stakeholders about project goals, I interviewed people with Parkinson’s Disease to understand their needs for symptom tracking and managing life with the disease.
Recruitment: I wanted to recruit people with Parkinson’s Disease, distributed based on how long they’d been living with the disease, and including both people who already tracked symptoms and people who didn’t. Recruiting was challenging, so I recruited through personal networks, professional networks, participants in past studies, and every other channel I could think of.
Since early interviews showed that care partners are often key stakeholders, I expanded the target population to include care partners and interviewed them, recruiting through snowball sampling and other channels.
In all, I included 17 people with Parkinson’s and 6 care partners.
Methods: Interviews and early prototype studies.
Interviews with storyboards: After the first four interviews there were some themes arising already that could point us toward very different use cases, so I drafted some storyboards to understand the relative value and issues around four specific use cases. The storyboards helped me focus the conversations on the relative value of different features.
Prototyping: After about half the interviews I started sketching early prototypes and developing them. I used the remaining user sessions to get feedback on the prototypes and develop the designs.
Analysis and reporting: I did quick and dirty analysis during the project and rigorous thematic analysis afterwards.
Quick and dirty: I discussed emergent themes regularly with the UX team and with a larger group of cross-functional stakeholders. As I began prototyping, I got my team together and we did some post-it note affinity diagramming on the whiteboard.
Rigorous thematic analysis: I cleaned all the interview transcripts, analyzed them in atlas.TI and wrote a CHI paper.
Deliverables: Ultimately I delivered a report on the project, a list of design tensions and user needs, a couple of powerpoint presentations (given to different audiences), and a scientific publication accepted at CHI.
A crop of one of the storyboards used in interviews. Shows a person looking back over their Tap Test data and comparing their results over time to the average for all people with Parkinson’s Disease. The speech bubble is empty so that interview participants could fill it in themselves.
Key findings
Users wanted to track their symptoms so that they could identify triggers that affected their symptoms and talk to their doctor about their medication (plus some other reasons).
Not everyone wanted to track their symptoms, because they didn’t want to see data showing their symptoms getting worse. However, some of these users still wanted to contribute data to science.
Care partners are critical stakeholders, but people with Parkinson’s differ in how they want care partners involved (e.g., as recipients of data, as co-symptom trackers, or not at all).
Users experience a variety of symptoms - some can be tracked through tests in an app, and some are very individual and personal.
There were some usability issues with some of the endpoints used to measure symptoms.
Translating findings to design
Since not everyone wants to track symptoms, the homepage should prioritize the actions of tracking rather than data visualization.
Users should be able to track more than symptoms—they should also be able to track things like triggers and medication to see what affects their symptoms.
Users should be able to see data over long and short time periods.
Users need to be able to track different kinds of symptoms in different ways.
Care partners could not be included as users due to feasibility concerns.
Let users track more than symptoms
Users wanted to be able to track how meds and triggers affected their symptoms.
Track symptoms in more than one way
Some symptoms could be measured, some could be rated, and some could only be noted. Users needed to track them all.
What was my impact?
I defined the main functions of the mPower app for users.
I translated my findings into mockups that I handed to the design team, and worked with them to prioritize features since not all could be developed.
I demonstrated that care partners were important stakeholders in symptom tracking. Since including multiple users increased the complexity of the system considerably, we did not include them as users of the app. However, this finding gives us insight into future directions.
Notes and Acknowledgments
This work could not have been done without the amazing people at Sage Bionetworks. To name a few: Woody MacDuffie, Stockard Simon, Michael Kellen, Larsson Omnberg, Lara Mangravite, and many others. In addition, this work could not have gone forward without my participants. I thanked you when you participated, and I thank you again here.
I also want to note that one thing I learned in this work was that if you’ve talked to one person with Parkinson’s, you’ve talked to one person with Parkinson’s. The needs of this community are extremely diverse, and while my findings reflected the needs of some users, they definitely do not represent the needs of every person with Parkinson’s.