DCL Booking Experience

The Problem

The live Disney Cruise Line booking flow asks people to choose from 467 cruises with no clear hierarchy, so the journey starts in decision paralysis. There's no way to compare sailings side-by-side, itinerary details are buried at the exact moment people need them, and active filters disappear from view, so users lose their search context halfway through. Walking the flow end-to-end surfaced 22 friction points, each rated for severity.

‍

The Solution

Decisions before pixels. I clustered the friction into five journey beats (discover, compare, decide, personalize, checkout) and wireframed the five highest-impact screens in greyscale before touching color. Then, instead of inventing a new look, I read the brand that already existed: I audited the live site for color, type, spacing, and imagery, and used AI to extract those into reusable components and tokens. That let me organize and build out the full system and screens far faster than a manual rebuild. The result is five redesigned screens running on one shared library.

‍

‍

The Product

The DCL Booking System is a complete, reusable design system plus five high-fidelity screens, all built from the live Disney Cruise Line brand. It turns a sprawling catalogue into a guided path toward one confident booking decision.

Underneath the screens sit 75 token primitives and 58 semantic aliases, so every fill, stroke, and radius points to a named variable with zero hardcoded values. Comparison, which the live site never offered, becomes a first-class moment through a new Comparison Modal. The same tokens and the same components power both desktop and mobile, so there's no second design system to maintain.

‍

Key Features

• Decision-First Information Architecture: Five journey beats with one decision per screen, so people always know what to do next.
• A Design System Read From a Live Site: 75 primitives and 58 semantic aliases extracted from the real brand, not invented in a vacuum.
• First-Class Comparison: A new Comparison Modal puts three sailings side-by-side, the exact moment the original flow was missing.
• Itinerary as a Decision Tool: A map-led layout with contextual day cards and a sticky booking action, instead of a static brochure.
• One Library, Desktop & Mobile: The same component instances reflow to 375px with no parallel design system.
• Themeable in One Variable: A Halloween theme is pre-wired, so a full seasonal reskin is a single variable swap.
• Built for Engineer Handoff: Every component ships with annotated token specs that compile to CSS variables, Tailwind config, and typed component usage.
• AI-Accelerated System Build: Used AI to extract components from the live brand and quickly organize, assemble, and build out the screens, replacing a slow manual rebuild with a fast, repeatable workflow.

‍

Designing for better decisions

Live DCL site

• 467 cruises, no filter hierarchy — decision paralysis from the start
• No way to compare options side by side
• Itinerary details buried; key info missing at the decision point
• Active filters invisible; users lose search context mid-browse

Redesigned system

• 467 results made scannable with filter chips
• Persistent comparison tray across screens
• Itinerary surfaced at listing level
• Active filters always in context

primitives

75

semantic aliases

58

components

11

screens, desktop & mobile

5

Wireframes — decisions before pixels

01Friction log

Catalogue the pain

Walked the live booking flow end to end. 22 friction points, severity-rated low to high.

• 22 friction points logged
• Low-to-high severity rating
• Linked to evidence screenshots

02IA

Cluster, then route

Grouped friction into journey beats — discover, compare, decide, personalise, checkout. Each beat asks one question.

• 5 journey beats from 17 frictions
• One decision per screen
• Comparison promoted to a first-class moment
• Itinerary reframed as a decision tool

03Low-fi

Sketch the answer

Wireframed the five high-impact screens in greyscale only, locking the IA before any colour.

• Listing with persistent filters
• Compare drawer and 3-up modal
• Itinerary as a decision tool

Foundations — read what's there before you redraw it

01Audit

Listen, don't draw

Scraped the live DCL site for colour, type, spacing and imagery. The brand has a voice; start as a listener, not a redrawer.

• Colour palette extraction
• Display and body type sampling
• Spacing and grid audit
• Imagery library logged

02Tokens

75 primitives

Turned observations into a token graph: colour ramps, spacing scales, type ramp, radii. All primitives, all named.

• Colour ramps (navy / cyan / neutral / Halloween)
• Spacing scale 4 → 96
• Type ramp 12 → 32
• Radii, strokes and feedback states

03Aliases

One swap, every screen

Layered 58 semantic aliases on top — color/action/primary, color/text/price-best, color/feedback/*. A brand swap becomes one variable.

• 58 semantic aliases on top of 75 primitives
• color/text/price-best introduced as a first-class concept
• Halloween theme pre-wired (a one-variable swap)

Components — 11 components, zero hardcoded values

01Atoms

Smallest reusable units

Single-purpose atoms. Every fill, stroke and radius bound to a semantic alias. Zero hardcoded hex.

• Button · Input · FilterChip
• Stepper · Switch · Checkbox
• StatusPill · Tag · Badge
• Divider · Icon · Image

02Modules

Compose, don't redraw

Modules made from atoms. CruiseCard exposes its image as INSTANCE_SWAP, with 17 real DCL photos wired in.

• TopNav · SearchBar
• CruiseCard (INSTANCE_SWAP, 17 images)
• DateCard · ItineraryDayCard
• StateroomPicker · PromoBanner · Modal

03Patterns

Page-level scaffolds

Patterns that consume modules. ComparisonModal is a new pattern, introduced because comparison was a missing first-class moment.

• HeroSearch · ListingResults
• CruiseDetail · TravelParty
• ComparisonDrawer and ComparisonModal (new)

04Hand Off

Engineers can build this without asking a designer

Every component ships with annotated token specs. Tokens compile to CSS custom properties, Tailwind config and typed component usage — zero ambiguity at handoff.

• Annotated specs: BG · BORDER · RADIUS · PAD · GAP
• CSS: --color-action-primary, --radius-card…
• Tailwind: extend.colors.action, borderRadius.card
• Typed usage: Button variant=“primary”, Card padding=“lg”

Screens — five screens, one library

01Listing

Find a cruise, fast

Persistent active-filter chips, no hidden metadata. Pinnable cards feed the comparison drawer.

• Active-filter chip rail, every chip removable
• Pin-to-compare on every card
• Best-value badge using color/text/price-best
• Sticky filter sidebar

02Compare

Decide between three

The ComparisonModal pattern: three sailings side by side. It exists because comparison was a missing first-class moment on the live site.

• Three-up side-by-side comparison
• Sticky decision rail
• Mobile stacked layout with a tab-pill switcher
• Pinned cards survive across pages

03Itinerary

A decision tool, not a brochure

Map at roughly 60% of the viewport. Day cards redesigned for context. A sticky CTA rail keeps booking one tap away.

• Map-led layout (roughly 60% of the viewport)
• Contextual day cards
• Sticky CTA rail
• Travel-party screen documented on the same library

04Mobile

Same library, 375px

Mobile listing and comparison reflow using the same tokens and the same components. No parallel design system.

• 375px viewport
• Stacked compare with a tab-pill switcher
• The same component instances as desktop

Explore the live Figma file.