How to Build Design Systems From Scratch?

As applications evolve, organizations not only have to invest in technology and people, but also uphold their visual integrity. This will help users recognize the brand they’re interacting with across different touchpoints and navigate between them more easily.

In this article, I present a walkthrough of the steps I’ve taken when building a design system from scratch. I contextualize this process within my experience of developing a design system for Radar, an internal Netguru platform. I also offer key lessons I’ve learned throughout the journey, which I hope will be useful for designers and product owners looking to create their own design systems.

First, allow me to cover some basics.

What is a Design System?

A design system is a toolbox of components and standards to create and scale applications. It helps streamline processes through consistency in visual elements and design practices. Design systemslay out the principles, rules, and constraints on how visual elements should be used. They also contain the corresponding reusable code for visual elements, which speeds up the implementation.

What should a design system include?

It's critical to understand that a design system is much more than a style guide or pattern library developed for a specific project. It should be a dynamic product that evolves with the organization and development of the digital platforms. It functions as a reference point among the designers and developers.

A design system is typically created from scratch and unique to the needs of the business (and the platform/s it serves). However, there are common elements among mature design systems. They include:

• Principles and guidelines: These are the foundational directives when it comes to product design. They cover areas such as UX/UI standards, accessibility compliance, how to handle animation, and rules on scaling, among others.
• Pattern library: This part of the design system is made up of reusable components, color tokens, page templates, reference files, and many other visual artifacts. For those familiar with the atomic design methodology, pattern libraries would encompass how atoms, molecules, organisms, templates, and pages should be deployed.
• Code: These are the corresponding code snippets that implement components in the pattern library. Developers pull this code into the platform they’re working on from a central repository. It should also include coding standards, guidelines on versioning, supported platforms, and other relevant technical information.
• Branding: This part of the documentation is the closest to conventional style guides. It covers aspects of brand identity, particularly rules for using the logo, colors, and typography. It could also include publishing guidelines covering the brand voice, grammar, and formatting preferences.

Why build design systems?

Businesses need to build and maintain design systems for two primary benefits: consistency and efficiency.

• Consistency: By having a design system, project teams can minimize usability problems and maintain consistency in the user experience. A design system establishes an agreement to employ repeatable visual (and non-visual) qualities. A coherent user experience ultimately benefits users to more easily recognize brands and navigate through their digital platforms.
• Efficiency: Instead of creating elements and components from scratch, designers can draw from the design system when working on a user interface. Design and development teams can minimize mistakes and boost productivity by accessing reusable visual elements. This is also useful when a lot of people work on the same project, especially during handovers.

How did I build a design system?

I want to preface the process below by admitting that I don’t consider myself as an expert in design systems. I created this design system with the help of online resources and consultations with colleagues in Netguru, particularly our product designers. I’m quite certain that I’ve made mistakes and my work can still be improved. Nevertheless, I’ll be continuing to hone my craft, and I fully intend to elevate my skills in this domain.

Creating a design system for Radar

I’ll be going through the process I’ve taken in creating a design system for a specific project – Radar. Radar is a platform used in Netguru for skills and experience verification, used particularly by our business development professionals, project managers, and other decision-makers. In my view, it’s one of our most valuable internal tools.

Radar informs Netguru employees about which skillsets, tools, techniques, and coding languages we have at our disposal. This is particularly useful when we submit proposals to prospective clients. For instance, our business development team uses it to know if we currently have access to specific technologies and expertise that a client would need.

Radar has gone through some iterations over the years, such as the introduction of a Graph View to supplement the Radar View (see image below). Our R&D team is planning to enhance and scale the product further in the near future.

A few Netguru colleagues thought that Radar needed a design system to help it scale easier. Because I wanted to learn more about design systems, I volunteered to take on the challenge to build my first design system from scratch.

Radar user interface (UI)

1. Preparation

Since this was my first time creating a design system, I sought guidance from our Design System Lead (Karina Graj) and other Netguru product designers. They briefed me on their own experiences in developing design systems. They also provided me with materials from past projects and online resources, including a course on design systems on Awwwards.

I continuously consulted with our Design System Lead, who mentored me throughout this design system project.

2. UI audit

Radar was already an existing product and there were already designs in Figma accessible to everyone in Netguru. I went through the designs and took screenshots of elements that needed to be grouped into components.

As you can see from the image below, I grouped these screenshots into categories such as clickable elements, modals, cards, and so on. This was to construct an overview of the product and the work I needed to do.

Audit of the Radar UI to map all components which needed to be made

3. Design fundamentals

Having done that, I set up the design fundamentals. I established typography styles and a color palette based on three color groups: green, navy, and semantics.

Typography, color palette, and tokens in the Radar design system

4. Collect existing components from the UI

Based on the UI and design audit, I collected all of the elements from the UI that needed to be made into reusable components.

5. Apply design fundamentals to collected components

Then, I applied the newly made typography styles and color palette to all the components I had collected. In doing this, I made sure to comply with the accessibility standards we observe in Netguru.

6. Improve components

I thought that the elements still needed to be improved. Hence, I worked on them by applying auto-layouts, making border radiuses consistent, ensuring consistent spacing, and so on.

7. Add new components

