Building a Design System from scratch

The UX team at RunSignup has been building out a design system for the past year. It will help us save time, and build more consistent products. Here’s what we’ve been up to:

Design System? Huh?

For the non-UXers out there, a design system is a collection of reusable components and guidelines that help ensure consistency and quality. Here’s a screenshot of our design system:

Our design system features a simple UI that lists all of our components, grouped by type. It also has an excellent search, just like our dashboards, to allow someone to get right to the component they need, if they know the name of it. The component screens themselves each have a working demo, explanation of the code they need to run it, and some explanation of when to use this component, and notes regarding configuration options.

This offers our developers a simple place to get ready-to-use components for the projects they are working on. These components have been designed, built, tested and approved by both our UX team and our Development team.

We take inspiration from many impressive design systems from other companies. Here are a few of our favorites: 

The amount of consideration put into these systems is truly amazing. 

How a Design System helps development

It speeds things up for us. Here’s a simple example. A developer needs tabs for the project they are working on. Prior to the design system, finding the code you need could be tricky. A developer would have to find an example of the component you want to use in the UI. We have over 300 distinct screens to go through. You then have to locate that instance of the component in the php templates. You then have to find the appropriate styles in the stylesheets. There might be multiple variants of tabs that different people have created. 

The design system simplifies that process for the developers. We have standardized our tabs, so there is only one style. If they need tabs, they go to the design system, search for tabs, grab the copy and paste code, and it works out of the box. Simple. The developer knows these are the official tabs we use. These tabs have been vetted by the UX and Dev teams.

Each component will be improved over time. We will improve the visual design, interaction design, accessibility, and layout responsiveness (for big and small screens) on these components.

How a Design System helps product design

Consistency and Efficiency. When designing new UI, we are now asking ourselves more healthy questions, like “Do we have a component that handles this?”, “Are we thinking about this generically?”, “Does this justify being a new a component?”,  and “Can we standardize this?”

By debating the need for new components, and moving toward standardization, we being to create interfaces that are more consistent. 

Here is a simple example, using our “plank” component. Here is the plank component being used in the race dashboard:

The plank is a simple component used to group configuration data on an entity. It also offers a delete action. There could be a number of ways to design this, but this is our currently recommended solution for adding and deleting items to a list with very few data points.

Here is a new screen we are working on, and it also uses the plank component:

This second screen could have been designed a variety of different ways. We opted to use the plank component to gain consistency. Users have seen this component before, and they are familiar with it. This consistency makes our users more efficient. There are fewer things to learn on this screen, reducing their cognitive load.

We are designing these new components atomically, meaning our components are comprised of other components. Think of it as a lego kit for us to build our products with:

Just like the simple lego plane above, we can combine our building blocks to build more complex components:

This atomic approach furthers our consistency and build quality.

Building our Design System on our own platform

There are many tools to help teams manage their design systems. We’ve opted to code our design system from scratch. Our design system run son the same codebase as our products. Doing this allows our component demos to run using actual production level code, so there is no unexpected difference in functionality from the design system to our actual products. 

Incorporating our Design System into our tools

We have visual representations of our components built into the design tools we use, like Sketch and Adobe XD. When we are mocking up new screens, we pull in the accordion component from a library, instead of redrawing it, or copying it from another file. This speeds up the design process exponentially, and creates consistency across mockups created by different designers.


Overall, we have a long way to go. Our design system is not nearly as mature and polished as the examples above like MailChimp and Material Design, but we admire them, and aspire to be like them one day. Like everything we do, we are committed to improving, iteratively, over time. By improving our design system, we will be improving our products, by becoming more consistent, and creating efficiencies for our customers and developers. 

Our design system has already helped us speed up our design and development efforts. It has moved us away from screen design, and into system design. This is a healthier, more sustainable design methodology. For a small team of designers, we’re proud our fledgling design system, and we are excited about watching it mature into a more and more comprehensive system.

Leave a Reply

Leave a Reply