Project Overview
About Astrolabe
Astrolabe is an innovative platform that seamlessly consolidates data from various Imagineering sources into a user-friendly repository, ensuring easy access to important Imagineering project information. With the search feature at its core, Astrolabe will efficiently surface up-to-date project data collected from its own database and other relevant sources. Lastly, it integrates with authoritative sources for project rosters, project names, aliases, and establishes a unified language for location definitions. This harmonization aids in effectively organizing assets and data across all Imagineers' applications.
Timeframe
12 months delivered in 2-week sprint intervals
Role
UX Design, UI Design, Product Design, Content Strategy, UX Research, Information Architect
Partners
Imagineering’s Tech Studio, Disney's Tech and Digital
Tech
Figma, Vuetify, Airtable
My Role
As the lead designer working on the first phase of Astrolabe, the Administrative Client, I was involved in creating an intuitive and visually appealing interface specifically tailored for site administrators, managers, and developers. I focused on designing flows and the UI for data management, user permissions, and other configuration settings. I took on responsibilities for managing data sets that would live in Astrolabe, their unique attributes, and flows related to managing those data sets. Engineers on the project provided me with entity relationship diagrams (ERDs) that I used to aid my work. Additionally, while working on Astrolabe, I diligently documented all UI components, contributing to the development of the comprehensive design system known as Cosmos Web Apps, which is further detailed in this case study.
Problems and Challenges
Due to its multidisciplinary nature and extensive history, gathering consistent information for a project at Imagineering can be a complex task. Here are some of the problems that I faced during this project and Astrolabe aims to tackle:
✦ Each project is unique, making it challenging to establish standardized definitions of what makes up a project. ✦
✦ As Imagineering evolves and experiences attrition, there is a risk of losing critical legacy knowledge that is invaluable. ✦
✦ Imagineers are wickedly talented and possess strong opinions on how their organization should operate and influence their workflow, which proved to be an interesting challenge when getting feedback from them to influence my design decisions. ✦
Solution
The Administrative Client of Astrolabe served as the first phase in addressing the complex problem of gathering consistent information for Imagineering projects. By establishing an intuitive interface, the Admin Client streamlines data management and began to define project information. For the first four sections of the Admin Client I worked on (users, companies, projects, and clients) I prioritized speaking with relevant team leads and reading company documentation to make the most informed design decisions as possible. The initial release was aimed at developers and allowed them to begin data migration from other applications to Astrolabe.
What is Imagineering?
Founded by Walt Disney in 1952, “Imagineering” (WDI) refers to the unique approach of blending creativity, storytelling, and technical expertise to design and develop immersive experiences, attractions, and entertainment products. Imagineering encompasses a multidisciplinary collaboration of artists, engineers, designers, architects, and various professionals who work together to create magical and memorable experiences for Disney parks, resorts, and other projects. There are over 30 different disciplines that make up the Imagineering department.
Phase 1: Establishing Design Foundations
I started this project from scratch, therefore I had to determine everything from breakpoints, color scheme, type ramp, and application chrome. While Tech and Digital has a design system with established foundations called Hyperion, Imagineering was looking to create a new look for Astrolabe. With this new look came an entirely new design system that I owned while working on Astrolabe. I let Astrolabe's needs drive the roadmap for the new system. While I was working on these deliverables, the engineering team was working on the tech stack.
Type Ramp
Deciding what font family to use for Astrolabe was simple; Disney's very own font named Inspire. While Hyperion established a varity of font sizes and different use cases, Vuetify, the front end framework we were using, was calling for your typical H1 though H6 type ramp with a Body 1, Body 2, Subtitle 1, Subtitle 2, Overline, and Caption. I had to establish new sizes and weights for what felt best for the application.
Colors
For the primary, secondary, and tertiary colors that were requested, I utilized the large color library that Hyperion offered. After illustrations were created by our Art and Illustration team, I integrated Imagineering's brand colors into the application.
Application Framework
The main framework of the application (left nav, app bar, footer) went through a few different iterations before I landed on the current design. Considering that this app could be used "backstage" in dimly lit areas, Imagineering did not want what Hyperion offered, which was something completely white and "bright". I struck a balance when I finally landed on a dark left navigation (using WDI Black) and a warm gray for the background color instead of stark white.
Inputs
Using Material Design as a framework, I created different input styles early on.
Phase 2: User Studies
As a newbie to the world of Imagineering, I conducted comprehensive user interviews to gain insights into how Imagineers searched for, stored, and utilized current and past project data. These studies provide valuable insider knowledge into the inner workings of the dynamic world of Imagineering and gave more context to the reason behind Astrolabe. Here are some of my findings:
✦ Imagineers get pulled off projects or move to a new one and don’t always prioritize documentation. ✦
✦ WDI has a reputation for not writing things down. ✦
✦ Keeping up-to-date documentation is hard. ✦
✦ Project information is dispersed over many different shared platforms making it difficult to find things. ✦
✦ All disciplines within WDI are different in the way that they manage, store, organize, and prioritize project data. ✦
✦ Tenured Imagineers set the precedent for the way they want project information relating to their discipline to be stored. ✦
✦ There are regional restrictions on what platforms can be used to store and share data. ✦
I went on to reach out to specific Imagineers to get more information on certain entities to help guide design decisions when it came time to design certain index pages that housed data sets.
Phase 3: Index Page Components
Index pages host the different types of data that users can sort and filter through in Astrolabe. Index pages can be viewed in either a list or a card view. Each item has a context menu that presents the user with CRUD options, a route to a "profile" page, or a route to a settings page depending on the user's permissions.
Card view for the Project Index
List view for the User Index
Considering the diverse range of attributes associated with certain groups of information within Astrolabe (such as companies with their names, websites, contacts, locations, contracts, previous names, associated WDI projects, vendor status, and parent-child relationships) conducting user studies became essential. By collaborating closely with Imagineers familiar with specific data characteristics, I gained insights into critical attributes to display on index line items, information suitable for profile pages, and necessary details required when adding any data to Astrolabe through the creation flow.
The many different iterations of the index pages I designed.
When it came to the design, I went through many different iterations for both the card and table view to come up with something that could clearly display what Imagineers recognized as critical info when it came to browsing through their projects. I tend not to use wireframes when I have the content to fill the space. Below is a silent critique I held to narrow down the final design for the project card.
A silent critique is conducted by allowing your fellow designers a 5-10 minute time range to comment on their thoughts, questions, and ideas on an area of your design that you want feedback on. Afterward, you discuss their feedback and are left with their notes to work with.
Phase 4: Sort and Filter Behavior
Phase 5: Settings Page Layout
It was required early on to design a pattern for setting pages that could hold potentially large amounts of configurations for the sets of data. Considering the list of settings could get lengthy, I opted for a second-tiered navigation as opposed to a tab format to allow room for more pages if necessary. Using the UI inputs I designed, I was able to puzzle piece different sections of the settings page together for as many use cases as I could think of.
A snapshot of my annotations frame for the settings page. This is a peek into what my deliverables looked like.
Early mockup of settings for a particular client. The user would reach this point by first going to the Client Index ("All Clients") displayed as a list and selecting "Settings" from a context menu on a list item.
Phase 6: Content Management
I utilized a web-based app called Airtable to establish a structured approach for managing and organizing data attributes, use cases, user flows, modals, copywriting, and user study findings. I was able to easily collaborate with my Product Manager and allow them to fill in my knowledge gaps within these tables.
This snapshot details the configurable attributes for each data group, a description, grouping, input type, and whether or not it was required for the creation flow.
In relation to data sets specifically, I listed and grouped actions that users could perform per groups of data (such as delete, archive, and view settings), any consequential actions that would ensue, and any related modals or alerts as a result. Attributes were also listed for each data set (here listed under the column called "Entity") along with whether they were required for creation flow, permissions details, and input styles (text field, radio button, drop downs, etc.). I also crafted copy for modals, both those related to entities and those not in relation, to provide clear and concise information to users in a friendly way. The tables that I created in Airtable felt like the beginnings of a robust approach to content strategy.
Site Map
In order to illustrate the complexity and scale of Astrolabe to my development team and ensure a logical information architecture for users, I created a comprehensive site map. This artifact served as a visual representation of the application's structure, allowing us to better understand the relationships between different index pages. By mapping out the navigation paths and content hierarchy, I could ensure that users had the ability to easily find and access the information they needed. The site map played a crucial role in aligning the development team and facilitating a user-centric approach to the design of Astrolabe.
Using Figjam, I created my version of a site map that detailed pages, sub-pages, actions that a user could take on each of those pages, and any results of those actions. This artifact was updated weekly.
Phase 7: User Flows
There were a few crucial flows that needed to be created for the first release of Astrolabe. The first is the creation flow. To start, my team and I determined the bare minimum information necessary to input data, which I cataloged in Airtable. The creation of UI components for input controls, like radio buttons, text fields, and date pickers, was prioritized early on in the project so we could determine which component made sense for each attribute. Using these components, I built an intuitive creation flow that followed the established requirements for each entity.
Company creation flow divided by steps and possible alternative flows.
A rough prototype I created for the company creation flow within Astrolabe.
Town Hall and Peer Response
I was given the opportunity to present my work on Astrolabe to the entire department during our quarterly town hall meeting. For 90% of my colleagues, this was the first time they were learning about the work being done in partnership with Imagineering. After the presentation, I received many positive remarks about my work and was asked to give a few talks to other designers on how I was building a design system in conjunction with the engineering team along with the demands of other design deliverables.
Learnings and Final Thoughts
During my one-year tenure on the initial phase of Astrolabe, I was able to successfully create a strong foundation for the continued work managing data both visually and through intuitive user flows. I gained a deep understanding of the relationship between engineering, design, and product. One of the biggest takeaways from this project is that content matters! Next understanding your users, and knowing what content going to fill the space on the screen is essential to making better-informed design decisions.
Although I was only able to see Astrolabe through its first release to a small group of users, I was happy to be a part of a significant milestone in Imagineering's journey toward a more streamlined, cohesive project management tool.
