Case Studies

Safely defying gravity  —  A case study

View the original post

Safely defying gravity — A case study

Designing and testing an Apple Watch app for the Onewheel

I ❤️ my Onewheel.

If you’ve never seen or encountered one before, they are basically these electric self-balancing hoverboard things straight from back to the future.

They are extremely fun to ride, with almost everyone who has tried mine quickly becoming addicted to the sensation of ‘floating’ around gyroscopically balanced on a go-kart tyre.

They aren’t just for leisure either. In places where the law permits, they are an increasingly popular part of the growing micromobility revolution alongside e-scooters and the like. Here is a short video from the Wall Street Journal explaining the concept (and rating the Onewheel as a favourite 😉).

But this relationship hasn’t always been perfect. On a couple of occasions, I have been cruising along and suddenly taken a dive like this unfortunate chap:

Moving footage of a man riding a hoverboard, leaning too far forward and getting thrown off onto the road.
Thankfully he was ok. Protect your brain cage, always wear a helmet. Credit: Justin & Gregg

The Onewheel has mechanisms that try to prevent incidents like this (which are rare!), but they aren’t always transparent to the user.

In this case, had the rider been more aware that he was about to overwhelm the motor that keeps him balanced and ‘hovering’ off the ground, he may have been able to avoid this misfortune.

Some crucial aspects of this user experience just aren’t that great…

These accidents, affectionately called ‘nosedives’ by the community, mostly happen because the user lacks sufficiently clear, real-time feedback about what their board is doing and where its limits are.

So, after faceplanting onto the tarmac myself (again), my brain was sufficiently scrambled and I decided to design, prototype, and user-test a solution to the problem.

The outcome of this journey? A new peripheral interface concept, in the form of a redesigned Onewheel companion app for the Apple Watch.

Shots of the interface and various features, which are explored in detail further down in the article.
A visual overview of the main features and UI

What follows is a look at some of the research done, insights found and decisions made along the way. It’s quite a lot for a medium post, so I’ve broken it down into four general sections:

  • Discovery — A look at the issues with existing solutions and the initial user research used to find the common pain points.
  • Solution Mapping — Where the problem statements are defined, features prioritised and the structure of the app are laid out.
  • Iteration and Testing — These sections look at how the design of the main dashboard specifically took shape.
  • The App Experience — A granular look at the various aspects of the design and features of the finished concept.

The State of Onewheel UX

Nosedives and Pushback

The truth is that my unplanned meeting with the ground was likely my own fault. Nosedives are almost always a result of user error. Board malfunctions do occur, but Future Motion — the creators of the Onewheel — builds them like tanks, so it’s pretty rare.

Nosedives typically happen because the system has a limited capacity to balance and propel the rider, and when that is exceeded by asking too much of the board, the motor can no longer provide enough torque to maintain that balance, and the nose drops to the floor.

The board does try to warn the rider. When it is near capacity, it will surge extra power to the motor and lift the nose — Future Motion calls this ‘Pushback’. The rider is meant to feel this and back off — it’s actually reasonably intuitive.

An tutorial illustration to explain the concept of pushback
The way Pushback is meant to work. Credit: Future Motion

However, it does have a few problems:

  • It’s not always clear that it has happened. If you are riding especially hard you might not notice it, particularly if your weight is shifted far forwards.
  • It’s unfriendly to new riders. If you are inexperienced, the board suddenly lurching backwards on you is more likely to interrupt your concentration and balance. Pushback relies on the skill of the rider to intuit the limits of the board.
  • It’s an opaque warning. Pushback just happens, it’s somewhat binary, and doesn’t do much to educate the user on what capacity the board has at any given time or why it is happening (cold weather or wind can limit the capacity of the board for example).
  • It encourages riskier riding. If you intentionally ignore Pushback, as some do, you can often ride much faster, risking increased injury from a nosedive. A warning that doesn’t correspond accurately with imminent danger is much less useful.

I think these problems are the source of the pervasive complaint online that nosedives happen ‘out of nowhere’ — riders were probably warned with Pushback, they just didn’t know it.

So if the direct interface with the board is insufficient, what other options are there?

The Apps

The Onewheel does not have any physical controls on it aside from the power button.

Instead, it is managed with a smartphone app paired via Bluetooth. It provides key information to the rider like current speed, trip distance, battery remaining etc., as well as allowing them to change settings like the riding mode and track their rides (a popular feature in the community).

