LeaveReady is a human-centered AI commuting concept that helps people make informed journey decisions during transport disruption—without turning predictions into promises or recommendations into permission.
AI product strategyUX/UI and prototypingAI output auditHuman-centered design
Concept study · Scenario-based prototype · Illustrative transit information
08:00 ● ▰
▣ LeaveReady
Routes for 09:00
✦ AI journey comparison · Arrival estimates
▣ Bus 24Matches preferences
08:12 → 08:52 est.
13 min walking · 0 transfers · €3.20
Train A + Bus 5Alternative
08:05 → 08:56 est.
10 min walking · 1 transfer · €3.50
€0.30 above saved fare limit
Both routes are shown with trade-offs. Your saved preferences stay unchanged.
Review alternative for today
Illustrative route times and fares. No live transit verification or automatic booking.
01 / The user problem
A commute isn't just a timetable problem.
Emma, 34, travels to the office three days per week and needs to arrive by 09:00. When her usual bus is delayed, she must compare arrival reliability, walking, connections and cost while preparing to leave. A route that looks faster may not be the right route for her.
She needs an understandable recommendation she can question—not a system that silently optimizes on her behalf.
Design question: How might LeaveReady help Emma make informed journey decisions while keeping AI uncertainty, memory and actions under her control?
02 / Product strategy and critical decisions
AI provides context. Emma keeps authority.
I tested the concept without AI: it remains a conventional route planner with departures and reminders. AI earns its place when it interprets Emma's confirmed priorities and explains why a particular journey fits—not merely because it predicts an arrival.
Decision 01 / Modality
Augmentation, not automation
What: AI compares journeys; Emma selects the route.
Why: Automatic switching could impose additional walking, cost or unreliable connections. Convenience alone does not justify delegation.
Decision 02 / Transparency
Make every answer checkable
What: An AI label, recommendation, provenance, uncertainty cue and three exits.
Why: A polished answer without its assumptions could create false confidence in an estimated arrival.
Decision 03 / Consent
A prediction is not permission
What: No automatic taxi booking, payment or location sharing.
Why: An unwanted financial commitment is harder to undo than an extra confirmation step.
Central principle: LeaveReady may recommend a journey, but it must never turn an estimate into a promise, a one-time correction into permanent memory, or a saved preference into permission to act.
03 / Designing the AI response
Make it inspectable, not just persuasive.
I wrote the response contract before prompting AI to generate interface concepts.
Canonical illustrative journey: leave 08:12 · Bus 24 toward City Centre · estimated office arrival 08:52 · 13 minutes walking · 0 transfers · €3.20 fare.
What the user sees
“Leave home at 08:12.”
Bus 24 toward City Centre. Estimated arrival: 08:52. Show the boarding stop, direction, walking allowance, fare, transfers and a route timeline.
Why this response
“Arrival is an estimate.”
Based on Emma's confirmed 09:00 goal, saved walking and buffer preferences, and illustrative transport information. Missing live information stays unknown.
Explore the actual scenario-based prototype rather than a strip of tiny screenshots. The experience covers today's recommendation, route preferences, comparison, journey preview and the critical-state branch. Every answer is predefined so the behaviour can be reviewed consistently.
Original interactive prototype · illustrative travel data · no live navigation, booking or payment
05 / Human review of AI-generated work
AI gave a plausible answer. I checked it.
The generated interface looked credible but contradicted the design specification. I compared the output against the agreed route values, provenance and interaction boundaries, then corrected unsupported elements.
Readable reconstruction from the documented AI-output audit. Click to enlarge.
AI-generated deviation
Before / Unverified
“Arrival 08:42”
AI changed the specified 08:52 arrival, omitted the provenance and confidence cue, and introduced “Recommended” without explaining ranking criteria.
Human decision and correction
After / On specification
“Estimated arrival 08:52”
I restored 08:52, the explanation of inputs, an explicit uncertainty cue and the correct walking/boarding details. An estimate was not presented as a guarantee.
My HAI judgment: The missing uncertainty cue could be more harmful than missing provenance. Without “Arrival is an estimate,” Emma may treat 08:52 as guaranteed and make a costly decision. Both matter, but preventing false certainty comes first.
06 / Critical states
Failure should reduce AI authority—not user control.
I designed four distinct responses for moments when the system cannot, is uncertain, is corrected or must decline an action. Each state explains what is known, what is missing and what Emma can do next.
08:00 ● ▰
▣ LeaveReady
Taxi cannot be confirmed
Unverified availability
I can't confirm a taxi option for your 09:00 arrival goal. Availability and fare are unknown. Nothing was booked or charged.
Compare public transport · Change route · Not today
Scenario-based interface behaviour · No live provider integration.
Design rationale
Don't invent a successful outcome.
If taxi availability or fare cannot be verified, LeaveReady must explain the gap, avoid implying a booking, and offer a useful alternative path. An unconfirmed fare cannot become a promise.
Human-controlled boundary: Booking and payment require Emma's separate confirmation.
07 / Responsible personalization
Using, remembering and acting are three separate permissions.
LEARNS FOR THIS JOURNEY
Emma's confirmed start, destination, current route information and chosen constraints help prepare today's options.
A correction is temporary unless she says “Save for future.”
STORES ONLY BY CHOICE
Explicitly saved preferences, such as home address, office days, 09:00 arrival goal, walking allowance and departure buffer.
Each saved item should show its source and remain editable or removable.
NEVER STORES
GPS trails, journey history, calendar contents, mood, health, payment-card data and inferred willingness to pay for taxis.
Use for one journey is not permission to remember.
View
Show real saved values and where each came from—not unverified assumptions.
Edit
Future recommendations must use the newly confirmed value.
Delete
Stop using the removed preference. Never silently restore it.
Reset
Require confirmation and explain exactly which saved preferences will be deleted.
These memory rules are product requirements and conceptual interface designs, not verified persistent-storage functionality in the prototype.
08 / Bias and alternatives
Familiar isn't always better.
Repeatedly ranking routes by previously saved preferences can suppress options that may fit Emma's current needs. I addressed this familiar-route loop by making one alternative visible with meaningful trade-offs and by flagging conflicts without changing saved preferences.
Leave 08:05. Duration 51 minutes; 10 minutes walking; one transfer; €3.50 fare—€0.30 above the saved limit.
The alternative reduces walking by three minutes, but arrives four minutes later, involves a transfer and exceeds Emma's fare preference. She can review it for today. Her saved preferences stay unchanged.
09 / Working with AI, critically
I briefed the tool. I evaluated the output.
ChatGPT supported visual concepts, scripted critical-state responses, a memory-screen draft and initial narrative structures. I used Figma to assemble and review the designs. I retained responsibility for the rules, constraints, review and final choices.
01
Specify the interaction
I defined the AI response anatomy, required departure and arrival values, real labels, exits and the difference between confirmed data and estimates.
02
Constrain the AI prompt
My four-round brief separated screen structure, journey content, interactions and visual language. It explicitly required 08:12, 08:52, 13 minutes walking, €3.20 and a disclaimer for fictional route data.
03
Audit against the specification
I marked what survived, what was dropped and what appeared uninvited. I found timing drift, lost provenance, missing uncertainty and misleading ranking.
04
Correct and name the limits
I restored the correct text and response rules. I rejected claims of live verification or measured benefits: the prototype uses fixed-response scenarios and illustrative route information.
Documented brief excerpt / content constraint
“Use specific, actionable journey information: 08:12 departure, Bus 24, 08:52 estimated arrival, 13 minutes walking and €3.20 sample fare. Explain why the route was suggested, distinguish estimates from confirmed information and disclose fictional data.”
10 / Evaluation, evidence and limitations
Prove the designed behaviour. Don't invent product results.
What was investigated
A clickable scenario-based prototype
The user flow covered Today, route preferences, route review, journey preview and taxi-related critical states. The responses were written before interaction and use controlled illustrative data.
A qualitative first-time-user observation identified a possible mismatch: “Start journey” could sound like live navigation even though the interaction opens a preview. The proposed correction is “Start journey preview”.
Evidence boundary
What this does not claim
No live transit accuracy, GPS navigation, taxi inventory, booking, payment or working memory deletion was demonstrated. No travel-time improvement, conversion gain or statistical usability result is claimed.
A production release would require reliable transport integrations, real consent and memory controls, safety validation, accessibility testing and further user research.
Human-owned design decisionsAudited AI draftsScripted interactive prototypeTransparent limitations
11 / Reflection
Better AI should improve predictions—not silently gain authority.
Across the project, I moved from defining what AI may do, to checking what it says, to controlling what it remembers. My responsibility as a designer is to verify its output, expose uncertainty and keep consequential decisions with Emma.
KEEP
Write the rules first
Define behavioural boundaries, consent and evidence before generating interface screens.
STOP
Trusting plausible AI output
Correct data and calibrated confidence matter more than polished appearance.
NEXT
Test and validate
Test “Start journey preview”, uncertainty comprehension and preference controls with first-time users.
