Misty Cripps · Vaquita DesignRunning App for Smartwach
Designing a complete running experience for a tiny screen, a moving user, and a runner who wants more data, not less.
I designed a complete running app for a fitness watch: run setup, GPS acquisition, in-run interaction, post-run summary, and historical run management. Most conventional and mobile UX patterns assume a user looking at the screen. A running watch is a different problem.
A running watch isn’t a phone strapped to your wrist.
The fundamental constraints are different in ways that affect every design decision. The screen is small. Targets are difficult to acquire. The user is moving. Glanceability matters. Physical hard keys become a primary input method because sweaty fingers and bouncing wrists make touch finicky. Every interaction must be evaluated to determine whether a runner can perform it without breaking stride.
At the same time, runners are hungry for more data, not less. When we interviewed them, the top three stats they wanted visible during a run were pace, heart rate, and distance, but splits, elevation, gait, stride rate, and elapsed time were close behind. Most wanted to customize what they saw. The challenge was delivering all of that without building an interface that demands focused attention.
Testing scenarios with someone in motion on a treadmill isn’t routine software design usability work, but the findings directly changed the design: the half-map concept was deprioritized, notifications shifted away from social, touch target sizing became a first-order constraint, and the hard-key mapping was simplified based on what participants expected.
Hard keys for high-stakes actions. Touch for moments of transition. Four in-run views the runner customizes.
The interaction model placed start and pause on physical hard keys. These are the actions performed mid-run, when the runner is moving and can’t acquire small touch targets. End was on touch, the moment the runner stops, no longer in motion, ready to see results. Below that, four in-run views the runner could swipe between, each tuned to a specific glance pattern. Stats showed configurable metrics in a customizable grid. The map is split into half-screen (quick orientation) and full-screen (street-level detail) options. Laps presented a tabular list of splits for interval training.
The work was grounded in structured concept testing I planned and moderated. Participants performed tasks on paper prototypes, then treadmill sessions with two fitness watches running different interaction frameworks. The study used the think-aloud protocol with observers taking notes and photos, followed by quantitative experience surveys. The prototypes tested fundamentally different interaction frameworks: one with settings before the run and vertical swipes for the map; one with settings accessible during the run and horizontal swipes for navigation between stats, notifications, and map. The findings shaped what shipped.
The interaction choices that would have looked clever in a meeting and failed on a wrist.
Each rejection below is a place where a more conventional or more elegant-seeming choice would have failed the runner. Sometimes, for reasons concept testing surfaced, sometimes for reasons the constraints made obvious. The decisions defended runner agency, tactile certainty, and the fact that the user wouldn’t be looking at the screen most of the time.
The complete app, end to end.
Four approaches to start/pause/end were evaluated in concept testing: hard-key start/end with touch pause, single-press stop and double-press pause, touch-only with collapsed/expanded states, and pause-menu interstitial before ending. The final approach used hard keys for start and pause, touch for end, with an elapsed-time banner serving as both status indicator and interaction anchor. Tactile certainty for the actions performed most often while moving, while touch is reserved for the moment the runner has stopped.
Stats defaulted to a 1×2 grid showing the runner’s chosen metrics, tappable to cycle through available data points. Half Map gave a quick orientation check alongside live stats. Testing showed that runners preferred the full-screen version, so Half Map was retained as a quick-glance option, and Full Map became the primary option. Full Map activated pan and zoom via double-tap with toggles for contextual markers like water fountains and restrooms. Laps presented a running table of splits supporting both auto-laps (by distance) and manual laps (hard-key press), configured before the run.
GPS lock is the unglamorous interaction that gates the entire experience. The design used a 60-second countdown that communicated progress without demanding the runner’s attention. A retry option was available if the acquisition failed. A fallback to run without GPS was the critical design decision. Rather than blocking the runner entirely, the system acknowledged that sometimes you just want to run, and an imperfect dataset is better than no run at all.
Notifications slid in from the left edge and stacked when multiple arrived. The system displayed contextual alerts (nearby water fountains, restrooms), device alerts (low battery), and status updates (GPS signal quality). Research shaped two choices: auto-dismissing toasts were preferred, but with the option to tap or swipe to clear early. While about half of the participants were interested in route-based landmark notifications, most were not interested in seeing social notifications during a run. The strategy prioritized contextual, run-relevant alerts over social ones.
Run Setup offered configuration for run type (outdoor, treadmill, laps), lap settings, route selection, goal type (time or distance), and the stats layout. Run Summary appeared immediately after the run ended, displaying key stats and a route map with opt-in, selective sharing controls. Past Runs presented a chronological list with sync status indicators that distinguished locally stored from cloud-synced data, and each run’s detail view mirrored the summary screen.
A complete running app reasoned through from first principles.
The design specifications.
The documentation of the work: an interaction design document (every screen, every state, every gesture) and the research document (concept testing methodology, treadmill session findings, participant quotes).