Screenshots of the Future Motion Onewheel phone app

A smartphone is just not a great peripheral interface in situations where the rider is ripping up trails at 18 mph or commuting on a busy road — you don’t want people fumbling around in their pockets trying to unlock them when their focus should be on where they are going.

The smartwatch is an ideal candidate for a peripheral interface to the Onewheel. It’s easily accessible, hands-free, and designed for lightweight interactions.

So Future Motion created an app for that platform too. It showcases important information like current speed and battery life, and lets the rider toggle their headlights and riding mode.

Onewheel Apple Watch screenshots

Job done? Not exactly. Neither the phone nor the watch app will warn of an impending nosedive or that Pushback has been engaged, and the watch interface is more like a thin client for the smartphone, instead of a standalone experience (though this is a technical limitation to some extent).

Finding out users’ thoughts about the companion app experience on the smartwatch was the next step.

User Survey

A survey was sent to riding communities on Discord, Reddit, and local groups — it received 174 responses.

The first screening questions determined what % of the respondents could be considered ‘enthusiasts’ vs ‘casual riders’.

I anticipated a definite lean towards enthusiast, veteran riders, but the distribution was still better than I initially feared. For example, I did not expect ‘early adopters’ to be such a minority:

A graph showing a breakdown of how long users have ridden the Onewheel for
5+ years = v. early adopter/kickstarter days, 2–5 years = veterans, 1–2 years = XR/pint buyers wave, 3–12 months = some riding experience, >3 months = still green

The Onewheel watch app had a 100% install rate amongst respondents who own an Apple Watch (roughly 1/3rd of the total sample). Few people with other wearables were even aware that apps existed for their boards.

Still, there was a lot of feedback regarding what users like and dislike about the current watch app:

A list of raw positive and negative comments on the Onewheel
A small sample of the responses

These comments were grouped and the main critical themes identified:

  • The app isn’t independent of a smartphone. The practical drawback is higher connection latency, the need to initially connect to the board with your phone (easy to forget, high friction), and the fact you have to carry that fragile device with you at all times.
  • The presentation is not optimal. Users report having to scroll to see content or change settings, difficulties with readability outdoors, and a lack of clear hierarchy.
  • Some desired functionality or information is missing. Users miss things like the ability to ride-track from their watch and, most crucially, also noted the app doesn’t do anything to indicate Pushback or warn of an impending nosedive.

Despite these criticisms, 32% of respondents rated the Onewheel Watch App as a 4 or 5 on a 5 point scale. A further 30% rated it as a 3.

For the current audience at least, Future Motion seems to have done a decent job at meeting expectations — but there is also still plenty of room to improve, especially considering:

Of the people surveyed who did not own a wearable, 90% would purchase one, or be significantly more motivated to, if it had a well designed Onewheel app.

This suggests that there is a large, unfulfilled need out there for a quality Onewheel watch app — excellent motivation!

What do users prioritise?

To learn what features respondents found the most valuable, they were given a very limited number of answers to submit only those that mattered most to them.

A bar graph showing the most requested features by users

One major distinction in responses between those defined as enthusiasts and those who are just casual riders is that the latter does not seem to value social and ride tracking features as much.

This initial research would then go on to help inform the problem statements and feature prioritisation beyond that.

Defining the Problem Statements

These problem statements guided the design process and were constantly referred back to at every stage. They were defined with a user-need structure and ordered by priority:

I : Onewheel riders, of all skill levels, need fast access to critical, real-time information about the status of their board — even in situations where they have little attention to spare — so they can make safer riding decisions.

II : The same group also needs convenient, minimal friction access to specific, essential board settings, so they can ride without requiring high-friction and potentially dangerous alternatives like their smartphone.

III : Enthusiast Onewheel riders need a convenient method to record their rides, so they can easily keep records of their experiences and compete with others in the community.

Problem statement III is undoubtedly superfluous compared to the other two and in a real project would risk getting cut from the scope. However, given that Future Motion has been trying to improve ride tracking themselves, this was a good opportunity to see how the experience could be improved using the smartwatch.

Features and User Flow

