POOL SWIM FEED AND METRICS REDESIGN
A redesign aims to tell a better story of each user’s swim, and a better navigation system and information structure for users to view their swim in the easiest and the most informative way.
Why the Redesign?
As the social aspect of FORM Swim App, it is very important for the face of the app to tell a compelling story for all kinds of swims. The problem with the previous design is that visually it only tells the story of what stroke types the swim contains. As much information as we can share when users tap into the feed tile, the feed tile itself is telling a very weak story without attracting users into looking into the detail of other people’s swim.
Another problem with the previous design is the amount of data being thrown into user’s face, for someone who has doesn’t have that much urge to look into swim data, such as fitness swimmers, the previous design shows too much data, it is overwhelming. And the complexity of switching among the different categories of data.
To solve these problems, we decided to redesign the pool swim feed and details screens.
Paper, Pen, Sketch
My Design Process
To decide how competitors are showing users their swim data, I looked through different competitor apps such as TrainerRoad, TrainingPeaks, and Garmin. All of which are strong competitors in their fields.
A common thing I noticed is that all of their graphs look very complicated, and the cognitive load is massive for users. It got me thinking about how we can show a swim story without making it look as crazy as some of these graphs. TrainerRoad has a relatively simple and rich story graph. It tells the whole story of that bike ride, but it is also not overly complicated that makes users wonder what they are.
A very interesting finding is that they all overlay graphs over graphs, which at first doesn’t make much sense to me from a design perspective as it complicates the graph. But from a storytelling perspective, it actually tells a super strong story, it tells the pace of each position an the heart rate progress. The graphs grow together.
Strava is the biggest fitness online community there is. We referenced it a lot back when we were first designing the app. But this time, we were more looking into what its running analysis is and what we can learn from that.
Strava’s swimming data and visualization are really bad, that’s not what I want. Instead, I looked into Strava’s running analysis. It shows all the main metrics and data points in this one long screen where users can just scroll down and see. There are numbers, there are graphs, and there are buttons.
It is a smart idea that they don’t show all the data at once, because of the cognitive load and the attention span users have. Also, not everybody cares about those deep analyses. For a lot of people, just want to know how long they ran and how fast they ran. That’s it. Embedding deep data into secondary screens is definitely something FORM’s app can learn from.
How Do Swimmers Swim?
Based on the swimmer, a swim can be very different.
For triathletes and competitive swimmers, their swims usually follow a plan, breaking into sets, each set includes several intervals, while each interval includes several lengths.
Based on the swims we collected within the app over the last year and talking with several competitive swimmers (including one Olympic Swimmer!), triathlete, and fitness swimmers. The conclusion we got was that competitive swimmers usually start with a warm-up set, then dive into each set with a target on either pace, heart rate or other metric, then they will use other swimming equipments to do kicks, and then going up to another level of intensive set, at the very end, it will be a cool down set to calm down.
For fitness swimmers, an interval is usually not how they swim since their goal is to stay fit or just for fun. So their swims are usually length based, they swim several lengths without a coach or detailed plan.
How to Tell Their Stories?
To decide how to tell swim stories, we need to know what key elements are included within a swim, they are:
More importantly, what do swimmers care about? What metrics do they want to see in their swims?
Sketch and Ideate
When I started sketching some ideas for the Pool Swim feed tile, the first thing I think about was curves. Like every other designer, I like curves, it’s pretty, continuous and, pretty!
Unfortunately, pretty doesn’t mean everything. Especially in this case. Data visualization needs to be true to the data. And that’s why curves don’t work. A swim is length-based, which means we can have one piece of data at a time, and it is not continuous, so using curves doesn’t make sense at all in this case. As pretty as it is, this does not represent the truth of the swim.
After that iteration, I pivoted to a point where each interval will get one data point, where it still shows the progress, and maybe even still have some smooth curves on some of the graphs.
I also tried using pixels to illustrate the graph since the goggles is using a very pixelated screen. As cool as it is, it took away the advantage of how much pixels we have on a screen and limited it to a certain amount. It seems more of a limitation I set for myself.
In the end, none of these graphs work because they don’t tell the full story of a swim. A swim is made of different length, where these options only showed interval numbers, it didn’t even mention any length.
Wireframe and Testing
The goal of this version of Feed is to make it as illustrative as possible which means it should be able to tell its own story. That’s why I decided to show elements like Average Pace, interval, heart rate, time, and distance. These are the values that can show people what this swim is all about very quickly.
The design of the Swim Detail screen is very much inspired by Strava’s analysis screen. I like how it gave users a glimpse of all the data that they all want, and hide those that are not necessary to everybody. With that in mind, I decided to make the swim detail screen highlight data points that everyone cares about, such as total time, avg pace, total distance, stroke rate. Time, distance, and heart rate get their own graph to tell how they are. Based on the nature of a swim, the data shown on this screen is also going to be different.
After wireframing these, I ran these ideas quickly with some swimmers in the office, who hasn’t seen or heard of this redesign project. I showed them the design concept, asked what they think these are and how do they feel.
Some key takeaways I had from this testing is that:
1. Swim details screen is very easy to understand, 100% of testers know what it is, and what each section means. Scrolling down to view more content is a lot easier than tapping on a tab on top over and over again.
2. 0% of the users understood what the graph in feed tile means exactly. Some can guess what each bar means, or what the overlay graph means, or what the horizontal dotted line means, but no one can understand fully what the feed tile is trying to say. In one word, this is just confusing.
I was shocked by this result since I researched deeply into other competitors, and thought most people will like it and understand it. THAT’S WHY USER TESTING IS SO IMPORTANT!!! I took the information back to the product and design team, trying to decide if the graph really needs to change. We really like the design itself, and we know that it tells a compelling story of the swim. So maybe all we need is just education for users who don’t understand this.
With that in mind, I moved on to the UI phase and started planning some onboarding experience for users to understand this graph easily.
UI and More Testing
The UI iteration of the feed tile followed up on the last design, where it still shows the comprehensive story of a swim, using colors and overlay to illustrate. The feed tile will also contain different scenarios based on the nature of a swim. If it’s an interval, it will be the most complicated as it has the most amount of data. If it’s a lap swim, it will be a lot simpler and requires less cognitive load to understand the graph.
The big change for this is to add an onboarding screen or user guide. This will give users the chance to understand how to read the graph. To make sure users can always reference the guide, it will also be embedded in the swim details screen so that they will always have the chance to read it if they want to.
The timing of when the onboarding screen should appear is key. I don’t want it to appear when the user is just going to close it. For example, if it shows up right after the user opens the Feed screen, it’s very likely that the user will dismiss it because:
1. User goal is unknown: users might be in the app to edit their goggles.
2. What are these: Without even seeing a feed tile, showing users a user guide will create confusion.
So I decided to show it after the user tap on a feed for the first time. Since the user is tapping on a feed, it is very likely that they want to know what this swim is, and then they will have more chance to read through the user guide and understand the design.
Another key point is also to breadown the feed graph in user guide to show its details one step at a time.
On the feed tile side, other than a more interesting visual and intriguing story, the new feed tile will also very likely increase the engagement rate of users' interaction with each other. Encourage users to share it to Instagram, Facebook, and Strava. Which will increase the publicity rate of form swim app and form swim goggles. Showing off the complex data we can collect during a swim is a game-changer.
On the swim detail side, it gives users a super-easy way to view their data, instead of tapping into each tab to view a single category of data, now user can just scroll through the screen easy to view the most important data. If they want to view more detailed data, there is a CTA for them to study them. The redesign eased the friction of viewing data, as well as the overwhelming amount of data being shown to them on tap.