Disney
Disney
Dining Modifications - Allowing guests to modify their dining reservations in the My Disney Experience app.
Background
Part of planning a vacation to Disney World is booking dining reservations at the numerous experiential restaurants in the park. Reservations are hard to come by and must be made up to a year in advance.
The My Disney Experience application allowed guests to book dining reservations within the app, but guests were not able to modify those reservations within the app.
The only way to modify was either to call customer support over the phone, sit on hold for 30 minutes, and hope they could accommodate your request or simply cancel your reservation and hope you could rebook with the desired modifications. Neither experience was good for the user, costing them valuable time and posing unnecessary risk.
Project Goals
Simple: Create a simple way for users to modify their dining reservations within the app that reduced the perceived risk for the user.
Multiple Use Cases: Consider users modifying months out as well as hours before (likely in the parks)
Flexible: Design should be able to be flexible to accommodate Disneyland and Disney World.
New Design Language: Implement the feature in the new design language.
Challenges:
This feature was to roll-out first in the My Disney Experience App. Several months prior to this project, our team launched the new Disneyland App, complete with a brand new design language.
MDX App had been built 6 years prior. The long term goal was to convert MDX into the new design language, piece by piece.
The Dine Mods project was to be the inaugural attempt to shoehorn our new design language and components into an old code base and design pattern.
Discovery Phase
First step, identity our users needs. Since the design needed to accommodate the needs of Disney World and Disneyland, we needed to map out the different user needs at each park. We wanted to understand:
Why would a guest need to modify a dining reservation?
How do the guest’s needs differ between visiting DLR and WDW?
How do guests currently feel about modifying reservations?
Disneyland:
Less pre-visit planning
Predominantly a local crowd vs. tourists
Less restaurants than WDW (144 vs. 872)
Only a few on-site hotels (more day visits)
Disney World
Much more pre-trip planning (some travel agents)
Longer trips overall = more plans
Modify reservation in order to work around a FastPass reservation or a change in plans.
Current modification flow is laborious or too much risk to take.
Guests don’t want to risk losing the reservation that they already have.
Next up, we needed to unpack how we were going to fit our new design system into MDX’s legacy design. The distinct difference were:
Different navigation structure: Hamburger menu
Distinctly different visual style
Detailed Design
Combining navigation patterns: I embarked on wireframing out all the entry point flows, working through the hamburger menu navigation pattern. In addition, I prototyped all these flows as it was crucial to be clear about the desired interaction patterns.
For example, the new design language typically had new screens appearing from the bottom, in a layering format. MDX was built more on a side-to-side pattern. Prototyping helped ensure that the developers knew what interactions needed to be adjusted.
Edge cases: I discovered that some reservations had multiple experience types:
Character Dining (think breakfast with Mickey Mouse)
Table Service
This created the possibility for someone to modify a reservation time without realizing they were booking a whole new experience. Say goodbye to Breakfast with Mickey… We worked through an interstitial page that notified the user that they were changing experience types and to confirm that this was intended.
Testing & Iterating
We partnered with our Research team to test the design with users in the parks. I built out the prototypes and collaborated on a testing plan. One of the testing takeaways was that guests weren’t certain whether their reservation had successfully been modified. This was due to the experience once they completed their modification and went back to their reservation home screen.
I iterated on the design:
Added in a fade out-fade in interaction to emphasize that there was an update (feedback).
Saved the scroll position so reservation card was in view
The Handoff:
Remote: Our team was primarily working remote, both on the engineering front and management.
Parallel Work Stream: In addition we had another team working on a similar timeline that was building components we needed to reuse.
Detailed documentation was essential for this handoff. I was responsible for all wireframes, annotations and motion studies to help our dev team during the build. I was also the point person for all our developers throughout the build, answering questions, providing further motion studies, and aligning on modifications when complications arose.
Post Launch:
Soon after the launch, we heard from the customer support team that calls for modifications were already starting to decrease. Over the following months, we only saw a further decrease in calls to modify, and increase in modifications within the app. In addition, the DineMods project truly paved the way for many other features to be added into the MDX app in the new design language. The process my small team established was repurposed by new project teams due to its thoroughness and overall success.