Potential features (settings, indicators, functionality etc.), including ones suggested in the survey, were assessed and scored according to a specific set of criteria, which would determine their relative priority:

  • 🎯 Efficacy — Proposed features must answer one or more of the needs in the 3 problem statements, or are a dependency for a feature that does.
  • Feasibility — WatchOS imposes a range of limitations on what an app can do on the platform, so certain features would be difficult or impossible to implement (I do make some qualified exceptions).
  • 😍 Desirability — Is the proposed feature in high demand or otherwise expected by users (based on the survey data).
  • Suitability — Select features that are more suited to the characteristics of a wearable app, and deprioritise the ones that are not.

I also made a distinction between indicators and app functions. Indicators were prioritised separately as they would essentially be competing for real estate on the main dashboard UI.

A MOSCOW chart showing the prioritisation of potential features
Independence (highlighted in red) is currently not technically viable for this app. The reasons for its inclusion anyway are discussed towards the end of this article.

Next, features had to be organised in relation to one another — to create a map of information and to define the user flows.

A hierarchical (parent-child) model turned out to be the preferable option to a paginated (peer) model.

A diagram showing the difference between a page based and hierarchical navigation paradigm
Hierarchical (left) vs Paginated (right) — from Apple’s Human Interface Guidelines

The paginated prototypes had the advantage of easy access to functions like rides and system toggles with just a left-right swipe, but there were just too many elements that couldn’t be considered peers to the main dashboard for it to be a viable layout.

Mapping out the user-flow was straightforward once that choice had been made, as wearable apps are ideally no more than a few layers deep and only require a simple structure:

A visual map of the app’s information architecture
The final user flow ended up looking slightly different at the end of the process

Dashboard concepts

To meet the benchmark laid out by the first problem statement, the main dashboard needs to display key real-time information — current speed, battery life, and indicate Pushback — at a minimum.

It has to be optimised for interactions lasting under a second to avoid distracting the user too much from the task of riding their Onewheel — to be highly glanceable.

A glanceable interface is one that the user only has to look at infrequently, for an absolute minimum amount of time, to accurately parse all of the information they may require.

A moodboard with annotations of various designs
Inspiration came from car and aviation instrument clusters, as well as other great Apple Watch apps — all of which have been optimised for glanceability

Enter the ‘power’ indicator

The first and most important feature of the dashboard is to warn the rider when they are at the limits of their board.

Another binary alert like Pushback on the watch interface didn’t make much sense here, riders are not likely to be looking at their wrist whilst riding. Haptics and audio cues are much better suited to this ‘warning’ function when someone is on the edge of nosediving — these important elements are discussed later on.

So what role should the graphical interface play? I envisioned an indicator that wouldn’t just let them know when a rider reached the limit, but that would provide a continuous, visual scale so they get a sense of how hard the board is getting pushed whenever they glance at their watch.

Think of it like a gauge that fulfils roughly the same purpose as a rev counter does for a combustion engine — except when you go past red you fall on your face.

The benefit is that warnings will become less opaque and riders will have a way to actually see the variable capacity of the board rather than having to guess about where and how far away the limits are.

I settled on calling this value ‘power’ — a bit cheesy and potentially conflicts with battery power/charge, but it accurately describes what is being shown.

I experimented with a range of ways — some abstract and symbolic, some more straightforward — to represent this value. Each of the visuals below represents a few of the main themes:

An animation showing a variety of different visual styles for the dashboard design
It’s not quite as important as glanceability, but it’s desirable for visual mechanics to be intuitive such that they require little explanation


I moved on pretty quickly from sketching into making mid-fidelity interfaces in Figma — the watch is so small that it’s just as quick and lets you visualise more complex ideas during ideation.

Questions soon began to arise about what features and elements of the dashboard would be the most glanceable and efficient, but there were far too many variants to user test each of them granularly.

Instead, I decided to build MVP prototypes and eliminate as many ideas as possible via heuristic analysis and field testing — with the aim of user-testing only the most useful stuff to come out of that process.

A video showing the live testing of one of the designs
Riding around with one of the early prototypes

These prototypes were built quickly and cheaply to enable the rapid iteration of concepts. Static mockups, videos, and even a few quick and dirty apps built using Xcode were loaded onto an Apple Watch for testing.

Testing a spritekit particle effect spinner in playgrounds

Prototypes were modified or eliminated based on whether they passed a series of tests — such as observing how they were affected when viewed outside, where the glare of direct sunlight renders the watch screen much less visible.

Various designs used outside in the sunlight
Visibility takes a noticeable hit in the sunlight at about ~30 degrees rotation from the ideal position. Any design that could show Pushback value/colour and speed here was considered to have passed this test.

