TRISHA
IYER
MedRhythms
After participating in user testing and parsing through interview data for a music-based stroke therapy app, I noticed that there was a need for customized product experiences, where users could change the experience to suit their needs. I designed a project surrounding this need, continually refining it based off of feedback from my coworkers.
ROLE
UI/UX Designer & Strategist
TOOLS
Figma
TEAM
MedRhythms InTandem Product Team
Product Purpose
Music is used as a therapy to improve walking in people with neurological disabilities. Walking to a rhythm engages the motor system. So, this company created a product that allows people use music therapy on their own, without needing a physical therapist. It helps users walk to the beat of music and slowly improve their walking overtime.
Problem
The company received significant feedback during user testing about several pain points in the current user experience. After initial root cause investigation, I realized these pain points stemmed from whether a user had high or low tech confidence, thus impacting their expectations and overall experience with the product.
Also, in later concept testing, most users said that they preferred having some level of control over their experience, and they liked the idea of having options to customize aspects of their experience.
Solution
A customization flow that allowed users to change their experience settings.
Preliminary Evidence Organization
This is the summarized data from initial user testing. Each bullet point represents different user suggestions. After looking through all the data, I noticed two trends. On one side, there were tech confident users who wanted more choices and fewer guiding features. On the other side, there were less tech confident users who wanted more clarity surrounding their experience and more guiding features.
Set-Up Screens
These are instruction screens before a walking session. People wanted:
​
-
the option to skip instructions​
-
more clarity using videos and images
Voiceovers
There are guidance voiceovers during a walking session. People wanted:
​
-
The same amount of voiceovers
-
Less voiceovers
-
The option to turn voiceovers off
Metronome
The metronome is a ticking noise that helped the users stay on beat when walking to music. People wanted:
​
-
the current metronome, which only comes on when a user is off beat
-
the metronome on all the time
-
no metronome
Music
The therapy basis is walking to music, and there was limited music selection. People wanted:
​
-
a larger music selection
-
a smart music channel like Pandora
-
the ability to filter music by genre, artist, or mood
Walking
The current session has a 30-minute walking requirement. People wanted:
​
-
the ability to customize walking time
-
the ability change focus or intensity
Problem Statement
Tech-confident and less tech-confident users need control over the app and need ways to customize app features in order to create seamless therapy experiences that aren’t distracted by confusing or uncomfortable features.
Hypothesis
If the product provides more options for app guidance and control, both tech confident and less tech confident users will report higher satisfaction with the UX, as measured by concept-testing user interviews.
Project Objectives
Primary
-
How might we understand the experiential needs of tech confident versus less tech confident users?
-
How might we provide more guidance and control features?
-
How might we offer more customization options, without causing decision fatigue?
-
How might we help users customize their experience without complicating device setup?
Secondary
-
How might we add options to increase or decrease guidance and control features?
-
How might we make use of the settings tab to add customizable guidance and control features?
-
How might we adjust guidance and control features based on initial user preferences?
-
How might we allow users to change guidance and control features while they’re walking a session?
Initial Desk Research
I started with competitve analysis, looking at other exercise apps. I came across an app called Down Dog. Down Dog is a yoga app that allows users to customize every aspect of their experience. I took inspiration from Down Dog for my initial wireframes.
Initial Concept Testing
My coworkers were preparing to do concept testing, and I created a concept direction based off of the Down Dog app. The customization features were based off of the primary evidence collection. I included as many features as possible to garner user reactions.
Seven out of eight interviewees said that they liked aspects of this concept and liked having choices. In particular, many liked the 'Coaching Settings' screen. However, they also said it was overwhelming to have so many choices at once. They didn't want to choose all of these settings before every walk.
This made sense because the customization screens were purposely made to be more complex than the current app screens. Essentially, I was trying to understand the screen and choice complexity boundary. At what point would it be too much?
Workflow
Given that most users liked the 'Coaching Settings' screen, I used that screen as my base. I decided that most of the customization options should live in the 'Settings' tab, where people could access them when needed, but they wouldn't see the settings before every single walk. I also added an accessibility section upon request from my manager.
Wireframe Structure & Accessibility Considerations
On the screens below, there is one customization option per screen in order to prevent the screens from being overwhelming. All the description text is center-aligned because oftentimes in neurological diseases, one side of the brain is affected, and it can be difficult to read left or right-aligned text. The touch-targets are large for dexterity issues. Also, initially, ‘Sound Settings’ had 4 options, but it was reduced to three to avoid choice overload.
​
I followed a similar structure for all customization options including music, metronome, set-up screens, voiceovers etc.
​
Accessibility
Accessibility features weren't part of the original project, but my manager asked me to add them later. Since everyone who uses this therapy has a disability, there must be an accessibility section. To figure out which accessibility features to include, I asked for coworker expertise.
Ultimately, it seemed like the main accessibility requirements were text size, text alignment, and a simple vs. standard mode. However, I also had some questions on which of these options are really necessary. For example, do there really need to be different text alignment options when centered seems to work well for the most part? This is a question that can only be answered through user testing.
Text Size Experimentation
The more difficult part was including options for a more complex experience. For example, what if someone wanted to turn on scrolling? What if someone wanted music filters and scrolling? What if someone needed text read-alouds? Initially, I created a set of toggles that users could turn on or off. However, this could cause choice overload, so it made more sense to have simple and standard modes with default settings (that could then be changed).
Ultimately, I had to think about these three questions:
What features should be in simple mode?
What features should be in standard mode?
What features should all users have access to and be able to toggle on and off?
Onboarding
In my competitive analysis research, I noticed that many apps include questions in onboarding to determine preferences. So, initially, I created a similar flow, essentially using some of the ‘Settings’ screens in the onboarding experience. However, a coworker said that this would increase clicks and make the initial experience more overwhelming. Also, how would people know what customizations they want without trying the therapy first?
So, I had to consider how to reduce clicks during the onboarding process. What was the most concise way to make sure that users had everything they needed and had some preferences set? What's a good way to ensure that both tech-confident and less tech confident users have reasonable defaults?
The initial onboarding experience already had welcome, language, and wifi screens. So, I added one extra screen that gives users a choice of a simplified or standard experience to start. This way, users are given a choice, and they can have some initial preferences.
Other Use Cases
I also considered different use cases of customization options, where users might access them, and how they might be used. For example, one use case was the onboarding experience. An advanced user might go under 'Settings' to access customization options. The third use case was customization reminders. These exist to help users remember that they can customize their experience.
Next Steps
Unfortunately, I didn't have time to do the last step of my project. So, the next step would be concept testing that focuses on customization features. This way, users can tell us if the designs are going in the right direction.