Vrbo · 10 weeks
Expedia Group
Finding design-system gaps by building Vrbo’s property pages, then turning them into six component proposals.
The design-system challenge
EGDS is one specification that reaches designers and engineers as Figma, a prototype kit and production code. Every arrow pointed away from the spec. Nothing carried what a builder found back up to it.
Real flows find real gaps.
Could building Vrbo’s densest page in EGDS find its gaps, and carry them back to the system as proposals?
Approach
From prototype to system contribution.
- 1
Prototype
Build the Vrbo property-detail flows in the EGDS prototype kit, with existing parts only.
- 2
Surface gaps
Log what the kit couldn’t do, with the screen that exposed it.
- 3
Define patterns
Review each gap and decide which ones are reusable system patterns.
- 4
Contribute
Put the proposals into Figma, the written spec and the prototype kit, with a senior designer.
Prototyping
Build to learn.
- 1
Reconcile the references
Each flow started from the reference designs, checked against EGDS 2 components before anything was built.
- 2
Build with the kit
I built the flows in the EGDS prototype kit using Cursor and Claude, with existing kit parts only.
- 3
Log every gap
Anything the kit couldn’t do went into a shared feedback log, with the screen that exposed it.
- 4
Review it in code
Tyler’s review caught a full-screen sheet being removed before its exit animation finished. The fix keeps it mounted until the exit completes. Photo Tour then merged as PR #47.
Gaps
Every gap, pinned to the screen that exposed it.
Review photos, inline.Filter cut mid-word.No label–value row.Label lost at 20% frost.Not every gap is a missing component.
- Reconcile
Carousel
Already being built elsewhere in the system, so dropped from my list.
- Extend
BottomSheet
The existing sheet, with four changes.
- Coordinate
StickyFilterBar
Existing parts that had to work as one pattern.
- Adapt
Status timeline
An older EGDS 1 stepper, brought forward.
Review asked of each one: an existing capability, work in flight, a variant — or a genuinely missing pattern?
Six proposals for EGDS 2.
- Refined
StickyFilterBar
Keeps filtering in reach.
- Refined
Toolbar
Keeps the listing’s name.
- Refined
StepIndicator
Shows where you are on the refund clock.
- Designed
ListItem
One expands, one navigates.
- Designed
DataRow
Gives a value somewhere to live.
- Designed
OverlayFilterPill
Stays legible over the map.
- 1
StickyFilterBar Refined
EGDS had Tabs, PopoverSheet and ActionList, but nothing that did all three together. StickyFilterBar pins beneath the Toolbar, scrolls when the row overflows, and anchors its menu to the pill that opened it.
- 2
Toolbar Refined
Scrolling the hero away took the property name with it. A new prop on the existing Toolbar carries the title and back control into a compact header, instead of adding a second header.
- 3
StepIndicator Refined
A filled dot read as selected, so the refund schedule looked like a date picker. The EGDS 1 stepper, brought forward, labels each window Ended, Now or Upcoming.
- 4
ListItem Designed
The library only had a row that expands in place. Rows like Manage booking go somewhere else, and the affordance should say which of the two a row does.
- 5
DataRow Designed
Rooms, beds, house rules and price lines are label–value pairs. A variant on ActionList reuses its icon, label, trailing slot and divider instead of adding a new primitive.
- 6
OverlayFilterPill Designed
Faith flagged the map filters: at 20% frost the label sat on roads and water. A solid surface is predictable; a denser frost keeps more of the map. Which one stayed open.
Try the states
Every state was exported, not described.
StickyFilterBar
StepIndicator
First window
The page was the audit.
Delivered.
A 14-flow prototype, Photo Tour merged as PR #47, and six proposals with states, written specs and renders.
Status.
Three refined, three designed, prepared for EGDS 2. Neither acceptance into a production library nor a customer-facing change is documented.
Not yet measured.
No testing with travellers, no production or adoption data, and StickyFilterBar’s keyboard behaviour is still open.
What I took away
- 1
Building was the research.
The gaps that mattered were behaviours — pinned, overflowing, current, upcoming — and none of them show up in a component inventory.
- 2
Review decided more than my drafts.
Amy’s questions are why most of the six extend something EGDS already had, instead of adding to it.
- 3
Test before asking for adoption.
Next, the two refined components go in front of travellers and keyboard and screen-reader users. The refund wording and the filter menu are the likeliest to fail.
After the summer