By the end of this process, many ideas had been eliminated — particle effects and overt animation, multi-coloured gradients, and ‘wings’ that showed the tilt of the board — to name a few of the more outlandish examples.

3 distinct candidates were left to user test and compare:

  • Design #1 — designed with left-aligned large text, extra information (current ride, icons) and a directional power indicator.
  • Design #2 — two circular indicators, one for battery and one for power, around centred text.
  • Design #3 — edge to edge power indicator, with a large, centred speedometer, and the battery life displayed along the bottom (inspired by usTwo’s work here).
3 different designs examples lined up
The 3 finalists ready for their closeup — simple, bold designs seemed to stand out the best

Usability testing — ‘The Playstation test’


  • To learn if there was a significant difference in the glanceability, both perceived and actual, between designs (or if I should go back to the drawing board because none might meet the required standard).
  • To gather qualitative feedback from users on various key aspects of the designs (e.g perceived affordance — how ‘intuitive’ the purpose of each indicator is).
  • To record observations about user behaviour as they used the interfaces.

The setup

There’s not a whole lot out of work out there on wearable usability testing, especially for a case like this, so a little bit of improvisation was necessary.

To measure glanceability, I devised a test that would use a high speed camera to track how long a users’ gaze was distracted from a primary, high focus workload when they needed to read information from the watch.

Unfortunately, this primary workload couldn’t actually involve riding a Onewheel — chasing a rider down the street trying to film their eyes would be hilarious to watch and also very impractical.

So an analogous, controlled environment had to be set up that approximated a similar demand on the users’ attention — I selected a console and a racing game for the job:

A playstation 4 and a copy of Gran Turismo, a racing game
‘The latest in cutting-edge user testing’

There is some method to the madness here.

Driving around a virtual track at high speed should place similar or greater requirements on focus and concentration when compared to riding a Onewheel — an ideal situation to put pressure on the test participants and force them to keep their glances as short as possible.

6 participants were given a (sanitised) Apple Watch loaded with a small app that I wrote — ‘Glanceo’ — which showed static images of each interface in various different states, controllable remotely via smartphone.

A demonstration of an app that switches the screen of the Apple Watch based on phone interactions.
A visual demo of Glanceo. I know my baby is a bit ugly, but it did the job

The participants were stood in front of a tv screen, given a Playstation controller, and asked to race around a track in a racing game (Monza if you’re curious) as fast as they could.

An iPhone recording at 240 fps — 4 milliseconds a frame — was mounted on a tripod to track the time interval of their glances.

An interval was measured as the period between the participants gaze breaking fixation with the game and returning to it — a ‘glance’.

The sessions were broken up into 3 rounds, one for each design.

At specific points (sharp corners), where focus requirements were highest, the players were prompted to read aloud from one of the three primary indicators on the watch: speed, battery life or power — multiple readings were taken for each indicator (extras were taken where a reading had failed for some reason)

At the end of each round, there was a break and they each filled out a short, post-task survey (loosely based on the TLX survey) to learn about their perceptions of the task overall and the perceived performance of each indicator.

We also had a brief chat where I probed the reasons behind some of their answers, and a semi-structured interview at the end of the three rounds where participants ranked the designs in various categories.


Pairwise comparison was done on each set of glance time data points to work out the relative differences in performance between each design ‘within-participant’.

Those differences were then used to evaluate an overall mean difference and calculate a t-distribution per pair, describing the possible range of relative performance between the indicators for each design overall.

A dot plot showing the differences between designs and indicators. There are 4 items with statistical significance, with design#3’s speed indicator falling behind.
Comparisons highlighted in blue indicate the presence of a statistically significant difference

What became clear is that the glance data alone was not sufficient to draw much of a distinction between the design candidates.

Marginal cases weren’t really counted, so the only thing that was appropriately significant was the poor glanceability of the speed indicator on design#3, even after attempts to increase contrast using shadows and a lower luminance palette.

Realistically, many more samples would have been required to increase precision and draw more useful conclusions from the quantitative data — I only really expected the biggest problems to show up here.

However, the test did provide an excellent context for gathering and supporting qualitative insights. The post-task discussions, surveys and observations made during the process yielded a lot of information — these are just a few of the highlights:

A breakdown of some of the insights, indicating a strong lean towards designs #1 and #2.

