NAVAN
Hotel Change & Cancel Flow
When one modal tries to handle six booking states, users hit dead ends. We redesigned from states up — and established a pattern that scaled to every travel vertical that followed.
Problem
A single modal can't handle 6 booking states.
The platform's original change/cancel UI was built for the simplest case: a refundable booking before check-in. It worked fine — until users did anything else.
Hotel modification requests were flooding the CATI (call center) channel — not because users wanted to call, but because the UI gave them nowhere else to go. Actions appeared without context: users couldn't tell if a cancellation was free or penalized until they were already mid-flow. Post check-in? Hard stop. Non-refundable? Hard stop. No alternative paths, no explanation.
"Change" was a single action masking three fundamentally different sub-flows with different rules, pricing, and supplier implications. Manager approval and virtual CC paths were invisible to users entirely — creating abandoned sessions and false support tickets. Support agents were manually bridging every gap.
My Role
Led design across the full cycle — from discovery through engineering handoff — working closely with a product manager throughout. On the strategy side, I mapped the complete hotel booking state machine (6 states, all valid transitions) and drove stakeholder workshops with Support, Product, and Engineering to surface edge cases before a single wireframe was drawn.
I defined the "Hotel Change Phases" swim lane, which became the team-wide source of truth referenced by product, QA, and engineering. To execute, I produced two full-flow iterations in Figma — screen-level UI across all states, every decision point, edge case, and escalation path — and delivered specs, annotated flows, and acceptance criteria directly to engineering.
The Work
State first. UI second.
The first deliverable wasn't a wireframe — it was a complete booking state map. Nothing was wireframed until every state-action pair was defined.
I created a swim lane diagram mapping every booking state across four tracks: user action timeline, hotel stages, booking actions, and TA actions. This resolved immediate ambiguity about scope and continued to be referenced through development and QA — an artifact with outsized ROI that essentially eliminated an entire category of stakeholder back-and-forth.
V1 → V2: what engineering review exposed
V1 established the complete decision tree — both Change and Cancel paths end-to-end, with all branching logic. Engineering review flagged two specification gaps: the virtual CC authorization step was insufficiently defined, and the "Add Days" path incorrectly assumed supplier availability could be checked inline. These weren't design failures — they were exactly what structured cross-functional review is for. V2 resolved both gaps and simplified the entry point: instead of showing all actions and gating at submission, V2 surfaces only the actions valid for the current booking state. This cut decision paralysis at the start of the flow and eliminated an entire class of dead ends upstream.
Designing escalation as a feature
The non-refundable cancel path was the hardest design problem. The obvious solution — a hard stop with policy copy — treats escalation as a failure. Instead, I treated it as a product feature: three explicit paths with different effort/outcome tradeoffs, each surfaced with full context so users could make an informed choice rather than hit a wall.
Cancel-Rebook: platform handles cancel + new booking end-to-end. Highest effort, highest outcome. Contact Support: escalate to CATI with full booking context pre-populated. Warm handoff, not a dead end. Contact Hotel Directly: platform surfaces hotel contact details. Lowest friction for users who prefer to negotiate.
Outcomes Summary
A pattern, not just a fix.
The redesign shipped in Q4 2022. The state-first approach and the Hotel Change Phases swim lane became org-wide references used by product, engineering, and QA throughout development — and beyond. Engineering and product rarely needed to re-litigate edge cases during the build; the artifact had already resolved them.
Targeted the #1 CATI escalation driver
Hotel modification contacts were the highest-volume support category. The redesign's self-serve escalation paths — Cancel-Rebook, Support with context, Contact Hotel — gave users exits that didn't require a phone call.
Scalable pattern for other verticals
The state-aware action model — show only what's valid for the current booking state — was referenced when Flight and Car modification flows were redesigned in the following quarter.
Team alignment artifact
The Hotel Change Phases swimlane became an org-wide reference used by product, engineering, and QA throughout development — and beyond. It reduced back-and-forth on edge cases to near zero during the build.
Invisible states made visible
Manager approval and virtual CC authorization — previously invisible to users and a major source of abandoned flows — were given dedicated, status-tracked screens with clear next steps.