Mosaic: Global Design System
Blizzard Entertainment
Building an atomic design system to streamline the web app creation process as the demand for studio-catered internal tools increase.
The Project: an atomic design system built from the ground up to address the specific needs of web tools within the Blizzard-Corporate Applications library.
Background
The corporate applications team at Blizzard is responsible for a large library of internal tools that keep the company’s day-to-day running smoothly. Many of these tools were made several years ago individually, leading to a lack of consistency. Our design team aimed to address this issue by uniting existing tools under an atomic design system we called “Mosaic”.
Time & Scope
Competitive Analysis
System Audit
UI Designs
Component Design
Content Design
Documentation
Time: 16 months (ongoing)
Tools:
Project Management: Miro, Jira, Google Sheets
Design: Figma
Testing: Maze, Dovetail
Collaboration: Zoom, Slack
How could we streamline tool creation in a meaningful way to take time back from repetitive processes and give that time back to developers?
As a part of a small design team consisting of 2 UX designers and 1 visual designer, I helped build an atomic structure for a global design system, designed reusable components and provided documentation for proper use, and evangelized the importance of a centralized source of design truth. Partnering with the rest of the design team, a product manager, and development team, we delivered a scalable design system that would serve as the foundation for current and future internal tools.
My Role
Design System Architecture
Field Research, Competitive Analysis, User Feedback
Roadmapping & Prioritization of Components
Interaction Design & Content Strategy
Collaboration with Designers, PM, & Developers
Documentation for Proper Usage of System & Components
Evangelized Need for Design System to Stakeholders & Outside Teams
What I Did
Understanding the Problem Space
Although a design system should be scalable and address any design situation, due to time constraints, we had to deeply understand the purpose for this design system and the bare minimum requirements for this to be effective for our stakeholders.
To reiterate our north star, our aim was to streamline the tool creation process and give back valuable time to development teams to focus on things like research and iterative development. So, we had to prioritize building components most pertinent to this creation process and leaving space for future scalability.
Finding the Common Ground
Blizzard’s vast internal tool library includes different tools for different teams, which means different goals and branding. If this design system was to be adopted, it needed to accommodate what already exists and make room for what could exist.
As such, we thought it would make sense to name our design system “Mosaic”, to highlight the diversity of branding styles we would be working with.
Learn From the Best
We knew Mosaic would be a heavy undertaking, so we wanted to make sure it was built right. Competitive analysis of other existing systems from top companies revealed repeating patterns that we would use as guidelines:
Different tools have different goals. Leave room for specific content and visual style variations. We can leverage Figma’s variables (their take on design tokens) to have a basic foundation that can expand with variations.
Flexibility
Components are not all built the same. Allowing for larger components (molecules) to build on top of what smaller components (atoms) already do is key.
Atomic Architecture
The devil is in the details. A design system only works if the components are used as they were intended. Make those instructions clear as day.
Documentation
Getting Started
We knew what the end product needed to look like, but were unsure of how to get there. Upon reflecting on the philosophy of our atomic architecture, we realized that, just like Mosaic, we needed to start with a sound foundation and build upwards from there.
As we planned our roadmap of components, we leveraged our field research to create a tier list of components from the most basic to complicated. This tier list then informed our prioritization order for building out these components:
Styles
Even more foundational than atoms, these would determine the most basic frameworks for component designs. Examples include: color library, typography, iconography
Atoms
The most basic components that would act as the building blocks for more complex components. Examples include: button, check box, tags
Molecules
More complex components that combine atoms to create something multi-functional. Examples include: card, text field, table
Built-In Flexibility
As we began designing components, we knew that they would likely appear very differently in different tool contexts. As such, flexibility in visual design was top-of-mind.
To tackle this, we designed the most bare-bone version of components with basic branding guidelines that acted as a blank canvas for other tool brandings to add on top of.
The idea was to build our first iteration of components within the Mosaic library and utilize Figma variables to create other libraries with more specific branding guidelines. This way, we could control changes in basic design elements from variant to variant, to accommodate for different brandings.
Similarities: basic outline of component, functionality, interaction
Differences: color, typography, dimensions & border radius
What’s a Blueprint w/o Instructions?
We could build the most beautiful and functional components ever, but none of that would matter if they were used improperly. Documentation was a key requirement for every component, and so we formatted each component page to include space for specific notes, specs, how-to guides, and contextual examples to ensure that components would be used properly.
Adopting a Growth Mentality
Like with any other design process, we learn as we go along. With the iterative design process in mind, we built our design system to accommodate any future learnings and allowed for changes to existing components to easily be made, while also propagating to any other dependent components.
This adaptability proved to be an incredible asset, as technical limitations and critical feedback would lead to many design iterations and changes. Updating designs was straightforward and with the architecture we established, it was easy to control the scope of design updates. We could choose between updating a specific brand’s library of variables for a specific change, or updating the most basic Mosaic component to foundationally alter designs.
The System in Action
Once we had a minimally viable product for Mosaic in hand, we strategically partnered with tool developers to slowly implement our global design system for their tools. While this was, and continues to be, a time consuming process due to how many tools exist, the benefits do outweigh the costs in the long run. We’ve seen component updates that used to take days to implement be rolled out in minutes!
It was really exciting to also build new tools with our global design system’s components! Because we already had these components implemented and built, all we needed to do was establish brand guidelines and add them to a variable library, and within an hour we had a whole design system for a new brand! By implementing a reusable component library that could be altered to accommodate new brand guidelines, we cut development costs significantly and shrunk development time for new tools by months!
Below is a short image gallery of a few components that the team built for everyday use:
The Impact of Mosaic
Streamlining End-to-End Design of New Tools
Shrinking Component Update Timeline from Weeks to Minutes
Proper Documentation Decreased Number of Errors and Overlapping Functionalities
Approachable Design System Understood by All Team Members
Clear Guidelines Led to Less Questions & Deviations
Within the span of one year, we:
Updated 5 Existing Tools in the OpsCenter to Use Mosaic
Built 5 New Tools Using Mosaic DS as a Foundation
The Future of Mosaic
As mentioned earlier, Mosaic needed to be scalable. As such, we engineered Mosaic to be a living-and-breathing system that could have new styles, atoms, and molecules added at any time, as well as any updates to any existing components.
As more tools dependent on Mosaic are created and added, I’m sure new component needs and use cases will arise. Mosaic has a sound foundation that can potentially expand without end, so I’m excited to see how it continues to evolve and innovate!