Member-only story
Raising a Design System in a team
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.
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.
