WM - Internal Design System
Mission: Create a modern, scalable design system for WM’s internal applications
Impact: Over 21% improved efficiency in dev process, noted impressions of modernization by employee testers
Introduction
Picture this:
You join a new company in the operations sphere. You’re excited to hit the ground running and make big moves, improve efficiency, ‘get those numbers up’, and all of that good stuff. You log into your new company’s software on day one of the job, and boom; you’re confused.
Before you are looooong data tables with minimal formatting. Numbers crowd every inch of your screen. There are acronyms like you’ve never seen inhabiting buttons that you can’t press. Oh, the humanity!
You get asked for a report, so you ask a coworker how you can export some of this data. “Good luck,” they say. “That could take hours to figure out.”
This is (somewhat) an exaggeration of the Internal Tools experience at WM pre-Design Systems. A lot of out-of-the-box solutions from software providers all stuck together in a very confusing, very inconsistent manner. For years, the learning curve when joining the internal teams was absurdly steep because it involved navigating this maze of bad UX to figure out even basic operations.
Enter the Studio Design Team. We conducted a huge audit of the entire Internal Tools suite, and began taking notes on what wasn’t working. For one, we needed consistent design language across products. Though complex data tables were the name of the game, they needed to be readable and usable to actually serve their purpose. Perhaps most importantly, new capabilities on our development team could be leveraged to improve efficiency of operations through machine learning and integrated systems.
Our priorities were set. We needed a design system that was organized, scalable, and modular.
I worked with another designer to bring the Internal Tools design system into fruition and iron out all of these inconsistencies that plagued our employee-facing products. Since then, I have been the sole designer responsible for expansion and upkeep of the system.
WM's Internal Tools were plagued with inconsistencies and broken, detached components. Design Systems to the rescue!
FOUNDATIONS
Jumping-off point
We were lucky to not begin this design system from absolute zero. The Internal Tools suite was already using WM’s brand-approved colors, a standard grayscale, and a fairly consistent typography system (though said system was not yet documented). I began the process of collecting these foundational elements into a document in a new Sketch library to begin the process of building an atomic-based system from Foundations up to Molecules. Below are the final versions of those foundational documents (note that colors and typography styles here were linked to symbols / styles in Sketch and accessible across all documents where permission was allowed).
Building in accessibility
After laying out our foundational elements of color and typography, we checked in with one of our research leads who told us a story about a dispatcher who had mistakenly reported a missed pickup in the past due to a huge design oversight. The colors used in the status indicator section of the pickup info page in our tracking application were not colorblind agnostic, and because of their similarity in the red-green spectrum, he had selected the wrong status icon, the three of which were only differentiated by color.
We had already consciously updated our design process to ensure at least two visual differentiation factors existed for variants indicating status or other boolean-type differences in icons and interactive elements, but it served as a good reminder to lay out our system in the color-blindness checker and ensure everything was up to proper standards for accessibility. We then added those pages to our foundations file with necessary adjustments so they were easy to access to other designers. The results of those checks are shown below.
Colors adjusted for Protanopia
Colors adjusted for Deuteranopia
Colors adjusted for Tritanopia
Planning for scalability
After we had done a comprehensive audit of the what we already had and what we needed to add to the Foundations library, we began the larger process of organizing existing components into the atomic library structure. We were already using components stored in numerous Sketch files for things like icons, input fields, buttons, modals/cards, and calendar inputs. However, these components were not consistently linked to one parent component in a library, which was the root of many design inconsistencies that had to be remedied in previous releases.
We brainstormed and categorized each of the pieces we had into the list, then went back and added the larger components that we would also need in terms of which elements nested where. We wanted to ensure that the order of atoms > molecules > organisms was correct so that going forward, we could avoid the inconsistencies that had bloated our backlog in the past.
Below you can see a section of the initial chart we used to organize that plan:
ATOMS
Considering functional priorities
In addition to maintaining an organized protocol to keep nested components connected and up to date, we wanted to think about building out the atoms portion of our library so that it could scale into as many molecule- and organism- level components as possible. This meant taking extra consideration of things like symmetry, padding, typography usage, and occupied pixel area. This same thinking would also allow these components to be molded to new use cases with relative ease, because modularity was being built into their specs from the beginning.
We also met a few times to decide how responsive we wanted these components to be, and where exactly to allow overrides. We wanted to strike a balance of controlled responsive design, where components weren’t so rigid and unchangeable that they couldn’t be adjusted for multiple uses, but not so flexible that they could fall out of visual consistency with their primary versions when such adjustments were made.
From the very start, we designed our atoms library to prioritize organization, scalability, and modularity.
Building in documentation
It was our priority to lay out documentation for spacing and sizing very early on in designing our components so that we didn’t lose consistency or organization as the system grew. We primarily achieved this through documentation frames within the design system and Design System Manager website that went very granular in terms of color and spacing details. Below you can see an example of our Input Box with icons documentation that was published to DSM for developers and other stakeholders to reference:
Capturing multiple states
We also made a conscious effort to document the multiple states of atoms that might change based on state contexts of pages within the design system as well. Most of our atoms followed the same scheme from standard, filled, hover, focused, error, and disabled states in terms of colors, outline pixel width, typography style, and shadow. Below you can see the multiple states of input boxes laid out in a grid pattern to document each possible state and its respective visual alterations:
Navigational atoms
Because our internal applications pull data from multiple APIs and synthesize them to present useful correlations to our dispatchers, navigating between and within the programs’ numerous pages and tables became an essential point of organization and consistency. To keep the nav elements clean and simple, we created a system of buttons and paginations to allow users to easily move between pages in the system.
Most of these navigation concerns centered around the Resource Center application, which is by far the most data-heavy and most essential to be able to quickly navigate within given its multiple primary pages. For Resource Center, we created three key navigational elements; the main left nav bar (which is collapsible), the primary top nav, and the sites bar (which allows dispatchers to filter data based on hauling sites and market areas).
MOLECULES
Navigation
Because of WM’s large library of atom-level components, we had to decide where to differentiate between the different atomic levels. Where individual elements of the navigation were classified as atoms, we decided to label full constructions of navigation sections as molecules. The same went for table backgrounds that included several nested atom components functioning simultaneously.
Below you can see how several of the individual navigational elements stacked together to create full nav components, and how inputs and buttons organized together to create table backgrounds. These are the makings of our molecule-level component library:
Tables (backgrounds + rows)
The next major category of molecules consisted of table background constructions. These kinds of components are common for WM’s internal tools suite because they serve as the frames for large data tables. Because of how much data they can house, they need to be laid out logically and have be robust enough to handle large amounts of data without creating confusion or misleading planners as they form routes or compile data on drivers and vehicles.
Below you can see examples of table backgrounds that were constructed for Resource Center to hold the numerous steams of data from APIs, and further below that you’ll find the rows where data actually populates and is displayed:
Establishing the Molecules library helped us to see our design system at scale, and know where modular elements would best serve us.
ORGANISMS
Fully populated Resource Center data tables
To build to the final organism level of our internal tools, we took these molecules for navigation and for data tables and pulled them into one single dashboard view that allows our internal users to navigate as they need while viewing complex data tables, all without losing pertinent information or their place in the larger system. Below you can see how the molecules created specifically for Resource Center come together into the final dashboard organism:
A fully populated page from the Labor tab of the Resource center, with all 3 primary nav molecules surrounding the table background + row molecules
Live-tracking GANTT tables
Though I walked through the specifics of the Resource Center’s design system elements for the purposes of illustrating our process, here you can see an example of how we followed a similar approach for our GANTT tool and compiled the molecules created into a final dashboard organism. For this tool, the row becomes even more important as a molecule because it is actually displaying live, up-to-the-minute tracking data about a truck’s location and their status within a ticket.
You’ll also note the presence of components we created to be modular at the atom level (including the day/night selector and icons) as well as shared components at the molecular level (top navigation, sites bar). Allowing these components to build modularly not only saved us time in the design process and allows for pushing update easily across products, but creates a sense of visual consistency across our internal tools suite that makes programs feel appropriately connected and familiar.
Using similar molecular components similar to those of Resource Center but tweaked to suit the live-tracking function of the GANTT tool, here is an example of populated data rows within a table background, coupled with the site bar at the top
Driver Assist Tool main screen
Despite our Driver Assist tool adhering to entirely different development standards than our internal web applications, you can see how our atomic design system approach still helps create a unified visual identity by using modular pieces that work within the DA environment. Below you can see shared icons, typography styles, and styling elements for things like cards, headers, and images. Our philosophy for products that have OS restrictions was very much to carry over as much as we could from existing atom- and molecule-level components to retain visual identity and aid in making our product suite feel more bespoke and connected.
CONCLUSION
Key Takeaways
Rebuilding our design system from zero using the atomic design approach was a labor of love, but it turned to be one of the most worthy investments of my time at WM. What took several months of hard, planned work almost immediately began to pay off in saved time on component updates, easier turnaround on asks that could be met using existing atoms and molecules, and a place to send stakeholders and team members looking for specs or answers on questions about design elements from Foundations up to Organisms.
After creating the system, I have continued to maintain it as a library in Sketch and through Invision’s Design System Manager, which has involved pushing updates when changes have happened since the system’s creation. Those pushes have mostly gone off without a hitch, and even when more granular changes are necessary, they are much easier to execute than before.
Getting team buy-in
What took a bit of effort after the system’s creation was onboarding the rest of the team about it’s characteristics, usefulness, and potential to improve their workflows. The system was finished in mid-2022, and since then I have been able to get the entire product design team on board and connecting their work into the Sketch libraries.
I truly enjoyed the process of putting the whole system together, and so have been eager to help designers integrate their suggestions for changes and updates as we’ve gone along. After using the system for a few months, the time it took to update internal tools shortened significantly and we were able to fit a higher volume of tickets into each sprint as outlined by the strategy and dev leads.
In short, I loved creating this design system and would be excited for the chance to do it again!