Evaluation and further iteration

Design#3, despite the very high visibility of the power indicator, just didn’t perform well enough in other areas — so it was discarded.

Choosing between the remaining two candidates was more difficult — #1 had higher ratings for its speed and battery, but #2’s power indicator performed better — both designs would likely have been viable solutions to go forward with.

The decision ultimately came down to which of them could be improved the most based on the insights from the user test.

Enlisting the help of a few riders to conduct field tests with, and after a significant number of iterations and further interviews, the conclusion we came to was that design#2 had much more room to improve.

For example, the strength of #1 was the readability of its large text size, which could be incorporated into design#2. Conversely, the strengths of design#2 — namely the highly glanceable power indicator — did not translate well the other way.

Two versions of the main dashboard UI, showing iterative progress
The ‘child’ of design#2 was ultimately selected

At the same time, other features had also been designed, tested and integrated — a process I won’t go into here for the sake of brevity — but are showcased in the following sections of this article.

Main Dashboard

The power indicator

The outer ring on the interface is designed to provide a visually intuitive way of determining how much power the Onewheel is outputting in a given direction. Another way I like to think about it is the relative ‘strain’ the board is under.

When the rider leans either forwards or backwards to start moving, the two lines fill their respective halves, mimicking the tilt of the board. The greater the demand on the board, the more area they fill.

These coloured ‘blades’ — so named because they unsheathe — also fade from green to orange as the power value increases, and then flash red once the rider gets too close to the limits of the boards’ output. Flashing was added to the indicator to aid in peripheral glance detection.

Animation of the Onewheel moving and the watch interface matching its movement
The relationship between the Onewheel and main dashboard

The blades also leave a second, darker ‘ghost’ trail that decays after a short delay — the precise delay time would likely be a few seconds after the user had viewed the dashboard (after raising to wake).

These ‘ghost trails’ were added because riders were observed riding fast, but then often slowing down before looking at their watch — it allows them to see the recent maximum they were demanding from the board.

A closeup of the dashboard UI, showing darker trails behind the lighter ‘blades’
A closer look at the blades and the ‘ghost’ trails

Testing showed that users most intuitively understood that a clockwise rotation corresponded to moving forwards and anticlockwise backwards, relative to the board.

Even so, a ‘flip direction’ toggle was added to the main menu to let the user invert which way, left or right, the app considers forwards and backwards.

This is useful for some left-handed and goofy stance riders, but also those who prefer for the orientation of the display to be relative to their perspective instead of the board.

A flip toggle that changes the direction, clockwise vs anticlockwise, of the ‘blades’ rotation

The battery ring

The ring representing how much charge remains is mostly unchanged from the FM developed watch app. A subtle gradient was added to draw the eye to the end of the circle.

The text indicator was initially blue to match, but outdoor testing revealed that using anything but white text takes a big hit to fast legibility, especially at an angle.

The battery ring at various levels of charge

There are many conditions that affect the speed a battery drains at — a steep hill, cold weather, or just riding fast. An energy usage indicator on the ring lets the user know how fast they are burning through their charge at a particular point in time.

The aim is to help them make better decisions about their journey (e.g they may need to shorten their ride if they are burning through their battery quickly) and to educate them on what conditions can cause faster drain, assisting them in building up their own intuition.

A white tab appears on the battery ring, becoming larger as more power is consumed
The original design featured a darker tab to display usage, but it was much harder to read outside

There are cases where the battery can also gain charge, either via the regenerative braking system or through simply getting plugged into the wall.

To visualise this, the ring pulses with light when there is a net gain in battery charge, with a more rapid movement indicating a faster rate.

The battery ring pulses with light to indicate charge
Onewheel plugged in and charging

Contextual UI

There is usually a tradeoff between glanceability and information density in interface design.

Glanceability is greatly affected by the amount of information being displayed — Designing Glanceable peripheral displays

So, to get the best of both worlds, the dashboard changes the information it presents based on context. When a user is stationary or going slow, the interface can safely show a richer variety of information.

When they exceed a certain speed threshold, non-essential elements are hidden and critical indicators like current speed and power are enlarged to make things quicker to read.

A shot of the interface progressing from a maximised state, showing lots of detail, to a minimised state, showing less detail more prominently
The dashboard in various stages of transformation

Icons placed in their own quadrants let the rider quickly see what modes their board has toggled.

