Detour
Project overview
Travel planning tools help you decide where to go. Booking platforms help you buy tickets. But no product manages the relationships between your bookings. The time dependencies, priorities, and flexibility that determine whether your trip adjusts gracefully or falls apart when something changes. I designed Detour as an AI itinerary orchestration layer. It understands the connections between every reservation in your trip. Before departure, it stress-tests your schedule for timing conflicts. On the road, it handles daily adjustments like weather changes. And when a major disruption hits, it maps the full cascade of downstream impact and generates a recovery plan that protects what matters most to you.
Three Levels of Agent Autonomy
When an AI manages your trip, how much should it do on its own? I designed three tiers. Silent, where it auto-rebooks a delayed train to the next one. Approval, where it suggests a restaurant swap and waits for your OK. And suggestion-only, where it flags a risky connection but lets you decide. The line between them isn't technical. It's about consequence. If a change costs money or affects something you care about, the system asks first. If it's logistically obvious, it just happens. I spent a lot of time getting this boundary right because that's what makes the system feel helpful instead of controlling.
Showing Cascading Impact, Not Just Notifications
Most travel apps tell you "your flight is cancelled." That's not useful. I designed the disruption screen to show the full downstream chain. This flight affects this hotel check-in, which affects this dinner reservation, which affects tomorrow's morning tour. Each node shows the severity and your options. The hard part was information density. You're stressed, you're at the airport, you need to understand the situation in under ten seconds. I used progressive disclosure so the top-level view is three to five cards, and you drill in only if you want details.
Building Trust Before Anything Breaks
The recovery engine needs to know what matters to you. I first tried a settings page where you rank categories. Nobody used it. So I embedded priority signals into the booking process itself. When you add a reservation, you tag it: flexible, important, or can't miss. That tiny interaction costs nothing in the moment but gives the system everything it needs later. Don't make people think about priorities in the abstract. Capture them in context.
Priorities as a Design Input, Not a Settings Page
The recovery engine needs to know what matters to you. I first tried a settings page where you rank categories. Nobody used it. So I embedded priority signals into the booking process itself. When you add a reservation, you tag it: flexible, important, or can't miss. That tiny interaction costs nothing in the moment but gives the system everything it needs later. Don't make people think about priorities in the abstract. Capture them in context.