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:
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.
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.
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 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).
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.
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.
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:
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:
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.
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.
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.
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:
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.
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:
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.
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.
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.
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).
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.
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:
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
Icons placed in their own quadrants let the rider quickly see what modes their board has toggled.
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.
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.
Other forms of information are presented with notifications, which already exist on the current app and only required a few styling tweaks.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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:
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.
This solves a point of friction I’ve personally experienced with the current app — having to go through the tedious process of pairing.
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’
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.
‘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’
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.
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.
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. 🔥
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.
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 🥺.
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.
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.