As an intern at Walt Disney Animation Studio, I helped initiate accessibility efforts at the studio by researching color accessibility in different tool tips and data visualization. I also updated and re-designed a show planning, studio planning and workforce planning tool called Playboook. In my free time, dabbled in coding and data work along the Information Services team.
Due to NDA restrictions, I am unable to disclose all visual details of my works
Part 1: Research in Accessible colors
introduction
Inclusivity through Accessibility
Accessibility is so important not only to create an inclusive environment but also to ease the workflow. Especially in the context of Disney, because the animation studio has so many propriety tools, it was important that everyone including developers realize the importance of accessibility so that all artists, animators, toolers and creatives have equal access to the tools that will help them bring their imagination to the screens.
Problem
Colors in Playbook
My research for accessibility was mainly focused around a tool called Playbook; the tool gathers and visualizes data in different ways to assist with show planning, studio planning and workforce planning tool. Although Playbook was created with accessibility in mind, the initial color palette could not sustain the increasing data and features in Playbook.
There were two obvious pain points:
Not Enough Colors: “We need a palette that offers at least 12 colors to cover all of our use cases. Perhaps more.”
Hard to Distinguish: “...Not enough variation in brightness, many data points become indistinguishable very quickly. Color legends become useless”
Slate module can easily hold many data, leading to indistinguishable colors
Research
Visual Content Accessibility
Web Content Accessibility Guidelines
The most basic rules to follow in web accessibility are outlined by the WCAG guidelines. There are a total of 73 criterions which make up 3 levels of conformance (A, AA, AAA) around its core principles: perceivability, operability, understandability, and robustness. Out of the many criterions to meet the accessibility, I focused on meeting the A & AA Level for distinguishability (outlined in guideline 1.4) on use of color, contrast/size of text and images.
WCAG Principles
Color Contrast in Data Visualization
Because the pain points of colors in Playbook mostly were discovered in areas of complex data visualization, I decided to research further into how colors are defined for data.
After doing a secondary research on articles and guidelines from data-heavy companies like IBM, Adobe and AirTable, I realized that there is no perfect set of "color palette" to display data. If anything, there are researchers still looking for the best color palette for data visualization.
So, since there was no perfect scheme, there were many "general rules to keep" for a clean and accessible data visualization. Like:
Using reduced background to allow for as many colors (this means black, white and dark grays, off whites, etc.)
Using outlines when possible
Using shapes, textures, labels and other syntactical choices
Understanding sequential vs categorical palettes and their respective pain points.
Sequential palettes are often light to dark shades of the same color — demonstrating range of data sets
Categorical palettes are more complex as they are usually used to assign non-numeric meaning to categories in visualizations. IBM's Carbon Design Team set three rules for creating a categorical palette:
Differentiated: they should have a sufficient visual contrast among themselves (optimized for all color deficiencies).
Diverse: as a set they should avoid false associations or correlations due to similarities in brightness or hue.
Sequenced: in order for the palette to be effective in visualizations with as few as 2, and as many as 14 categories, the colors need to be sequenced in such a way that differentiation and diversity is evenly distributed.
Tools & Resources
As I was researching, I ran across tools and resources that could help developers and designers take this further and use it to whichever needs they would design for:
Despite the above summary of research on accessibility, I've come to realize that the color contrast for WCAG is merely a guideline; meaning that certain contrasts that fail/pass in contrast ratio does not accurately measure up to the visibility.
For example, take a look at the figure below:
WCAG guidelines for color isn't perfect I'm interested in learning more about colors and building better system for accessibility.
So, if you’re interested in colors in accessibility, let’s talk!
Part 2: playbook Milestones re-design
Project type
Tool Redesign
Project Date
July 2021 - Aug 2021
Tools
Figma, Miro
Role
UX Design
Summary
I was given a task to update and re-design a show planning tool called Playboook in order to add a new stakeholder.
In the second part of my internship I worked directly with Playbook to re-design the show planning module Milestones to match the needs of a new stakeholder and also update the interaction since its original creation.
Playbook is divided into 3 parts: show planning, studio planning and workforce planning
Understanding & Defining
Pain Points
Understanding the Assignment
There were two important goals in re-designing the module:
1. Create new designs to fit it the needs of a new stakeholder, the Creative Development team and introduce them to Playbook. 2. Update current designs to refresh the module from the clutter that had been built up by increasing functions through requests.
Design Requirement of the New Stakeholder
My mentor had previously met the Creative Development team and had talked to them about their process and discussed how Playbook could help. I was passed down an outline of important key dates and other requirements/concerns they had.
Use the pre-defined color scheme for certain set of key dates
Need flexibility to only see certain set of key dates or processes
Need to change and edit key dates or processes
Need to be secure/private as their processes were highly confidential
Pain Points of Playbook
As for the general re-design for Playbook, my mentors and I created a list of accumulated pain points based off of the feedback they had gotten. I added on to the list as a first time user of Playbook.
Accumulated un-labled functions are confusing for users & is not visually accessible (overlaying shapes and texts and not setting proper contrast in colors.)
Certain features are not being used or is ambiguous.
The information on the gantt chart is too cluttered. (shapes and texts overlay on top of each other, the addition of new stakeholder functions would make it even harder to read)p
Gantt chart interaction is poor; especially correlating time and key dates on the chart (users have a hard time navigating between different time points and the time bar does not correlate will with points on the gantt chart)
Empathize & Define
Research
My main goal of this research was to explore different ways to organize Milestones data and functions. I needed to first understand the context of the data I was working with, for whom these functions were made for and why, and see industry standard ways these data & functions are displayed and interacted with.
Understanding Production Terms, Key Dates and Significance
After gathering all of the pain points and requirements, I knew that I needed more context in order to come up with a proper solution. While my team showed me through the different functions in the Milestone module,I was looking to get a deeper understanding of what each key date meant, how they correlate to each other and the significance it held to production.
I looked through documents and set up chats/un-structured interviews with the people in the Playbook team and current users of Playbook in the studio and ended up learning a lot about the process that happens behind animated movie magic.
Who are Current Playbook Users
Through my chats, I found primary users to Milestones modules and although I wasn't able to directly interview some of these users directly, through their roles and positions within production, I was able to deduct and created out a short user journey of how they might use the module. Based on my key users, I mapped out functions they primarily use and re-traced their steps in the module to simulate their journey and find any pain points or processes that could be made easier.
Studying Gantt Charts & Timelines
The Milestones module was a digital version of what used to be a collaboration of whiteboard and paper record to keep track of and display important dates studio-wise. When first building, the Playbook team designed this on top of the gantt chart. I did a quick comparative analysis of how other application like Airtable display gantt chart. I also analyzed other timeline features in applications like Adobe Premiere Pro to study different interactions.
HCI and Interface Guidelines
I kept in mind different HCI guidelines like Shneiderman’s Eight Golden Rules, Norman’s Seven Principles, Nielsen's Ten Heuristic Principles and general interaction rules like being consistent, offering feedback, lessening the amount of information that should be remembered between actions. I also tried to keep in mind the Keystroke-Level Model, which just basically meant that I wanted to reduce the number of actions a user has to take to do something
Synthesizing Research
Main Functionalities of Milestones
Playbook's main function was to provide various way to view key dates with adjustable categories of key dates, time range and number of projects.
It has helper functions to edit the key dates and calculate extra data based on key dates
Project Breadth vs Depth
Looking into the user flow of current users, there were two main types of users: users who care about the future and users that care about present time. Future-focused users needed to see the breadth of the project,
Ideally, each user would want the flexibility to see only the information
iterating
Prototype
Based on the research, I ideated on different ways to display dates, organize data and create potentially helpful features.
&
I ended up creating 3 major iterations of the prototype and worked with developers and my mentors to get feed back and adjust my designs or think of new ideas depending on the amount of technical debt or priorities.
Meeting the Creative Development Team
After designing the Milestone module based on the first set of requirements, I was given a chance to meet with the stakeholder. In this meeting, I presented a prototype demo and found more needs for the development team through discussion. During the meeting, I was able to do a live design session to clarify and ideate with them. I iterated on my design based on feedback and added new features they wanted before my final meeting. with the development team.
solution
Final Prototype
Here are what my designs looked like excluding NDA details!
What playbook looks like currently
Filter Menu
Detail pop-up for key dates
Semi-interactive prototype:
TLDR
Accomplishments!
I participated in studio's initiative for inclusivity by researching web accessibility methods and working to define accessible color palettes in data visualization.
I re-designed user interface of the show planning module in Playbook for a potential stakeholder, Creative Development team.
Participated in 40+ hours of knowledge transfers of various web technologies like ReactJS, GraphQL, Django, Elastic Search, and ApolloJS.
Got hands-on experience by working on different projects Information Services team supports. Updated a UI feature in Playbook and tested in Cypress.
TLDR
Accomplishments & Reflection
I participated in studio's initiative for inclusivity by researching web accessibility methods and working to define accessible color palettes in data visualization.
I re-designed user interface of the show planning module in Playbook for a potential stakeholder, Creative Development team.
Participated in 40+ hours of knowledge transfers of various web technologies like ReactJS, GraphQL, Django, Elastic Search, and ApolloJS.
Got hands-on experience by working on different projects Information Services team supports. Updated a UI feature in Playbook and tested in Cypress.
The studio follows a waterfall design process because there are only 2 product designers at Disney Animation support the entire animation studio with 1000+ people and many, many proprietary software. This also meant that only a few project get re-designed every year. So, I put a lot of internal pressure on myself as developers would take a few months to build my design and it must be able to sustain some years of use.
The Walt Disney Animation Studios was a magical time
-this page is currently under construction- but feel free to click through some visuals I created during the internship
