The Goal

Andrews McMeel Universal launched The Puzzle Society, an online gaming website, in 2021. What started as an MVP model quickly grew to a product that required rapid enhancements for users. 

As the website grew, so did the need for internal structure and organization. My team needed a style guide and component library to act as the source of truth for ongoing projects in order to keep the team united. In developing this design system, I aimed to bridge the gap between designers and developers, making it easier to collaborate and make enhancements to the product. 

The goal of this project was to create and maintain a design system for the Puzzle Society brand. The work included buttons, typography, colors, UI, header and footer styles, iconography, and more.

The Solution

We wanted to lay the groundwork for future versions and get all existing experiences properly documented. For this reason, we started by componentizing all existing pages using the atomic design framework.

We began by auditing all the font styles and colors and other atom-level components and standardized those components in AdobeXD. For example, we had previously been using an inconsistent combination of Title Case and Uppercase font styles for our primary and secondary buttons. In our audit, we decided to eliminate the Title Case font style entirely and replace it with the Uppercase font style.

With the atomic design approach, we continued to standardize the organization of atomic components into organisms. We plan on eventually turning those organisms into templates and pages. Below is an example of how we componentized our mobile navigation drawer.

This style system will continue to evolve as the product changes over time. Once all of our elements are componentized it will be much easier to make small and large scale changes and pass off design changes to the development team.

Below is a birds eye snapshot of select style system components.

Takeaways

My initial style system iteration was seamless. It was well-organized, incorporated all of our site styles, spacing, layout, etc. And then I presented it to the development team. After talking with the team I learned that instead of presenting a polished design system for them to review, what I really should have done was collaborate with a member of the development team throughout the entirety of the process. While developing the site, certain design rules for components had changed as the developers found more streamlined ways of building the components. Although my initial work was by no means wasted, I had to backtrack and redo specs and design rules based on how the components currently functioned on the site.

Bringing in the development team not only benefited design, but engineering as well. In doing so, it ensured that our experiences had a consistent look and feel, not just in our design specs, but in production as well. It helped to unite all teams across the company around common components and a common language so that we spent less time talking about the actual design system and more time solving problems.

Illustration by: Terry Elkins