yulu — annotated wireframes
Structure and hierarchy for the rider app, before any visual design. Grayscale is deliberate: nothing here should be decided by colour, and every failure state is drawn as a designed screen rather than an edge case handled later.
12 happy-path screens · 5 failure states · readiness rule: required = max(trip × 1.5, 2 km)
Heading / emphasis
Body copy
Primary action
Agent-driven region
A · Account setup
Four screens, deliberately thin. Each field removed is a field that can't fail, leak, or block a rider standing at a bike. No value-proposition carousel: the persona is a returning category user, not someone who needs convincing that e-bikes exist.
A1
Phone entry
1Single field, numeric keypad on open. Errors resolve inline on blur, never on keystroke — a half-typed number isn't wrong yet.
A2
Verification
2Six boxes visually, one labelled field to assistive tech. Resend reads "Resend in 30s" — the countdown is never the only cue that it's unavailable.
A3
Name
3First name only. No surname, email, or gender — none of it is needed to complete a ride.
A4
Wallet setup
4"No deposit, no cash" stated up front — answering the objection before it's raised. Skipping costs nothing here, because payment is captured at the bike (A8), not on trust.
B · Finding a ride
The structural decision of the whole product sits here. Destination comes before the map, because readiness is trip-dependent — a bike ready for 3 km is not ready for 9 km. Without a destination the system can only promise a 2 km floor, which is a weaker guarantee than the product is built to make.
A5
Destination — first step
readiness + battery · computing
5Required range shown per destination, before the rider commits. This is the Battery Decay Agent's arithmetic made visible without ever being labelled as AI.
6"Just browsing" fallback applies the 2 km floor only, with an honest banner on the map. Never pretend a floor-based check is a trip-based one.
A6
Map — cleared bikes only
readiness · silent
7Bikes failing the check do not render. No greyed pin, no "unavailable" state, no tap-to-discover. The rider's model becomes: if it's on the map, it can make this trip.
8The list is a full equivalent of the map, not a secondary view — a map-primary interface whose list is reduced has excluded screen-reader users from the core task.
A7
Bike preview
battery decay · surfaced when marginal
9:41yulu
Reserve and walk over
Walking directions
9
10
9Range framing is always present — "24 km on this bike / your trip needs 9.3 km". A percentage is a fact the rider must translate; a comparison is the decision itself.
10Marginal-trip notice appears only when the bike clears by a thin margin. Meaning is carried by heading text and icon, never by colour alone. "Continue" stays available and unpenalised — the agent informs, it does not gate.
C · Taking the ride
Payment sits at the bike, not at signup. Authorising before the bike is verified means paying for something that might not open — so the hold is placed with the object physically in front of the rider, and released the instant an unlock fails.
A8
Payment at the bike
11A hold, not a capture. Stated plainly here so the rider knows the difference — capture happens at ride end, and F2 releases the hold if the lock never opens.
A9
Unlock
readiness · live re-check
9:41yulu
Scan the code on the handlebar
12
12Manual bike-ID entry is a first-class path, not a permission fallback. QR scanning needs visual targeting and steady motor control that not every rider has.
—The timer does not start until the lock is confirmed open. No charge for a bike that never opened.
A10
Live ride
battery + billing · silent
13Running fare always visible. The research surfaced billing anxiety directly — a hidden meter creates the exact uncertainty this product exists to remove.
14Pause exists for the multi-stop commuter in the research. Lower rate, stated before committing, auto-ends at 40 min — a held bike is a bike removed from supply.
15"Report an issue" attaches full telemetry automatically. The rider never re-explains what happened; the Billing Agent gets its evidence without an interrogation.
A11
Parking + lock confirmation
readiness · verifying close
16The app does not take the rider's word. It holds on "Confirming the lock…" until the ping arrives. Deliberately the inverse of a lock that reads as closed but isn't — the confirmation is the system's responsibility.
A12
Receipt
billing · surfaced when adjusted
17The single most important trust moment: the system caught its own failure and corrected it before the rider noticed. Stated as fact with the reason, without her having to ask.
D · Failure states
Five designed screens, not error handling bolted on afterwards. Every one resolves in the rider's favour by default — the behavioural rule ("prefer a false negative over a false positive; never resolve ambiguity in the company's favour") expressed as interface rather than asserted in a doc.
F1
No bike can make this trip
readiness · surfaced by absence
9:41yulu
Notify me when one's ready
Try a shorter trip
Search another area
18
19
18The second sentence does the work: "There are bikes here, but none have the range for 6.2 km. We'd rather tell you than send you to one that runs out." Without it, an empty map reads as a broken app. Naming the check converts apparent failure into visible diligence.
19"Try a shorter trip" appears only when the failure is range-driven — some bikes would clear a nearer destination. Turns a dead end into a choice.
?Open: should "Notify me" predict a wait time? A confident "about 8 minutes" that's wrong costs more trust than vagueness. Left unresolved pending testing.
F2
Unlock fails
readiness · surfaced
9:41yulu
Try again
Find another bike
20
20"We haven't started your ride, and your payment hold has been released." The rider's instinctive fear here is being billed for a bike she can't use, so the release is stated rather than assumed. Retry caps at two — don't let someone fight a broken lock indefinitely.
F3
Battery dies mid-ride
battery · missed prediction
9:41yulu
Walking directions
I've parked it
21
21Three decisions: fare stops at battery death not ride end, so no charge for walking a dead bike; the adjustment is pre-applied and announced here rather than deferred to the receipt; and no apology language — a factual statement plus a solution reads as competence, an apology reads as an incident.
F4
Billing agent uncertain
billing · escalated
22Ambiguous telemetry — a GPS gap across the disputed window. Rather than a false-confidence auto-resolution: "You haven't been charged for the disputed time while we look." Uncertainty defaults to not charging; the company absorbs it, not the rider.
F5
Lock won't confirm at end
readiness · surfaced
9:41yulu
Try again
End ride anyway
23
23"End ride anyway" stops the fare immediately, flags the bike for pickup, and pre-flags the ride to the Billing Agent. This is the persona's original bad experience redesigned: the same hardware failure occurs, but its cost moves from the rider to the system.
What the ratio says
Twelve happy-path screens against five fully designed failure states. Most micro-mobility apps invert that proportion — failure gets a generic error toast and a support number. Trust is built or destroyed in exactly these five screens, so they were wireframed at the same fidelity as the happy path rather than specified later as edge cases.