Snorkel Design System

Overview

Industry Dive is a business-to-business media company publishing high quality journalism in niche industries. I helped standardize our publication websites by defining and creating a design system. This project included restructuring our HTML/SCSS, designing granular system components and documenting component usage guidelines.

Role and responsibilities

  • Product Designer @ Industry Dive
  • Design Systems, Design Ops, Documentation, Front-end development
  • May 2019

In the fall of 2018, Industry Dive began its organizational transition from hybrid front-end designers and backend developers to two scrum teams comprised of product designers and full-stack engineers.

With this transition came a number of issues:

  1. The engineering team was creating multiple, differing versions of common components.
  2. Product designers spent significant time on-boarding engineers to the front-end codebase due to its complexity.
  3. Product designers were not thinking globally when creating UI mockups.

To address these issues I helped build a maintainable design system for our publication websites. The design system would resolve our process inefficiencies and provide a single source of truth for use across teams. Myself and one other product designer owned this project from start to finish with the VP of Design overseeing the process. I assisted in every step of the project, leading development for half of the components and reviewing the others.

Getting Started

To kickstart the project, we made a list of UI components—e.g. alerts, buttons, etc.—that are often used throughout our publication websites. While design principles and guidelines are essential to a complete system, we focused on creating reusable UI components first. This way we could maximize the impact and practical value for Engineering.

After creating our minimum viable product (MVP) component list, we defined each component’s purpose—e.g. “Alert banners communicate key information, globally”—and determined if it was a stand-alone element (atom) or a group of smaller components (molecule). For our MVP we also included two main design building blocks: color and typography.

Our initial list of components:

  • Alerts (atom)
  • Buttons (atom)
  • Feeds (molecule)
  • Form elements (atom)
  • Labels (atom)
  • Messages (atom)
  • Sidebar boxes (molecule)
  • Typography (utilities)
  • Color (utilities)

Auditing our components

Before creating a system with our components, we needed to audit their design and functionality on our publication sites.

Our approach was comprehensive; we printed out every unique website page template that used an MVP component and taped the pages to a wall. We then sorted the pages into categories based on intended function—e.g. soft, medium, and loud calls-to-action. We saw design discrepancies across our categories. Using these buckets, we defined design guidelines and rules for component variations.

Sorting the site
The wall with button pages sorted by intended function

Implementing the system

After the component audit, it was time to design and code the actual system. The design system is only helpful if it is accessible to all team members working on the product. We needed to ensure that the design tools and engineering resources all aligned with the new specifications.

There were three phases to standardizing our system:

  1. Technical implementation: Refactor the relevant code on our live publication sites
  2. Sketch library: Create a Sketch UI component library for designers
  3. Design system site: Implement an internal design system site for Engineering to reference

1. Technical implementation

Following our live site audit, we began to refactor the relevant production code. This involved updating SCSS class names and removing page-specific styling. As part of the refactoring, we modified our SASS partials to be consistent with our new components. After lots of debate, we decided on a BEM approach. This entailed naming classes based on the component (block) and appending “–” for modifiers and “__” for elements. After defining the style naming conventions, we applied them to the relevant components. We also deleted any page-specific styling that was being applied to the components. In the end, we eliminated a lot of code, made styes global in scope, and created a cohesive set of design patterns.

2. Sketch library

After implementing the design system in the production codebase, we created resources for our product designers. We use Sketch for mockup creation, so I created Sketch libraries to share components across the design team. Sketch libraries allow designers to grab a component—e.g. button—with a predefined style and use it across files. This ensures consistent UI and negates the need to recreate the same components with each mockup.

Atomic elements in Sketch
Atomic elements in Sketch

3. Design system site

After the completion of the design audit and Sketch library, we created a website with the code of our UI components and corresponding usage guidelines. The site serves as a single source of truth for engineers, designers and all other internal employees.

The creation of the design system has empowered product designers to rapidly design product interfaces and enabled engineers to implement efficiently.

Next »