IHG — One room card, four rate types, four viewports
The choose-room-and-rate step of IHG's booking flow — one room card, four rate types as states of a single component, designed across four viewports.
Viewports designed as first-class layouts — 1440, 1180, 768 and 375 — with one room card and one rate component across all of them.
[ The problem ]
Choosing a room is where a hotel booking either closes or stalls. The guest has to compare rooms, then compare rates within a room — public, member, preferred, points — and every one of those carries its own conditions. The existing step put that comparison in a dense list where the rate a guest qualified for was rarely the one they saw first, and where the same information was laid out differently at each screen size.
[ Goals ]
Approach
The room card carries the decision. Every card holds one photograph, the occupancy and bed facts a guest actually filters on, the cancellation terms, and one rate — with a View Prices control that opens the rest rather than stacking them all on the page. Rates are the hard part. A single room can carry a public rate, a member rate, a preferred rate through AAA or a corporate agreement, and a points option. The design treats them as one component with states rather than four layouts: the same card, the same price position, with the qualifying rate shown against the public rate it beats. A non-member sees what membership would save; a member sees the saving already applied. Four viewports were designed as first-class layouts, not as a desktop that squeezes. At 1440 the filters sit in a toolbar above a wide list; at 1180 and 768 the toolbar collapses to a filter row with a More Filters sheet; at 375 each room becomes a full-width card with the rate pinned where a thumb reaches it. The empty state was designed with the same care as the full one: filters stay visible and set, so a guest can widen a filter instead of starting the search again.
[ Scope and constraints ]
[ The work ]
The surfaces.
The room card
Give a guest one place to judge a room — what it is, who it sleeps, what it costs and whether they can cancel.
One photograph with a carousel, occupancy and bed type as icons, free breakfast and cancellation as plain text, and a single rate with View Prices to open the rest. Scarcity ("Only 2 remaining") sits with the room, not the price.
One card, reused at every viewport and behind every rate type.
Member value, shown not claimed
Make the difference between a public rate and a member rate legible at the moment of choosing, without turning the page into an advert.
Non-member on the left, member on the right. The qualifying rate takes the price position and the public rate sits struck through above it, so the saving is arithmetic a guest can see rather than a claim they have to trust.
The same component serves both audiences — the rate a guest qualifies for is the one they see first.
Preferred and negotiated rates
Handle the rates a guest brings with them — AAA, corporate, association — without a separate layout for each.
The preferred rate takes the price position with the public rate struck through above it, and the qualifying programme is named under the room so a guest knows which of their memberships is doing the work.
A fourth rate type landed as a state of the existing component rather than a new page.
When nothing matches
Keep a guest in the search when their filters return nothing.
The filter toolbar stays in place with the selections intact, and the message sits in the results area rather than replacing the page — so widening one filter is a single click away.
The empty state is a step in the search, not a dead end.
Four viewports, one system
Design 1180 and 768 as real layouts rather than as a desktop that squeezes.
At 1180 the filter toolbar keeps its row and the room card holds its horizontal layout. At 768 the toolbar collapses to primary filters with a More Filters sheet, and the card narrows without stacking. The rate component is identical at both.
Each viewport was specified from the same file, so the room card and rate rows never had to be re-solved in development.
Mobile
Carry the whole comparison to 375px without losing the rate detail that makes it a decision.
Each room becomes a full-width card with the photograph, the facts and the rate stacked in reading order. Rate options open in place, and the member discount toggle sits at the top of the list where it applies to everything below it.
The same decision, one thumb-width wide.
[ The system underneath ]
[ Results ]
4 | Viewports designed as first-class layouts 4 | Rate types as states of one component 1 | Room card used at every screen size
The rate system shipped as one component with states rather than a layout per rate type, which is what let member, preferred and points rates land without a redesign each time. The work went to development across all four viewports from the same file, with the room card, the rate rows and the filter toolbar specified once and reused.
What I carry forward
Designing the rate types as states of one component rather than as separate layouts was the decision that held. Every new rate type after that was a state, not a redesign.