A diagram illustrating the position and function of four indicators: riding mode, simplest, headlights and ride tracking

Turning the digital crown also provides an extra power-user interaction, allowing the rider to see less essential — but still relevant — information when they want it.

Animation showing different kinds of information as the digital crown is turned

Notifications and Haptics

Most of the time, riders will have their wrists lowered and the watch screen dimmed/off, so even a highly glanceable interface will be useless at keeping them safe & informed.

Instead, the app would ideally continue to run in the background and use audio cues, haptic taps, and notifications to alert them without ever requiring them to look at their watch. (This might only be possible today in a limited sense using the special ‘frontmost’ app state in WatchOS).

The pushback alert

Currently, WatchOS does not support custom patterns (CoreHaptics), so developers have a limited palette. Given that constraint, this was the ‘default’ Pushback warning:

Still, custom audio-haptics will probably be permitted at some stage — it benefits apps hugely on iOS. It would make a big difference in this app’s case because a rider would be able to associate specific examples solely with the Onewheel and various board states.

For Pushback, one idea was to use continuous, repeated pulses, that increase in frequency as the rider leans further forward after crossing the initial threshold. Though effective, this would be a huge drain on the watch’s battery life and might even become annoying.

A warning that plays when the board senses that it has passed the Pushback threshold, ‘waking up’ the rider to the fact that they are nearing the limit, was the alternative solution.

Both the audio and haptics were subject to extensive iteration and testing. Careful attention was paid to find the right balance between clarity, interpretability and perceived loudness (even in noisy spaces), whilst also making sure it didn’t feel abrasive or too aggressive (as the rider might hear it quite often).

Some more enthusiastic (I won’t say insane) riders like to intentionally induce pushback and even nosedives, so users are given the option to turn the warnings off or to just confine them to haptic sensations.

A menu that lets users modify the pushback warning


Other forms of information are presented with notifications, which already exist on the current app and only required a few styling tweaks.

A view of various notification UIs — battery, too hot/cold etc.
Not necessarily an exhaustive list

These types of notifications all appear with a standard haptic bump and ‘ding’ — shared with all other types of notifications on WatchOS — which means the rider needs to look to know the information.

So, again, exploring the custom audio-haptic cues made sense here.

In an informal experiment on a few participants, all were able to pair each of the cues with the respective battery life warning without difficulty.


Of course, there are other parts of the app beyond just the main dashboard, so thinking about how the user gets around was also important.

A gestural interface

Gesture-based navigation on the main dashboard ended up being preferable to buttons. Large touch targets would just take up too much valuable space which could be better used for displaying information.

Smartwatch apps should rely on gestures more than on navigation elements — Nielsen Norman Group

I tried out a ‘swipe up’ gesture first, but after using it in a prototype, it felt a little bit clumsy to use.

Tapping the interface twice to open up the menu
Testing out the double tap gesture to open the menu

The final interface opts for the long press gesture.

Apple had depreciated the ‘force press’ not too long ago and has been encouraging designers to move functions elsewhere, but the prototype felt more natural and deliberate compared to other options like the double tap — plus it’s already an established gesture.

Long pressing the interface to bring up a menu. A short tap brings up a tooltip instead.
A visual demonstration of the tap and long press interactions on the dashboard

A tooltip appears for a brief moment whenever a user taps the screen on the main dashboard, which should answer any fears about discoverability.

Additionally, using the menu whilst riding at speed is both unfeasible — the board doesn’t accept commands above a few miles an hour — and dangerous.

So when a rider attempts to open it, a tooltip like the one below might show and prompt them to slow down, accompanied by a ‘failure’ haptic bump to communicate the point without the rider needing to look.

Two tooltip UIs
Left: standard tooltip. Right: when the interface is tapped whilst moving at speed.

Main menu

The menu is intentionally designed with standard patterns found in other system apps on the watch.

It’s laid out with high priority toggles at the top of the page, so they can be rapidly accessed, and with the lower priority settings below the fold.

A breakout view of the main menu

When a user issues a command to the board, like changing the riding mode, it can often take a second for the request to actually go through. Toggles flash to indicate a pending command, whilst a colour change indicates the current state.

An animation demonstrating how toggles react to interactions
Toggle interactions

Another decision made based on user feedback was to elevate the riding modes out of its own page and onto the menu, so users could get back to the dashboard in one click after switching.

Ride Tracking

