Lessons from LEGO: how a design system sets the building blocks for product success

If you’ve ever worked at a startup, you know that things are constantly changing: you have to be quick to iterate and experiment to build the best product possible for your end users. We run with new ideas, learn from the results, and try again if it doesn’t work.

I’m on a team that is trying to solve a seriously tough problem — improving access to mental healthcare. In my two years as an engineer at Quartet, I’ve worked on four different teams and many projects focused on putting together the different pieces of this puzzle. For me, knowing that I’m helping people in need makes these tasks rewarding, and having new challenges to tackle all the time keeps it engaging.

Tackling such a complex problem, especially in a startup setting, necessitates rapid development — and that comes with challenges. For us, this resulted in the proliferation of one-off components and custom styling. Despite our early adoption of a component library, our code base was becoming difficult to maintain: for example, tasked with replacing a loading spinner with an updated design, a developer had to hunt down all the separate instances and handle each individually. A simple task turned into a day-long effort — time that could have been better spent in other ways. We quickly began to realize that a cohesive, organized approach to design would ultimately save us time.

Enter Ole: Quartet’s design system, named for Ole Kirk Christiansen, founder of the The LEGO Group, and inspired by the metaphor of LEGO building blocks. This custom design system is the combination of a living style guide, based on the concepts in Brad Frost’s Atomic Design, and a new design language that is shared between designers and engineers.

We saw that pausing to develop and document our own design system allowed us to continue to move quickly towards our goal without racking up the tech debt. It meant we were equipped to build a consistent and beautiful experience for our users — while freeing up our product and engineering teams to focus on impactful work.

You know how it goes — we’re all super busy in the startup world. How do you make this happen?

Invest in building blocks. First, we shifted our mindset to embrace foundational building blocks as necessary for progress. As the engineer leading this effort, I was responsible for bringing the new brand look and feel to our web apps and bringing organization and standards to our UI code. I began by updating our existing color variables to the new brand colors and added variables for font sizes, line heights, spacing, and layer types.

Get organized. Each variable is named in a logical way that points to its use and will make updating these values in the future easy. Font sizes are named caption, body, and h1 through h5, and layer types include variables like base, flat, or raised. Having a common language made a difference immediately: “What color is that now? Grey-30? Let’s go with grey-20 instead, and grey-30 for the hover.” Nice.

Next I moved on to our component library, beginning with atoms like Label before moving on to molecules like InputField. For each component, passed properties control variations. The Heading atom takes a size property which determines if it is an h1, h2, etc., and the component renders the font size accordingly. Buttons can be standard, secondary, or outlined, each with its own hover and disabled states. We use styled-components, so the CSS lives with the component’s JSX, making it easy to find where a style is defined.

Clean up your act. Next up was cleaning up our main repo, home to both our apps for clinicians and patients. I found all the places where we had added styles on top of the common library styles and stripped out the customizations. Sometimes engineers had opted to write their own styles from scratch rather than use the common components; I replaced many a styled anchor tag with our Anchor atom. I also removed hard-coded pixel values for font sizes, padding, and margin, replacing them with our new variables.

Make it beautiful. From a visual perspective, perhaps the most rewarding part was updating the layer styles throughout the app. I could replace several lines of CSS — border, background color, box shadow, border radius — with a single layer variable, and with the new styles, the result was an airier, more beautiful UI.

So we cleaned up our code, built out Ole — has it paid off?

Short answer: YES! Just a few months in, we’re already seeing the benefits: increased speed, fewer decisions in designing each new UI, and common language improving communication and efficiency between product designers and developers. As we continue to design and build, clear guidelines in Ole will make it easier for engineers to fill in the gaps in designs so not every state of an interface needs a mock. On smaller feature enhancements, we can minimize design input without compromising the overall polish of the product.

As we build across platforms, Ole will continue to give us consistency, predictable user interfaces, and a unified visual experience — so our users have the best possible experience with Quartet’s platform. That’s not to say our work is done: the beauty of a design system is that it allows for evolution as we build. We’ll continue to collaboratively make the design system even more useful — because it benefits all of us.