Strava Dashboard: Persona to Prototypes to Validation
Nike makes sneakers for Lebron James, not the mildly out of shape guy who likes to shoot around on the weeks. In the same way Strava is designed for an athlete that is obsessed with analytics and data-- not necessarily for someone going out for their first ride in 10 years. While those personas are wildly different, I don't think their needs and behaviors are mutually exclusive. I looked at how I could potentially develop a feature that bridges that gap. The project can be roughly summarized in the following points:
- The goal is to increase the amount of times a Strava user engages with the app in addition to post-activity interactions.
- The process is to interview users to determine pain points, develop a hypothesis, build, test, and validate
- The outcome is a very simple, but intentional, dashboard developed through a series of sketches, wireframes, prototypes, high fidelity mock-ups, and animations.
- I learned that users have a very private relationship with their results, and while there is a wide range of preferences, they all are based around the same few variables.
One of Strava’s challenges was made clear to be with a single sentence during user interviews: “I have never opened Strava just to browse.” Strava is ubiquitous for cyclists wanting to track their activity, but is struggling to gain the same reputation for viewing that data. We want to make Strava easier and more usable for athletes looking to compare and view their data. I believe that by adding a dashboard interface and quick access to recent data users will open to "browse" Strava 15% more.
To gain a unique insight to the product I development a persona. This persona stood in for a particular (and fictitious) user who can act as a single vision for this potential product feature. I believe this fits into Strava's key target market in that Chas is already an active athlete. Chas is the type of athlete that is serious enough to track his activity and committed enough to care about a finer level of results- two cornerstones of Strava.
Using some guerilla research techniques (and a healthy budget for buying coffee for strangers) I interview 6 cyclists about their Strava habits and what pain points they experienced. I went in with a vague but directed interview script. I wanted to see how users compared their data and performance, and how easily they could accomplish this relatively simple task. What I found is that everyone is completely unique and different. These research interviews gave me an insight to how users use Strava and what pain points they encountered. As I developed prototypes I revisited this step. I would get my prototype in front of as many people like Chas as I could. This resulted in a lot of iterating to end up at more optimized product.
Once I had obtained pain points from users, I developed design stories: standalone actions that they wish to accomplish within Strava. I then organized their design stories to establish what common threads existed through all their needs.
Each design story represented a unique task the user wishes to accomplish, and it is crucial those task fit together into a coherent and experiential product. After several attempts and countless hours of staring and rearranging, I developed a task flow that started to reveal the shape of a feature that may improve Strava’s usability.
Sketches and wireframes:
With a clear sense of user needs and approaches, I began to understand the UX and began sketching and wireframing. Since this feature was going to be "data-heavy" I spent a lot of time up front thinking about data visualization; going through a lot of ideas of how to present all the data. After that I moved to UI sketches and storyboards.
As I mentioned previously, the "solution" has been altered and iterated on many time. (You can see a post-mortem critique of all these "failures" on my blog as well). Once I got to a minimum level of viability in a prototype I put it in front of potential users to break down all my hypothesis. This allowed me to go through a large number of iterations and changes in a relatively short timespan and ultimately deliver a more effective solution.