Walt Disney Imagineering // UX Design, Product Management

Walt Disney Imagineering is, according to their website, "...the unique, creative force behind Walt Disney Parks and Resorts that dreams up, designs and builds all Disney theme parks, resorts, attractions, cruise ships, real estate developments, and regional entertainment venues worldwide." I was lucky enough to have two contracts with them since graduating from the University of Michigan - one with the arm called Research & Development and one with Show Software. I can't tell you a lot (Disney - so secret!), but I will tell you what skills I used, show you some prototypes, and talk about what I learned!


It has to be said: The thoughts and opinions presented here are my own and do not reflect those of any division of The Walt Disney Company. To the best of my knowledge, I have omitted confidential material (including all images, which are from Google/open source and not internal sources) in order to comply with my many non-disclosure agreements. In addition, some mockups seen here are modified from the actual version and may not reflect exactly what was created.

Walt Disney Imagineering Research & Development: Product Manager, UX Designer, UX Researcher

From June 2015 to December 2015, I had a contract with Walt Disney Imagineering Research & Development - which was, naturally, incredible. It also was heavily protected by multiple different NDAs. I have nothing physically to show from this contract, as I could not take any assets with me after I finished, but I can give a quick breakdown of what I was hired to do, a summary of the skills I used, and some project hints:

  • I was hired as a Product Manager (with a desire for me to do UX work too), but since my team was only about 2 people (as well as working with multiple different teams throughout Disney and outside of it), I tended to wear multiple hats: PM, project manager, UX designer, UX researcher, communications liaison, technical evangelist, information gatherer...

  • I primarily worked on internal applications for Imagineers which consisted of approximately 8 different Ruby on Rails applications used to assist Imagineers in their everyday work. I spent my days pulling code, QAing the code for bugs, and priortizing tickets for our multiple different vendor teams. I also took bug reports from users and fixed issues.

  • During my time at R&D, I was "hired" by another group within Imagineering to create a hi-fidelity mockup of their new site idea -- basically a large database of tools for Imagineers is all I can say about it. My mockups were made in Adobe Illustrator and were well-received. The team got the funding for their project based on my ideas.

  • This contract taught me a lot about self-sufficiency. I came right out of grad school and did not join a big UX team. I joined a large corporation, a small team, and had to learn to make decisions and design within very tight constraints. That may be what all UXers have to do, but I had to learn how to do it without bouncing ideas off other people sometimes. There wasn't always an opportunity. I love working on teams so this was a challenge for me, but it ultimately made me a stronger decision-maker and problem-solver.

  • All of the applications I worked on were internal applications. I am very well-versed in designing internal applications for employees - maybe it's not the "fancy" design other people crave, but it's just as, if not more, important. I love intranets and employee-facing products! (But I also love guest-facing, as they say at Disney, products, too!)

Walt Disney Imagineering Show Software: UX Designer

From August 2016 to January 2017, Walt Disney Imagineering brought me back for a contract with another team called Show Software. I worked on multiple different projects as a UX designer and even am able to show you some mockups I did in Sketch! I also learned quite a bit in Framer.js, a dynamic prototyping tool using CoffeeScript.

Media Vault Alternate UI - Digital Asset Management

Media Vault is the asset management system for Imagineering. It is built on Open Text Media Management. The system is complex and very dynamic; however, the Media Vault team asked me to design an alternate UI to sit on top of OTMM that allowed "general" Imagineers (not Super Users) to quickly find the assets they were looking for without all of the extra features that OTMM offers.


The alternate UI was designed using Bootstrap and Material Design elements, based off of a UX design library that my UX team at WDI created. I completed the iterations on the mockups in Sketch and animated some elements using Framer.js to show interactions. The idea behind the alternate UI was to increase the efficiency and flexibility of the full site. We just wanted something that was Google Image-like: fast search, easy download, responsive design.


Challenges

