Disney Travel

2020

Disney relies heavily on independent travel agents across the country - and the world - for bookings to their resort hotels, park tickets, meal plans, and special package offers. To support these bookings, Disney provides a booking engine for registered agents that provides one-stop shopping for all the components that comprise the typical Disney vacation. Disney leadership recently expressed an interest in evaluating this system as a possible target for enhancements and improvements.

We were in the process of prioritizing this as a project when COVID took the stage. The team assigned to the opportunity was now on the bench, so we asked for and received approval to conduct a discovery phase for this project in good faith that the output would benefit Disney as a client when Disney returned to business as usual.

Quick to Concept

The team devised a plan for a two-week exercise to include:

1. A content and flow review of the existing travel agent site,

2. An internal survey using staff as "proxy" travel agents,

3. A performance review focusing on backend processes and APIs,

4. Prototyping UX/BA/QA staff for prototyping one or more proofs of concept, and

5. Time with dev teams to define a buildable single-sprint solution.

The team agreed that our goal with this initiative was NOT related to visual design, rather we would focus on performance, content and agent workflow. Visual interest would need to take a back seat to other priorities given the limited time allocations approved for this project.

A Heuristic Review...

...of the site revealed that page load times when editing rooms, meals, and other selections were longer than is typical for a mostly-text site. Flows for many of these edits included loss of context since selections often loaded as new pages outside of the context of the initial list view. Evaluators also noted that forms contained images that would be appropriate for a consumer user but actually create clutter for an agent who interacts with this content regularly. It was clear also that content was not well organized reducing the agent's ability to scan for specific information.

So, we had uncovered areas for improvement, but we needed to understand site usage from the travel agent perspective. Since Disney was offline and unable to provide those users, we enlisted 8 internal staff members, explained to them what it was like to be a Disney Travel Agent (DTA) and asked them to respond to a short survey while using the site to complete some typical tasks.

Survey Reveals a few issues:

Clickable areas and actions were not always obvious in part due to page clutter
Selection flows we not intuitive and seemed to require more clicks than necessary
Page load times and transitions were considered slow
Some form elements were deemed unnecessary for the agent user type

Defining the Problem

Live tests revealed that the application was slow. At every point of inquiry or data entry, the application connected with an underperforming backend system resulting in lag-times during the agent's workflow. Survey respondents confirmed that this was THE critical issue with the application.
Selection and edit tasks consistently directed the agent to pages outside the view of the reservation details or cart pages. This flow often created a loss of context for the agent.
Users identified several instances where extraneous information impeded workflow. While detailed content would be appropriate for a consumer, images and long descriptions of resorts and meal plans were unnecessary for a travel agent who used the site daily.

Our Approach

Given the time allotted to this project, we needed to manage our efforts. The BA - acting in the product owner role - established a schedule of quick prototype iterations while the dev team worked on backend services to improve performance. I (as UX lead) would implement collaborative reviews to include devs as we iterated on solutions. It would be important to iterate only on solutions that could be coded within the 3-week timeframe.

We reviewed the user journey and agreed as a team to reduce the number of redirects from core detail and cart pages. The benefit here would be two-fold: reducing calls to the backend and reducing clicks.

Initial Wireframing

UX, BA, and QA began sketching ideas for details and cart screens that would facilitate a more contextual experience, with the goal of keeping the main page visible at all times. Two flows were considered during the first 2 days of wireframing.

We would respect the current configuration which maintains separate pages for existing reservations and new (in-progress) bookings. But we would also explore the idea of combining these functions into a single UI. It was important to create these clickable rough drafts quickly in order to get feedback from the dev team by the end of day 2.

Eliciting Developer Feedback

"Boy were they quiet," was all that I could say after our first share session with the devs. We had some pretty good wireframes, but no one wanted to state an opinion. Was it a language thing? Or the fact this this team had not worked with the guy with the Southern drawl (me) before? In any case, we needed to fix our collaboration model ASAP..

After making a few intuitive updates, we shared the second round of XD files, except this time I had prepared a Mural board that would allow some silent critique. After the demo, each dev was able to share thoughts by adding virtual post-it notes to the board. By the end of this session, we had identified the problems we wanted to solve and had even sketched some solutions to test in our prototype.

With our newfound trust and a pocketful of ideas, we - the entire team - decided that this time-boxed effort should focus on the flow with separate sections for completed reservations and new bookings in order to reduce the effort needed on the backend.

After making a few intuitive updates, we shared the second round of XD files, except this time I had prepared a Mural board that would allow some silent critique. After the demo, each dev was able to share thoughts by adding virtual post-it notes to the board. By the end of this session, we had identified the problems we wanted to solve and had even sketched some solutions to test in our prototype.

With our newfound trust and a pocketful of ideas, we - the entire team - decided that this time-boxed effort should focus on the flow with separate sections for completed reservations and new bookings in order to reduce the effort needed on the backend.

Long Story Short

The team continued wireframing, creating prototypes incrementally based on team feedback and publishing each day for feedback through Adobe XD. The final prototype addressed the loss-of-context problem using accordions in the cart and detail pages instead of redirecting to new pages on every click. We created new tables to include only relevant content so that the agent would not be exposed to images and descriptions from the consumer site.

Our BA and QA organized the final presentation and we shared the final prototype along with the dev team's interpretation of several of the inline form elements. The dev team also demonstrated how a rearchitected backend could improve site performance. The final results will be shared with Disney in the coming days to determine if the project will be prioritized and become active.

Late version of the Disney Travel cart page prototype

Prior to this initiative this application launched a new page for almost all of the add/edit buttons and load times for those pages were in excess of 7 seconds each. Web services were modified to preload content in the background prior to use and content was moved into in-page accordions to maintain context within the cart page.

DT2a480.mov.mp4

Nothing fancy, but effective nonetheless.

Other improvements include the addition of a fixed footer with summary details and primary calls-to-action visible at all times. If the general concept is approved by Disney, we will incorporate a visual design phase into the next round of the travel agent project.

Next: capSure