Hopefully, you’ve already heard about the cool Routes feature that Strava launched within the past year. This new feature recommends personalized routes from any location in the world and is powered by both the millions of Strava activities and OpenStreetMap, the world’s biggest open-source map dataset. It also estimates how long your route will take based on your recent activity and provides elevation and surface information.
When our team began the Routes project, we weren’t focused on Routes at all; we were focused primarily on coming up with an ideal training experience that would uniquely differentiate Strava from other training apps.
We kicked off this project with research designed to better understand the needs of runners who race, particularly when it comes to training for races, by asking our community questions about their training solutions, what primary needs they were solving for, and what had been working for them. We quickly realized that traditional training plans can be boring — and in most cases don’t work — and that athletes prioritize keeping their routine fresh and fun.
Trying out new things is a core part of the training process. Athletes are always looking for novelty and exploration to keep things fresh and fun. They often seek out new information from a variety of sources and always in a state of experimentation.
“If you are doing the same workouts over and over again, it doesn’t really improve how you are or what you do.” — Anonymous research participant
Initially, we came up with 4 different concepts:
- Routes from Here — three disparate routes generated from their chosen location.
- Maps for Runners — places, local routes, and training suggestions for runners based on their interests and locale.
- Subscriber Buddy— an assistant that suggests personalized routes based on the inputted parameters.
- Goals — workout and route suggestions based on one or more specific goals.
Athletes are on a constant search for new running or riding routes (looped course) from the location of their choosing, and they tend to highly rely on friends, communities, clubs, and experts to learn and find new suggestions. How can Strava utilize community knowledge about best routes and secret spots and inspire athletes? As a social platform that is used by more than 78 million athletes, those athletes’ experiences and expertise are Strava’s power. Who knows the best routes, segments, and places better than the very athletes who run them every day?
“Strava athletes know the best places to ride and run, and with 50 million of you in total, that’s a whole lot of routes — not just the world’s must-do roads and trails, but also the easiest ways to get around town and the most bang-for-the-buck workouts from almost anywhere.” — Strava Stories
To help athletes easily plan their rides and runs, we decided to build Personalized Routes on mobile, while Route Builder allows athletes total control and shows them nearby segments for a chance to test their fitness or claim a spot on the leaderboard. Personalized Routes on mobile generates three personalized route suggestions based on athletes’ preferences. In addition, Personalized Routes shows details about each route, such as estimated time, elevation, surface, and distance to set up clear expectations.
Designing Map Interactions
Designing interactions for maps on mobile devices poses a unique challenge, as maps are complex systems that require you to consider a lot of data.
Routes Screen: Map + Bottom Sheet
From the very beginning, we understood the importance of the relationship between maps and data. Data complements the screen’s primary content, and the sheet component allows athletes to see the secondary content while they interact with the primary content. That was the main reason we decided to center the whole experience around the map and a bottom sheet.
Athletes can view and interact with a bottom sheet at the same time as the rest of the screen, which is great for multi-tasking. The initial vertical position of bottom sheets is capped at ~50% of the screen height. Sheets can be expanded to full-screen and scrolled internally to access additional items. They can also be minimized to a 10% view to allow for a full-screen map interaction.
As for filtering options, we decided to go with a modal bottom sheet. Its blocking behavior makes it a great option for menus to help users focus on their available choices.
After launching the MVP (Minimal Viable Prototype) we started nailing down details and one of the most important issues that were uncovered during the user interviews was terrain type. How might we clearly communicate the surface type of routes to athletes?
After a few user interviews, we realized that athletes have strong sentiments about Strava’s orange color and prefer simple visualizations, such as solid for paved, dashed for unpaved, and white for unknown areas.
After launching the Routes MVP, we quickly realized that while the route quality was pretty high and users liked the suggested routes overall, in some cases, they wanted more control and to be able to adjust the routes slightly based on their own preferences.
To allow for editing capabilities, we introduced an Editing Mode with movable waypoints. While designing for editing, we made sure to keep some of the most common usability issues in mind:
- Swipe ambiguity: Things are often too small on mobile, and athletes might accidentally shift the entire map when they just want to activate and move a waypoint.
- The 36 x 36 px pinpoints recommendation: Small targets take longer to reach, and it might take users a few attempts to move what they want to move. Fingers on a touch screen are much less precise.
- Invisibility: Touch interfaces lack hover states. In addition, athletes can’t see the gesture or what they’re touching on the screen because their finger covers part of the screen.
Taking all of the above into consideration, we decided to allow the user to drag the map, keeping the pin fixed so they could avoid making mistakes and would have a high level of precision.
There may be a route that is very popular in one direction but might include difficult turns on busy streets in the other direction. While the Heatmap data was directional, their three suggested routes didn’t provide any visual directional indication, making it hard for athletes to understand directionality.
We decided to introduce animation to Routes to include a direction of travel. The more meaning and data we add to the map, the more visual clutter we risk. Animation helped us since we didn’t have to add any new elements. For the final iteration, we combined directionality with surface type for easy comprehension.
The Routes launch was not the end goal, but rather the start of a long journey. Before the launch, we had a set of assumptions about how athletes use Strava’s map environments. After collecting data on usage post-launch, we found that the biggest issue wasn’t with the core Routes experience, but with surrounding features.
During usability testing, we discovered that athletes struggled to find the routes they had previously saved. In addition, the old UI lacked a lot of information, such as time, elevation graph, surface type, and segments after saving a route.
But our priority for the new design approach was to introduce a visual depiction of physical space — a new way to organize Saved Routes that would be consistent with the new UI.
We’re still working to better understand how to offer a quick and simple way for athletes to organize and manage the Saved Routes list, a clear image of what is saved, and a way to locate specific content easily and efficiently. But in the meantime, we believe that this redesign will be the first step for a better experience.
All the work that has already been done is not yet final, and we are planning to keep iterating and improving. Each iteration helps us get just a bit closer to building a highly successful feature for our subscribers.