Meet rides, Apple Watch style. It makes it super easy for riders to start, pause and finish tracking their journeys.

One key design decision was to remove the need to manually name a ride at the start or end of a journey. Users only have to press one button, and the rides are automatically labelled by date, time and geographical area.

The ride tracking journey, from start to finish
The process of starting, pausing, and finishing a ride in the app was greatly simplified for the Watch

The ride interface is simple, leaving out much of the detail found on the smartphone app. Distance and max speed values are shown, also indicating if the rider breaks a personal record during their journey.

Current ride interface

The line graphic, which uses GPS to trace the path of the rider, does away with a detailed map to avoid adding clutter. (A paired iPhone would likely be required to supply the location data).

Users might also want to quickly pause and resume their ride tracking — maybe they stop for a coffee — so when tracking is active, items on the menu change accordingly to enable fast access.

The main menu changing to show pause/active ride

Ride browser

Riders can also browse their history, viewing key data like their max speed, distance travelled, and the GPS path of their rides. If an internet connection is available, the app will also download a map image to accompany the path graphic.

Browsing through previous rides
Note the custom names are replaced by location/date/time to make tracking a one-touch experience

Behind the scenes, the watch records a lot more data that isn’t surfaced to the user. Instead, these records will be synced with the user’s phone, which is more suited to displaying and interacting with this rich information.

A screenshot of the Future Motion Onewheel phone app
The Onewheel phone app stats page

Extra bits


It would be fantastic to have real-time complications on the watch face, but WatchOS limits apps to around 1 update about every 15 minutes, or whenever the app gets opened.

This means that data like current speed isn’t viable, and showing battery life without qualification is counterproductive because it will quickly be out of sync with the board.

Instead, battery life is displayed alongside the time the data was fetched — to provide the user with additional context for the information:

Battery life complication screenshots
Large rectangle complications can show more info, like riding mode. Smaller, utilitarian complications show the name of the connected board.

When the wheel isn’t connected, the complication instead prompts the rider to ‘Tap to connect’, allowing them to open the app and auto connect with their wheel, provided it is turned on and available, in just a single press.

‘Tap to connect’ complications for when the Onewheel is not connected

This solves a point of friction I’ve personally experienced with the current app — having to go through the tedious process of pairing.

Tapping the apple watch complication to instantly connect to the Onewheel
Instantly pair with a tap

Siri shortcuts

A nice quality of life feature, shortcuts allow riders to control their boards just by raising their watch and issuing a voice command, without even needing to take their eyes away from the road to look.

Some examples of the shortcuts:

  • ‘Hey Siri, turn on/off my Onewheel headlights’
  • ‘Hey Siri, turn on/off Simplestop’
  • ‘Hey Siri, start/pause/stop tracking my Onewheel ride’
  • ‘Hey Siri, change my riding mode to Pacific’
Siri controlling the Onewheel’s headlights

Made for every Apple Watch

There are currently 4 different sizes of Apple Watch, and users expect a great experience on all of them.

Predefined system elements are used wherever possible — all of the fonts used support dynamic type, and are mostly sized based on Apple’s presets, making scaling down the interface programmatically quite straightforward.

The interface on all four versions of the Apple watch

8. Conclusion


‘Dummy’ prototype apps were shared with a small group of riders, and the visual designs were shown openly to members of the community. Feedback was generally positive, except for an observation that the battery % indicator had receded a bit in prominence.

Crucially, everyone was able to intuit the intent of the power gauge, and observed that it would improve the safety of the riding experience.

One piece, in particular, made me even happier though:

‘Yo, I would buy an apple watch just for this’

— 8bitsandwich

The real win.

What I can say is that, at least with respect to my initial motivation (helping riders avoid further accidents), and meeting the expectations of Onewheel riders, I see this design concept as a qualified success.

To take it further would require formal development and getting it into the hands of general users — which is unlikely to happen in the near future.

Technical viability

This section has been updated due to developments from WWDC21.

Designing for the Apple Watch is much closer to actual development when compared with other platforms — there are lots of procedural quirks and technical limitations you have to bear in mind, even at an early stage.

With this project, I aimed to design an app that respected those restrictions, to make something that could actually be realised, but I also did take a few liberties (hopefully I have been clear about where).

The main one is that, though independent Apple Watch apps technically can connect with Bluetooth peripherals, that connection gets terminated almost immediately when the wrist is lowered and the screen is dimmed/turned off.

