Clearco Design System

When I first joined Clearco, we didn't have a design system. Designers worked in silos, prioritizing speed over quality and consistency. Over time, this added to an ever-compounding front-end debt problem.

This case study is currently still a work in progress. If you had any questions, please get in touch!

My Role
Lead Designer (Roadmapping, UI Design, Design Ops)

Jen de Vera, Senior Product Designer
Michael Chiu, Senior Visual Designer
Nate Devey, Engineer

The Wild Wild West

Complete and unfettered freedom — this was the scene that I stepped into when I first joined Clearco. Though some might argue that design systems can stem a designer’s creativity, as our design team grew to more than just a handful of product designers, our old way of doing things was clearly no longer going to work.



(Above) What it felt like in the early days of Clearco. Wild, free, and void of any structure and order.

"If you want to go fast, go alone. If you want to go far, go together."

Each designer worked independently, prioritizing the speed and delivery of their own areas of the product over consistency. As the team and codebase grew, this became a bigger and bigger problem. It became apparent that we needed a better way to design and build, so I led a small team of designers and engineers towards a possible solution — a design system.

We called it the Clearco Design System, and with it, our goal was simple: achieving great design at scale.

The Foundations

We started with the basics. The web, when you break it down, is just an amalgam of texts and colours. With that in mind, we were careful to establish typography and a colour palette that was intuitive, adaptable, and accessible.


UI Colour Palette — Functional colours were added to our brand palette to give designers the ability to convey important feedback to users.


color usage

Colour Usage Guidelines — Each colour in our palette was selected with an intended use case. Each level was tested for contrast ratio compliance.


We started by running an audit of our existing UI and figuring out what components were most frequently used. This helped us prioritize our components roadmap, starting with buttons and form fields.


Buttons! — The most frequently used UI components. We built out many variants of our button styles to accommodate multiple use cases.

forms and buttons

Forms and Buttons — These two components were the most heavily used elements in our UI. Getting them to jive well together was an important consideration.


Dialogue Modal — A more complex component that utilizes a combination of multiple components and atoms.

date picker

Date Picker — A date selection drop-down menu with a calendar view.

data table

Data Table — A simple table style with a subtle hover effect and pagination.


Creating a space for component guidelines and other documentation was incredibly important. Education was a fundamental part of implementing a design system that could be adopted.

Component Specs

Inline Notification Documentation — Each component guideline details the anatomy of the component along with any functional variants and customization parameters.


UI Testing — We back-tested key screens in our product to ensure that global styles and components can be easily refactored.