OnRoute


Problem

I like to go out walking on the greenway trail near our house, and so I’ve tried out a couple exercise apps to track my progress. They’re all broadly similar for the most part.

But there’s one QOL feature they all lack – the ability to accurately map out and measure your walk AFTER you’ve taken it, in case you didn’t have your phone with you (or any other reason to not track during). Sometimes you can make it work through map apps and placing multiple stops, but if the route loops back on top of itself or does anything else unusual the process just falls apart. So I decided to mock up an app that would include this.


Research

Target Audience

  • Millenials (21-35)
  • Runners, walkers, joggers, bikers
  • Specifically those exercisers who like to track their progress for distance, as opposed to (only) time or calories

Topics of Interest

  • What drives people’s choices between the existing apps?
  • How do those who wish to track/log distances do so currently?

Findings


Competitive Research/Analysis

First, we have to nail down features. I don’t want the app to have too broad a focus – some fitness apps try to squeeze in coaching, meal tracking, logging every possible kind of exercise, and so on. This app will be focused solely on walking/jogging/running and tracking that activity, so we need all features to be centered around that.

So, I checked out several of the leading apps for what kinds of features they include to get a base to work from.

Strava

  • Positives – People either like or are indifferent to the social aspects. They like that accounts are not locked to your devices.
  • Negatives – They used to have a tracking feature that would let you compete against others for segments of your run (including leaderboards), but it was removed.

Key Takeaway


Persona


User Journey/Flow


Sketches/Ideation


Feature Prioritization

“Must” features that are common to most competitors:

  • Live-tracking progress (a given – distance, calories, pace)
  • Logging past exercise (the feature is common, but our method is not)
    • Want to include an option to pull up past routes, so if the same route is logged often the user doesn’t have to retrace it each time.
  • Progress history (daily, weekly, monthly)

Long-term/post-release features:

  • Social/group options: the obvious social features like the option to share your route/exercise are pretty basic, but a more unique option (in an app where the point is logging routes) would be to pull down routes others have used so you could try them out. This would be best if it they were pulled anonymously (for user safety, so a given user can’t be tracked). Post-release feature, given that it requires an established userbase to be worthwhile.

“Optional”/Unnecessary features:

  • A lot of apps have music options directly within the app. There are two reasons this feels unnecessary. First, with the rise of Spotify and other streaming apps, users are more likely to have set up their playlists, etc in an outside app actually dedicated to music. Second, for the same reason, it’s less common for people to buy/download/rip music files than it was ten years ago – and in-app music features usually run off the music files actually on your phone, so if there are fewer users with music files on their phone, the feature is closer to being a waste of resources.
  • Food logging – as planned at the start, this would broaden the scope of the app beyond its initial intent. Could be a long-term goal if users wanted down the road, but not a focus.
  • Coaching/training features – also a long-term feature that would likely end up in an app like this, but this is a feature that’s hard to differentiate much between apps. More likely to get added long-term than food logging, due to being more closely related to what the app is about.

User Flow


Wireframes (partial)


User Testing


Design