Examples of challenges I worked through in this project:

  • I had to constantly think through how users think about filtering search results. It seems inherent with the ubiquity of Google searching, but it was a challenge to design an ituitive search + filter based on Imagineering needs

  • Since this is primarily a database for searching for assets and downloading assets, translating that to mobile was interesting. Cast Members in the parks may need to use their mobile devices to find appropriate assets, and the current MV did not have that ability. Searching on mobile can be translated easily enough, but filtering was another challenge to work through. I used Amazon and other e-commerce sites for inspiration. Advanced Search on mobile was also a challenge and we need to do some future testing on whether or not it is necessary to include on mobile.

  • We wanted to avoid modals as much as possible, so I had to design a way to allow users to preview asset results (and see important metadata) without a modal. We decided on a Google Image-like preview pane that had expandable sections as there are possibly hundreds of lines of metadata applied to each asset.
alternate UI iteration 1
Example of first iteration of alternate UI screen with filtering

alternate UI iteration 2
Example of first iteration of alternate UI screen with quick search dropdown
alternate UI iteration 3
Example of final iteration of alternate UI screen with filtering
alternate UI iteration 4
Example of final iteration of alternate UI screen with quick search dropdown
alternate UI iteration 5
Example of final iteration of alternate UI screen with photo thumbnail preview expanded
alternate UI iteration 9
Example of final iteration of alternate UI screen for mobile photo preview
alternate UI iteration 9
Example of final iteration of alternate UI screen for mobile photo preview - "show more"
alternate UI iteration 6
Example of final iteration of alternate UI screen for advanced search
alternate UI iteration 7
Example of final iteration of alternate UI screen for advanced search on mobile
alternate UI iteration 8
Example of final iteration of alternate UI screen for advanced search on mobile

Media Vault Batch Upload

The Media Vault team needed a more efficient way to batch upload multiple assets and enter metadata during the lengthy upload process. With members of the MV team, I designed a batch upload process that solved all of their current issues with uploading.


The batch upload was designed using Bootstrap and Material Design elements, based off of a UX design library that my UX team at WDI created, and it matches the alternate UI. I completed the iterations on the mockups in Sketch. This piece of the database does not need to be responsive as it is intended for large drag/drop uploads and intensive metadata entry.


Challenges

