Creating a Design System: Our Approach and Experiences
Creating a design system is one of the services we offer at Netguru. So far, we’ve created design systems for either enterprise-size or smaller companies. Our approach and process are based on our experiences and the issues we’ve encountered so far. Design systems have been quite a popular topic recently, and when it comes to their creation and development, no global standards have been established yet. This is why we want to show how we approach this subject.
In this blog post, we’d like to share some insights into creating design systems. You will learn how to start, how to build a design library assets, and how you should structure the documentation.
It takes two (and more) to tango
Setting up the right team is crucial. On the one hand, we need someone with UX skills; on the other hand, we also need a more UI-savvy designer. Obviously, we could find a unicorn with expertise in both fields, but she or he would quickly become a bottleneck as such projects are complex.
A design system consists of a few elements. The first is a design library, which is a repository of UI elements. The second piece is the documentation, which is linked to the design library. The documentation often contains some code snippets of design components, which makes a major difference compared to static style guides. We’ve covered the differences and showed the pros of having a design system in our previous blogpost.
To create a design system you need at least one designer and one developer, but, as we stated above, it might be inefficient. The task will take too much time and will be exhausting for the two. The more people you can involve in the creation of the design system, the better outcome you will get.
An optimally sized team, based on the projects we have done, should consist of five people. Breaking that number down, you need four product designers with different expertise (2x UI, 2x UX) and a developer. The ratio is four-to-one then. This number could be scaled up, so for more complex design systems, you can have eight designers (e.g. with illustration and motion proficiency) and two developers. An example of an advanced design system is the one Atlassian have.
They have covered every area of their products: colors, illustrations, components, to name a few. Having plenty of products in a portfolio like theirs requires some unified guidelines. We hope you now understand the business benefits of having a design system.
Choosing the right team model
A design library team should consist of specialists in areas such as user interface, illustration, and motion design. A documentation team should be made up of designers who have expertise in user experience, research, as well as from front-end developers who excel at codifying design components.
During our trial and error period, we struggled because our design library was often broken due to synchronization issues. We would recommend choosing one person who will be responsible for updating the master library file (the library owner). In other words, one designer should aggregate all the approved design components from the rest of the team and merge them into the design library file. It allows the team to have better version control over the library. One person responsible for keeping everything in order will also reduce the information creep because the rest of the team will know that the repository has only one owner. The rest of the team should inform the library owner about their needs and issues regarding the component library.
We keep the master library file on Google Drive and have Sketch linked to that library. It works well now, but it didn’t work when more than one designer was allowed to make changes. This team model is called “solitary”.
How to get started
Once you’ve found the right team for the task, it’s time to kick the project off! As needs vary from company to company, we assume that you’ve already built at least one digital product. The first thing we recommend doing is listing all elements that need to be included in the design system. You can use post-it cards and a whiteboard or use a worksheet, as we do.
Then, you need to prioritize the items by usage. To facilitate this task at Netguru, we assign priority points from 0 (mandatory) to 3 (superfluous). You can also use the worksheet from Nathan Curtis’ article on medium.
How to prioritize the components
When your app consists mainly of input fields because you collect some data from your users, input fields, in general, should get a high priority, and the issue should be discussed early on. If you think that input fields aren’t a good example of a topic that might deserve so much attention — you are wrong. Every component that interacts with the user should be thoroughly examined. For example, we can have password input fields (which require a multilevel validation), standard fields, text areas, PIN prompts, and so on. Each of them should get a detailed treatment in terms of visuals, behavior, usage, and anatomy. This is the only way to have the components consistent and to get a successful product as a result. The difference between good and great lies in the details.uns
Once you’ve created a list of the components and prioritized them, you can allocate the items to relevant sprints. Depending on the team’s size, an example roadmap could look like this:
At the same time, another designer can start building up or simply collecting the product principles or visual language elements such as brand guidelines, colors, typography and grid.
Let’s take the grid for example. In our opinion, introducing the grid units at the beginning speeds up the design process later on. For example, while designing for mobile, it is recommended that you lay out designs on an 8px grid. As a result, we can assume that 1 grid unit (gu) = 8px. One of its benefits is spacing consistency and scalability across various device sizes. Let alone the rhythm, which comes along as an extra bonus for using the grid properly.
Ideally, another designer could simultaneously start establishing documentation templates for describing the elements. The template should include arrows, lines, rulers, numbers, captions, which are used later on for creating the documentation.
As the design system is getting bigger, it’s easy to fall into the trap of having inconsistent documentation. One of the main goals of having a design system is to reduce inconsistencies in the company’s digital products because an inconsistent design system is useless.
To avoid the inconsistencies, along with the documentation template, establish one standard process for uploading graphics and screenshots to the documentation. For example, all visual examples should be exported at @2x, have the same margins, and be properly named. Also remember to keep all assets in one place (we use Google Drive), in case someone new on the team needs access.
Putting it all together
As we initially stated, a design system is a combination of a pattern library and documentation. You should end up having a design library with all the components placed in the file. A pattern library is the final outcome of the work of the design library team.
Once the components have been designed, the documentation team will be able to create the necessary descriptions and provide the anatomy of the components (e.g. margins, height, width). The structure depends on the end platform of the product(s). If a product is served for both desktop and mobile, then also some rules for breakpoints and viewports should be covered. An example table of contents for each component and pattern looks as follows:
Description
Specification
Anatomy
1. Element name
2. Element name
Behavior
Qualities
Measurements
Usage (worth having some animated examples)
Code snippets
Dos & Don’ts
Further maintenance
For keeping track of our progress we use a kanban board, and we work in biweekly sprints. The rest is aligned with the Agile approach: we have status calls on a daily basis, where we inform each other what was done the previous day, what our plan for today is, and what the potential blockers are. Once every two weeks we conduct a thorough review, and we go through all the new and revised components, one by one. The entire team is present at these calls because everyone somehow contributes. The roadmap serves here as a guide. Some of the elements could have their second or even third iteration, because of new issues will arise during the development. That’s normal. A product design process is never finished. As design systems are living “beings”, they have no definition of “done”.
Key takeaways
- A Design System consists of two components: a design elements library and documentation.
- Start by listing down all the elements that need to be included in the design system.
- Prioritize the elements by usage and allocate items for the first sprint.
- Start with the visual language: colors, typography, and grid.
- Introduce grid units (for example while designing for mobile 8px = 1gu).
- Create templates that will describe the elements (arrows, lines, rulers, numbers, captions).
- Set up one standard process for uploading graphics and screenshots to the documentation.
- Keep the source files of the graphics and screenshots from the documentation available to everyone.
- Select one person who will be responsible for updating the master library file (a design library owner).
- The rest of the team can contribute to the library, but they need to contact the library owner first.
- The rest of the team should inform the library owner about their needs and issues regarding the components library.
- Keep the master library file on Google Drive and link that library with Sketch.
- Make backups and keep track of file versions.
- Keep track of the progress by using a sheet, Jira, or another piece of tracking software.
- Have daily meetings when you update each other on what was done the previous day, what is going to be done, and what the potential blockers are.
- Create a structure for the documentation.
- Keep a changelog of the master library.
- Communicate with stakeholders often, keep everyone on the project in the loop.
- Create a note on the Slack channel with all the important information and links (to the library, to the UIs, and so on).
Design Systems are quite a challenging endeavor, which requires experienced people in order to deliver high quality and usable outputs. The goal is to have a library of reusable components, followed by clear standards so that designers and developers can build coherent digital products. Served as a single source of truth available to everyone in the company, a Design System allows employees to be on the same page and in the loop.
Originally published at www.netguru.com.
