GoodHire's Design System

Launch GoodHire's first design system with Styleguides and UI Components.

BACKGROUND

Timeline

Jan 2019 - Now

My Role

I helped define and design the Styleguide and components of our design system. I’m working with the front-end engineering lead on launching the design system.

Tools

Sketch App, Abstract App, Storybook, Zeroheight

Project Background

GoodHire has been growing rapidly over the past years. Along with that, many teams working on different parts of the product created inconsistencies over time, resulting in disjointed user experience. When I joined GoodHire, the design team just moved from Photoshop to Sketch. As we were scrambling to produce mocks within Sketch, I noticed there were little to no rules on UI components for reference. Meanwhile, our engineering team shares our passion for creating a UI component library to help optimize workflow. Therefore, We started our journey together to create GoodHire’s first design system. 

Why Design System?

Design and develop faster with reusable UI components

The design system enables the design team to rapidly prototype and experiment with ideas in high fidelity and the dev team to build faster with reusable code. 

Ship a better product with a consistent user experience

Presenting customers with an intuitive and unified design throughout the product experience fosters trust in users and helps with retention.

The Timing was Right

We didn’t start from scratch. The team attempted to build a design system before, but it was not successful because the rules were not followed. Now the team finally found a good timing to make another effort to build our design system.

 

Our stakeholders involve higher-management, front-end developers, and marketing designer. They were supportive because the timing was right. From the design team’s perspective, we just moved from Photoshop to Sketch so everything needed to be redesigned in Sketch. The marketing designer was in favor of the plan because the old style guides were hosted on a site we were moving away from. In addition, our front-end engineering lead was excited about building reusable UI libraries to increase speed. Last but not least, our higher-management gradually understood the importance of building a design system with multiple demo sessions.

Fill the Gap

A common misconception people held within the company is that the design system is solely a static styleguide, including color, typography, and so on. The design system is far more than that. A design system also includes repositories of reusable UI components with well-defined rules and interactions.

 

I broke down a page in our main flow to illustrate to the company what UI components are, and how they function like lego block to assemble an interface with a set of guidelines. 

Getting Buy-in

Building the System

I started with the iterative approach and focused on small areas of the product at a time, gradually working our way through the whole product - designing, building, and documenting a design system as we go. The progress can be slow, but it brings small wins that show the value of the design system. 

 

The first step was to consolidate our color, typography, grid, and spacing. Once the foundation was laid, we moved to build our global small components and templates. 

The graph shows our process of designing, building, and documenting each component, with tools we identified would serve our needs best. 

On the design side, I use the Abstract App to manage the design system library. When I complete the design for a defined component, I put it into a separate collection for technical handoff. Our developer will then implement the component within the Storybook. Lastly, both teams will document on Zeroheight, our design system site that serves as the central hub for design and code.

The design library and design documentation on Abstract App

Sample for Foundations

Sample Components

Templates

Measure Success

Clear Documentation to Align Teams

We learned from our past failure that a successful design system needs rules that are clear and easy to follow. We also need to foster co-ownership of the design system between designers and developers because the design system needs to be built both in design and code. We believe the design system will be successful when it serves as the single source of truth for both teams.

Increase Efficiency for Both Teams

The main benefit of the design system is to help speed up our work so we can ship faster. We made an effort to define whether the design system can help reduce story points required for feature development in the future, but the team found it hard to quantify reduced story points. Though we couldn’t figure out how much time has been saved, both teams found it very helpful that we can now quickly pull components from the library. Ultimately, the design system frees up teams to focus on solving real customer problems. 

Create a Better User Experience

Last but not least, having a successful system is also about seeing the outcomes of all that hard systematic work reveals itself in production applications and experiences that our customers use. With a more unified and predictable site experience, we will be able to better retain our customers.

MORE PROJECTS

© 2020   Designed by Lu