Design plays a huge part in a company or product’s success and design systems have become essential to this process. The increasing demand for better user experiences has put a lot of pressure on designers who are forced to take on more projects and work faster while still delivering high-quality work. Without a standardized design language to pull from, this can create a lot of problems.

What is a design system?

Design systems are sets of standards for design and code, together with components which unify both practices. You can think of them as Lego kits and instructions which everyone has access to and bases their work on.

A design system’s purpose is to increase product development efficiency by establishing a consistent design language for better aesthetics, UI, and UX.

They should not be confused with style guides or pattern libraries. Style guides focus on graphic styles such as colors, fonts, and illustrations and how they should be used, while pattern libraries contain functional components and their usage. Basically, the difference between design systems and style guides or pattern libraries is in the standards and documentation accompanying the assets. When bundled with guides on why and how they should be used, they become much easier to use and clearer to discern.

Why you need a design system

Design does not scale easily and attempting to do it through hiring, without having any standards in place, is not a good way to go.

Every new hire brings with it new ideas for colors, patterns, and typography, adding to the inconsistency and increasing the cost of maintenance. The only way to prevent this is to use a design system. The more a design system grows, the more consistency you have, as well as faster development speed.

Building a design system

Let’s go ahead and take a look at the steps you will need to follow in order to build your own design system:

  1. Create an UI inventory

Build a catalogue of every reusable component in your product. This will allow you to discover inconsistencies in your design language. It will take some time, however, but this is an essential step.

Here is what you need to take inventory of:

  1. patterns – collect examples of patterns used in your products.
  2. colors – colors are a very common source of inconsistency across a product portfolio.
  3. typography – in complex projects, typography can easily get out of hand and without a consistent typographic scale across the project, the information architecture can get convoluted and difficult to understand for users. At the same time, this can increase the costs of product maintenance because of the fragmentation in the code. Inventorying your text styles allows you to show team members and stakeholders where the styles used are inconsistent.
  4. icons – icons offer users context and help them speed up the recognition of key actions. If used inconsistently, they can confuse them and increase maintenance costs.
  5. space – space is key in any UI and must be managed efficiently. Take note of the grids used in your products as well as the paddings used in containers.

  1. Make a case for a design system and get everyone on board

Before you start any work on your design system, ensure that everyone in your organization is on board for the process. Use the information you gathered while creating your inventories and tell them about the inconsistencies you found and how they negatively impact users’ experiences.

Getting your team’s support:

  1. describe how you built the UI inventory
  2. present them with each category’s inconsistencies
  3. explain how they are negatively impacting the user experience or the development process
  4. present the design system as the answer
  5. explain the process of building the design system and that you will need a team for it
  6. explain that every designer and developer will be able to contribute

Getting your stakeholders’ support:

  1. describe how you built the UI inventory
  2. present them with each category’s inconsistencies
  3. focus on numbers and how they will influence the process (number of shades, types of buttons, icon libraries, etc.)
  4. explain how they are negatively impacting the user experience or the development process and again focus on numbers (e.g. hours & money wasted)
  5. present the design system as the answer
  6. explain the process of building the design system and that you will need a team for it
  7. remind them that a design system will help the company deliver better experiences to the market and faster

  1. Build your team

Now comes the part where you assemble a multidisciplinary team to help you implement and manage the design system. Being by identifying the skill sets you require and then deciding on who you want on your team. Typically, design system teams will consist of designers and front-end developers.

Here is what you need to do:

  1. identify the skills you will need to fix the inconsistencies identified in your inventories
  2. identify the skill you will need for the design system’s long-term success (maintenance & governance)
  3. identify the people with the required skills
  4. check your team members’ availability and how much time they can allocate to work on the design system
  5. establish everyone’s role and how decisions will be made
  6. decide on sprint lengths
  7. decide when to gather the team for planning and post-sprint meetings

  1. Establish rules and principles

This means establishing what technology you will use for writing the design system, how you will distribute it, and you are going to use one of your existing products as a starting point.

Here is what you need to do:

  1. decide if you’re going to build the design system from scratch of base it off of an existing product
  2. decide if you’re going to use existing technologies to build your design system or introduce a new one
  3. decide how you’ll be distributing the design system
  4. decide what the design system’s KPIs are
  5. establish your design principles
  6. communicate all your decisions and conclusions to everyone in the company

  1. Establish a color palette

