Clearco CASE STUDY
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)
Team
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.
Colour Usage Guidelines — Each colour in our palette was selected with an intended use case. Each level was tested for contrast ratio compliance.
Components
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 — 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 — A date selection drop-down menu with a calendar view.
Data Table — A simple table style with a subtle hover effect and pagination.
Documentation
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.
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.