CASE STUDY / 01

Detour.

AI travel itinerary orchestration, designed for the moment your plan breaks.

ROLE

Sole Product Designer End to end

TIMELINE

4 weeks (2026)

TEAM

1 Designer (self-directed)

PLATFORM

Mobile iOS concept

PROBLEM

Multiple apps.

One cancelled train.

No answers.

You're in a ryokan lobby in Hakone. Your Shinkansen just got cancelled.

02 / 22

PROBLEM STATEMENT

One cancelled train doesn't just kill a train ticket.

It kills the dinner after. The tea ceremony.

The Kyoto hotel that's still expecting you tonight.

​

No product handles those connections.

03 / 22

RESEARCH · METHOD 01

Diary study.

Six multi-city travelers logged every on-trip decision for the duration of a recent trip. The goal wasn't big disruptions. It was the quiet, continuous adjustments nobody remembers.

What showed up

"I didn't realize how often I was adjusting until I wrote it all down."

"Most changes were small. 10 minutes here, swap this for that."

Participants 02 & 05

Daily adjustments, on average

2–3

Across 6 participants, recent multi-city trips. Each adjustment propagated to at least one downstream booking.

04 / 22

RESEARCH · METHOD 02

Critical incident interviews.

Five travelers who had recently lived through a major disruption. Where the diary caught the average, these interviews caught the extremes.

The finding that anchored the product

The hardest part wasn't finding alternatives. It was not knowing what else would break.

"I rebooked the flight, then realized my airport pickup and first night hotel were both wrong now."

"I spent two hours fixing things that broke because of one delay. Each fix created another problem."

Participants C03 & C05

05 / 22

RESEARCH · METHOD 03

Competitive experience audit.

Each existing tool owns a slice of the problem. None of them own the system.

TripIt

Aggregates data. No intelligence.

Google Calendar

Shows events. No relationships.

Expedia Romie

AI assistant. Only Expedia bookings.

No product orchestrates across all your bookings. That gap defined the brief.

06 / 22

SYNTHESIS

From scattered points to a connected graph.

Existing tools treat bookings as isolated points. Travelers think in systems. One cancelled train pulls two activities and a dinner out of place with it.

How tools see it

→

How travelers see it

07 / 22

PRODUCT DEFINITION

Detour.

Understands the relationships between your bookings. Re-orchestrates when things change.

THREE CAPABILITIES

Stress test

↓

Daily adjustments

↓

Disruption recovery

FOR

Self-planned multi-city travelers.

08 / 22

Two minutes before the trip saves two hours during it.

DESIGN DECISIONS

Exploring interaction directions.

The question wasn't "how much AI." It was how does the AI arrive in a moment of stress?

A

Chat-based

Natural interaction, low learning curve. Not chosen: too slow when the user is already stressed.

Not chosen

B

Timeline diff

Changes at a glance, clear comparison. Not chosen: too narrow on mobile.

Not chosen

C

Solution-first cards

Fastest to decision, details on demand. Chosen.

● Chosen

Takeaway. Solution-first cards won because they move fastest to a decision when the user is already under load.

09 / 22

DESIGN DECISIONS

Three tiers of delegation.

Not every action carries the same weight. The framework maps reversibility against how much the system acts on your behalf.

TIER 01 · REVERSIBLE

Auto-execute

Low risk, system does it, you observe.

TIER 02 · MIDDLE GROUND

Draft, then confirm

System prepares it, you tap to commit.

TIER 03 · IRREVERSIBLE

Suggest only

High stakes, you remain the agent.

Takeaway. Trust is built through transparency about what the system will do, not through settings.

10 / 22

DESIGN

Design foundation.

DESIGN.md is the single source of truth. Tokens, components, patterns — version-controlled, cross-screen consistent by default.

11 / 22

PRODUCT · D0

Connect and go.

No registration. Email is identity. Missing bookings can be added later.

Phase 1. Connect email.

Phase 2. Scanning.

Phase 3. Trip found.

12 / 22

PRODUCT · D1 + D2

See your trip as a system.

Stress test catches issues before they become emergencies.

D1 Trip overview. Itinerary as a graph. Amber days flag tight connections.

D2 Conflict detail. Stress test drills into one tight connection with fix options.

