PRINCESS CRUISES
Interactive Deck Plans
Improving usability, refreshing visual design, and defining a scalable production process
Overview: Our interactive deck plans were the first of their kind in the cruise industry. However years had passed, and it showed. I led the end-to-end redesign, rethinking the user experience from the ground up, refreshing the visual design, and building both the design system and the production process that brought it to life across an entire fleet.
The result shipped, worked, and has remained in production for several years.
The Situation
The original deck plans had accumulated significant technical and usability debt. By the time this project began, they suffered from a dense, hard-to-read interface, small text, and a clunky interaction model built on outdated technology that didn't function on mobile. They could display ship information — but couldn't do anything more. Guests had no way to visually browse or choose a stateroom during the booking process.
There was a clear opportunity to rebuild the experience to perform both functions. Informational deck plans for ship overviews, and a guided, visual stateroom selection tool embedded in the booking flow. The latter would be another industry first.
TEAM: IT Project Manager · Senior Programmer/Analyst · Manager of Web UX & Design · Web UX/UI Designer (me) · Marketing Specialist · 1 internal and 2 contract Production Artists
My Responsibilities: Product design, information architecture, interaction design, prototyping, competitive analysis, asset production workflow design, production artist management, and quality assurance
Research & Discovery
We started with whiteboard sessions to map business requirements against user needs, then I ran a competitive analysis — looking not just at other cruise lines, but at adjacent industries with similar spatial navigation challenges: airline seat maps, concert venue seating charts, and hotel floor plans. Several constraints shaped everything that followed:
Two distinct use cases with different needs. Informational deck plans needed to show full decks with color-coded stateroom categories. The booking flow required a more focused experience. Guests would be guided to a section of the ship and a group of decks matching their selected category and price point. These weren't just different screens; they required fundamentally different asset sets.
Marketing copy at every decision point. The marketing team had copy requirements that needed to fit within a constrained interface requiring careful hierarchy and layout decisions throughout.
A complex pricing model. The booking integration had to reflect a fare pricing scheme developed by Yield Management, dividing each deck into five sub-sections. Every design decision had to accommodate this structure without exposing its complexity to guests.
The existing assets weren't usable. The marketing team had EPS files of the deck plans, but these were built for printed brochures. They were not drawn in a usable state for our needs, wrong structure, wrong intent. The public areas could be adapted, but every stateroom would need to be redrawn from scratch. This was not a minor task.
A technical constraint that defined the asset format. The application required live text for room numbers, and each stateroom needed to be individually selectable as a vector element. The solution: staterooms and their corresponding numbers would be output as structured SVGs overlaying a static PNG of the surrounding visual elements. This determined how every asset had to be built.
Design
With the functional requirements defined, I created wireframes and refined them into finished designs covering both the informational experience and the booking flow. The two experiences shared a visual language but served different purposes:
Informational view: Complete deck layouts with color-coded categories, designed for browsing and orientation
Booking view: A focused, guided experience that surfaced only the relevant section of the ship, helping guests understand location relative to their fare tier without overwhelming them with the full ship
Getting the information hierarchy right in the booking flow was the central design challenge. Guests needed enough context to make a confident location decision, while the interface had to accommodate the pricing structure, marketing copy, availability states, and accessibility requirements. All within a constrained viewport that had to work on mobile.
Production
Once the design was validated, I developed the asset production protocol and led a team of production artists over three months to execute it across the fleet. The scope was 17 ships. Roughly 22,000 individual staterooms, each redrawn as a structured vector element with a very strict layer order and naming convention.
A problem that could have derailed everything
Midway through production, SVG files exported from Illustrator began generating errors in the application. I traced the issue to corrupted layer IDs, the attributes the application relied on to identify path and text layers for each stateroom. Extraneous characters were being introduced during export, and while the specific characters varied, their positions within the code were consistent.
Rather than manually correcting files, I wrote a set of regular expression patterns and used BBEdit's grep find-and-replace to systematically clean the output. The fix was fast, precise, and became a standard step in the production pipeline applied to every file going forward.
This kind of problem, quietly breaking output in a highly repetitive production process, is exactly where having a designer who can read code pays off.
Results
Without access to the formal success metrics, the outcome is best understood through what the project actually delivered:
Two industry firsts: Interactive deck plans were already novel when originally launched; embedding visual stateroom selection into a live booking flow had never been done in cruising
Fleet-wide execution: 17 ships, ~22,000 staterooms, a consistent and scalable asset system
A process that outlasted the project: The production protocol and SVG pipeline I designed were replicable and could be applied to future ships
Sustained production use: The tool has been in active use for several years — the clearest signal that it worked
Learnings
This project reinforced that design leadership at scale requires building systems, not just producing deliverables. The early investment in defining a strict asset protocol paid off throughout production where every hour spent establishing the right structure saved multiples in rework downstream.
The SVG debugging episode was a reminder that constraints in production pipelines tend to surface late, when they're most disruptive. Having a designer who can think beyond the canvass can become an invaluable asset.
More broadly, some of the most valuable design work on this project was invisible in the final product. The fare-section structure, the asset division logic, the production naming conventions aren't seen on screen. But without it, none of the rest would have shipped.
