IHG — The system behind the booking flow
The shared design system behind IHG's booking flow — the booking component, type scale, button hierarchy, form states and alerts that every step is built from.
One booking component, specified in three configurations, used at every step of the flow and on the brand sites that feed it.
[ The problem ]
A booking flow is not one page. It is a search, a room and rate comparison, a payment form and a confirmation — each with its own team, its own release and its own edge cases. Without a shared system, every step re-invents the same controls and the guest feels the seams. The flow also had to hold together across four viewports and across brands, so the system had to be specific enough to build from and loose enough to carry a brand.
[ Goals ]
Approach
The booking component came first, because it is the one element that appears on every page of the flow and on the brand sites that feed it. It was drawn once and specified in three configurations — the full search bar, the compact bar, and the stacked panel — so a team could pick a configuration rather than redraw the control. Type is documented as a scale with the weight, size and leading written next to each step: H1 Graphik 400 and 500 at 62/115%, H2 at 30/115%, H3 at 24/115%, numbers at 40/115%. A developer reading the file does not have to measure a screenshot. Buttons are documented as a hierarchy — primary, secondary, tertiary, collapsed, expanded and a basic link — with a note on which to use where, so the decision is made in the system rather than per page. Form fields carry every state a booking form actually hits: label, filled, helper text, error with message, and dropdowns collapsed, with helper text and expanded. Alerts are specified with their padding and the spacing between stacked messages, at each viewport.
[ Scope and constraints ]
[ The work ]
The surfaces.
The booking component
Draw the one control that appears on every page of the flow — and on the brand sites that feed it — once.
Three configurations from one component: the full search bar with destination, dates, guests and rooms; a compact bar for pages where search is secondary; and a stacked panel for narrow columns. Each is specified with its own field widths and the same search action.
Teams pick a configuration instead of redrawing the control.
A type scale you can build from
Remove the guesswork between a design file and the built page.
Every step carries its weight, size and leading in the label: H1 Graphik 400 and 500 at 62/115%, H2 at 30/115%, H3 at 24/115%, numbers at 40/115%. Each is shown set as a second line so the leading is visible rather than described.
No measuring screenshots — the specification is on the page beside the specimen.
Buttons as a hierarchy
Make the choice of control a system decision rather than a per-page one.
Primary, secondary and tertiary CTAs, collapsed and expanded controls, and a basic link — each with a note on where it belongs. Pagination and stepper controls are specified in the same sheet so counts and arrows match the buttons around them.
One primary action per page, and a documented answer for everything below it.
Every state a form actually hits
Specify the states a booking form reaches in practice, not just the empty one.
Label, filled, and field-with-helper-text; the error state with its message in place; dropdowns collapsed, collapsed with helper text, and expanded. Each state is drawn rather than described, so there is nothing to interpret at build time.
Error handling arrived with the component instead of being retrofitted.
Alerts, with their spacing
Make system messages consistent across four viewports, including when several stack.
Each alert is specified with its padding per viewport — 28px at the large viewport, 24px at medium, 16px at small — and with the gap between stacked messages called out, because a booking form can surface several validation errors at once.
Messages that look deliberate at every width, including the awkward case of several at once.
[ The system underneath ]
[ Results ]
3 | Configurations of one booking component 4 | Viewports the system covers 1 | Shared system across every step of the flow
The system is the reason the payment page, the room and rate step and the brand sites read as one product rather than three teams' work. Because the states are documented rather than implied, error handling and helper text arrived with the components instead of being added later.
What I carry forward
Specifying the booking component in three configurations rather than one was the decision that made the system usable. Teams stopped redrawing the control and started picking one.