June 2021 – Sep 2021
WM Service Excellence (SE) Design System
Building a design system that not only accounts for, but revolves around accessibility
Deliverables
Flexible library files, system documentation
What is the SE Design System?
At WM, I was one of the co-designers on a workstream called Service Excellence (SE). You can read about one of my SE projects here.
The SE Design System is a subsystem of our global design system. It was created specifically for this workstream to maintain consistency across our internal platforms.
This design system was created by me and one other designer. While I also worked on building out the global design system at WM, I was the main contributor to the SE subsystem.
Why We Needed a Subsystem
Because a lot of our field operators worked in the middle of the night, or on huge monitors, or were colorblind, accessibility needed to be at the forefront of our visual design principles.
So while it shares some of the same components and layer styles of our global system, its most notable differences are in its iconography and text styles which are much larger than what you’d normally see.
Our Approach
Structure
We built our design system through Invision’s new DSM. On a high level, we’ve used a system of systems structure, where there is one global DS and then a bunch of subsystems that are used for different purposes such as email, mobile app, and Service Excellence. Within each system, we have foundations, atoms, icons, and components.
Design System Architecture graphic created by InVision Learn
Naming Conventions
When coming up with a naming convention for our global system, our primary goals were:
Make it easy for us to find what we need when we’re designing
Use a language that bridged the gap between designers and developers
For the most part, we agreed on a general convention:
file name (if applicable) / type or use / category or family / variants
e.g. atoms / input / default / auto / standard
The more difficult part to agree on was the order of the variants. When we’re swapping out one text style for another, for example, do we want to sort by the color or the weight first?
This was something that varied by both designer and workstream. For SE, we decided on:
size / alignment or state / weight / color
e.g. h1 / left / bold / black
The Design System
Color Styles
SE has a lot of color styles that do not align with WM’s normal branding. Most of these colors are used to represent different states and indicators. For example, we use colors to quickly identify different ticket types (i.e. what type of service we’re providing to the customer and what type/size container they’ve ordered). We’ve tested all of these colors against each other to ensure usability for different types of color blindness.
Layer Styles
Our layer styles included borders that would ultimately represent different states when applied to the different products within SE. These were also tested for accessibility.
Text Styles
The font we used for SE was Inter. It’s worth calling out that the kerning for our different text styles is abnormally large to make text more readable on large monitors.
Atoms
Our atoms consist of input fields, buttons, dropdowns, list items, checkboxes and radios, basic modal templates, and tooltips.
Iconography
We use icons a lot in SE because we try to avoid using color only as an indicator. Our icons are bigger, thicker, and bolder than usual — again, to account for accessibility.
Components
Components that we built are not often used across every single product we have in SE, since they can have different use cases and users. However, most of the components we’ve built will be used across a number of products that serve a similar audience or purpose — for example, navigation.
This is an example of one of our component pages for navigation.
Documentation
We keep our documentation in WM’s Confluence site to make it accessible to designers, developers, and stakeholders alike.
On one end, we keep documentation surrounding high level design system structure i.e. what our system of systems looks like and how to use the naming conventions.
We also have documentation surrounding atoms and components — where to find them, how to use them, what the different states are, spacing guidelines, and developer information.
This is an example of one of the documentation pages we created for SE iconography.
Next Steps
Design systems are always evolving, and the SE subsystem is no exception. We continue to create new elements and adapt existing ones to match our needs as we work on updating and building new products. Along the way, we also upkeep documentation to ensure longevity and ease of transfer (if any other designers or developers needed to hop on).