You asked for a designer who thinks voice-first. Rather than describe it, we built the session. Start a workout on the device, talk back with the quick replies, and read the plan while the coach keeps counting.
Your app already works: a Flutter codebase, a Figma library, a logo, real users. What it does not yet have is a voice-first structure. Today voice is a microphone icon inside a screen-first product. The three places people actually use it make that arrangement fail in three different ways.
A coach in the ear changes what the screen is for. It stops being the primary surface and becomes the record: the place you glance at to confirm what was heard, and the fallback when speaking is impossible. That inversion touches every deliverable in your posting: flows, hi-fi screens, the design system, prototypes and the store listing. It is the reason to bring in a designer now, before more screens accumulate around the old assumption.
Our stance, stated up front: voice is the entry point, not a feature. Every spoken path gets an equal tap path. Nothing auto-logs without an undo. We say this here so you can disagree early.
Logging a meal means talking across the room. The screen must read at arm's length and confirm what was heard without a tap.
fails: small text, modal confirmationsRecognition drops, headphones are in, and the phone is face-down. Cues must be short and the rep count must survive a misheard word.
fails: long sentences, taps between repsPeople will not speak to a phone in a carriage. Voice-first here means the same flow, driven entirely by taps, with captions doing the coach's job.
fails: voice-only paths, autoplay audioThese are not a style guide. Each one is a decision we will defend in review, and each one is visible in the demo on the right as the warm-up runs. device: warm-up
Every intent the coach understands is also a visible quick reply. The gym is loud, the train is silent; the same session has to work in both. Tradeoff: quick replies cost screen space, so we cap them at five and let context choose which five.
One clause per cue, numbers first, no encouragement filler while someone is under load. Longer lines are for rest periods only.
The coach acts on what it heard and shows the heard text in the transcript. It only asks "did you mean…" below a confidence threshold, and it never blocks the count while it waits. Tradeoff: occasional wrong actions, always undoable, instead of constant confirmations.
Every spoken line is mirrored as text with a timestamp. That transcript is also the workout record, so nothing the coach said is lost when the earbuds die.
Text appears before audio. The orb shows "thinking" within 100 ms. If the model has not answered by 900 ms, a local rules engine speaks the safe line first. Chapter 05 shows where those numbers come from.
The device is a working state machine, not a picture of one. Start a workout, then use the quick replies while the coach counts. The states below light up as the session moves; you can also jump straight to one. device: set in progress
| Quick reply | What the coach does | Why it is designed that way |
|---|---|---|
| Slower | Switches to a three-count tempo and cues it aloud. Persists for the rest of the set. | Tempo is the single most common mid-set request; one word must be enough. |
| Skip | In a set: logs the reps done and moves to rest. In rest: starts the next set now. | Skipping is never a failure state. The log stays honest ("7 of 8"). |
| Reps left? | Answers with the number first, then the context ("Three. Then two sets."). | Numbers first survive noisy earbuds; context can be missed. |
| Pause / Resume | Freezes the count and the clock; the coach stops talking mid-line if needed. | Pause must be instant. We stop speech synthesis, not just the timer. |
| Repeat | Replays the last coach line exactly, with no new latency shown. | Repeat is served from cache; it should never round-trip to a model. |
Timings are compressed so a whole session fits in about a minute: the six-second warm-up stands for two minutes, and rests are six seconds rather than sixty. Heart-rate values are generated, marked illustrative, and never presented as measured.
Happy paths are cheap to draw. The product lives or dies on recovery. Each branch below is a real script the device can run; the first one plays automatically as you arrive here. device: misheard branch
Confidence 0.41 falls under our 0.55 threshold, so the coach asks once, offers two tap answers, and keeps counting. If nobody answers in eight seconds it keeps the current pace and says so. Silence is an answer.
The coach starts a rest-period line, the user says "skip" mid-sentence. Speech stops within 200 ms, the transcript shows the line as cut, and the intent is honoured. Tradeoff: barge-in requires echo cancellation so the coach does not interrupt itself; we specify it as a requirement, not a nice-to-have.
Basement gyms lose signal. The on-device rules engine takes over: counting continues, cues get shorter and pre-recorded, an "offline" badge appears, and the log is written locally. When the connection returns, nothing is re-asked.
We are proposing design, not a rebuild of your backend. But a voice UI drawn without its timing budget is fiction. This is the pipeline we design against, and the numbers that decide when the orb changes state. device: latency HUD on
Targets at p50, illustrative until measured on your stack. Below 900 ms the orb goes straight from listening to speaking. Between 900 ms and 1.5 s it shows thinking. Past 1.5 s the local rules engine says the safe line ("Counting.") and the model's answer, if it arrives, is dropped rather than spoken late.
| Decision | Option we did not pick | What we recommend and why |
|---|---|---|
| Speech recognition | Fully on-device STT. Private and fast, but accuracy in a loud gym drops noticeably and vocabulary is fixed. | pick Streaming cloud STT with on-device VAD. Partials drive the UI early; the final transcript drives the intent. |
| Coach voice | One neural voice for everything. Simplest, but every cue pays the full TTS latency. | pick Pre-rendered clips for the twenty most frequent cues; streaming TTS for everything else. |
| Wake word | "Hey Tempo" always listening. Marketable, but battery cost and false triggers in a shared gym. | pick Session-scoped listening: the mic is open during a workout and closed otherwise, with the state always visible. |
| Rep counting | Voice-counted ("one, two…"). Charming and useless under load. | pick IMU and optional camera on device; rep events skip STT entirely and reach the policy in under 50 ms. |
The plan maps one to one onto your posting: flows and wireframes, hi-fi iOS and Android screens, a Figma design system with variables, developer-ready prototypes with Flutter handoff, and store screenshots. Week eight is buffer on purpose. device: rest
We read your Figma library and current build, map every roadmap feature to a flow, and wireframe the voice-first restructure. Friday W2: flows signed off, or a written list of what we disagree on.
Dialogue trees for logging, workouts and insights, with the recovery branches from chapter 04, the latency rules from chapter 05, and the copy for every coach line. This is the document your engineers will actually read.
Components with variants, variables for colour, type, spacing and motion, and a mapping table to Flutter: each variable names its ThemeExtension field. Friday W4: system v1 in your file, not ours.
Voice mode, unified logging (voice, photo, text writing the same entry), live workout, weekly insights, onboarding and paywall. Platform differences are documented, not improvised.
Interactive Figma prototypes for the five core flows plus one coded state-machine prototype like the device on this page, so the Flutter team can see timing, not guess it.
App Store and Google Play sets in en-GB, built from the real screens. Week eight absorbs review rounds. If it is not needed, the engagement ends a week early and you are not billed for it.
Figures are in pounds and illustrative until we have seen your Figma file and roadmap; the shape of the offer is not. Toggle the optional modules to see the total. device: cool-down
40% on kick-off, 30% at the W4 milestone, 30% on handoff. Fixed price means we absorb overruns; scope changes are quoted before work starts.
Flutter implementation, backend or model work, user research recruitment fees, and copywriting outside the coach's lines. We will name a partner for any of these if you want one.
You own every file, token and line of copy on final payment. We keep the right to show anonymised, non-confidential process work.
Health data is UK GDPR special category. We design with synthetic data only and never ask for production exports.
You talk to the people doing the work. Weekly 30-minute review, asynchronous Loom walkthroughs for everything else, and a shared channel where questions get answered the same day. device: summary
Owns flows, hi-fi screens and the review cadence. Has shipped consumer health apps on both platforms and has opinions about paywalls.
Owns the dialogue trees, coach copy and recovery branches. Writes for the ear first and the screen second.
Owns the design system variables, the Flutter mapping and the coded prototype. Speaks widget tree with your engineers.
You show us the current app and Figma file. We show you which parts of this proposal change as a result; some will.
Within five working days we return an annotated audit: what to keep, what to restructure, and a revised fixed price if scope moved.
Week one starts the following Monday. First Friday, you have the flows in your file.