6 Steps for Building a Great Design System

“A design system is one of the most important strategic assets for your company. It is a living digital product that requires a team, a plan and a set of specialized tools.”[1]

— Brent Stewart, Senior Director Analyst, Gartner

We at Infragistics are also strong believers in the value of a design system. It changes the way companies innovate and speeds up the pace of app creation. We would also like to add that design systems are evolving and they are an investment that pays off in the future. However, many companies still overlook the benefits of a design system, which unfortunately results in behavioral and visual disruptions, brand discrepancies, poor usability, miscommunicated design standards, and other inconsistencies in the design process. Other times, there is the moment of failure that arises somewhere between the moment of building a design system and implementing it properly. Which again leads to the same setbacks mentioned above.

To help you deal with these challenges, we will dive into the how’s and what’s of architecting an effective design system and will also show you what goes into it and why you should use one.

The things you will learn by the end of this article:

• What is a Design System?
• Benefits and why use a Design System?
• How to build a Design System?
• Why choose Indigo.Design for your Design System?

If you’re already familiar with Design Systems, you can skip to the 6 Steps for Building a Design System right away.  If not, continue reading.

What Is a Design System?

There is this popular definition that a design system is a collection of design assets that you use to build user interfaces. But it is truly much more than a library of reusable UI components. Design Systems are handcrafted “design empowerments” that:

• Serve as a single source of truth for product teams.
• Tune in to a specific usage context and app domain.
• Work as an inventory of UX design patterns and brand style guidance.
• Speed up the design process and significantly improve consistency.

To us at Infragistics, consistency means remaining style and behavior-consistent across any design program, development IDE and everything that happens in-between. Taking consistency to a whole different level, our goal is to provide consistent tooling not only for designers who use different design programs with UI kits for Sketch, Adobe and very soon Figma but also for developers no matter what framework they prefer, such as Angular, Blazor, or something else. This way, the product development process culminates in a consistent experience for app users in the end.

The type of streamlined process and consistency we talk about can be achieved via automations, and through plugins that, for instance, let you apply an overarching theme to your design library all at once. It also means enabling innovative and much more efficient approaches to handling the designer-developer handoff, saving yourself the time and energy of trying to explain ideas or justify animations and micro-interactions that are usually not in the Sketch, Adobe XD and Figma files. 

Why Use a Design System – The Benefits and Its Value?

It's no surprise that companies like IBM, Atlassian, Salesforce.com, NASA, and more have implemented a design system paradigm to managing their design-to-development process. Building, using, and maintaining a design system leads to more coherent experiences because there is no need to rebuild components or patterns. Instead, designers and developers benefit from a unified inventory which:

• Fosters re-use and delivers flexible design assets, saving you time and efforts on designing them from scratch.
• Governs clear standards and brand compliance through consistent typography, colors, voice and tone.
• Reduces production defects as the UI controls are used at scale across teams and different projects.

We’ve already explored all the benefits of using a design system in our Comprehensive Guide. So, if you want to learn about its advantages, the value it brings, its anatomy, and some design system examples - there you will find it all.

How To Build a Good Design System in 6 Steps?

What constitutes a good design system then, well to put it simply something that is not a black box for design, but allows different integrations, comes in a form that is flexible for designer to integrate in their processes and DesignOps , while at the same time assuring, they design with the end user in mind, enabling various ways to collect feedback from stakeholders and making it effortless to run tests with actual users. And of course, a good design system is not costly to maintain, easy to evolve and has a clean and transparent design system architecture. 

Step 1 – Run an inventory

If you are getting started with building or using a third-party design system, the first step is to run an inventory of your products or wireframes. This will help you narrow down the components which are critical for your project as they will appear again and again from one screen to the next while you explore the product. With the inventory at hand, you can more easily understand how these pieces are produced from smaller elements - a button comes with a certain shape, a combination of colors and let’s not forget, the typeface of its label. What you will also understand as you dig deeper is that a button alone is nowhere near what you ultimately need and it has its special role in a menu navigation or a form that users must fill.  

Step 2 - Define the sub-atomic pieces

This takes us to step two which is defining the sub-atomic pieces or the underlying foundation for how things will look so they can shape a product that is consistent and pleasant to the eye.  Our experience with Indigo.Design led us to believe that the elements that fit into this category and that must be visible to the designer using the system are:

• Colors
• Typography
• Shadows
• Icons
• Visual graphics such as illustrations

However, there could be equally crucial but more subtly visible things like the layout grid size, which usually determines the padding sizes, and border radius for the rounding of components. As an example, if we use a 4px grid, our in-component paddings are likely to be 4px, 8px, 16px or combinations of them say 8px+16px=24px. As a result, this will define an 8px rounding of a button for example and a 24px margin between two adjacent buttons.

Step 3 – Narrow down the actual UI components

