Sovos Logo

Sovos' Mosaic Design System

UX Design | Design System

Contributed to Sovos’ newest design system and added component demonstrations to documentation.

I worked on this project for three months during my UX internship. I served as a copy editor, UX designer, and content contributor.

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:

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.

Screenshot of this project's competitor research
Sample of competitor research

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.

Screenshot of the project's proto personas
Developer and designer personas used to identify goals and pain points

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.

Annotated screenshot of Mosaic's components page
An example of the different demos for designers and developers. Both interactive demos are linked to the same Storybook story


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.

Annotated screenshot of the stepper component
The Stepper document, annotated to show the document's structure

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.

Screenshot of a status section of the Mosaic documentation
A Do's & Don'ts section explaining the guidelines for a table row's status
Screenshot of a usage section of the Mosaic documentation
Two UI mockups explaining the interaction between the toolbar and the date range picker


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.

Return to Work ->Arrow