← BACK

OVERVIEW

PROBLEM SOLVING

DESIGN DECISIONS

FINAL PRODUCT

CONTEXT

CONTEXT

For Swimmers,
By Swimmers

Most fitness trackers aren’t built for swimmers. After water-damaging my phone trying to keep track of my practices, I designed ripl, a more intuitive way to make waves.

OVERVIEW

Interviews into Affinity Maps

I conducted deep-dive interviews with swimmers ranging from casual lap swimmers to collegiate athletes, mapping their insights alongside quantitative data from 44 survey responses.

Affinity mapping current user pain points and pathways.

I ultimately identified a gap between swimmers' desire for data and the ability to capture it:

01
Recognizing swimmers just want to swim
When swimmers just want to swim
When swimmers
just want to swim

Swimmers' hands are too wet to get dirty; they reject complex practice setups for low-effort, analog methods—like printed sets, whiteboards, and recycled workout components/coach-prescribed sets.

Swimmers are simply looking to swim; they prefer printed sets, whiteboards, and recycled workout components and/o coach-prescribed sets.

Swimmers would not put in extra effort to build out practices, especially for a screen.

+
02
Navigating a "sync or swim" environment
A "sync" or swim environment

Consistency is community-driven. Peer accountability helps swimmers 'lock in' during practice, but can also drive recurring app usage. Tackling the fatigue of solo training can directly translate into user retention.

Consistency is community-driven. Peer accountability helps swimmers 'lock in' during practice, but can also drive recurring app usage.

Swimmers thrive when in groups, which can further drive app usage.

=
03
Addressing the accuracy gap

To push performance, swimmers time themselves, but relying on clocks on deck requires approximations, mental math, and active recall; they lack means—such as exact interval splits—to actionably track progress.

To push performance, swimmers time themselves, but currently rely on approximations, mental math, and active recall, rather than exact metrics/splits.

Swimmers may time themselves but lack precise ways to track progress.

↓
How might we create a tool leveraging swimming's social and technical aspect to keep users coming back?
How might we create a tool for swimming's social and technical aspect to keep users coming back?

PROBLEM SOLVING

Sketches and sprints!

Based on market research, I mapped the original vision for the app, with early sketches focused on a quick and easy workout builder (e.g. Hevy, Strava)—fledged with the ability to scan practices and invite others to work out.

Based on market research, I mapped my original vision for the app, like Hevy or Strava—but with the ability to scan practices and invite others to work out.

Based on market research, I mapped my original vision for the app, like Hevy or Strava—but with the ability to scan practices and invite others to work out.

The Reality Check

However, research revealed a critical flaw: you can't quick start a practice, but swimmers also don't follow practices to a T, anyway. Practice is fluid; swimmers frequently adjust intervals or distances mid-set based on fatigue or lane density.

Competitors like MySwimPro dominate the practice-building market, and yet my survey revealed that swimmers rarely purchase these subscriptions, validating these findings.

However, research revealed a critical flaw: practice is fluid; swimmers frequently adjust intervals or distances mid-set based on fatigue or lane density.

The Nuance to Social Swims

User research clarified a vital distinction in social swimming: others seeing their practices would not affect (and might even deter) motivation.

Motivation came from showing up and swimming with others (not how hard you swam).

I pivoted to a collaborative multi-stopwatch, transforming progress tracking from a solitary burden into a shared interaction. By leveraging coaches/resting peers as timers, the design turns 'dead time' into a social utility that drives retention with zero additional overhead.

I pivoted to a collaborative multi-stopwatch, transforming progress tracking from a solitary burden into a shared interaction.

By leveraging coaches/resting peers as timers, the design turns 'dead time' into a social utility that drives retention with zero additional overhead.

DESIGN DECISIONS

Flexibility First

Instead of forcing users to pre-program a set, I designed a "Quick Time" Ad-Hoc Timer. This allows the "timer" to define a set as it happens (e.g., "let's do 3 x 50s for time"), mirroring the fluid reality of practices.

Building for Scale

Standard timers fail to handle the density of real practices. To manage this, I implemented progressive disclosure via a collapsible queue to reduce cognitive load.

Meanwhile, manual heat triggers accommodate staggered starts, prioritizing human flexibility and data accuracy.

Increasing focus

Splits can tell a swimmer how fast they're progressing, but form informs how they can progress faster (via technique).

I introduced a video-overlay feature for single-swimmer heats, allowing the timer to record the swim while logging splits.

Splits can tell a swimmer how fast they're progressing, but technique informs how they can progress faster.

I introduced a video-overlay feature for single-swimmer heats, allowing the timer to record the swim while logging splits.

Visualizing the Grind

With these new data from practices, I designed a progression graph that maps splits over time, eliminating the burden of memory-based approximations.

By implementing contextual aggregation through session averages, the tool identifies the user's "base pace," fostering sustainable, long-term progress.

Fit for the wrist

While the mobile app solves for group logistics, the Watch solves for individual flow. I stripped away the collaborative roster to focus on a singular, high-contrast metric view.

While the mobile app solves for group data capture, the Apple Watch still offers a unique opportunity to focus on solo training while timing.

REFLECTION

Building for what's real

Working with developers as the lead designer kept my designs grounded.

To bridge the gap between us, I learned HTML and CSS to build more realistic screens and better communicate my visions and requirements.

Working with developers as the lead designer kept my designs grounded. I learned HTML and CSS to build more realistic screens and better communicate my visions.

UX beyond UI

Designing system logic (handling multiple groups, staggered starts, and databases for progression) across different user experiences was one of the most challenging, yet rewarding parts of designing.

In designing system logic (handling multiple groups, staggered starts) around swimming, we digitized the accountability that keeps swimmers coming back to our app.

A special thanks to…

Cymberly Tsai (frontend developer)

Cymberly Tsai (frontend developer).