Reach me at:
andrewshpachuk@gmail.com
↗
@lingvo838
↗
↗
Contact
About
Lisbon-based ride-hailing app
A complete UX system for recovering items left in taxis — passenger app, driver app, back-office, and the edge cases that make or break support flows.
Role
Product Designer
Client
Lisbon-based ride-hailing app (confidential)
Year
2026
Scope
32 screens · iOS only · Prototypes
Tools
Figma
Overview
When a passenger leaves something in a taxi — a phone, a wallet, a child's coat — the moment after they realise it is a small panic. The clock is running. The car is gone. They don't know who to call. They don't know if the driver has it. They don't know if they'll ever see it again.
Most ride-hailing apps handle this poorly. Some bury the recovery flow in a help section. Some pass everyone to email-based support that takes 48 hours to reply. Some don't have a structured flow at all.
I was contracted to design a complete lost-item recovery system for a Lisbon-based ride-hailing app. The brief was open: design a flow that works for the passenger, works for the driver, works for the back-office team, and handles the cases that go wrong.
I shipped the full system in three days as Figma prototypes — 32 screens covering all three surfaces and the most common edge cases. The work was approved and went into development.
The starting point
Before designing anything, I spent the first half-day on competitive analysis — how do Uber, Bolt, FreeNow, and Kapten currently handle lost items? Three patterns emerged across the industry:
— The buried form pattern. A help-section form that asks the passenger to describe the item, then promises someone will be in touch. No real-time feedback, no driver involvement, no clear timeline. Passengers report waiting days for a response.
— The email handoff pattern. Even worse — the app routes the passenger to an email address, where the item is now competing with billing complaints and bug reports for support attention.
— The driver-direct pattern. A few apps let passengers contact the driver directly. This works when it works, but creates new problems: drivers feel ambushed, passengers don't know what to say, and there's no fee mechanism for the driver's time and fuel to return the item.
None of these flows respect the asymmetry of the situation: the passenger is stressed and wants resolution fast; the driver is mid-shift and needs structured, low-friction interactions; the back-office only needs to step in when something breaks. A good system should let the passenger and driver resolve 80% of cases without back-office involvement at all.
That became the design principle: default to direct resolution, escalate gracefully when it fails.
Three users, one system
The system splits across three apps that all reference the same ticket:
The passenger opens the recovery flow from their ride history. They describe the item, where in the car it was, when they need it back, and pre-authorise a small return fee.
They get real-time updates as the driver searches, confirms, and proposes a delivery.
The driver receives a push notification with full ticket context — item description, location in car, passenger contact, time window. They confirm whether the item is in the car, propose a return time and fee, and navigate to the delivery point.
The back-office sees the ticket queue. Most tickets resolve without their involvement. The ones that don't — disputed deliveries, ghosted proposals, escalations — surface with full context: timeline, communication log, photos, payment status. Three resolution paths: confirm refund, partial refund, dispute.
The passenger app — 14 screens
The passenger flow had to do something specific: convert a stressed user into a structured information-provider without making them feel like they're filing paperwork.
The flow walks through:
01 — Entry point. From ride history, the passenger taps "I left something." Single tap, no menu archeology.
02 — Choose path. "How would you like to handle this?" Three options: contact driver directly (free), open a return ticket (small fee), or report it stolen (different flow). The framing matters — passengers need to feel they have agency over how this resolves, not that the app is forcing them into one option.
03 — Item details (2 of 3). What did you lose. Photo of the item (or a photo of a similar item online — explicitly allowed in the helper text, because most passengers don't have a photo of their own wallet). Description. Where in the car.
04 — Return details (3 of 3). When do you need it back. Where should it be delivered. Who else can pick it up.
05 — Waiting for driver. The hardest screen in the flow. The passenger has submitted everything and now has to wait. This screen explains what's happening, who is being contacted, what the response time is, and what happens if no one responds. Mental model anchoring: the passenger needs to know this is being worked on, even when nothing visible is happening.
06 — Item found. Driver confirmed the item is in the car. Passenger sees confirmation, can review the proposed delivery time, and can re-confirm the address.
07 — Item not found. The harder branch. Driver checked and the item isn't there. Passenger sees this gracefully — not a dead end, but a redirect to "check other places" with practical suggestions and a path to a human if the item was valuable.
08 — Return proposal. Driver has proposed a specific time, location, and fee (€8.10 in the prototype). Passenger reviews and approves. Clear, structured, no surprises.
09 — Driver en route. Live tracking once the return is in progress.
10 — Confirm payment. Pre-authorise the fee.
11–13 — Delivery confirmation. Hand-off, payment release, rating.
14 — Annual summary. A small reward at the end — your item is home. Soft, finishes the emotional arc.
The whole flow is designed around one rule: the passenger should always know what just happened, what is happening now, and what happens next. Three pieces of information, on every screen.
The driver app — 8 screens
The driver's interaction with the system is entirely different. They're mid-shift. They get a push notification. They have maybe 60 seconds to decide whether to engage before they accept the next ride.
15–16 — Push notification + ticket details. The push arrives with full context. Opening it shows item description, location in car, passenger's note, time window, and the fee they're authorised to receive. No menu, no searching — the driver opens the push and is immediately in the right screen.
17 — Item found confirmation. A pre-payment screen that shows the full amount upfront. Pre-authorised — charged after delivery. This is critical for trust. The driver knows the money isn't yet taken; the passenger knows it's secured. A short checklist confirms they've verified the item ("I physically have the item with me," "It matches the description," "I'll keep it safe until delivery"). The friction is intentional — it makes the driver pause, verify, and commit, which prevents the worst case of "yes I have it" followed by "actually, never mind."
18 — Item not found. Same structure, opposite branch. "No problem" framing — explicit copy that the driver is not penalised for not finding the item. This protects the system from drivers who would otherwise lie to avoid blame.
19 — Create proposal. Pick a delivery time window. The fee is calculated automatically based on distance and effort, but visible to the driver before they send.
20 — Waiting for passenger. Mirror of screen 5 from the passenger side, but from the driver's perspective. Same principle: the driver needs to know it's in the passenger's court without re-checking the app.
21 — Navigation to delivery. Standard map flow, ETA, address details.
22 — Confirm delivery. A green banner appears: "You've arrived." Single action — "I handed it over." Optional escape hatch — "Report a problem." Both ship the ticket forward with full context.
The driver flow is shorter than the passenger's because the driver isn't the one who's emotionally invested. Their job is to verify, propose, navigate, confirm. The system reflects that — economical, structured, fast.
The back-office — 7 screens
Most tickets resolve between passenger and driver. The back-office only steps in when something breaks: driver doesn't respond, passenger disputes the delivery, item turns up damaged, fee is contested.
23 — Ticket queue. Filterable list of all tickets — All / Escalated / Disputes / Closed. Each row shows ticket ID, item, passenger, status, driver, opened time. Status colours communicate priority at a glance: red for disputes, orange for escalated, green for in-delivery, neutral for closed.
24 — Ticket detail. Full context on one screen. Item details, payment status, delivery timeline, communication log between passenger and driver, options to call either party, options to reassign to another nearby driver. The principle: a support agent should be able to answer "what's happening with this ticket" within five seconds of opening it.
25 — Escalated ticket. When the driver hasn't responded within the time window, the ticket auto-escalates and lands here. Banner at the top with the trigger reason. Resolution options surface as buttons: close, refund, reassign.
26 — Dispute ticket. When passenger and driver disagree on whether the item was delivered. Both sides' statements are surfaced side by side. The agent can confirm, refund, or request more information.
27 — Manual close. A modal for closing tickets where automation didn't fit — five close reasons, optional internal note. The internal note field is for the next agent who picks this up — not for the customer.
28 — History / archive. Closed tickets, searchable. Audit trail for legal and quality review.
The back-office tool is intentionally calm. No bright colours, no animations, no dashboards-with-numbers. Support agents work fast and at volume — the interface needs to disappear so they can do their job.
The edge cases
This is the part of the project I'm most proud of, and the part most lost-item systems get wrong: what happens when the happy path doesn't happen.
I designed four edge case states for the passenger app, each addressing a real failure mode:
29 — Driver auto-escalation. Driver hasn't responded within two hours. Passenger gets a push notification with a support reference number already attached — before they have to ask for one. The copy is explicit: "Full refund if item can't be recovered." Removing the fear of losing money on top of the item is half the work; the other half is showing the system already has it under control.
30 — Dispute at delivery. "Tell us what went wrong." Four predefined reasons cover the most common problems (this is not my item, item is damaged, driver didn't show up, other), plus a free-text field. The submit button is red — deliberate. This is a serious action, not a casual tap. Below it: "Cancel – it's fine," because passengers sometimes open the dispute flow by mistake or resolve it verbally with the driver on the spot. Giving them a graceful exit prevents accidental escalations.
31 — Proposal expired (passenger ghost). The passenger never responded to the driver's proposal. The ticket stays open for 48 hours, but the passenger is now in the wrong. The framing acknowledges this without blame: "Your proposal expired. Mário sent a return proposal but it wasn't accepted in time." Two paths forward: update delivery details, or close the ticket with "I found it elsewhere."
32 — High fee warning. When the proposed fee is unusually high (€42 in this case, because the driver is 28 km away and 55 minutes out), the system warns the passenger before the standard proposal view. Red card for the current fee. Green card for the "wait and save" option — set a wider window and let the driver naturally pass closer, fee estimated at €8–12. The two CTAs are intentionally flipped: wait option first, accept option second. Nudge the passenger toward the cheaper choice without removing their agency. The estimate is a range, not a fixed number — honest about variability.
Every edge case is paired with explicit copy that explains what's happening, why, and what the passenger can do about it. The system doesn't pretend nothing went wrong. It tells the truth, then offers a way forward.
A note on copy
This kind of flow lives or dies on its writing. "Cancel" vs "Cancel — it's fine." "Your proposal expired" vs "We tried your proposal and it didn't go through." "Item not found" vs "No problem. We'll let the passenger know."
Every microcopy decision in this system was made deliberately. The principle: the system is on the user's side, even when the user is the one at fault. No blame language. No legalese. No fake cheerfulness. Just clear, kind, accurate sentences.
This isn't a separate writing layer applied at the end. It's part of the design — and on a flow this emotionally loaded, it might be the most important part.
Outcome
The complete system shipped to the client in three days. Three apps, 32 screens, fully prototyped, fully annotated with rationale notes for the development team. The client approved the work and moved it into development. The contract closed successfully.
The most useful thing I took away from this project is that three days is enough for a fully thought-through product flow, if the thinking is done in the right order. Spending the first half-day on competitive analysis and the structural principles meant the screens almost designed themselves once the foundation was right. Most of the friction in projects this size comes from designing without a clear structural foundation, not from drawing screens.
Reflections
If I were running this engagement again, I'd push for one round of usability testing with real ride-hailing users before handing off. The flow is structurally sound, but there are inevitably small interaction moments — the timing of the waiting-for-driver screen, the wording of the dispute reasons, the weight of the "wait and save" nudge — that would benefit from observed reactions instead of designer instinct.
I'd also push for visual design after the structural approval rather than alongside it. The prototype's visual language is intentionally neutral, and that was the right choice for the prototype phase. But there's a version of this flow that would land even better with the visual polish of a finished product.
© 2026. Made by Andrew Sh