THE BRIEF
→Improve online top-ups.
THE QUESTION I CHOSE
Which commuting decisions could software responsibly remove?
Fluxy — A commuting agent that steps in when the journey changes.
I turned a narrow online top-up brief into a product that protects the passenger's goal, prepares the next decision and leaves consequential choices in human hands.
The decisionAutomate preparation, never a consequential action without a person seeing and approving it.
[01.00]>Read the burden
The top-up was one transaction inside a commute people had to manage continuously.
> WHAT I MAPPED
None of the decisions was difficult. Their accumulation was.
Before leaving, passengers checked balance, weather and timing. During travel they monitored delays and transfers. When the network changed, they compared alternatives and rebuilt the rest of the journey.
- 01Prepare
Balance, weather and timing before leaving.
- 02Monitor
Delays, transfers and remaining time.
- 03React
Options when the network changes.
- 04Recover
The rest of the journey after disruption.
> COMPETITIVE BENCHMARK
Transport apps informed passengers. They rarely carried the decision forward.
I compared local operators, journey planners and mobility products across eight behaviours. I marked partial support instead of rounding it up: the opportunity only became visible when information, anticipation and consent were considered together.
BEHAVIOURMetro + TMBCitymapperGoogle MapsSNCF ConnectTfL GoFluxy
Multimodal routing×✓✓✓✓◐
Real-time disruption alerts◐✓✓✓✓✓
Proactive rerouting×××◐◐✓
In-app payment / recharge◐××✓✓✓
Standing preferences×◐◐✓✓✓
Automatic fare reasoning×××◐✓✓
Approval before spending———◐◐✓
Passive routine learning××◐××✓
✓ Full◐ Partial× Not supported— N/A
- 01Repeated decisions
Passengers repeat the same small decisions every day.
- 02Information arrives late
Real-time information only becomes valuable when a change is detected.
- 03Checking has a cost
The cost of missing an important update is much higher than checking once.
- 04Trust is contextual
People accept anticipation when it is clear why the intervention matters.
Goals stay stable. Routes, context and recommendations can change.
[02.00]>Define the agent
The strategic move was a product that decides when interaction is necessary.
> WHY AN AGENT?
The problem was not access to information. It was who had to do the work.
At that point, I changed my position. A better dashboard would still require the passenger to wake, check, decide and act every day.
So I defined Fluxy as an agent that observes, anticipates and recommends continuously — then asks for approval at the boundary where human judgement matters.
> AGENT-ASSISTED JOURNEY
One goal. Three levels of autonomy.
I mapped the agent as a decision system: first understand the passenger's goal, then classify the impact of change before choosing whether to act, ask or step back.
01Goal
Arrive before 08:45
02Observe
Monitor balance, network and time
03Detect
A disruption threatens the goal
SILENTLow impact
Adjust the journey without interrupting the passenger.
No notificationCONSENTSolvable
Prepare the best alternative and ask before applying it.
Passenger decidesFALLBACKNot solvable
Explain the constraint honestly and preserve control.
No false promiseThe interface appears at the decision boundary — not before.
> INTERACTIVE MODEL
See how Fluxy reasons before it intervenes.
Start with a passenger goal, introduce a change in context and inspect the recommendation. The prototype makes the operating model tangible without pretending the agent should decide everything.
Open in a new tab[03.00]>Bound autonomy
Trust needed an interaction model, not a reassuring tone of voice.
> FOUR AUTONOMY RULES
These rules defined when Fluxy could stay silent, prepare context, ask for consent or admit the goal could not be protected.
- 01Goal stays fixed
WhenContext changes around a stable arrival goal.
Fluxy mayRecalculate and prepare a better option.
LimitNever change what the passenger is trying to achieve.
- 02Useful before visible
WhenRoutine information becomes consequential.
Fluxy maySurface only the next useful action.
LimitNo notification when nothing needs a decision.
- 03Consent at cost
WhenMoney, personal data or commitment is involved.
Fluxy mayStage the action and explain the reason.
LimitThe passenger approves before anything happens.
- 04Fallback honestly
WhenFluxy cannot protect the original goal.
Fluxy mayExplain the constraint and the safest alternative.
LimitNo confident answer when the system is uncertain.
I treated the agent as a policy system, not a chat surface.
THE WORK
I translated fare policy, accessibility, operations and passenger trust into explicit autonomy rules, then used AI to simulate edge cases and produce auditable decision traces.
THE BOUNDARY
AI expanded scenario coverage. It did not define the boundaries: payment, personal-data expansion and major journey changes always remained behind human approval.
> VISUAL IDENTITY
Calm by default. Visible when it matters.
I translated the agent's behaviour into a semantic visual system. Paper is the only product background; amber is reserved for Fluxy speaking proactively; transit and alert colours describe system state rather than personality.
Trust is built through consistency, not personality.
Fluxyby Metropolis Underground
Fluxyby Metropolis UndergroundNAMEFluxy
Move with confidence.
PERSONALITY
CalmHelpfulPredictiveHuman
PAPER#F5F3EF
INK#12151C
AGENT SIGNAL#E8A33D
TRANSIT#1F7A6C
ALERT#B23A3A
VOICE & ACCESSIBILITY
Confident, plain and transparent about every recommendation. Supporting text and error colours were deepened when the brand values failed WCAG AA — accessibility won over exact hex fidelity.
> BRAND IMAGERY
The agent belongs in the journey, not at the centre of it.
Everyday movement, with assistance present only when context makes it useful.
[04.00]>Make it testable
Three moments made the autonomy model concrete enough to inspect, challenge and test.
01 / DAILY BRIEF
Build trust before disruption.
One glance replaces checks for balance, weather, timing and route confidence.
02 / SMART RECHARGE
Autonomy stops at payment.
Fluxy monitors balance and stages the top-up. The passenger still authorises the transaction.
03 / GOAL PROTECTION
The objective survives change.
When disruption threatens arrival, Fluxy explains the trigger and recommends a route in terms of the passenger's priority.
> WHAT THE PROJECT DEMONSTRATED
The strongest product decision was deciding when the product should disappear.
One model connects the daily brief, low balance and disruption instead of treating them as separate features.
Clear boundaries distinguish what Fluxy may observe, prepare, recommend and execute.
A coherent language carries the same principles through product behaviour, interface and brand.
The interaction model is designed. Trust still has to be earned in use.
This is an independent concept, so I would not present prototype coherence as product impact. The next step is to test whether passengers understand why Fluxy intervenes, notice when consent is required and recover confidently when the original goal cannot be protected.
- Comprehension of the intervention trigger
- Consent and refusal at payment
- Trust after an honest fallback
The interaction model can extend without turning Fluxy into a feature catalogue.
- Live activity surfaces for time-sensitive changes.
- Calendar awareness when arrival time matters.
- Wearable cues for hands-free journeys.
- Continuous learning with explicit permission.
Software can monitor, prepare and recommend. Consequential decisions remain human.
> MORE WORK