Since design systems also need to take into account prospective iterations of the product, I did some research on components and features that might be needed in the future. I added and created these new components to the design system.

8. Accessibility audit

Even having checked the contrast ratios throughout the whole process so far, I wanted to make sure it was all correct. I made sure that the design system meets accessibility requirements. For example, I double-checked if all states of clickable elements were correct.

Contrast ratios for accessibility

9. Apply design system components

Upon ensuring that all collected and new components were ready to be used, I uploaded the design system library and applied them to the existing UIs.

10. Engage the frontend team

Throughout the process, I stayed in touch with the Radar frontend team so that they understood my work on establishing this new design system for the platform. We went over component naming, token use, and other areas they needed to be aware of. Since the frontend designers and developers will actually be the ones who will implement the design system, it was important to solicit their input.

11. Color tokens

Setting up color tokens might have been the most complicated and time-consuming step for me in this entire process. I understood the concept of variables for developers, but it wasn’t easy to wrap my head around the concept of tokens. Learning about this through online tutorials and consultations with the Netguru Design System Lead helped me a lot here.

I went through all components one by one to see which color tokens I needed. Then, I created those swatches, added them to the color styles in Figma, and applied them to the components.

It’s important to reiterate that there was a lot of back and forth with the developers on this. We went through several issues such as missing tokens. I also thought that we could have been more consistent with the naming. I can appreciate now that it’s important for the frontend developers to sign off on the tokens because they will use them extensively (e.g., variables in the code).

Color tokens for Radar

12. Green light for development

As soon as the design system and tokens were ready, the developers could start using them. Based on recommendations from colleagues, we used Storybook, a tool for both developers and designers.

Developers use it to test components separately in an isolated environment. At the same time, designers (and even QA specialists) can use Storybook to see if the work done by the developers on the components is consistent with the design system.

Storybook

13. Documentation

Any designer can make a design system, but it will be useless if no one knows how to use it. This is why documenting the design system is essential.

I drafted documentation for each component section with general instructions. In addition, I created a change log for users to see what’s new, what’s changed, and so on.

Radar design system documentation

What I learned building a design system from scratch

At the beginning of this process, I knew almost nothing about design systems and I wanted to do everything as perfectly as possible. However, I’ve come to appreciate that this might hurt the learning process.

When embarking on a new topic, do your best, expect to make mistakes, and learn while doing. You can’t be expected to do everything perfectly when you are doing something for the first time. It’s in making mistakes that you will learn the most.

For those about to build a design system from scratch, I want to share with you the most important things I’ve learned.

• Feel free to start building your knowledge from online resources, articles, videos, and any other materials you can get your hands on.
• However, to accelerate your learning curve, it would be ideal to consult with or be mentored by someone who has had actual experience in design systems. If possible, keep in touch with them to assess your work and ideas. For this, I am grateful to Karin Graj, our Design System Lead at Netguru.
• When you have enough substance in your design system, have it used by other designers in real time for them to provide immediate feedback. This will improve both the design system and the platform it serves.
• Align with the relevant developers throughout the process as they will use your design system extensively.
• Think deeply about which components might be needed in the future. While no one can be absolutely certain about future requirements, make your design system as future-proof as possible.
• Put in serious effort when it comes to enhancing UX and UI components. Do it early in the process. These will be the building blocks for an entire UI. Focusing on them later on might cost you more time.
• I highly recommend that you use color tokens in your design systems. This is particularly useful when the design system needs to be used either for a design overhaul or for multiple brands. Remember that a color token can be applied to multiple components. Hence, it enables designers to change the colors of multiple components simply by changing just one token. This makes the design work faster and more efficient compared to having to change the colors of each component individually.
• Use icon wrappers. Instead of having multiple sizes manually for each icon, it’s much easier to have an icon wrapper component. You can import icons from an external file, and then change the size of the icon wrapper to determine the size of the icon.
• Include all states for clickable elements. Always keep this in mind.
• Component properties are a huge time saver compared to having a thousand variants for each component in the past.
• As you progress in your journey, join design system communities (online or offline) to elevate your expertise.

At the beginning of this process, I wondered how long it might take to develop a design system. For this specific project, it took me around three and a half months to deliver the current design system documentation we use now for Radar.

Take note, however, that building this design system wasn’t the entirety of my work throughout this period. I probably spent one and a half months working on it on a full-time basis, and another two months working on it as 50% of my workload.

I want to emphasize that building a design system from scratch is one thing, maintaining and improving it is another. In my view, there’s no such thing as a finished design system – only iterations. It's always a work in progress because products evolve.

Leveraging design systems to scale

Developing and maintaining a design system will require time and resources. However, leveraging a design system can speed up delivery as project teams can readily draw from reusable elements. Furthermore, design systems enable developers and designers to provide a cohesive look and feel across user touchpoints. I believe this can strengthen the relationship between the customer and the brand.

When building a design system from scratch, as you can infer from my own experience, there’s no such thing as a one-size-fits-all approach. There are critical areas to cover based on best practices, but it will ultimately have to meet the specific needs of a business.

That said, companies can definitely benefit from engaging a partner with a wealth of experience in creating design systems. They can facilitate the conversation among stakeholders, identify key elements to include in your design system documentation, and accelerate the learning process for your teams.