App Design: Idea to Prototype in 6 weeks

In fall 2016, I completed a part-time course on product design for the start-up environment, offered by Whitespace. I was able to take an idea to prototype in 6 weeks while working full time.

Goru is a mobile app that helps a first-time triathlete train for an upcoming race. Besides recording a live training session for progress tracking and reviewing, the app offers the ability to create training plans automatically from both personal and public training data.

Target Market

The ideal person to use my product is the millennial triathlete, someone who’s active and tech-savvy. I interviewed several people in this target market to identify their pain points and use scenarios. A user persona was created based on a collective set of empthy maps.

Meet Caro, who’s in her 20s-30s, lives in an urban area with access to nature. She’s run races before, and she’s trying out her first triathlon. Caro wants to use Goru to help her with planning, which she does ahead of time in her free time at home. When she’s out for a run or swim, she just wants to jump right into it instead of wasting time planning.
“I want to plan and train for a triathlon in the spring” — Caro

Competitive Analysis

The market for fitness tracking app is saturated. From reviewing the App Store and talking to users, a few apps surfaced as their favorites.

Garmin

The app requires a Garmin heart rate monitor or a wearable to be effective. There’s a good quantity of data visualization, but it looks very complex visually and potentitally confusing for the beginner user.

Strava

Strava has great social network support but it lacks planning capacity. The product offers an ability to explore crowd-sourced route segments but this requires the user to do the work manually.

Training Peaks

This product is present on both the web and mobile. It is designed for the professional triathlete with a solid activity tracking system. Unfortunately, the mobile app doesn’t track activity in real-time, and users would need to input all data manually.

Paper Prototypes

After an analysis of the current competitive landscape and user research, I was able to come up with some hypotheses for the planning process. These were mocked up in paper prototypes for quick ideation, iteration, and testing with users.

Top row: Recording a live activity. Bottom row: Planning for a future activity.

Key Findings

User needs were further refined during my interviews with the paper prototypes. Here are some key insights:

  • Training is planned in advance
  • Runners tend to run the same routes
  • Only days of the week are important in activity history
  • Heart rate was initially an important attribute to track, but I found out beginners didn’t think this was essential (but not all users thought so, as I later found out after talking to more users after the course was over).

Visual Design

In parallel with user interviews, I also worked on visual design and branding of the product. I decided to name the app “Goru”, which means goal or finish line in Japanese. I chose bright and bold colors to convey action, and paired them with a refreshing secondary color tier with some neutral colors. I chose a dark text on light background theme for easy reading in the outdoors. These elements were also tested for emotional reactions and usability.

Interaction Design

For the scope of this project, I focused on two main navigation flows: Record a live activity and Plan for a future activity. While the former is relatively straightforward, the latter was something innovative that the competitors did not have. I wanted to make this planning flow as simple as possible, keeping the amount of taps and screens to a minimum.


User-informed Iterations — A Case Study

Since planning for a future activity is a main feature of the product, I focused most of my usability test on its interaction design throughout the entire process, from paper prototype to high-fidelity mockups. The main action the user takes here is to filter a set of criteria for the app to recommend routes.

Paper Prototypes

The following paper screens show the evolution of this user flow:

Screens are explained below, from left to right.
  1. I started with the map in the center. This failed to convey any action the user could take. This alone helped me define what the user would like to do after planning for an activity.
  2. I started the idea of “Rating by others” and this later gave rise to a crowd-source map recommendation feature. I also added a filter for “Time” and moved the map to the next screen.
  3. I refined the filter process, changing a slider to selection buttons for “Rating” and “Elevation” (a user pointed out that she’d like to go for any elevation, which didn’t work well witih a slider).
  4. I further divided this filter process to be either “Time” or “Distance”, as I found out that their coexistence on the same filter did not make much sense. Users also expressed interest in running for x amount of time or distance when planning. I also removed “Rating” because as a user put it, “of course I would only want to run a 5-star route”.

High-fidelity mockups

Similarly, visual design for the app also went through several iterations.

Screens are explained below, from left to right.
  1. Adhering to the original style guide, my colors were either too muted (bottom) or too loud (top). I introduced action buttons here for users to quickly interact with the recommended route map. But I learned that simplicity for simplicity’s sake does not work here. The buttons were not useful when the user had not gained any detailed information on the route to take action. Furthermore, this introduced clutter visually (buttons on all the cards!).
  2. I toned down the bright red colors here and made the bottom section more lively, while at the same time differentiated user-saved routes (“Favorite Routes”) and community-saved routes (“New Routes”). I reintroduced the Map here in the form of an icon on the top right, so users could select the location where they want to plan for a future activity.
  3. The visual contrast of the top section was still too sharp, so I toned it down some more, while staying within the brand guidelines. I reintroduced unit here for the distance, because—despite my explanation that one could have set for miles or km in the app’s Settings so it should be known implicitly—everyone asked for units. At the end of the day, the users are always right.
  4. The little map icon in the top right was problematic. It was not clear that it was part of the criteria selection process—part of the filter. After several revisions, I moved the map selection down into the filter box for clarity. This is reinforced with the location specifically displayed in a text box. Along with the map icon next to it, the text box gives the affordance that this is editable. I also revised the visual design of elevation (“climb”), because the previous tab-bar design was conventionally used for navigation, not selection.

Compared with Strava

Strava has a Segment Explorer that can help the user plan for the next activity by exploring existing routes. The feature is a bit hidden: Home screen → More → Segment Explorer → Segment Detail.

Strava’s Segment Explorer

Here, Strava users would need to explore different segments manually, one by one. The Filter only offers limited control in view change and activity selection.

In contrast, Goru brings this into the main navigation bar and a detailed filter can be applied directly on the same screen, where routes are presented automatically and visually.


Interactive prototype

Below is a quick demo showing how a user can:

  1. View a past activity in the log
  2. Start recording a new activity, save it for review, and delete it
  3. Review and plan for an activity in the future

High-fidelity screens

Still here? Demo’s too low-res? Here are some high-fidelity screens for your enjoyment. From left to right:

  1. Quick start screen: Start a planned activity, or jump right into a quick training session. Micro-animation (not shown) blurs out any current screen, displays the “Up Next” section first, right before the “Quick Start” buttons pop in to temporally guide the user.
  2. Home screen: View a log of all past activities. I decided to go with an infinite scroll interaction instead of a more organized and strutured way of displaying the log (e.g., calendar, date selection, etc.) as initial user research showed that users were interested in reviewing recent activities within the month.
  3. Activity detail screen: The buttons make a come back here so the users can take more informed actions. This screen applies for any recorded and planned activity. I chose larger buttons and font sizes here with higher contrast due to the user tending to view this screen while in the outdoors.

Thanks for reading! If you enjoyed this case study, please feel free to recommend so more people could learn about Product Design.


HH Design is a community around design in the context of technology.

contribute