13 / 22

PRODUCT · D5

When things break.

Shinkansen cancelled in Hakone. Six downstream plans affected by one cancelled train.

D5 Notification. Alert lands in the day view context, not a siloed screen.

D5 Impact list. Full downstream breakdown, grouped by type and severity.

14 / 22

PRODUCT · D6

Two paths forward.

Must-haves (Arashiyama & Dinner) preserved in both plans. The cost difference is yours to weigh.

Plan A. Reroute today via Nagoya bus + Kintetsu train. ¥6,800 extra. Reschedules tea ceremony. Drops tonight's dinner.

Plan B. Wait one day in Hakone. ¥18,500 extra. Keeps Arashiyama and Michelin. Drops one Kyoto day.

15 / 22

PRODUCT · D7 + D8

Execution, tier by tier.

Three tiers in live action: auto-searched, confirm to purchase, draft your own message.

D7 Execution. Cascade of actions. Results stream in. Tiers 2 & 3 wait for your tap.

D8 Updated itinerary. New Day 5 / Day 6, all changes applied. You are back on a plan.

16 / 22

PROTOTYPES

See it in action.

Both Flows are interactive HTML/CSS prototypes. The Disruption recovery went into usability testing.

Disruption recovery. D5 → D5/D6 → D7 → D8.

Pre-departure setup. D0 → D1 → D2.

17 / 22

VALIDATION

Scenario-based usability testing.

5 participants. Full Prototype A flow. Think-aloud protocol.

GOING IN, I WAS TESTING

HYPOTHESIS 01

Users want solution plans before impact details, not after.

HYPOTHESIS 02

Automation needs visible acknowledgment to be trusted.

WHAT I FOUND

FINDING 01

4 of 5 navigated back from impact analysis to recovery plans at least once. Average disruption-to-plan time: 58s.

FINDING 02

3 of 5 tapped completed actions to verify they happened. 2 asked "how do I know the tea ceremony was really rescheduled?"

AFTER ITERATION

Plan selection time dropped to 31s. Zero of 5 users questioned completed actions.

18 / 22

ITERATION · 01

Solution first, details on demand.

Finding 01 said users bounced between impact and plans. I merged them. Plans on top, impact collapsible.

BEFORE · V1

D5 notification → separate impact page → separate plans page. Three taps, two ping-pongs.

AFTER · V2

Merged view: plans surface first. Impact analysis becomes optional expansion.

19 / 22

ITERATION · 02

Making automation visible.

Finding 02 said a static "Done" screen wasn't enough proof. I animated the cascade, 800ms apart.

BEFORE · V1

Static result screen. Users couldn't tell whether actions happened.

AFTER · V2

Actions complete one at a time. Checkmarks spring in with light haptic. Trust through visibility.

20 / 22

OUTCOMES

Tying it back.

Every opening beat from slide 02 gets an answer.

31s

Disruption to decision.

Average time from disruption alert to plan selection, down from 58s pre-iteration. Users stopped bouncing between impact and plans.

← NO ANSWERS

0/ 5

Questioned automation.

After making completed actions visually trackable, zero users asked whether rebookings really happened. Trust was built through visibility.

← MULTIPLE APPS

5/ 5

Completed full recovery.

All participants navigated from disruption notification through plan selection to execution without opening another app. One product handled what used to take six.

← ONE CANCELLED TRAIN

21 / 22

REFLECTION

Where this is still incomplete.

01

I validated the flow, not the product.

Usability testing covered Prototype A only. Prototype B, the pre-trip stress test that makes the entire framing work, never reached users.

02

The delegation tiers are logic, not evidence.

Users trusted the execution UI. That's not the same as trusting the tier boundaries. Does cancelling a Michelin booking sit in tier 2 or tier 3? I never tested.

03

I designed for one kind of traveler.

Every participant was self-directed and multi-city. Travelers on package tours, with families, or using agents would stress the design differently. The research was narrow on purpose. Next time I'd widen it.

Surfaced through usability testing and post-study reflection.

22 / 22

SAME SCENARIO

Same scenario,

different experience.

Your Shinkansen is cancelled. But you don't open six apps. Detour already analyzed the impact, generated two plans, and started executing. You confirm two tickets and one hotel message. Done.