Research & definition
Reconfiguring a design system
In summer 2021, Sovos launched Mosaic, the newest innovation to Sovos’ design system. When I joined Sovos as an intern, I was tasked with helping the project lead organize and reconfigure the "Components" section in Mosaic. This involved revising existing content, adding content, and creating the visuals for each component's document.
Compared to previous design system versions, the goals of this design system version were to:
- Improve component accessibility and response speed
- Consolidate all previous design system information into one source
- Use cohesive visuals, component demonstrations, and mockups to support the documentation text
Competitor research
In order to gain an understanding of design system best practices, I studied some of the most reputable public design systems online (Material, Carbon, Mailchimp, Atlassian, Salesforce, and Shopify). My goals in studying other design systems were to decipher the general structure of design systems and to understand what types of information are usually explained with visuals. I consolidated my findings within a Miro board and presented my findings to the project lead.
.png)
After presenting the research, the project lead and I decided to use these types of visuals to depict specific aspects of component documents: Component anatomy, to explain component structure; component behavior, to demonstrate how the component functions; do's & don'ts, to specify content guidelines; and component states, to demonstrate component functions. I was given total control over how the visuals were created, stored, and represented.
Catering to users
Mosaic's main audiences are Sovos designers and developers. Both users have different goals and pain points when navigating design systems. When building Mosaic, we discussed the best ways to display information so that both audiences were satisfied.
After identifying user pain points and goals, we decided to separate the component information between two tabs: an "overview" and "demo" tab. Underneath the "overview" tab is information for designers and "demo" holds information for developers. We made sure to use developer lingo throughout the document to make sure all class and property names stays consistent among teams.
.png)
Process
Building for change
A (proper) design system continues to evolve and change after its publication. Knowing this, there was a huge emphasis on making sure Mosaic was structured to anticipate change.
The component demos provided in both the "overview" and "demo" tabs are directly attached to their Storybook stories. If any changes are made in a story they automatically transfer over into the component's document. And, if any visuals need to be modified, all component visuals are stored under Sovos' Figma organization.
Consolidating existing documentation
Sovos' previous design systems were hosted on multiple platforms (Confluence, Storybook, and other API sources). Because of the multiple locations, users spent copious amounts of time searching through all the platforms to find desired information. And, in some cases, the information on these platforms contradicted each other.
In order to help users quickly find their desired information, document information is organized from most basic to complex-- starting with basic component summary, then component behavior, then interaction guidelines. If needed, this structure can be rearranged or modified to fit any component's needs.
.png)
After establishing each component's document structure, I began adding existing documentation into the Mosaic documents. Since the previous design system information was commonly inaccurate or incomplete (or the component had been recently modified), I scheduled consistent meetings with developers to ensure the code and/or properties of components were accurate.
Once all existing information was synthesized, I worked with developers to fill in any other information needed.
Creating component visuals
Each type of visual communicates a specific theme or aspect of a component. The Do's & Don'ts explain content guidelines and usage. Component mockups explain component behavior that relies on its surrounding context. Anatomy visuals explain the component's structure, and state and behavior visuals showcase the component's different uses, states, and contexts.
Conclusion
The published system
While the design system will continue to expand and change, a large portion of Mosaic components are documented for immediate use. You can view the Mosaic design system here.
.svg){kind=icon}