Search & Filtering System for Complex Travel Booking

INTRODUCTION

The Problem Wasn't the Controls

A travel manager in Munich types "London Monday morning refundable" into the search bar and hits enter. She gets 47 results. She starts filtering: price range, departure window, number of stops. Each control works. Each result updates. But ten minutes later she's still scrolling, still adjusting, still unsure whether the flight she's looking at is the best option or just the one she happened to land on. The interface gave her capability. What it didn't give her was a path to a decision.

That was the real problem. On a B2B travel platform managing flights, hotels, rail, and car rentals across multiple booking verticals, search, filters, and results had been designed as three separate features — built at different times, by different teams, with different assumptions about user intent. But users experienced them as a single decision flow: start with intent, narrow the options, compare trade-offs, choose. The interface did not reflect that experience.

CONTEXT

A Platform That Outgrew Its Patterns

BizAway is a B2B travel management platform used by companies across Europe to book and manage business travel. When I joined, the product had scaled quickly — flights, car rentals, hotels, trains — but each vertical had developed its own approach to search, filtering, and results presentation. There was no shared vocabulary for how a user should move from intent to decision.

Users needed to explore many options quickly, understand pricing constraints, see company policy restrictions, and compare travel combinations — often across verticals in a single booking session. The fragmentation was not just a visual problem. It was a cognitive one. Every time a user moved between verticals, they had to relearn how to find what they needed.

THE DECISION PROBLEM

Capability Without Clarity

Consider a user who wants to find a reasonably priced flight arriving before noon. A typical filter panel for this task might expose simultaneously: price range, outbound departure time, return departure time, number of stops, airline, layover duration, baggage allowance, refundability, and booking class.

“The interface had more capability than it had clarity — and capability without clarity is just a different kind of friction.”

The problem was not that the controls were broken. The problem was that they had been designed as isolated data-exposure mechanisms rather than as parts of a decision flow. There was no progressive structure to the exploration. No prioritisation of what mattered first. No feedback loop between what the user had done and what remained possible. Filtering was a feature. It needed to become a system.

SEARCH AS THE ENTRY POINT

Starting With Intent, Not Parameters

In most travel interfaces, the search bar and the filter panel are visually and functionally separate. The user types a destination, hits search, and then switches cognitive modes to operate a completely different set of controls. The redesign treats search as the opening act of the same decision flow that filters continue.

The prototype explores a natural-language search input that parses user intent into structured parameters. A query like “business class London Monday refundable” becomes visible, editable filter chips — making the system's interpretation transparent and correctable. The user stays in one mental model throughout: expressing intent, seeing interpretation, refining constraints, evaluating options.

FACETED FILTERING

Multiple Constraints, Considered Together

Faceted filtering — the ability to narrow results along multiple independent dimensions simultaneously — is well-established in e-commerce but underused in complex enterprise products. The challenge is not implementing it. The challenge is deciding which facets matter, in what order, and how they interact.

For travel booking, the most decision-relevant facets are price, departure time, number of stops, airline, and class. But there is a second layer that enterprise travel adds: policy compliance. A flight might be the cheapest option and still be wrong if it exceeds the company's travel policy. The faceted model here layers business constraints alongside personal preference — treating policy not as a blocker that appears at checkout but as a visible dimension of every result.

VISIBLE FILTER STATE

Always Knowing Where You Are

One of the most common failures in filtering interfaces is invisible state. The user applies three filters, sees 12 results, and cannot quickly answer: which filters are active? How many results existed before? What happens if I remove one? This uncertainty makes exploration feel risky rather than fluid.

The redesign makes filter state continuously visible through several mechanisms: active filters change visual state immediately, a persistent result count updates in real time, preset filter combinations (Direct, Within Policy, Cheapest, Business) provide common starting points, and individual filter values can be cleared independently or all at once. The goal is to make the user feel safe experimenting — because the cost of reversing any decision is visibly low.

PROGRESSIVE REFINEMENT

From Broad to Specific, Not All at Once

Progressive filtering means that users begin with a broad view and narrow gradually, rather than being asked to specify all criteria upfront. This aligns with how people actually make travel decisions: they start with a rough sense of what they need and refine as they see what is available.

The prototype supports this through layered entry points. The AI search input accepts vague intent. Preset filter buttons offer common constraint packages with a single click. Individual faceted filters allow granular control. And the compare function lets users hold two or three options side by side once they have narrowed sufficiently. Each layer is available, but none is required — the user decides how deep to go based on the complexity of their decision.

REVERSIBLE EXPLORATION

Making It Safe to Experiment

A well-designed filtering system should feel like a conversation, not a commitment. Every constraint the user applies should be easy to see, easy to modify, and easy to undo. This is what Vitaly Friedman describes as reversible exploration — the principle that users engage more confidently with complex systems when they know they can always step back.

In the prototype, this manifests as instant feedback on every interaction. Toggling a filter immediately updates the result count and the visible results. Clearing all filters resets to the full set. The compare function allows adding and removing flights without losing the broader search context. There is no dead-end state where the user has to start over. The system remembers where they were and makes it easy to adjust course.

WHAT THE PROTOTYPE DEMONSTRATES

Patterns in Practice

Search and filtering as one flow. The AI search input, filter strip, preset buttons, and sort controls are not separate features — they are different entry points into the same narrowing operation. The user can start with any of them and the system responds coherently.

Policy as a visible dimension. Travel policy compliance appears on every result card — green for within policy, amber for near limit. This turns an institutional constraint into a scannable attribute, not a surprise rejection at checkout.

Structured comparison. The compare function generates an AI-assisted side-by-side analysis with pros, cons, and a recommendation. This supports the final stage of the decision: not just finding options, but choosing between them with confidence.

Progressive booking. Selecting a flight opens a booking panel with pre-filled traveller details, a seat map with preference memory, and a price breakdown — reducing the transition from decision to action.

REFLECTION

What I Would Do Next

The system thinking behind this work — progressive disclosure, faceted filtering, visible state, reversible exploration — still holds. The patterns are sound. But the input model still assumes users know which parameters matter. The search input accepts natural language, but the underlying model is still translating intent into the system's vocabulary rather than the user's.

If I were extending this today, I would invest in two areas. First, adaptive defaults: learning from booking patterns to pre-populate search with likely parameters, so the system starts closer to the answer for repeat travellers. Second, constraint negotiation: when no results match all criteria, rather than showing an empty state, surfacing which constraint could be relaxed to unlock the most options — and letting the user make that trade-off explicitly.

The goal is not a smarter search bar. It is a system that understands the shape of the decision and meets the user where they are within it — whether that is a vague intent, a specific requirement, or a comparison between two close options. That is the gap between a good filtering interface and a genuine decision-support system.