An app that steers a boat from your phone

A device that takes the place of the steering wheel on a recreational boat and steers it from a phone. The owner pairs it, sets up the boat, draws a route on a map and the boat follows it.

The map is the centre of the app. Around it sit routes, notifications, boats, the camera and the account, and two modes of use: exploring and navigating.

I worked with a design partner, through an agency that handled the relationship with the client. Everything before the visual design was mine: turning the idea into a product, organising its functions, defining the flows and building the wireframes. My partner set the visual direction, and I helped him produce screens.

The work, in order:

1. 01RequirementsThe client’s list and the user stories, grouped by function.
2. 02Functional mapBy layers and screens, with every function tied to the number of its requirement. Two versions in a week.
3. 03FlowsFive, each with its code: log in, sign up, onboarding, pairing and route creation.
4. 04WireframesThirteen groups, from the map to the settings, with notes on how each screen behaves.
5. 05Visual designLed by my partner; I produced screens under his direction.

And the decisions that shaped it:

• Every function carries the number of its requirement

  With the hardware changing and the client one step away, I needed to know what each change touched. The functional map ties every function of the app to the client’s numbered requirement, from 1 to 74. When news came about the wheel, the map showed which screens depended on it. The cheaper option was a plain sitemap, which would have told us where things were but not why they were there.

• Pairing is designed from its failures

  The expected path is short: bring the phone close to the wheel and the app moves on by itself. What needed designing was everything else. Bluetooth off, the device not in pairing mode, the phone not finding it, the light not blinking: each one has its instruction and a way out, down to technical support. Phone permissions are asked for when a function needs them, not on opening the app, with a note on what stops working if they are refused.

• Three ways to make a route, one way to edit it

  A route can be imported from a file, built point by point or drawn freehand on the map. It took several proposals to make the three live together. What they share is the editing: a long press adds a point, dragging moves it, and pressing the line between two points inserts another. A point can also be typed as coordinates or picked from a search of places of interest.

• Only the captain can hand over the wheel

  The app is also for people who rent a boat and travel in a group. Joining a boat as crew is light: bring your phone close to the wheel and the owner accepts you from a notification. Transferring control is not: only the captain can do it. Knowing who else is on board before leaving is a safety measure too, for the day the captain’s phone goes overboard.

The app of a physical device is only as settled as the device. One pairing signal or one limit of the wheel can change several screens, so the behaviour of the hardware has to be written down before a flow is closed. Tracing requirements to functions and functions to flows was what let us reopen things without starting again.

What I cannot claim is how much of the released app is ours screen by screen: I have not compared them. Nor did we test with sailors on the water. That is the part I would insist on today.