Examples of challenges I worked through in this project (see next section for a more detailed look into my process):

  • The intended users for this system are Super Users. Building a easy-to-use system with enough complexity for them was a large challenge (and a challenge that happens during any UX work).

  • This system needed to also sit on top of OTMM, so the uploads were technically loading to a queueing area before loading to the real site. Error handling may have been the biggest challenge. How do we show when the system throws an error and indicate where the error occurred? How do users come back and correct errors when there's a queue and two sites? It took a lot of trial-and-error (no pun intended) to get error handling "right" - and will still need to be tested often with users.

  • Since there was a queue area and required metadata to be completed, we needed progress indicators at every step. Deciding where those progress indicators should be located and how they should be showing progress took some debate. In the end, we discovered that the users like to see as many assets as possible on a page, so our initial design (rows for each individual asset) was not feasible. We fixed this by using circular progress meters (from progressbar.js for individual thumbnails and one large progress bar across the top. Post-sending the assets to queue also included multiple progress meters and status indicator tags, as show in the figures below.

  • Metadata, metadata, metadata. How can users enter in metadata for multiple assets (100+) that all may have similar metadata information but also has different fields? We designed a way for them to multi-select assets to fill out fields and also copy/paste fields over. This system was the best way for the users to enter metadata and they were very happy with this solution.
batch upload iteration 1
Example of first iteration of batch upload using rows

batch upload iteration 2
Example of another iteration of batch upload using rows and line progress meters
batch upload iteration 3
Example of final iteration of batch upload with progress indicators, metadata form on the right, asset selected.
batch upload iteration 4
Example of final iteration of batch upload with large number of thumbnails showing, all assets selected.
batch upload iteration 5
Example of final iteration of batch upload once all assets are uploaded to queue and all metadata entered
batch upload iteration 6
Example of final iteration of batch upload once files are publishing to the asset database. Shows error messaging.

Process for Designing Batch Upload

I worked with only a few other people on this project, and I had a tight time frame for presenting a viable design. I can't show my whole process due to NDA constraints. Here's some insight into how I designed a particular feature of the batch upload - editing the metadata for multiple assets at once:

  • In order to see how users currently understand upload, I did an analysis on the current system and its steps to uploading assets and entering metadata. I had a general idea of the pain points users encountered, but wanted to have the current user workflow as a base for the new design as well as see the pain points for myself. The current system requires users to upload in smaller batch sizes because only one set of metadata "templates" could be applied at one time. After upload and application of template, the user would have to go back into the system and individually enter in metadata for each asset. Incredibly time consuming when hundreds of assets need to be entered per day!

  • Keeping the time-consuming issue in mind, I took to my dot grid notebook (the best way to sketch, in my opinion!) to start working through some of the challenges I had. How do we allow users to not only upload hundreds of assets at a time, but also edit certain fields of metadata for certain assets without losing speed or having them do each asset individually? How can the design give the user enough feedback about what assets they're editing so that they don't get lost in the system? Another challenge is that there has to be a security template first applied to entire batch -- it's required and is a restriction we had to keep in this design. Most batches, no matter the size, will have the same security permissions anyway, but we had to also account for applying that entire template first before editing the individual metadata fields.

  • I struggled with how the users could see both the asset thumbnail, the asset size, the asset status (uploading, metadata entered), and all of the editable metadata fields (could have 100+). Also, when should the user apply the security template? Should we hide it after it's chosen? What if it needs to change? A few of my first ROUGH sketched iterations are below - I brain dump as much as I can to get ideas flowing.
batch upload workflow
This was my earliest sketch, my first idea. I made a modal that could also be an entire page, if we decided. I wanted to show thumbnail, size, status, time remaining, but also allow the metadata form to be shown as well.
batch upload workflow
This sketch shows my concern for showing users where they are in the system and what exactly they're editing. At the top of the metadata field, I thought about adding tags (similar to a filter in a search) that show what assets are currently being edited.
batch upload workflow
This sketch was a blend between full page and modal behavior. I thought about giving the users more space per line to see metadata info for each asset, and when they wanted to edit it, a modal would appear.

  • For my first iteration, I went with the full page design (seen below, Iteration 1). I changed the selected colors to light grey (so the background of the selected asset would match the background of the metadata form). I also included a "select all" and "deselect all" checkbox in the header in case the user did want to edit the template (something that can only be done if all assets are selected) or make sweeping changes to all assets. The current asset that is selected and being edited is shown at the top of the form as well to give the user more feedback.

  • Because there is a lot of metadata to be shown and edited, I designed the metadata form to only show required fields (something I learned from users that most people only fill out those and nothing else) and then there is an expandable/collapsible section underneath that will show all metadata information. I wanted to condense the information that is shown to users so not to overwhelm them and also to surface all important information to the top, hopefully making it so the user does not have to scroll. The status for "Metadata Completed" only becomes green with required fields, so it made sense to only surface those.

  • The security template in this initial iteration was included within the metadata form on the right. This presented some issues. If a user was allowed to change this template when only one asset was selected, it would affect all assets (since only one template can be applied to a batch). Would the users understand that, even with helper text? Should it just be disabled?

  • For one of the next iterations (I went through a lot, can't show all of them!), I decided to move the "Editing:...." status information to the header to save space. I also tested out some ways to make it even more obvious what assets are being edited. I was concerned, and my team was as well, that it was hard to know what metadata users were changing when they selected one or multiple. See Iteration 2 and 3 for examples of tests of drawing out the selections more.
batch upload iteration 8
Iteration 1: "Currently Editing..." moved to header and light grey backgrounds for selected

batch upload iteration 9
Iteration 2: Darkening the grey background. Was also playing with the progress meters and "Ready to Publish" notifications, but that's unrelated to metadata editing for these examples.

batch upload iteration 10
Iteration 3: Pretty ugly, but highlighting with blue and bringing out the rows more clearly - it was a test :)

  • After doing this iterations, I had the opportunity to get about an hour with users. I showed them my designs, and as always, they had suggestions I had never thought of for the system. They informed me that they loved the ability to multi-select and edit; however, they want to see as many of their assets at once. I began the process of sketching out how I would show more thumbnails while still providing asset info and asset statuses.

  • The users also informed me that though it was nice to multi-select, they really needed the ability to carry over certain metadata fields from asset to asset. Sometimes they might need to copy four fields, sometimes it's just one. It would vary. This was something we hadn't thought of on my team -- but it was so obvious. Of course they want to speed up the metadata entry process. See Iteration 4 to the right for some initial sketching after user session.

  • Some initial ideas I had for copying over certain metadata fields were: allow the user to copy an entire form from one filled out asset with a copy/paste button at the top of the Edit Metadata form, or allow user to select from a dropdown menu what asset to copy (if they had already filled out info on an asset), or create templates for common metadata patterns.

  • The first idea for copying metadata ended up being the most viable, with some modifications. A dropdown menu of previously filled out assets to copy could get large, even with a type ahead, and we can't expect users to remember what metadata fields go with what asset. Additionally, it would be rare to have a large number of assets with the same type of metadata - at least not enough to warrant copying one asset over and over from the menu. The template option had the same issues as the dropdown menu - as it was essentially a template - as well as sharing nomenclature with the security template. Much confusion!

  • With the copy/paste method, I wanted the users to be able to have control over which fields they could copy. In the final version (below, Iteration 7), we chose to let users use a Copy icon to copy each individual metadata field if needed, or they could push the button at the top that allowed users to Copy All Fields. If they wanted to select multiple fields to copy, there was a button for that as well. The metadata form field would enter into "select" mode and checkboxes would appear for users to multi-select the fields they want to copy. (See Iteration 8, below)

  • Implementing copy/paste was a feature the users were also used to from a previous system they used for asset storage. It was a desktop app and very different than this system, but the behavior made sense to them, which helped our design. Additionally, if the users did not want to use copy/paste, they could also just multi-select the thumbnails on the left and edit metadata fields for multiple without using the copy/paste feature.

  • Finally, I designed the thumbnails to sit next to each other, similar to the style of the Alternate UI (seen above under Media Vault Alternate UI). I put in a slider to change the size of the thumbnails and also condensed the information on each thumbnail. This allows users to see as many thumbnails per page as they desire, as well as shows more clearly what assets they are editing with the addition of the blue highlight.
batch upload workflow
Iteration 4: Sketching out ideas for showing multiple asset thumbnails and how to copy certain fields over from asset to asset

batch upload workflow
Iteration 5: Once I chose to use the copy/paste method for metadata fields, I was trying to wrap my head around the flow. Had a lot of questions to answer!

batch upload iteration 6
Iteration 6: First attempt at designing copy/paste functionality. Made a "Metadata Options" button with a dropdown menu, but in the end, we decided that was too hidden.

batch upload iteration 7
Iteration 7: See the form fields on the right - buttons at the top for Copy/Paste, Selecting, and then small icon by each field for easy copying of one field at a time

batch upload iteration 9
Iteration 8: The form changes to allow users to multi-select individual fields to copy when "Select Fields to Copy" is chosen on main screen. Once a user checks off fields, they can click "Copy Selected."

batch upload iteration 8
Iteration 9: Lots of thumbnails shown, slider in the upper right to change size of thumbnails shown. Checkboxes for users to multi-select that appear on hover, or user can Shift + Click. You'll also notice we ended up moving "Change Template" (for the security metadata) to the header so it's out of the way of the metadata form and not easily accidentally changed.
  • The final version was approved by both users and executives. Based on many factors, this was the most viable design. You can see the final version in Iteration 9 above, as well as in the body of the main project description above the "Process" section.

Other Projects at WDI

I didn't just work on the above projects! I just can't show assets from the other ones. I assisted in redesigning and creating new features for the show monitoring system for the theme parks, which was a huge challenge as it included physical + digital controls. I also helped other teams create style guides for their desktop apps that matched our Web UI. Another project I assisted with was user research conducted on a Windows desktop app in .net. Whew. It was a busy 6 months. Want to know more? Connect with me!


Visit Another Project