←
BUILDING A DESIGN SYSTEM FOR THE MASSES
Design at scale
How we succeeded in building a design system that scaled across internal and external stakeholders.
←
BUILDING A DESIGN SYSTEM FOR THE MASSES
Design at scale
How we succeeded in building a design system that scaled across internal and external stakeholders.
←
BUILDING A DESIGN SYSTEM FOR THE MASSES
Design at scale
How we succeeded in building a design system that scaled across internal and external stakeholders.
INITIALISE
The mission
Take 2 internal products – one a user facing mobile webapp – the other being an admin tool. Both running on proietary components which didn't really foster consistency.
Change the business needs to enable 3rd parties to create integrations into the mobile webapp.
Add a fully native mobile app into the mix.
There you go.... How do you solve the challenge of having tons of products created by totally different teams – which all needed a consistent look and feel?
The answer was rather easy. Treat it like a product!
The team
Moritz (Tech Lead), Daniel (Frontend Engineer), Davy (Full Stack Engineer), Jan (Frontend Engineer), Miriam (UX Designer)
The timeline
Time to initial release – 3 Months
My role
I was responsible for driving the project, designing components, keeping requirements and processes in sync, aligning all potential stakeholders, driving adoption and making sure engineering and design are continuously aligned.
INITIALISE
The mission
Take 2 internal products – one a user facing mobile webapp – the other being an admin tool. Both running on proietary components which didn't really foster consistency.
Change the business needs to enable 3rd parties to create integrations into the mobile webapp.
Add a fully native mobile app into the mix.
There you go.... How do you solve the challenge of having tons of products created by totally different teams – which all needed a consistent look and feel?
The answer was rather easy. Treat it like a product!
The team
Moritz (Tech Lead), Daniel (Frontend Engineer), Davy (Full Stack Engineer), Jan (Frontend Engineer), Miriam (UX Designer)
The timeline
Time to initial release – 3 Months
My role
I was responsible for driving the project, designing components, keeping requirements and processes in sync, aligning all potential stakeholders, driving adoption and making sure engineering and design are continuously aligned.
INITIALISE
The mission
Take 2 internal products – one a user facing mobile webapp – the other being an admin tool. Both running on proietary components which didn't really foster consistency.
Change the business needs to enable 3rd parties to create integrations into the mobile webapp.
Add a fully native mobile app into the mix.
There you go.... How do you solve the challenge of having tons of products created by totally different teams – which all needed a consistent look and feel?
The answer was rather easy. Treat it like a product!
The team
Moritz (Tech Lead), Daniel (Frontend Engineer), Davy (Full Stack Engineer), Jan (Frontend Engineer), Miriam (UX Designer)
The timeline
Time to initial release – 3 Months
My role
I was responsible for driving the project, designing components, keeping requirements and processes in sync, aligning all potential stakeholders, driving adoption and making sure engineering and design are continuously aligned.
Identify
The audience
First things first.... We started identifying our target audience. Since we're dealing with UX, UI and a shippable product as the ultimate outcome – this was pretty straight forward:
Identify
The audience
First things first.... We started identifying our target audience. Since we're dealing with UX, UI and a shippable product as the ultimate outcome – this was pretty straight forward:
Identify
The audience
First things first.... We started identifying our target audience. Since we're dealing with UX, UI and a shippable product as the ultimate outcome – this was pretty straight forward:
Double diamond
Identify the needs
Multiple surveys across internal engineers and designers gave us a first idea of what we need to take care of while building.
In a second round of interviews with 10 external partners we identified even more requirements which were also quite surprising.
A component library is definetly not enough. We need to go way further!
60% didn't think they could adopt it. Further research made it very clear why. People feared bad documentation, little to no samples and a bad developer experience as their main arguments.
A second idea sparkled to make sure adoption is great: We need to communicate progress and advocate pro-actively about the work we do.
Double diamond
Identify the needs
Multiple surveys across internal engineers and designers gave us a first idea of what we need to take care of while building.
In a second round of interviews with 10 external partners we identified even more requirements which were also quite surprising.
A component library is definetly not enough. We need to go way further!
60% didn't think they could adopt it. Further research made it very clear why. People feared bad documentation, little to no samples and a bad developer experience as their main arguments.
A second idea sparkled to make sure adoption is great: We need to communicate progress and advocate pro-actively about the work we do.
Double diamond
Identify the needs
Multiple surveys across internal engineers and designers gave us a first idea of what we need to take care of while building.
In a second round of interviews with 10 external partners we identified even more requirements which were also quite surprising.
A component library is definetly not enough. We need to go way further!
60% didn't think they could adopt it. Further research made it very clear why. People feared bad documentation, little to no samples and a bad developer experience as their main arguments.
A second idea sparkled to make sure adoption is great: We need to communicate progress and advocate pro-actively about the work we do.
Validate
Craft & Test
To make sure we had the "right" approach we agreed to not validate our process but to rather really test it out with a real component and learn from those findings.
The test included a fully fledged Button component, a press release with pictures and a tiny campaign around it which was sent to our initially interviewed people with a survey attached.
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”.
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”.
Validate
Craft & Test
To make sure we had the "right" approach we agreed to not validate our process but to rather really test it out with a real component and learn from those findings.
The test included a fully fledged Button component, a press release with pictures and a tiny campaign around it which was sent to our initially interviewed people with a survey attached.
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”.
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”.
Validate
Craft & Test
To make sure we had the "right" approach we agreed to not validate our process but to rather really test it out with a real component and learn from those findings.
The answers were pretty overwhelming. 90% of our users would adopt the system.
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”.
Continous development
Iterate & Shape
Going component by component we developed a pretty decent flow and ended up with a mix of the composition approach from Chakra UI, the API from Material UI and the documentation detail approach from the Apple Human Interface Guidelines.
Visual regression tests helped us spot differences and make sure our engineering <> design files are always in sync.
Our release strategy was born and refined:
Component proposal and collaboration + ideation across different user needs
Presentation in our bi-weekly meetings to gather feedback and have the possibility to iterat
Full-fledged design in Figma with all states
Component creation in code
Documentation with best practises, samples, do’s and dont’s
Release notes and press releases — internal and external — around the updates
Feedback consolidation over time via GitHub and Figma
Continous development
Iterate & Shape
Going component by component we developed a pretty decent flow and ended up with a mix of the composition approach from Chakra UI, the API from Material UI and the documentation detail approach from the Apple Human Interface Guidelines.
Visual regression tests helped us spot differences and make sure our engineering <> design files are always in sync.
Our release strategy was born and refined:
Component proposal and collaboration + ideation across different user needs
Presentation in our bi-weekly meetings to gather feedback and have the possibility to iterat
Full-fledged design in Figma with all states
Component creation in code
Documentation with best practises, samples, do’s and dont’s
Release notes and press releases — internal and external — around the updates
Feedback consolidation over time via GitHub and Figma
Continous development
Iterate & Shape
Going component by component we developed a pretty decent flow and ended up with a mix of the composition approach from Chakra UI, the API from Material UI and the documentation detail approach from the Apple Human Interface Guidelines.
Visual regression tests helped us spot differences and make sure our engineering <> design files are always in sync.
Our release strategy was born and refined:
Component proposal and collaboration + ideation across different user needs
Presentation in our bi-weekly meetings to gather feedback and have the possibility to iterat
Full-fledged design in Figma with all states
Component creation in code
Documentation with best practises, samples, do’s and dont’s
Release notes and press releases — internal and external — around the updates
Feedback consolidation over time via GitHub and Figma
Release & Ship
Create, Document & Communicate
This was the most fun part. It took us over 3 months to have all our components initially abstracted and another 12 months to have them implemented in our actual products and across our design files.
Wait... we did really made it on time? Not really... we were 4 weeks due – but the open communication and inclusive environment enabled us to deliver the best possible quality.
Why did this work out so fast?
We were surprised by the speed of adoption and the eagerness of other teams to contribute and participate. We were overwhelmed of the enthusiasm we generated.
Release & Ship
Create, Document & Communicate
This was the most fun part. It took us over 3 months to have all our components initially abstracted and another 12 months to have them implemented in our actual products and across our design files.
Wait... we did really made it on time? Not really... we were 4 weeks due – but the open communication and inclusive environment enabled us to deliver the best possible quality.
Why did this work out so fast?
We were surprised by the speed of adoption and the eagerness of other teams to contribute and participate. We were overwhelmed of the enthusiasm we generated.
Release & Ship
Create, Document & Communicate
This was the most fun part. It took us over 3 months to have all our components initially abstracted and another 12 months to have them implemented in our actual products and across our design files.
Wait... we did really made it on time? Not really... we were 4 weeks due – but the open communication and inclusive environment enabled us to deliver the best possible quality.
Why did this work out so fast?
We were surprised by the speed of adoption and the eagerness of other teams to contribute and participate. We were overwhelmed of the enthusiasm we generated.
You said...
Communicate?
This might have been the hardest part of the whole project. But it was well worth it.
Collaboration and building a community turned out to be THE key factor for our mission.
You said...
Communicate?
This might have been the hardest part of the whole project. But it was well worth it.
Collaboration and building a community turned out to be THE key factor for our mission.
Our component creation and release flow included the creation of documentation, samples and full layout usage. We learned over time that people really love to have guidance on “how far” they could stretch the design system or not.
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”
You said...
Communicate?
This might have been the hardest part of the whole project. But it was well worth it.
Collaboration and building a community turned out to be THE key factor for our mission.
Our component creation and release flow included the creation of documentation, samples and full layout usage. We learned over time that people really love to have guidance on “how far” they could stretch the design system or not.
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”
The outcome and...
The Impact
We sadly didn't come up with the metrics before we started the project... But you always keep learning – right?
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
The outcome and...
The Impact
We sadly didn't come up with the metrics before we started the project... But you always keep learning – right?
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
The outcome and...
The Impact
We sadly didn't come up with the metrics before we started the project... But you always keep learning – right?
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
And most important
The Learnings
I've never learned so much about design systems as in this project.
We completely under-estimated the required effort of maintaining and evolving a design system
Keeping Code and Design 100% in sync is extremely hard
The value of having a design system was acknowledged and a new team with 100% dedicated members was born
And most important
The Learnings
I've never learned so much about design systems as in this project.
We completely under-estimated the required effort of maintaining and evolving a design system
Keeping Code and Design 100% in sync is extremely hard
The value of having a design system was acknowledged and a new team with 100% dedicated members was born
And most important
The Learnings
I've never learned so much about design systems as in this project.
We completely under-estimated the required effort of maintaining and evolving a design system
Keeping Code and Design 100% in sync is extremely hard
The value of having a design system was acknowledged and a new team with 100% dedicated members was born