What Is a Design System?

If you look it up in a dictionary, the definition of “design system” is quite straightforward. It’s a series of elements that can be re-used in different combinations, to make it easier to manage design at scale. To make it more understandable, think of  LEGO bricks.

There are more than 915 million possible combinations for six 2 x 4 LEGO bricks of the same color. 

A LEGO set contains bricks, plates, studs, tiles, and tiny human figurines. And you can re-use LEGO sets to build an unlimited variety of things. 

At Starred, we did precisely the same thing you’d do when playing with LEGO sets, but with our design system: we created our own bricks, that we could re-use for different projects. These bricks generate a variety of structures that look like they’re part of the same family.  We called this family Polestar. 

Logo of Starred Polestar Design System

Why Did We Build Our Own Design System?

We started working on our design system mainly because of four reasons:

  1. We are scaling up
  2. We needed consistency
  3. We needed to improve our teamwork
  4. Efficiency

We are scaling up

We want to continue growing as an organization and deliver a better product to more clients. One of the success factors for this is to have an effective design patterns’ repository: something that our co-workers from other locations can easily access, comment on, modify, and use. Our design system provides all necessary information for our new team members, too, so to make their onboarding easier and more efficient. 

We Needed Consistency

Consistency is a big issue when working on a large-scale product.
We want to improve the user experience with every new iteration. We continuously test new solutions and usage of patterns. As a result, there are always some pages with a legacy design on the platform. With the Polestar design system, we can minimize them because if we update one component, all of its copies automatically change.  The parts can be UI assets, behavioral patterns, or voice and tone snippets. Thanks to Polestar, we can now deliver cohesive, consistent user experiences, and our users started to learn and master the product faster.

We Needed to Improve Our Teamwork

Building a design system empowered our team to focus on people — not pixels.
The design team prepares the documentation that’s understandable and exhaustive for our developers. The documentation is also aligned with other departments. Our development team makes the components “in code”, which then become an integral part of the Polestar design system. 

QA tests are easier to perform because of the repetitive and more predictable patterns. We talk to each other much more often and give each other constructive feedback.  As a result, the whole process is more straightforward and meaningful for every participant.  

Efficiency

Our ambition is always to work more efficiently so that we can test more design solutions and deliver updates more often to our clients.  But efficiency doesn’t mean giving up on quality. Polestar allows us to prepare more iterations much faster, without the initial “carte blanche dilemma”: instead of trying to reinvent the wheel every time, we can re-use pre-existing design components. Every component you see on our platform is a copy of a “master component”. If, for example, we were to change the size of the font everywhere, we could adjust the master component, and everything would magically be aligned. 

The relation between time and effort in traditional design to development process vs. using the design system

Setting Up the Foundations

During one of the first meetings, we decided that we wanted to start building our design system organically, focusing on the low-hanging fruits, and developing it further when necessary. Before we started working on new components, we had investigated what we already had on our platform. We made a UI survey, and we mapped all the different components used at Starred. We made hundreds of screenshots in order to capture all elements, from buttons and text styles to various iterations of headings, blocks, or warning messages.

UI Survey. We mapped all the UI elements used on our platform to catch inconsistencies and duplicates. On this example, you can see all the different styles of icons we used to have.

With this exercise, we learned which elements we used the most and which ones were the most inconsistent. We noticed that the most important thing for us was to establish some principles on user experience patterns, set up the guidelines, and start building our own UI kit.

Grid

We wanted to utilize all possible screen sizes, since 60% of our feedback forms are opened on mobile devices, and that’s why we adopted the standard Bootstrap grid and adjusted it to our needs. 

We provide different grid types for different device categories to utilize the whole screen.

Colors

One of our ambitions was to introduce color consistency. Instead of reinventing every color ad-hoc, we came up with the idea of having a matrix of colors based on dominant shades. We then diluted the colors into ten separate tones for more design flexibility.

These are the colors we use at Starred. Instead of naming each color individually, we gathered them in groups that can be associated with different user activities: ink colors are used to display text, primary colors are used as dominant colors in our platform, and our greens, oranges, and reds are used for error and information messages. 

Paddings

We use consistent paddings and spacing throughout the platform, based on the multiplication of 8px. It’s easier to design similar patterns for the users by keeping everything always in the same ratio. Moreover, they look well, both on a high-pixel-density and standard displays.

Every component in the Polestar design system comes with construction principles, such as distances and alignments. 

Building the Components

Building the components was one of the most time-consuming and challenging feats we faced during the creation of the design system.

In fact, the beginning of such a process is always the easiest, because you simply replicate the components you already have, and know when and how to use them, but the tricky part comes when you have to design something new and put it into the design system. We start with the research and check if the pattern we want to develop is promising. Does it remove difficulties on the way of users to their goals?

Starred Design to Development process loop

We always put the design prototype to the test in its early phase and ask for real feedback from the clients. When they give us satisfactory results, we start working on the design.

This heatmap was the result of our initial tests, during which we wanted to check if our new card component drew our users’ attention to the right areas.

In our design documentation, we try to be precise and cover the edge cases upfront.  We also align with the front end developers to decide on the names of the components.  

The design documentation of searchable dropdown with the results displayed in the categories. 
The design is not just how something looks like, but also how it works. That’s why we include the behavioral description in our documentation.
… And animation when it’s necessary!

After that phase, the design is aligned internally with the relevant teams and pass to front end engineer to be coded and save in the design system. 

Design of a primary button and its representation in code
Polestar quickly became quite a project at Starred.

The New Visual Direction

The first part of the platform that we changed into the Polestar design was Template Gallery.  We received a lot of positive feedback from our users, and we noticed that they started to use the page much more often. Right now, we are busy with the implementation of Polestar principles to Starred Connect: our integrations’ hub, where users can connect Starred to external applications. 

The old design of the Template Gallery vs. Polestar Design
100% of the interviewed users saw the value of introducing the Polestar design system. 

The Values of “Work Smarter” & “Building Together”

Our values. Polestar is a significant improvement in working smarter and building together.

Before Polestar, our team didn’t have one repository of design objects to use. Our designers didn’t know which components already existed, and where to find them if they wanted to use them for their work. We tried to use the best practices and patterns to provide the best output, but it was challenging. We always used the working product as a reference, but it was inconsistent. Polestar changed all that.

If someone asked me to compare how I was working one year ago with my current routine, I would answer that I spend less time on unnecessary tasks and I’m much more productive. With the design system, we are at last able to work in a quicker way and deliver value to the clients faster and more often.  All the details have already been decided upon, and they are saved in Polestar. The product development team is finally focused on solving real client problems, rather than shifting pixels.