Connection screen asking the user to pair to the Onewheel with their phone first
This is why the current Onewheel App requires users to connect to their wheels with their phones first — an experience many complained about

With WatchOS 7, Apple has allowed for background tasks to reestablish a connection to get data. This development makes the design more viable, as it can receive information periodically in the background to update complications/send notifications to update the user on things like their boards’ battery life.

The app could likely be built today, albeit missing a few crucial features. The pushback indicator, which is most critical, essentially requires a constant passive connection so the board can atleast send one-off pushback alerts — still not possible at the moment.

So if that’s the case, why was this concept designed with a small number of currently unviable features?

  • It allowed for a fuller exploration of solving the core problem statements — designing an independent peripheral interface concept that fulfils those user needs and tackled the safety issue has value as a look at what could be.
  • If you don’t ask, you don’t get — The Apple Watch and other wearables are ideally suited to this use case, and it puts it out there for others to consider.
  • These restrictions are constantly evolving and remind me of similar limitations the iPhone used to have. As battery life improves and WatchOS gains more independence, I think we will see further improvements — possibly through offering extra background capabilities to ‘frontmost’ apps only — and this design was therefore made with the intent of eventually becoming viable in the near future.

Alternatively, this problem could be bypassed entirely by convincing Apple that Onewheeling constitutes a workout, so the app can run in the background.

Unlikely, but I can tell you that it’s good for the thighs. 🔥

Next steps?

Technical hurdles aside, I’m not suggesting Future Motion should go ahead and build a new app. But, to continue their expansion outside of their dedicated core fanbase into serving needs like utility and micromobility, progress still needs to be made when it comes to the safety and usability of their boards.

They almost certainly understand this, and they may solve it with a new peripheral interface like this app, or via some other means.

I have little doubt though that they are working on some exciting stuff behind the scenes — their ‘pint’ model was already a great step in the direction of accessibility and user-friendliness — and I can only hope that some of this work inspires them.

Promotion image of the Onewheel pint
Credit: Future Motion

Reflecting back

Why go to all of this trouble? Well, being locked inside for months definitely had something to do with it.

My Onewheel dropping me onto the tarmac presented a novel problem to think about and it was an opportunity to do something a bit different, having never designed for a wearable before.

The Apple Watches’ unique form factor, technical restrictions, and the fact that there are just far fewer resources out there about making stuff for it, really forces the designer to problem solve on their own.

For example, designs often feel radically different from what’s on your computer screen when compared to how they feel on a tiny wrist display — so I found getting prototypes onto an actual watch essential.

However, there is currently no easy way to do this like with phones and desktop designs, forcing me to rely on images and even compiled app prototypes — hopefully Figma or Framer Team will add a watch app target client one day 🥺.

Video of the app in use on the beach
Worst case scenario testing the prototype on the beach

Naturally, there are things that need improving or that I would do differently in hindsight. However, taking on these kinds of unique challenges and having to be flexible with a wide variety of disparate skill sets to solve them was a valuable experience, and ultimately made doing this project worthwhile.

It provided a context to get familiar with watchOS app development, APIs and frameworks, and to really dig deep into HCI papers and digest a lot of basic research on the subjects of glanceability, wearable usability testing and so on. In that respect, the benefits extend well beyond just the immediate design tangibles.

A visual of the software used to make the interactions
Crafting audio-haptic interactions was a particularly deep rabbit hole and might get its own article

I encourage more designers to look out for these sorts of novel problems, even if they might be a bit niche like this one, because there’s value in working on things where the solutions and conventions have yet to be fully established.

That experience and knowledge can then be brought back into other projects, and even might offer future utility as the rest of the world catches up.

So I hope others also experience their own ‘faceplant into the tarmac’ moment and become inspired…

…because I want more awesome wearable apps to use and epic case studies to read. 😉


Finally, I can’t finish without thanking a few people:

  • The testers, survey respondents, members of the community who participated in my research and gave feedback — you guys are awesome.
  • All my friends, family and colleagues that I pestered constantly with notes, doodles and designs.
  • You, for making it this far.

If you have any questions, critiques or comments, please don’t hesitate to reach out. You can find me over on LinkedIn, Twitter, or you can fire me an email at

Safely defying gravity  —  A case study was originally published in Muzli – Design Inspiration on Medium, where people are continuing the conversation by highlighting and responding to this story.