Disney Parks Ticket Store Redesign
If you think tickets with a tiered pricing structure is an easy concept,
wait until Disney added flexible usage benefits.
About the Project
This is a cross-platform redesign for web, mobile web and app for both Disneyland and Disney World.
The ticket configuration screen (ticket store) is the most visited experience across all platforms, throughout the entire project, we kept pushing ourselves to redesign a ticket store that:
Is easy to use
Suites users with different level of familarity with park products
Explains the new seasonal ticket features and benefits
Facilitates users to choose the right ticket
Communicates the seasonality to help better manage the crowd
Successfully upsell/crosssell products to satisfy business needs
I was 1 of the 4 interaction designers on this project. My contribution included concept exploration and iteration, prototype development and motion defining.
Which concept best fits guests' mental model?
Seasonal priced ticket concept is quite unique in that there weren't any existing similar product for us to iterate design patterns from.
After rounds of workshops, we came up with these 3 distinctive concepts with 2 assumed users' mental models to test with
Mental Model 1: "I want to see what my tickets would cost on Dec 25":
With Concept 1 & Concept 2
Mental Model 2: "I want to purchase tickets that allow me to use on a range of dates"
With Concept 3
Concept 1 - Date Selection First:
Concept 3 - Flexibility Toggle:
Concept 2 - Duration Selection First:
Concept 4 - Date Driven with Today Button:
After the 1st round of test at Disney World, we found out:
Most of the guests are date driven
Savings are secondary compared to their schedule
Thus a 4th concept was added based on the findings as shown above.
Collaborative Prototyping, with Dynamic controls
The concepts shown above are Axure prototypes we built. It was an interesting challenge to collaborate with the 2 other designers in a different office location. We managed to do it by creating dynamic reusable components and then each take on one of the 3 concepts to work on separately.
While working on it, we kept an iterative mindset, utilizing global/local variables, conditions and customized action panels to create more dynamic prototypes so that later on it could be modified on the fly during the 3-day test sessions based on the feedbacks and design iterations.
Solving the valid usage dates problem
The 4th concept tested well. The only drawback was that almost every participant kept hang up on is understanding the valid usage dates concept:
We did a lot of iterations during the testing week but none of them felt right. The added layer of usage info is overwhelming regardless. Here's one example:
By the end of the two test sessions we eventually found out that valid dates info is secondary to the users. We thus detached it from the calendar interface and put it inside a slide up info layer through "About 1-Day tickets". We also mentioned it later in the flow on the confirmation screen as well.
Bite-size content, progressively revealing them as needed
After settling down on the app design, we moved on to see what the web and mobile web experience would be like.
The original web ticket config page is a static page with steps marked on the left:
But because there're added complexity for the 1-day seasonal tickets, this page structure doesn't work anymore. Inpired by Virgin America flight searching page, we designed this interaction model called progressive revealing.
Each section of input defines what to show next, and we only show it when it's needed:
Want to hear the full story? Shoot me An Email: 📤
Hero Image Credit: Brett Kiger Attribution-NonCommercial-NoDerivs 2.0 Generic (CC BY-NC-ND 2.0)