Patterns Day 2019 - Inayaili de León
On This Page:
5 untruths about design systems
In their presentation at Patterns Day 2019, Yaili talked about the untrue truths around Design Systems.
-
Worked on Design Systems for both product and within agencies.
-
Has seen the mistakes that have been made.
-
When people talk about Design Systems - they often talk about the beautiful public sites available.
-
Then you see blogposts, podcasts, videos telling us how they figured things out
-
Then we look at our design systems and see the mess.
-
What you see in a public design system is a facade.
-
In reality, things are ugly, unfinished with tape and gum holding things together.
You’re not alone in having an imperfect system with documentation people don’t follow, with people ignoring the system exists altogether. No-one has it all figured out. No-one.
Untruth #1
“Everyone loves and understands our work.”
“Some people hate us, and many don’t know what we’re trying to do.”
By explaining it to others in the company as “Do you know Google’s Material UI” doesn’t work.
What works is to sell the system, adapting to the different needs and requirements of the different teams in the company. How things would change, and what would get easier when you use the Design System.
You want to get from “Why am I wasting my time on this?” to “When can I start to use it?
Untruth #2
“Our documentation is always up to date.”
“We don’t always have the time to document things.”
- When you look at the ‘faced’ you can see things like the nice grids, icons, and typography.
- The truth is there are a lot of components that are used on sites now that are not documented and some that you may not even know about.
- Working on a Design System is like a train that never reaches its destination. It just stops once in a while.
- There is work we know that needs to be done, but nobody is asking for it.
- Make time to improve things bit by bit.
- Decide on a holistic structure.
- A documentation page structure could have: Examples, Usage, Anatomy, Developer Guidance, API.
Untruth #3
“Everyone works together in harmony.”
“We block each other all the time.”
- This does not just the members of the Design Systems team.
- People will go ahead and just build something that matches their needs
- You need to work on if patterns being created are new, or can be extended from existing components.
- We shouldn’t block people from using the system, but should have process in place to improve the system.
- You need to be comfortable in the knowledge that a Design Systems team will work slower than a ‘features’ team.
Untruth #4
“no one ever needs custom components”
“someone needs a custom component every day”
- It can be considered too soon to add a new component.
- There might not be the time to create a shared solution
- “I would like it if no-one asked for a new component”
- The relationship between a product and a design system team is like a ‘push and pull’
- If the product didn’t try new things, it would eventually become stale.
- But if every change was accepted, you would be in a mess.
- Make new things, think outside the box but be in the knowledge that it might not actually change what is within the design system
It’s a balancing act. If all you do is accept all the proposals, you’re not doing a good job of maintaining a solid foundation in a Design System. The quality of work is going to suffer. If you say no to every request for change. People will just stop coming to the Design System. They will think that no-one is listening and that it is not for them.
Each new request needs to be within the context of the system.
Untruth #5
“We validate everything.”
“Most times we push to the system without testing.”
- Sometimes there is not the time to get things through the entire process of testing, auditing, etc.
- This goes back to being slow with the Design System.
- You need to have conversations about what you’re working on
- You need to build it
- You need to continually improve it
- You need to document it
- You need to test it
- Think of ways you can get other people to help with this process to validate things.
- How can we make this true?
- make a rule that a component is 100% valid until it has user-tested feedback.
- you can have a label in your documentation that it needs testing
- have regular catch ups with your testers to get them to include new components in their tests
- work closely with the teams implementing the components to see the good and the bad points of them trying to use the Design System.
