The Digestible Plan for
building a Design System
Before diving into how to build a design system you first need to ask “is it necessary?”. When joining a company it is a quick study to learn if a design system is working effectively or if there are opportunities for improvement. Ask yourself the following questions to see if building or improving an existing design system is necessary:
Are designers and developers speaking the same language? If you find that designers refer to components as A and developers refer to components as Z, chances are they are not on the same page and they will struggle communicating with each other. Essentially it’s Spanish and English, and we want everyone to speak French..
Can the system be more adaptable and scalable? A product changes over time; new features, new patterns, new workflows. These changes don’t always mean new development, it can mean changes to existing experiences and existing code. If developers have to go hunt for instances where they need to make style or component changes that is a clear sign that your design system is in need of improvement.
Could designers and developers be using their time more efficiently? If designers and developers are concerned with maintaining and developing UI it leaves less time for innovation and focusing on real user problems. When a Design System is set up properly it enables designers and developers to use their time more efficiently and in return the focus can be directed fully addressing user problems. When a Design System is not set up effectively designers and developers will spend their time caught in a web of process and infrastructure inefficiencies and in return your users will not benefit.
These are a few of the many signs that a company needs to invest time in improving their Design System. If you answered yes to any of the above questions that is a good indicator that you need to improve your design system as you are not currently reaping all the benefits that you could be. Design systems are ever-evolving sets of reusable components, principles, and guidelines that are built with the goal of providing designers and engineers a shared language for consistent product and web design. They are a robust system that should act as a single source of truth for a company. A design system will give engineers, product managers, and designers the tools and guidance they need to create smoother user experiences and digital products. It will streamline design and engineering efforts and aim to eliminate redundancies and remove inefficiencies in the current design and development processes.
Infrastructure is defined as the basic equipment and structures that are needed for a country, region, or organization to function properly. To build a proper design system you cannot just focus on design artifacts, you need to focus on the systems and operations that will bring those artifacts to life. Focusing on infrastructure will allow you to build the foundation to bring those artifacts to life.
To build a proper design system you cannot just focus on design artifacts, you need to focus on the systems and operations that will bring those artifacts to life.
The following plan lays out how to execute on building a robust design system while taking into account legacy work. At this point accounting for legacy work is pretty inevitable because at some point every designer or group of designers tried to make sense of their one off designs by collecting a library of their work that is passed off as a design system. This can be a blessing and a curse. It allows you to not start from scratch but it does require attention and clean up before you can build a solid foundation. So do not be discouraged by significant legacy components and screens, and think of the benefits that come from having some initial work done.
Step 1. Identify and develop the correct infrastructure to support the Design System creation
Many people make the mistake of rushing to figma or wherever they choose to house their design system and start moving things around, organizing, and making changes. The best thing you can do is not rush. Throwing yourself into the space without a good plan will be chaotic and overwhelming. Surprisingly, you can benefit a lot of your design system work without actually touching the design system. Documenting the systems, process, and infrastructure around the Design System can all take place on a simple word doc or Confluence. It’s simple, put a “technological” pen to paper and just plan.
Ask yourself and your team, how do you want this Design System to work, be managed, handled changes?
Where will your library live? Will you have the Design System live in figma, storybook, notion or just showcase screenshots on confluence? Will it be in more than one location? When making the decision of where a system should live, ask yourself who you want the audience to be and how do you want them to interact with it? Do you want other department stakeholders to be able to view the system or do you want it to only be accessible to designers and developers? Do you want developers or other stakeholders to make comments or edits to the system content? Figuring out how you want people to interact with your artifacts should answer the question of where it should live. Whatever you choose, make a decision and make sure it is documented.
Document how you will make changes to your library/system. Will you update the main branch and denote a component as “In Progress” or “Done”? Or will you require all individuals to branch off and make a change in an isolated area that then needs to reviewed and approved before being merged in?
If you have a large group of designers and especially if you allow non designers to have access to figma I would highly recommend implementing a more controlled change process of branching off to makes changes. This will allow you to control and keep track of all changes that occur and in an unideal scenario allow you to revert to a previous branch. A good rule of thumb is have two reviewers tagged on every branch, one reviewer being the Design System owner or manager, and require each branch has two approvals prior to being merged.
Change management for a Design System is paramount. One of the main benefits of a design system is that there will be consistency throughout your experiences. If changes begin to occur and they are not communicated and approved then a design system’s consistency will become compromised and you will begin to have instances that fall out of sync. That’s why Change Management needs to be decided on and agreed on prior to any design work taking place. Every team member should agree to the rules and regulations around making changes to a design system.
Another facet of change management is version control. Version control is extremely beneficial if you are working closely with engineers to try and create 1:1 parity between the design system and the dev component library. Together you can decide what the official maintenance and version management should be so that versions are in sync with how engineers want to do releases.
All of these decisions and process decisions should be documented in a single place. I recommend creating a Control Management document that clearly lays out all the decisions that went into creating the design system. This document will act as checklist for existing designers and a wonderful onboarding artifact for new designers.
Output: Design System Infrastructure - Control Management document
Example process map that may be an artifact you want to include in your Change Management documentation.
Step 2. Capture Current Inventory and Documentation
The goal here is to capture the legacy system and components. There are two things to focus on capturing in this step; inventory of styles and components and instances of inconsistencies. Capturing all of the inconsistencies as simply as “Button”, “Instance 1”, “Instance 2”, etc. This will allow you to have a view of the parts of your system that needs improvement and addressing.
What is important about this step is to not try and change anything and make improvements. Be harsh and honest about what you are working with, you will address resolving all the inconsistencies later. This true capture of your inventory will be the first version of your design system, version 0.0.0. This should be a simple and even fun task for your design team.
Output: Design System Version 0.0.0 (existing design elements and documentation)
Step 3. Address the Gaps
Now, it’s clean up time. You have identified all if the styling inconsistencies throughout your system and product. Meet with your team to decide once and for all, which styles you want to agree to keep. It is important to have this be a team clean up task as a single individual may not have all the context around why a design intentionally deviated away from the norm. A team discussion will allow everyone to be aware of the use cases that you need to account for when deciding styles and will allow everyone to be present for when new rules and style decisions are made. After these decisions have been made you can create your first branch!
Branch off from your main Design System Version 0.0.0 to have a “Clean Up” branch. In this branch execute all the decisions that have been made around styling and addressing your inconsistencies. Again, have team reps set to approve the branch before it is merged in. After it’s merged in you should feel that you Design System is clean, consistent, and is a good foundation to build on and improve. Congrats, you have addressed the gaps and did not get overwhelmed in the process!
Output: Design System Version 0.0.1 (Address Style Inconsistencies)
Step 4. Enable Outcomes + Reap the Benefits
After addressing the gaps we want to bring our Design System to the next level where we can truly be proud of it; making sure the system achieves our desired outcomes. The following train of thought should guide you on how you will need to set up your 1.0.0 version. Ask yourself the following questions:
1 - What is the outcome you are trying to achieve?
2 - How will people interact with the design system to achieve that outcome?
3 - How should you design the design system so that people will achieve that action?
Asking yourself these questions will help you breakdown your goals to the core tasks that are needed. Let’s try some examples:
Example 1:
1 - The outcome we want to achieve is that engineers and designers have a shared language.
2 - This means that we want both engineers and designs to navigate the design system and dev component library the same way and call components by the same name.
3 - To enable this behavior that means we should have engineers and designers sync and agree upon an Information Architecture and nomenclature that works for both teams.
Example 2:
1 - The outcome we want to achieve is to cut down engineering efforts by not making them build a bunch of separate instances for the same type of component.
2 - This means that our designers must build components that can be fully configurable so that there is parity with the engineering dev library.
3 - To enable this we need to have one component that serves the needs of all the separate instances. There should not be a separate search or location input, there should be one text input component that can be configured for search or location instances. This means that designers need to take the time to build components with configurable props and then test them to make sure they work for desired instances. Each component should have their own testing before they go live and make sure they approved by engineers.
You will craft your artifacts with purpose and enable optimal outcomes for your design team.
Identifying all the outcomes and benefits you want to achieve for your Design System will help you identify the requirements for your design system build. Focusing on enabling the outcomes you want will allow you to set up your design system for optimization. With this approach you will not just decide on Information Architecture, component lists, and styles; you will craft your artifacts with purpose and enable optimal outcomes for your design team.
Output: Design System Version 1.0.1 (Optimized Design System)
