Vail
A concept study: five bookings, one trip ā planning a mountain vacation without the spreadsheet
Role: UI/UX Designer ā self-initiated concept study
Subject: Vail Mountain Resort ā trip planning across lodging, lift tickets, lessons, equipment rental, and ground transportation
Timeline: 2 months
Platforms: Native mobile (iOS), designed as a companion to the desktop booking experience
Scope: Icon system, paper flow sketches, screen design, 10-screen booking flow, high-fidelity interactive prototype
What it demonstrates: Pattern thinking under multiplicity ā one booking pattern designed once and reused across five services, unified in a single trip itinerary; the concept-scale version of component reuse
The Challenge
Planning a ski trip is five bookings pretending to be one decision: somewhere to stay, lift tickets, lessons, equipment, and a way up the mountain. On the desktop sites of the era, each was its own silo with its own checkout ā the actual trip existed only in the planner's head (or spreadsheet). My brief to myself: design the trip, not the transactions. Make five bookings feel like assembling one plan, so the planning became part of the anticipation instead of the tax on it.
The design question underneath: could one interaction pattern be strong enough to carry five different inventory types ā rooms, tickets, lessons, gear, shuttles ā without five different UIs?
"Nobody plans 'a lodging reservation plus four other checkouts.' They plan a trip. The interface should agree with them."
App Icon Design
Even though Vail Mountain Resort already had an established and recognizable brand logo, I decided to proceed through my routine of sketching icons, and then mock up digital graphic versions of those sketches to arrive at the final app icon. I always like to give myself, as well as the client, options and variations.
Initial App Sketches
The initial sketches helped define the user flow, uncover potential usability challenges, and explore solutions before moving into higher-fidelity design. They provided clarity around the original concept and helped bridge the gap between early ideas and a more structured product experience. This stage was essential for validating the direction and establishing a strong foundation for the final design.
Architecture Decisions
One booking pattern, five services. The core of the study is a single repeatable flow ā browse ā sort ā detail ā check availability ā summary ā add to trip ā designed once and applied to every service. Sorting adapts to what matters per category (price, rating, distance to lift), but the pattern's shape never changes: learn it booking lodging, and lessons, gear, and transport are already familiar. This is the concept-scale version of the instinct that later became my systems work ā design the pattern, not the instances.
"My Trip" as the product. Every booking lands in a single itinerary with a running total ā lodging $1,047, lift tickets $2,068, lessons, rentals ā so the user always sees the trip as a whole, cost included. The aggregate view is what converts five checkouts into one plan, and it's the screen the whole concept exists to justify.
Let the mountain sell itself. The visual layer stays out of the way of the photography ā full-bleed imagery for emotional freight, cool-blue UI chrome for the transactional layer, one primary action per screen. The home menu is the trip's table of contents: five services, five photographic doors.
Icon: options before the obvious. Vail's flag mark was the safe answer; I still sketched alternatives (snowflake, skier, peaks) before earning the brand-mark conclusion.
Sketch straight to high fidelity. With the flow resolved on paper, I skipped lo-fi wireframes and built the prototype at full fidelity (Proto.io) ā the right economics for a solo study where the risky question (does the repeated pattern feel coherent?) only answers in the tappable version.
User Flow - Lodging
Why Concepts?
Between client and system work, self-initiated studies are where I practice specific muscles without production constraints ā here, pattern reuse across heterogeneous services. Real subject, self-imposed constraints, finished prototype.
What The Study Produced
A complete, prototyped trip-planning experience ā 10 screens covering the full booking arc from launch to aggregated itinerary.
A worked example of one pattern absorbing five service types without breaking ā the study's transferable finding.
What Iād Do Now
Check the pattern against the real constraint. Five services means five inventory systems; the "one pattern" elegance lives or dies on whether availability, pricing, and cancellation rules can actually normalize. Today I'd pressure-test the pattern against those backend realities first ā the design lesson enterprise work taught me later.
Design the trip as a shared object. Ski trips are group decisions; I'd make My Trip collaborative ā shareable, voteable, split-payable ā because the single-planner model was the concept's quietest false assumption.
Plan for the trip's whole lifecycle. The study ends at booking; the product opportunity is the trip itself ā day-of lift status, lesson reminders, gear pickup ā where the app earns its home-screen spot for the other 51 weeks.
Tokenize the pattern. The five-service reuse was held together by eye; I'd now spec it as components with defined variant slots per service type ā making the study's core idea explicit instead of implicit.