Concept · 05Modular tiles

Card stack by room type

A modular, slightly softer take on the rate list. Each rate reads as a self-contained 'offer' inside its room-type container, rather than a row in a list.

Hotel PDPRooms & Ratesimplied context · 764 px
Card stack · per room type
Selected: Flexible · Bed & Breakfast
$251/night
Selected: Flex · Bed & Breakfast
$224/night
State breakdown · 2 states
State 01 / 02Nothing selected
Card stack · per room type
Selected: Flexible · Bed & Breakfast
$251/night
Selected: Flex · Bed & Breakfast
$224/night
State 02 / 02Rate selected · footer active
Card stack · per room type
Selected: Flexible · Bed & Breakfast
$251/night
Selected: Flex · Bed & Breakfast
$224/night
Design review · breakdown
What this is
Each room type is a soft outer card. Inside, each rate is a smaller bordered tile with attributes and Reserve. Spacing keeps each rate visually self-contained.
Why it works
Friendlier, more modular feel than a table. Each rate reads as a discrete 'offer' rather than a row in a list, which reduces the spreadsheet fatigue of dense inventory.
Best use case
Customer-facing or hybrid B2B/B2C contexts where a slightly softer, less spreadsheet-like interface is preferred.
Tradeoffs / risks
Less efficient at attribute comparison than the table layout. More chrome per rate increases vertical footprint. Card boundaries can compete with the room-type grouping for visual hierarchy.
UX notes · scannability · normalization · booking confidence · provider transparency
Normalization shown via the room-type wrapper. Rate-plan label carried per-tile. Booking confidence reinforced by the room-level selected-rate footer with live price.
Hand off · Claude Code prompt

Paste this into Claude Code to regenerate this concept as a standalone interactive wireframe component.

You are building one self-contained, fully interactive wireframe-style React
component that demonstrates a single hotel "Room Normalizer" concept.

# Concept
- Number: 5 of 14
- Section: normalizer
- Name: Card stack by room type
- Tagline: Modular tiles
- One-line summary: Soft outer card per room type; each rate is a discrete bordered tile with attributes and Reserve.

# Framing
A modular, slightly softer take on the rate list. Each rate reads as a self-contained 'offer' inside its room-type container, rather than a row in a list.

# What this is
Each room type is a soft outer card. Inside, each rate is a smaller bordered tile with attributes and Reserve. Spacing keeps each rate visually self-contained.

# Why it works
Friendlier, more modular feel than a table. Each rate reads as a discrete 'offer' rather than a row in a list, which reduces the spreadsheet fatigue of dense inventory.

# Best use case
Customer-facing or hybrid B2B/B2C contexts where a slightly softer, less spreadsheet-like interface is preferred.

# Tradeoffs / risks
Less efficient at attribute comparison than the table layout. More chrome per rate increases vertical footprint. Card boundaries can compete with the room-type grouping for visual hierarchy.

# UX notes (scannability · normalization · booking confidence · provider transparency)
Normalization shown via the room-type wrapper. Rate-plan label carried per-tile. Booking confidence reinforced by the room-level selected-rate footer with live price.

# Visual + interaction requirements
- Wireframe fidelity: monochrome, system UI, no brand color. Use Tailwind
  utility classes only. No images. Use simple borders, muted backgrounds,
  and mono labels for meta text (uppercase, tracking-widest, text-[10px]).
- Canvas width: 764px, centered. Internal content respects that frame.
- Context: this lives inside a hotel PDP "Rooms & Rates" section. Assume
  3 normalized room types (King, Queen, Double Queen) with 5–8 bookable
  rates each. Invent realistic mock data inline — rate label, bed, meals
  (room only / breakfast included), cancellation (free until N / non-refundable),
  payment (pay now / pay at hotel), price per night.
- Fully interactive: every control the concept implies must work in-browser
  with React state only — no backend, no router. Examples: accordions expand,
  tabs filter, sort headers sort, "Show N more" reveals rows, builder toggles
  recompute price live, sticky CTAs update with selection.
- Accessibility: real <button> elements, keyboard focus rings, aria-expanded
  on disclosure controls, aria-pressed on toggles.

# Deliverable
- A single default-exported React component file using TypeScript + Tailwind.
- No external UI library. Inline any small primitives you need.
- Include the mock data inline at the top of the file.
- File should run as-is when dropped into a Vite + React + Tailwind project.

Build only this concept. Do not generate the other 13.