uzzle’s rapid product growth led to user experience inconsistencies across the product and internal confusion regarding intention of components.

What I found:

• Inconsistencies across the platform
• Divergent patterns
• Conflicting guidelines
• Duplication of components
• Long-drawn delivery due to underutilization of design systems capabilities

The foundations of Jigsaw supports the brand logo, spacing scale, typography, color system, icons, and interactive components.

It was important for the new design system to support a large number of colors and type, as our previous and limited design system meant we were often supporting custom styles in Figma and the codebase.

Each component, a collection of reusable interface elements, came in multiple variants to support different sizes, states, and color palettes. It was critical to define the differences between component classes so that design decisions are efficient and accurate based on the context of the page.

Patterns were created to show reusable component combinations that address common user objectives. Patterns were created after components had styles applied to them so that if something changed in the future, the styling and components would waterfall into patterns. While not every possible pattern was developed, this library served as the basis for our users most common objectives.

Time & resourcing

• Being at a startup means working with finite resources. What I saw as a huge opportunity for our team and our users was also a time commitment. I had to advocate for the design system as an investment, and I also had to sacrifice my own design time to build it when I was the only designer on staff.
• Solution: I started a daily one-hour virtual meeting called “Office hours” which I would dedicate to working on the design system. I opened up this hour to anyone to swing by and ask questions. Product managers and developers would stop by to ask questions about other matters, but this meant I could also get ad-hoc input on the system.

Documentation

• There are plenty of great documentation examples when it comes to design systems, but building reference libraries isn't in scope for our startup. However, we still needed some guiding principles on when to use styles and components.
• Solution: Directly in the design system, I provided different examples of when to use certain styles. I also identified common patterns across the site for future reference when building features. Each component came in several variants so designers could quickly swap states and color stories to provide realistic screens to developers.

Transitioning

• At the time the design system was built, we did have some variables. The existing colors and typography wasn’t robust enough for what we were building, however, which meant a lot of styling was being manually entered, even if it was used in multiple places.
• Solution: I took our existing variables and mapped them against the new design system to build a visual regression chart. This could help developers staffed on the project understand what needed to be added as new vs updated.