DDesign systems have been around for quite a while. They’ve arisen with the need of designing for not only one thing, but for a whole set of elements, keeping the same look & feel among them, so all the individual parts look as though they belong to the same family. Design systems were first developed as manuals of standards used for signs and brand books, arriving later in the web with CSS frameworks, like the popular Twitter Bootstrap, serving a set of UI elements such as typography, buttons, and dropdowns. They became more solid with the Atomic Design methodology and adopted patterns and guidelines with the Google Material Design.
Today a large number of companies are building their own custom Design Systems to keep consistency among their products as they grow, making it easier for them to scale. A few great examples are HubSpot Canvas, the visual language of Airbnb, Polaris from Shopify, and Lightning from Salesforce.
HubSpot Canvas
But the fact is that, although Design Systems are useful and make the work of designers and developers way easier, building them can be quite hard. It’s hard because it involves people, processes, and generally a lot of effort in disrupting a lot of work that has already been done.
Working on building and raising a Design System with my team has taught me a lot, and based on my experience here are some helpful things I’ve learned:
It needs to be adopted by everyone
The first step for a successful Design System is to make it official. The Design System should be the only source of components and tools for everyone involved in building products, from the beginning.
It’s okay to have the Design System as a side project at first, but educating people from the beginning is important to keep them excited, to have the design system be respected and to let people be aware of their backlog. A Design System should be communicated even before getting off the ground.
It needs to have principles
Setting principles will help you make decisions with confidence and keep each individual aligned on one common vision. A principle keeps everyone on the same page and helps the individuals to better visualise the Design System as something purposeful. It’s the first thing you need to communicate to the team, and you can do this by messaging them on Slack with related content, sticking posters on the walls or telling the story on the first page of the documentation. Everyone should be proud of the work they are doing.
It needs to be designed for people
Design Systems are designed to be used in products, but at the end of the day, we are all working with and for people. It’s important to keep this in mind because it guides the process of creating and raising Design Systems. Creating for people means keeping the process as collaborative as possible, making it less bureaucratic and giving everyone a voice as well as freedom for them to create and suggest: a community.
It only works if everyone owns it
A Design System shouldn’t be owned by just one individual, but co-owned by designers and developers. When people feel as they own it, they are more likely to make it work. The ideal would be for all the designers and developers to be involved in the project at the same time, which would be nearly impossible. But as there will always be one group of makers and one of users of the Design System, swapping between these two is the secret to making them owners.
It should be scalable
Design Systems are great in theory, but many of them fail because they are too hard to maintain, causing people to get frustrated. Making the process frictionless and easy to update and document gets people more engaged in keeping the Design System alive. For example: we have a Trello board where designers can submit requests for new components. Once a request is submitted, they can create the component by themselves or have someone with more experience with that component create it. The component is then shared in Slack to get feedback and, once everyone is happy with it, submitted into the Sketch library file. It’s all about being organised.
Manager coordinates, people build
Just because Design Systems should be owned by everyone, it doesn’t mean management is not needed. But the manager can’t be a dictator whose job is to unreasonably ask people to build components, but rather coordinate the team, considering ideas and filtering them, keeping in mind that all ideas are valid as all of them are born from needs. If your role is to manage a Design System, remember to be open, inclusive and transparent.
It shouldn’t be compared to other Design Systems
Every company is different. They have teams of different sizes, different users, and different challenges. The only comparison you should make when building a Design System is how it was before you started.
A Design System is a living thing
Design Systems are a living product with a roadmap and a backlog. It’s an organism that grows and changes as the company, their individuals, their product, and their customers do. And that’s why it requires continuous maintenance, support and a lot of love.
Being open to feedback and to the constant changes and iteration is what makes the task of raising a design system so challenging and fascinating.