The third step includes the actual components that you have identified while making an inventory. Always start with the ones that can be seen most often in your product UI. These usually are buttons, icons, input fields as well as text paragraphs and images that are usually not shaped as components but exist as native elements. It is important to think about the different types of components such as whether an input field will be used for text input, entering a number, or even selecting a date. You may want to consider different styles, i.e., you may have 10 buttons on a page but there is usually one that is more prominent than the others – the CTA. 

Step 4 – Design validation states

You may think that the fourth step is building the UI patterns and layouts with these components, which would take us one step closer to designing the product screens. But no. Prior to that, we must go back to the components again.

One thing to remember is that a UI is never static. It flows for the user with response to the interactions he or she makes. A component that does not define a hover, focus or disabled state is as good as a glass hammer. Nevertheless, we cannot expect that our users are always on the right track either. Therefore, designing validation states and error messages is important at this middle stage of the design system architecture.

Furthermore, as you are creating the intricate content templates of the layout of a component, don’t forget to make sure it is:

• Fluid
• Behaving as expected when resized
• Responding properly to composing elements being moved and removed

All three design tools that we build Indigo.Design for —Sketch, Adobe XD and Figma —give more than a decent degree of smart/auto layouts. Once your conquest for smart components is complete, you will reap all the benefits applying the same strategy to the layout of your patterns. 

Step 5 – Build design patterns

Now the fifth step is building those patterns. Since this a rather straightforward process, I’d like to give you some examples for the UI patterns we have made in Indigo.Design. If you are building a product that plays media, you may find it useful to have a pre-built media player and volume control layouts. If you are building conversational UIs, chat and social feed patterns will come in handy. Moving towards a more formal context, you may need a variety of forms for a product in the insurance and compliance industry. And finally, almost any business will eventually need product detail pages, price comparison tables, an onboarding or a user profile.

The best thing about patterns is that you can build them as you go. A certain type of a form may initially exist in the design as it is used only in a single context. But as its usage in the product grows, it will naturally become a pattern that will be the single source of truth for all instances of that layout in the variety of contexts it is being used. 

Step 6 – Prepare design documentation

The final step is documenting your design system. The goal here is to have to reduce the effort on this as much as possible. If your design system architecture is stable and flexible enough, the number of things you will need to document will be minimal. So, we may jokingly say that the goal for the architecture is to write as little documentation as possible once the design system is complete. However, that does not exclude having a section with release notes in your UI kit file. Or having a section with onboarding examples and even online documentation providing design system examples with the do’s and don’ts when it comes to using and configuring components or rebranding the design system. To make things a bit simpler, all this can also be handled by leveraging a design system manager.

Another goal of the design system architecture is having to do as little maintenance as possible and expanding the scenarios a design system can cover by adding new components and patterns without breaking the existing ones. And since many consider three to be a lucky number, I will add a third goal for a successful design system architecture. That is when the new Head of Marketing or Design decides that the brand of a given company needs a complete revamp. Well, the design system can streamline the redesign, adapting to it in a matter of minutes, rather than weeks.

Following these steps and thinking about the design system agnostically from brand, use case and product as you build it, will help you reduce product design and development challenges in the future. Once the foundation is stable, you can come back and apply all these specifics on top of it.

However, it’s only natural to understand that there are always certain challenges when implementing new processes. But that’s ok. That’s why we want to share ours as we set off to create Indigo.Design. Many of them were related to certain paradigm shifts in the design programs we wanted to support. Then, there was the ongoing challenge of making sure that the components we use at design time and the components developers use to code are in sync all the time. To ensure that all this works smoothly, we have established certain processes and do regular reviews because it is something worth spending the time on, knowing it improves quality, workflow, and consistency.

With so many potential risks you may begin to wonder if you want to be in the design system maintenance business or would rather like to focus on your product and leave that to someone like us and Indigo.Design.

Why Choose Indigo.Design For Your Design System?

To put in place a solid and future-proof architecture of a design system, I would of course advise you to download and explore Indigo.Design inside and out. It saves you time and efforts, and allows you to focus on the actual design.

A few quick things to keep in mind:

1. Indigo.Design is a native library for Sketch and Adobe XD extending to Figma in the near future rather than a canvas full of elements to copy-paste.
2. Indigo.Design has not just components with states but also templates and variants that adjust automatically as the user of the design system changes a component's configuration.
3. Indigo.Design works with WYSIWYG App Builder to create real components in the web.
   • Simple and easy to use thanks to its modular architecture and drag-and-drop UI components.
   • You can get usable code output like source code for one or several Angular components or even an entire Angular app.
   • With .NET 6, the App Builder is now supporting Blazor code generation. This means that you can now create any Blazor UI with simple drag and drop and get all of the production ready Razor, C# and CSS code in one click.

      4. Indigo.Design has powerful mechanisms for theming so that you can apply your brand colors and typographies and make it your own.
      5. Indigo.Design will be rolling out distinct variants for Material, Bootstrap and Fluent that look and feel as those frameworks do.

Sources:

[1] Gartner, Build Better Products Faster With Design Systems, Brent Stewart, Van Baker, 2 March 2021