The Struggle is Real: An Exercise in Usability Testing
Her palms are sweaty, knees weak, arms are heavy. There is something a bit funky on her shoe already, looks like week old spaghetti…
She is at the end of her beautiful run through the Mission district of San Francisco, all that’s left is to pull out her phone, press the “stop” button, and upload those stats to Strava.
She looks down. The timer is going, the record page is in view, but the recording never started. Panic. Little did she know the Strava app was updated — now the record button needs to be pressed twice and she…only pressed it once. Game over.
Strava is a social network for athletes with millions of users worldwide. With Strava you can discover, record, plan and analyze workouts. It offers the opportunity to challenge yourself with some friendly (or not-so-friendly) competition between you and your friends, the pros, and your own ‘personal best’.
But Strava isn’t just about the stats. It’s about sharing those stats and creating a community around exercise. And for me specifically, it’s about sharing those stats with my family. I come from a ménage of athletes. I mean freakishly fit, competitive athletes. I however, am on what you would call the “artsy” side of athletic.
I don’t use Strava to compete with my family of mutant super-athletes, but the app acts as my lifeline to them. We stay in regular contact through the world of data-driven exercise — giving each other kudos and commenting on rides. A visit home always includes some discussion around recent or upcoming Strava activity. So when an update in the app caused me to struggle with basic functionality, I was curious and a little bit scared. Did others share this pain? Or was I just losing my grip on technology? But more importantly, would I be disowned by my family?
Guerilla Usability Testing — How I Took Matters into My Own Hands
I chose to run a guerilla usability test because it’s quick, inexpensive and fosters honest feedback by interacting with users in a natural setting. The process involves approaching strangers, asking them to answer survey questions or complete a few tasks with your product while you takes notes on their interaction and process (it’s less creepy than it sounds, I swear!). Guerilla usability testing is perfect for someone with little time to spare and a limited budget. It’s also part of the Lean UX process — a process which many startups implement — and I was eager to try it out for myself.
My goal was to identify trends in usability issues experienced by people on the street, and to then design solutions around them. I felt safe assuming that, like me, the Strava Engineering team would be short on time and resources. (As a Frontend Engineer, my team and I often needed to balance time and resource constraints with design decisions.) So, I wanted to design solutions that would help the user and be low-cost for the Engineering team…
The Process:
I laid out a quick and dirty process to follow. Design is not only about the visuals. It’s about the research and process that guide, shape, and validate this visual outcome. In an ideal world, the framework I would follow includes 5 phases:
But in reality, the process ended up looking more like this:
Step 1: Empathize
Talking to and observing people using the product is critical to building empathy with the users. But first I had to know who these users might be.
Strava, as a company, has a set of values. They created a product targeting a certain user base and I wanted to make sure I sampled that user base properly. So I created provisional personas to identify the archetypical Strava users’ values and goals. These personas would act as a guide when finding people to run the test with.
While this process did require a bit of time prior to testing it was important that the people I recruited would represent the Strava user base. Otherwise, the data I gather would provide little value in the end.
With these personas in mind, I set out to Yerba Buena park in downtown San Francisco in search of five (why five?) participants.
When meeting people I started with some brief context about why I was running this test. Then I followed up with a few questions to determine if they were potential Strava users; if they fit my personas. “Do you workout? Do you track your progress or are you interested in tracking your progress?” And so on.
For those whom I determined were potential Strava users, I requested they try to complete the following tasks:
- Start recording a run
- Pause the recording (you know, to “catch their breath”)
- Resume the recording
- Stop the recording
- Save the recorded activity
- Change the activity from run to bike ride
- Delete the saved workout
These core tasks proved challenging to 4 out of 5 of the users I interviewed. The results revealed that the struggle is real. There were opportunities for improving the usability of the Strava app.
Step 2: Define
While reviewing the test results, I recorded pain points and sorted them to identify common trends.
I then searched for low-hanging fruit in the highest impact area (on the graph, the area which is important to the business and users). These are issues for which small design changes would likely result in reduced frustration among users by increasing task success.
The major pain points I noted were centered around the ‘record to save an activity’ flow. Users struggled to:
- find the record functionality to begin with. The record button blends in with the rest of the bottom tab bar. 4 out of the 5 users tried to record an activity by clicking the “+” icon in the top left of the app instead of hitting the ‘record’ icon.
- pause an activity once in progress. To pause an activity you have to press the ‘stop’ icon. While every participant eventually figured it out (mainly by trial and error) it was not immediately clear to any of them.
- complete and save the activity. To complete an activity you have to first stop the activity. When stopped you are brought to a page with the below button options. Can you quickly deduce which button would complete and save your activity? 4 out of 5 of the participants could not.
Moreover, most users were confused by the iconography in the app. They often paused to explain to me their thought process while attempting to decipher the meaning of a particular icon instead of flowing through the app. The ‘pause’ and ‘finish’ icons were a particular struggle for many testers.
“I literally don’t know what is going on here.” — Susan L., usability test participant
It was interesting to note that after struggling to complete the first task, most users appeared to lose confidence in their ability to complete the tasks that followed. (The point was to test the app, not the user!) In a few short minutes, they gave up the trust they had in the app to help guide them through the process.
Step 3: Ideate
After synthesizing and analyzing the pain points, it was time to t̶a̶k̶e̶ ̶a̶ ̶c̶o̶f̶f̶e̶e̶ ̶b̶r̶e̶a̶k̶ brainstorm! I sketched out possible solutions to refine the activity recording process, and explored alternatives to the Strava UI. This was a time to let the ideas flow without restriction. After playing around with sketches and a few games of trash can basketball, I came back to the main goal of creating updates that would improve the user experience and be quick fixes for the Strava Engineering team.
I spent about 5 minutes floating some sketches around to friends who I know use Strava , and another 5 minutes gathering feedback around the office. This was all I needed since the goal of the design was to have users understand pretty immediately the purpose of the icons on various pages.
With feedback on my sketched ‘record’ button and process flow, I iterated on the tab bar and translated the sketched wireframes into Hi-Fi mockups that parallel Strava’s existing style and brand.
The images below show the current Strava UI on the left (‘before) and my iterations on the right(‘after’).
Step 4: Interactive Prototype
I then popped my screenshots into Marvel to have an interactive prototype to test. Go ahead, try it out! See if you can perform the following tasks (and please post any feedback or suggestions in the comments below):
- Record an activity
- Pause the activity
- Complete the activity after pausing
- Save the activity
So, What Did I Learn?
As designers, it can be easy to lose sight of our own biases when evaluating designs. Although user testing may sound like a cumbersome process — recruiting participants (by “pouncing on lone people in cafes and public spaces”, as Martin Belam describes it) and diligently observing them interact with your product — is it necessarily a big ordeal? In just an hour I drastically improved my understanding of how real people interacted with the Strava app. From there I was able to design simple changes to try to improve the user experience.
Performing a guerrilla usability test helped me iterate and improve on my own design process. It also reminded me that design, to the best of its ability, should adapt to the user and not the other way around. It’s not my job, as someone using a product, to make excuses for any points of conflict or confusion. It is my job as a designer, however, to understand these areas of confusion and work to design solutions for them.
While my goal was to work on my design process and practice guerrilla usability interviews, in the future I plan to take this process one step further by re-testing my updated design ideas using my prototype and A/B testing the icons.
Thanks for checking out my post! If you enjoyed it or have any feedback I’d love to hear from you. Feel free to comment below or reach out to mwegenstein[at]tradecrafted.com or on LinkedIn.
Note: I am in no way affiliated with Strava. I’m just a Product Designer who loves thinking about UX, wears too many Hawaiian shirts, and boasts the title of ‘Slowest Runner in the Family’.
