It seems that people are very often confusing a Design System with a component library. The differences are nuanced, drawing the line between those two will be hard and there’s no right or wrong — but maybe this story might help us understand those differences a little bit better and maybe it will help us understand the effort it takes to build and maintain a Design System…

Even tho the tooling might have changed in the last years after we started this – I think some principles might still be valid… I’ll try to pack all the experiences I’ve made in the last 6 years in different places on creating Design Systems into this little story in here…

This is where it all began…

Once upon a time, we had a total of 5 internal products which were all based on their own component libraries and our business strategy was heading more towards enabling 3rd parties to integrate their apps into our ecosystem. This was the perfect timing for me to implement a holistic approach on design and foster consistency across our company.

Since our products became more and more inconsistent and we were about to grow massively we knew it was time to create one valid source of truth for our design components which will also enable others to build something on top of them.

Our initial high-level goals were:

• Create a cohesive experience across our own products
• Enable internal designers and developers to get their job done more efficient
• Enable 3rd parties to use our Design System and extend our ecosystem by creating apps

Let’s build it like an own product

We were debating a lot about whether we should just “throw some components together and publish them” – or whether we should build it like we would build a new product.

We decided to go for the second option – and it turned out to be very a rather wise decision.

The process looked very similar to what you’d expect:

• Discover
• Ideate / Test / Validate
• Plan and create iteratively
• Continuously collect feedback and incorporate it
• Repeat

Discovery

The first step was identifying what we want to achieve as a team with a Design System. Since we didn’t know what 3rd parties were up to and how that plays together with the business needs we clearly had to do some more research here.

After collaborating internally with our business we realised that we want to enable an infinite amount of 3rd parties to create apps with our look & feel.

We nailed down 5 different types of users and started preparing surveys and questions to those specific user types. We scheduled interviews with the majority of them to learn more about their needs. We were able to talk to a total of 15 people who were involved in creating solutions that depend on the Design System.

The split was pretty straightforward. Since we followed Donald Norman’s “Why You Only Need to Test with 5 Users” we agreed to talk to 5 internal engineers, 5 external developers, 3 internal designers and 2 external ones — to make sure we capture 80%+ of the common use cases.

The survey consisted of the following questions:

• How much CSS would you like to code in the future?
• What do you expect from a great Design System?
• What worries you most about using a Design System
• How willing would you be to use a Design System in the future?
• What would be the killer feature for you to adopt it?

User Insights

After analysing the surveys we realised there were some very common patterns and worries along all the answers:

• 90% prefer to not have to code CSS anymore
• 60% expect to have samples of how to use components
• 70% were worried about not understanding the Design System
• 40% are eager to use the Design System
• 80% said the killer argument to use the system was design/development speed and consistency

Reading through those findings we were shocked that only 40% would like to adopt the system. We scheduled some interviews with engineers and designers with some hypothesis prepared to see if they would cover those worries.

What would have happened if we would have just released some components / pattern library? Most likely no one would have wanted to even use it….

After talking to the 60% who wouldn’t like to adopt the Design System we were able to nail down a lot of the worries — which were mainly:

• We have to make sure there are in-deep samples of complete page layouts
• Consumers expect to see Do’s and Don’t’s
• We need to communicate progress and advocate pro-actively about the work we do
• We need to provide a great documentation
• We should think about the abstraction level since some designers mentioned they would use this even for non-product work or cross platform

Competitive analysis

We identified some interesting aspects through our research… great… but… why should we reinvent the wheel? There are some component libraries (or are they fully-fledged design systems?) out there… So we went ahead to see what they do and why.

Material UILooking at Material UI we realised it has a nice API for the components but designers are lacking templates and best practises.

Chakra UIChakra UI was the new kid on the block and it was lacking a lot of documentation and best samples but it was refreshing to see their level of abstraction and I was pretty impressed by it’s composability.

Since I personally had a deep love for Atomic Design principles this was a great example of how we could structure our components.

Ant DesignAnt Design reminded me a lot of Material UI but with a very interesting approach on documentation — there were live code samples

Apple Human Interface GuidelinesThe by far best documentation on design principles out there. Even tho it’s not a Design System it helped a lot with shifting our mindset on documentation and guidelines.

Synthesising and adapting our mindset and plans

By synthesising all the findings and research we were able to align our goals and targets way better. We not only changed our perception on what people need inside the Design System but were also able to see that

Creating a Design System is clearly NOT only creating a bunch of reusable components.

We had to keep way more things in mind…. How do we make sure to continuously collaborate and communicate with stakeholders? How are we going to keep code and design in sync? How do we ask for and incorporate feedback? How do we create a hype around it so people will adopt it? What happens to non product related things (such as PPTs, Brand, etc)

We came up with a multi-track plan which relies heavily on iterations and async development, priorities and processes to make sure we’re going to succeed on this mission:

1. Create the components
2. Communicate, align and collaborate with people while creating them
3. Sync all relevant stakeholders regarding Design<>Code sync needs
4. Document extensively — give great samples of Do’s and Don’t’s
5. Implement weekly get togethers to show what’s happening and be wordy
6. Bi-Weekly releases and internal + external marketing about it
7. Feedback + Review process implementation to make adoption easy

Validating what we thought was right

To validate our plan, goals, and our ideas behind the design system we agreed on creating one simple and reusable component but with all the required materials.

We chose the Button component and created a Figma & React component with all different states, a very comprehensive documentation for the Button — giving people samples and guides around it and providing Do’s and Dont’s.