Since colors can impact all areas of the design system, you should start by building a color palette first. Decide what your primary colors will be, the naming convention, and the system for choosing accent (secondary) colors.

Here is what you need to do:

  1. identify your primary colors using your colors inventory
  2. decide on a naming convention for your colors
  3. decide on a system for choosing accent colors – e.g. 20% lighter/darker than the base color
  4. compare the color palette with the ones in your inventory and ensure you match, replace, or merge every color currently in use
  5. implement the new palette on a test server
  6. conduct QA tests to see how the new color palette has affected the UI
  7. check the contrast between your colors to ensure they comply with WCAG (Web Content Accessibility Guidelines)
  8. present all product designers with the new palette and the new UI
  9. invite product designers to test the UI and suggest improvements
  10. finalize the color palette
  11. implement the color palette in the product designers’ tools

  1. Build the design system’s typographic scale

Typography is just as important as colors are. Decide which typefaces you want to use and the typographic scale for a consistent information architecture across your products. UI is also affected by typographic scale so be sure to test it.

Here is what you need to do:

  1. choose typefaces
  2. establish a consistent typescale
  3. test the new scale against the text styles in your inventory
  4. implement the new scale in CSS on a test server
  5. test the UI impact of the new scale
  6. present the new typographic scale and the affected UI to the product designers
  7. encourage the product designers to test the interface and suggest improvements
  8. finalize the typographic scale
  9. implement the new scale in the product designers’ tools

  1. Build the design system’s icons library

Icons are useful for mitigating language barriers, usability, and influencing user behavior. Finalize the icon library and decide on the technology you will use to implement it.

Here is what you need to do:

  1. choose icons from your inventory that will become part of the design system
  2. decide the icon management method you will use to implement the icons in the design system
  3. if you intend to use a different technology to implement the icons, do it on a different server and test thoroughly
  4. finalize the icons library and add it to the design system’s documentation
  5. implement the icons in the product designers’ tools

  1. Standardize all the other style properties

Design decisions also include finalizing other style properties not covered above, such as grid styles or white space. The goal is the same, and that is to remove any inconsistencies.

The process here should be almost identical with what we described above for color palettes, typography, and iconography. Here is what you need to keep in mind:

  1. every part of the system must solve the inconsistency issues found in the inventories
  2. every change must be tested before implementation
  3. you must involve product designers in your testing
  4. every finalized part must be included in the documentation and communicated to everyone in the company
  5. every part in the design system must be available within the product designers’ tools

  1. Build your design system’s first pattern

Building patterns for a design system is an iterative process, which means you should take it one at a time instead of focusing on all of them at once.

Here is what you need to do:

  1. choose the most appropriate architecture for your design system’s patterns
  2. choose the pattern you will be working on in this sprint
  3. ensure the pattern uses the correct colors, typography, and icons
  4. review the code and make changes if necessary, to ensure that the component rendering the pattern can be implemented in every part of every product
  5. review the code once more
  6. ask your team to review the code
  7. make a list of all the patterns which will be replaced by the one in the design system
  8. consult with product developers and designers about any suggestions they may have
  9. implement the pattern on a test server and begin testing it
  10. finalize the pattern
  11. add the pattern to the design system’s documentation
  12. document all the usage and implementation guidelines
  13. test the documentation with the product team to ensure everything is clear and easy to understand
  14. ensure the pattern is available in the product designers’ tools

  1. Conduct a sprint retrospective

Sprint retrospectives should be organized regularly to analyze your progress and make any necessary improvements.

Here is what you need to do:

  1. summarize the first sprint’s KPIs
  2. ask your team:
  3. what we did well
  4. what we learned
  5. what should be handled differently the next time
  6. what could help us work better as a team
  7. ask individuals on the team:
  8. how they performed during the sprint
  9. what their biggest impediment was
  10. what they would change
  11. what else they have on their mind

Final thoughts

All the steps we have gone through should serve as good guidelines for creating your company’s design system. Remember that a design system is not just a product, but an ongoing process which is never finished and requires constant tinkering.

Instead of just pulling together design components such as pattern libraries and style guides, design systems function more as a sort of story the tells how an organization designs and builds its products. The design system includes things like design principles, UX guidelines, UI components, processes, code standards and repositories, resources, design toolkits, and more.

When given the proper attention, a design system has the power to transform typical organizations into powerful product design forces.