Design systems are generally composed of combining UI assets, Dev code, and documentation. However, as great as this is, many organizations are finding they need a couple more things to help support designers and developers in building better experiences. Design guidelines and governance are often needed to provide more explicit guidance on the use of components.
Design Systems have exploded in use over the last 10 years. Most consist of only a UI component library in a chosen design tool like Figma, Sketch, XD, or Axure. Increasingly, teams are also building software development kits (SDKs) with the components in code to match the design tool. The most advanced are linking the design tool to the code. Many organizations are also creating documentation websites for the design system. Typically these will include branding guidelines, an overview of typography, and then additional UI colors along with examples of the components. There may also be technical specifications for the ones who have a code library.
This is a lot of work and content to create and maintain, but there is one more piece needed for the design system to be more useful and complete. Once you have pulled all of this together and designers & devs actually begin using the system, they start asking questions. Should I use a drop down or radio buttons for this part of my design? Should the icon be on the left or the right of side of text in the button? Can I have two icons in a button? Most design systems will not have anything about how the components should be used or more importantly how they should not be used.
Just like other parts of the design system you could leverage other resources like google’s material design system or Apple’s Human Interface Guidelines. However, you will likely find that they will be too generic or have guidance that you do not want to include in your system. So inevitably you will be looking to add further guidance for your own system.
It is important that this guidance is not overly prescriptive. That is, you do not need or want to make it so that your teams cannot solve the design challenges in ways that improve the experience. Too many design systems put rigid limitations on how components should be used, to such an extent that experiences are actually made poorer.
An example might be requiring all forms fields have labels above. While this is ideal for simple forms, more complex forms may benefit from having labels to the left with some instructional text. Another common limitation might be to specify all form fields be equal width. However, studies have shown that it helps people to know what should be entered into a field when its width is matched to the length of the expected input. Zero Height has a good overview in their article on How to Document Your Design System that goes into the need for guidelines for your components.
One other thing that you will want to establish is a governance process for the evolution of your design system. When designers do run up against something that you do want to keep enforced, but they have a new context where it simply does not work you want there to be a way to handle those situations. Either you will want to incorporate that into the design system or in many cases give an exception for that instance. Those who lead, maintain, and build the design system should be made aware so that it is understood why there is an exception. Figma has a great overview of a design system governance process using their tool.
In closing, design systems should be considered living and evolving resources for your designers and developers. Systems that do not change over time are destined to become brittle and teams will resist using if not refuse to adopt in the first place.
Go to the comment form