Built because: "Whenever a user interacts with Fin, our system needs to make a real-time, three-way decision:"
The idea, in three working flows
Three tap-through flows, one per seat: the customer who asks, the colleague who inherits, the supervisor who corrects. Four screens each.
Designed prototypes. The conversations are fictional and nothing on this page calls a model.
Opened from the file system: the browser refuses module scripts here, so the flows cannot run. Serve the site folder over HTTP and reload.
Priya’s contract question escalates. The handover either carries what Fin knew or drops it.
Four screens, from the settled fix to a handover that repeats nothing.
The same escalation from Marta’s side: five fields arrive, and she replies without scrolling back.
Four screens, from queue to sent reply.
Fin misreads Nadia’s rate card and nothing flags it. The catch becomes a guidance entry, cost stated.
Four screens, from wrong answer to written rule.
d-049 · A seventh page shows the idea as three tap-through flows
- Decision
- Three tap-through flows on a seventh page, notes beside the glass.
- Because
- The replay pages argue at depth; the panel needs tap speed.
- Rejected
- Autoplaying walkthrough videos or GIF captures
- Would measure
- Whether a reviewer taps a full flow before a replay.