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.
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.
We started working on our design system mainly because of four reasons:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.