For a recent interview, I was asked to design a fitness app that allows users to set daily and longitudinal exercise goals. I had 4 hours to research, mock-up a concept, and produce a few high fidelity key screens.
I recognized how this project correlates to the client’s business (money savings goals), so I first took a look at how the client’s app was designed and grabbed several screenshots.
Next, I took a look at popular exercise and goal tracking apps to look for patterns and ideas. Strava and Aaptiv seemed to be the closest match to the client’s aesthetic and could serve as good idea sources.
I started by thinking about user types for beginning, experienced, and advanced users. I tried to think about why they’d be using my app, the problems they’re trying to solve, and what they may have tried in the past.
Next, I thought about the different stages of the user journey.
How would they get started? How would they return and continue to use the app? How would the experience differ depending on the exercise and goal? How could I motivate users to complete their goal? What happens when they do?
During this process, I considered an experienced runner who wanted to run a half marathon. He wanted extra training for core strength, weight loss, and circuit training in a pinch.
The primary event cycle would be to add a goal, return to the app to track and report progress, and eventually check off the goal.
The user could use a range of metrics for each exercise, especially core training, so I decided to focus on running since that was the principal objective.
I spend a little time thinking about affordances in notifications and within page structure. For example, as I displayed run progress, how might I suggest the next step?
My initial user types were too broad, so I narrowed the project scope into something workable within the allotted time.
I decided to start with an onboarding scenario. This reduced the overhead of needing to resolve the overall app structure just to present some layouts. I did take a moment to think about the four main app sections, just in case: new goals (Explore), summary (My Goals), current activity (Activity), and Settings.
Since this was a general (unspecified) exercise application, I needed a way to filter down to specific goals.
I decided the easiest solution was to use a photo or icon grid for the more popular exercise categories. From there I could offer several suggested goals based on popularity, skill level, and personal preference.
Probably the most critical view in the app was providing charts and graphs for goal metrics.
For a user considering a half marathon, the critical metrics are distance, duration, and frequency of each run.
I figured a graph displaying the last 30 days would be a good way to measure achievement. A sloping goal line could run behind the graph to show the necessary progress level over time to hit the goal.
I also explored the idea of progress bars that would show how close the user was to hitting their distance goal.
I also thought about performance-based stats like an “estimated date” when the user would achieve their goal and “chance of completion” to either encourage the user to keep going or perhaps reset expectations (without needing to start over).
Finally, I wanted to add a history list of each run, showing the data entered for each date. It would be editable in case there was a discrepancy.
For goal settings, I used Material Design's EditText forms. It seemed the quickest way to enter data.
For metrics, I didn’t have a lot of time to explore graph designs, so I only tried a couple: bar graphs and dot-graphs.
Since I only had an onboarding flow, I quickly mocked up potential app screens. This was mostly to test and confirm the onboarding screen designs would be consistent with the final app.
I chose orange for the accent because several exercise apps used it as their accent color
I used an icon grid because it was fastest and looks better
Suggested running goals targeting different user types
Goal with details, call to action, and social opportunites
Goal settings based on current abilities, additional options, reset button, and confirmation
The EditText forms of Material Design didn’t look right while resting. The spacing and lack of affordance made it difficult to understand these were editable settings.
I scrapped that design and quickly mocked up a layout based on Android application settings
Tapping each setting opens a selection dialog
I used the same Half Marathon image throughout the views for continuity.
Each item in the list contains a hero image, title, completion date, and highlights: what was accomplished this week, best result of the week, and best overall result.
For metrics, I simply cleaned up the wireframe design and made it smaller to fit more data within the screen area. I included one of my special metrics: outlook (excellent).
Daily Record displays running distances for the last 30 days, including the day of the week since that’s usually how people recall past events.
Behind the bar graphs I added a sloping dashed “goal” line to indicate how much the user needs to progress each day to hit the objective.
Progression is a great week to week to overall comparison.
The history data list allows users to make edits for greater accuracy.
Finally, I added some details to the Explore pages to double check and make sure the flow made sense and would fit into the final app.
The last thing I’ll point out is that while I did use Material Design as the base design system, I wanted to create something more universal.
Instead of the a top Toolbar, I used bottom navigation which left extra room on top for negative space (and Apple navigation).
This approach made it easier for this to be developed as a cross-platform app with minimal platform design differences.