The document outlines five pillars for establishing an effective design system: goal and scope, stakeholders and process, initial setup, users and technology, and integration. It provides a checklist of components to include, such as layout, content, data manipulation, and testing. The final sections emphasize treating the design system as a product that can scale, focusing on consistency over perfection, and sharing knowledge through preaching and links.
Design Systems are Beasts that want to get tamed!
Highly Challenging
Very Complex
Hard to Sell
and extremly rewarding if done right
I’ve curated a check list that helps setting our design system up
Tim Schoch
Freelance UX Designer Switzerland
mostly larger projects/products
worked with and for several design systems
Seen what worked and why some failed
First style guides
Then UX Patterns
Now Functional Components
Bring Design and Dev together
Not a one-off
Long term commitment
Q??? who treats design systems as products
Design Systems exist to simplify building other products.
Keep this in mind as UX Designer!
No dribbblization just because “a Design system is expected to have XYZ”
Be proud of your design system! Stay humble and focussed.
Shift Work from Product Team to Design System Team
Opportunity costs: product teams provide value, not perfect micro interactions
Concept I came up with
Five Stages that a design system goes through.
Mix Product Owner, UX Designer and Dev
Sell
Research
Design
Build
Maintain
Not linear: Mix and Match
Decissions from the End influence the Design Pillar
Sell
Research
Design
Build
Maintain
Not linear: Mix and Match
Decissions from the End influence the Design Pillar
Looks familiar?
No Research -> Design Actionism
Two distinct approaches
Fast -> One Product
Structured -> Multiple Products
This is the URL to the checklist, make sure to take a photo of this.
Open Source
Share it
Send me your questions
Article that you can copy to a Word file or Confluence and use as a guide.
Go through this checklist at the beginning, and write down our rough ideas.
Not perfect
Revise once we get there.
Let’s have a look at the Check List
Sell
Let’s have a look at the Check List
Sell
Understand
Product teams
Business cases
Contexts
Not too deep
pitch
What Problem are we solving?
What Benefit do we offer?
Talk to the important people and find out.
Do all Expectations match?
Based on our research, what will we deliver?
There aren’t many must haves in a design system.
Make sure you promise only what you need in the required fidelity!
Start small, expand where needed
Design Systems aren’t built in a vacuum
Necessary people on board?
Find allies and sponsors.
Pitch our story!
After a successful pitch
next stage is research
After a successful pitch
next stage is research
Get intimate knowledge about your product teams situation
Get to know all your products
Create a shared vision
Rules and UX Principles
- Simple Principle: Fun and colorful vs. minimalistc
- Casual Users vs. Professional Users
Often a team effort
Form the Character of your Design System
Lighthouse to check decissions against
Do we have enough understanding of the users of our products?
Worth chatting with the product teams
Create a hollistic picture to understand the needs you’re catering for
Check In with the devs of the product teams
Define the tech stack most suitable for our products
Of all the five pillars, this is my favourite.
Of all the five pillars, this is my favourite.
Following questions might sound simple
Don’t skip them
We want to design a system that works, not one that just looks good
Our Layout depends on product needs
Content density different in specialised B2E application from public facing website
Design of components varies based on content
Story
designers often want to perfect components
deal with all edge cases
I’ve been in meetings where several UX designers tried to find the perfect solution
Until someone asked: «do we actually have this situation?»
Keeping this in mind helps us to focus
There are some very important decissions to make when it comes to building our design system
A lot of the complexity comes from how to enter and edit Data
Based on all we know so far, what Manipulations do we really need?
Does it have to be inline Edit in a Table?
Or Master-Detail?
Just a Dialog?
Inline Edit in Tables is hard to get right both from a development standpoint aswell as regarding the micro interactions.
Choosing something simple here is a great way to cut down the costs.
But how important is efficiancy to the use case?
Product decissions: worth the effort?
A key to a good user experience is how we handle things when they go wrong.
More than Validation
How do we prevent Errors or make our applications more error tollerant?
Testing and documentation are just one slide here, but they’re one of the most important steps for any decent sized design system.
Both might be considered «unsexy» - but if we get it wrong and adoption for our design system will drop.
Docs: They’re under pressure, go with what’s easy to use
Testing: Trust in our quality, that we don’t break their product
Let’s takle the last pillar
Let’s takle the last pillar
Design Systems don’t look after them selves.
Long term support infrastructure
As Design Sytems grow, evolving them becomes harder and harder
Automate as much from the beginning
Release Notes are one of the most undervalued things in a Design System.
Let me show you why
«Our Design needs to breath, it needs space to live!»
Add 5px padding
-> Grows, thats fine. But it breaks the Buttons.
Add 5px padding
-> Grows, thats fine. But it breaks the Buttons.
Not just properties in code
Components have a visual API
Q??? what CSS properties are breaking changes?
Everything that changes size: margin, padding, border, line-height
Also Colors: accessibility can break if you change the BG color of a Button
Depends on the size of our design system
Wrap this up
build only what you really need
Nest Components in Components
The more you build,
The more complexity rises,
Edge cases appear,
More things to test
The Slower you move
Product Owner!
Features are like Chilis
Product Owner!
Features are like Chilis
Product Owner!
Features are like Chilis
Remember!
True for both product teams and UX Designers.
We can’t design the 100% optimised AppFlows but must adhere to standards.
Devs don’t have to spend time perfecting interactions and focus on business logic
Lastely: It’s never a One-Off.
You need to have a long term plan, even if you start small.
Design Systems need DesignOps
Slides, more articles and links on this topic
Followup -> leave email, recieve followup next week.