TL;DR
Context
Problem
Solution
Team
At a Glance
Error recovery
The old errors named nothing. The new ones name the cause — and a way out.
Connect first. Name it later.
Naming moved out of setup into a clear, skippable step after the robot connects — warmer copy, and nothing blocking the one job: getting it connect.
Meet Emma
Every metric is a person. This one is Emma.
Owners, in their own words — stuck mid-setup, in public.
Where I Started
I knew this flow cold — which is why I didn't trust myself to fix it from memory. I spent the first week with Customer Experience and Quality Engineering. CX showed me the same failures returning as tickets instead of self-serve fixes — onboarding was their #1 contact driver, 35% of tagged conversations. QE knew exactly where setup broke, and why it had never reached design.
Top Pain points
The failures weren't random. They clustered.
1
2
3
The Reframe
Can we design a flow that guides people through a simple, intuitive path — minimizing explicit instructions — and still provides guidance when errors occur?
Simplifying the flow
Built with AI
I prototyped the fix — then put it in front of people to break.
I prototyped the strongest direction with AI. Figma Make cut the “spaghetti work” of wiring screens, so all four error paths were interactive enough that testers could actually try to recover — and the prototype became the shared reference that aligned engineering before anything was built, not a static file left open to interpretation.
That let me de-risk the direction cheaply — real testers hit the flow before a single screen went into production.
AI prototyping was fast — and real enough to fail in: testers hit an actual dead end and found their own way out.”
Testing · two rounds
Round one settled the flow. Round two settled the errors.
Traditional vs. proposed, thinking aloud.
The proposed flow was consistently faster and preferred.
People wanted a flow that finds the device itself, not manual steps.
Simpler, more intuitive, clearer information.
Four scenarios: permissions, device not found, serial in use, Wi-Fi.
Support is a safety net, not a first step — people wanted to solve it themselves.
Human copy beat codes — “Incorrect password” over “Credentials invalid.”
Serial-in-use was the most discouraging; a clear retry restored control.
The pattern underneath both rounds: people didn't quit because setup was long — they quit because errors left them guessing.
The Call I Made
Two decisions set the structure.
The “Name it” screen — moved to after the robot connects, and skippable.
2
Fifteen screens became nine — and every dead end got a way out.
1
Power on
2
Connect mode
3
Network
4
Ready to scan
5
Scan QR
6
Connecting
7
Connected
8
Name it
9
Success
The old errors named nothing. The new ones name the cause and offer a way out.
Impact · in testing
Nobody got stuck. Setup got a third faster.
0%
0%
32%
32%
9
9
Traditional · 15 screens
Manual QR scan
Select device from a list
Limited error handling
Proposed · 9 screens
Scan made foolproof, manual serial fallback
Device found inline, Wi-Fi pulled in
A named cause + a way out of every error
What outlasted the project
The work didn't end at my nine screens.
This flow was never just one product's. It's the pattern every new Whisker device now starts from — instead of inheriting the broken one.
A reference flow
The new onboarding is the baseline the next device starts from — not the broken flow it would have inherited.
What ships on it
Feeder-Robot and future devices adopt the same flow and recovery path, so the work compounds.
A reusable component
The error-recovery pattern is a UX-writing checklist — name the cause, show the fix, lead with a retry, second exit — now built into our Figma, so no device ships an error missing any of the four.
A shared mental model
CX, QE, engineering and PM now share one bar: recovery at every step, support as a safety net — not a first step.
What I'd carry forward
Start with the downstream teams, not end there. CX and QE held the answer the whole time; I'd open the next project in their inbox, not mine.
Test beyond the building. Eleven Whisker employees is directional, not proof. I'd push for outside users before calling a pattern validated.
Take the hardware to engineering sooner. The scan constraint reshaped the flow and surfaced late. I'd pressure-test the physical limits before the first prototype.
Internal logic doesn't always match the user's mental model. Good onboarding is what bridges that gap.
EST. 2025
2:06:12 UTC