To test the success of it we created a press release with pictures and a tiny campaign around this component and sent it to our initially interviewed people and asked them what they think about this Button. Would they like to use a system that’s as comprehensive as this? Is anything missing?

The answers were pretty overwhelming. 90% of our users would adopt the system. There were 2 answers which helped us a little bit. One stated they “don’t want to use new tech…” and the second asked for “more full-page samples with this component” — which proved that we had to include this in our solution. A great learning because we thought that those samples would be “the last thing to add”…

We were pretty confident in finally starting what we wanted to do 1 month ago!

Crafting the Design System

Ideas and workflows from other Design Systems

We took the composition approach from Chakra UI, the API from Material UI and the documentation detail approach from the Apple Human Interface Guidelines.

Since there was no real workflow around Design Systems in place we came up with a lean one which allowed us to ship fast and make sure to test for visual regression.

Creation, Release and Sync Strategy

Keeping Design & Code in sync is one of the biggest challenges we knew we’re be facing. After we realised we couldn’t use Framer yet we defined to keep the versioning in Code AND Figma in Sync to be able to reference back to a specific moment in code.

The creation & release strategy of a component looked like this:

1. Component proposal and collaboration + ideation across different user needs
2. Presentation in our bi-weekly meetings to gather feedback and have the possibility to iterate
3. Full-fledged design in Figma with all states
4. Component creation in code
5. Documentation with best practises, samples, do’s and dont’s
6. Release notes and press releases — internal and external — around the updates
7. Feedback consolidation over time via GitHub and Figma
8. Repeat from Step 1 :)

Start abstracting current patterns and create the components

This was the most fun part. It took us over 3 months to have all our components abstracted and another 12 months to have them implemented in our actual products and across our design files.

Through our communication and collaboration efforts it was a great experience to see other designers and developers chime in and actually contribute towards the design system right after 1 month! It felt like other people had a learning curve and once they “got it” — they were our biggest fans.

With our limited time and resources on the design system team we wouldn’t have been able to update our 5 products within these 12 months ever….

Setup documentation and Do’s + Dont’s + samples

Our component creation and release flow included the creation of documentation, samples and full layout usage.

We were able to create a very comprehensive documentation that was able to not only include product-related guidelines, components and samples but also touch upon higher-level topics as Brand identity and guidelines for PPT slides, etc

We learned over time that people really love to have guidance on “how far” they could stretch the design system or not.

Communication + Collaboration around the project

Based on our initial research we knew adoption and education were 2 key ingredients for this project to succeed and we wanted to go above and beyond with it….

We tested multiple approaches to this — we tried internal team evangelisation, leading by example, sharing news and updates regularly over different channels but were the most successful with running a bi-weekly design system get together.

Updating teams on what’s new, what changed and what we were currently working on in very short cycles seemed to work best for our setup. People were eager to attend those sessions and our newsletters had a 100% open rates and our release notes did help to bring things across for people who weren’t involved closely in our processes.

We redirected people towards GitHub to be able to request features and have an inclusive environment for our external developers to be able to collaborate on potential new features, components and talk about existing issues.

Collaboration and building a community turned out to be THE key factor for our mission.

Feedback loops

To keep feedback loops short and feasible we did setup beta tracks of the design system so we could publish beta components while gathering insights early on in the process without investing too many resources in “creating the wrong thing”

GitHub turned more and more into the centralised hub for our feedback and insights database. While designers loved giving feedback straight in Figma we saw a trend here towards GitHub over time — most likely because they got more and more familiar with it and we tried to foster a “GitHub first” mindset. Mainly to keep the community in the loop and be more transparent — while having one single source of truth.

Incorporating feedback went through a similar process as the Design System creation itself — just on a different scale.

The Impact

Long story huh? Let’s see what we did achieve by treating our Design System like a real product.

• We were able to update 5 products in 1 year to use the design system — which translates to a 100% adoption!
• We enabled over 40 external developers to create apps we could integrate in our ecosystem based on our design system
• Our products fell way more consistent and had a cohesive approach to our design language and UX
• Our efforts speeded up ideation and mock creation by 30%
• Our efforts speeded implementation time up by 50%
• We were finally able to run visual regression tests which help us identify implications of changes

What did we learn?

• We completely under-estimated the required effort of maintaining and evolving a design system
• The value of having a design system was acknowledged and a new team with 100% dedicated members was born
• Keeping Code and Design 100% in sync is extremely hard

The biggest learning for us was something else tho:

You should treat a Design System just like you would treat one of your products and it’s lifecycle — but actually you should treat it even better!

Don’t compromise on resources you put into it, don’t compromise on quality and definitely don’t compromise on documentation and samples!

We don’t know what would have happened if we would have gone for the cheap way by just throwing out a component library in Figma and another one in Code – but we are pretty confident in saying that the whole project wouldn’t have been as successful as it ultimately was for our needs…

A question remains open-ended tho…

Do we really need to build a Design System or are we rather talking about building a Component Library?

I’ll try to catch up on that (and more) later on one day – promise :)

Thank you

• to all the people involved in the past years who helped me level up my skills and awareness in building amazing Component Libraries and Design Systems
• to all the amazing people out there building wonderful Design Systems from GitHub to Uber to IBM and beyond.
• to absurd.design and Karthik Srinivas for the beautiful illustrations

Michael Henning is a multidisciplinary Product Designer currently shaping the future of equity at Capdesk. With his teams, he obsessively focuses since over 20 years on crafting products people love. He has worked with companies like BMW, Red Bull, L’Oréal and Samsung but actually enjoys helping startups in creating meaningful products most. Connect with Michael on LinkedIn or Twitter.