Over the last 5 or 6 years design systems have moved from exotic to common place. But now you have a design system, how do you keep it alive, and hopefully flourishing?
Your Design system itself is only one small part of that. It needs a community around it. A collaboration model. You need to track its success. And documentation, lots of documentation. And a good deal more besides.
Dominik Wilkowski has been involved in bringing several large scale design systems to life, and seen what it takes for them to survive and thrive (and the things that can harm them or worse).
In this session he’ll draw on those years of experience to help you ensure your design system prospers.
Dom’s a developer, not a designer, but it’s not crazy or scary! (troll slide with Papyrus and Comic Sans)
The most important thing Dom’s learned is that when designers and developers work together, awesome things happen.
What does Dom mean by Design Systems?
— Laura Summers (@summerscope) April 11, 2019
Be smarter together and more efficient, work more closely, deliver things faster.
Design systems can include a massive range of assets – but it encompasses your digital brand. It is the source of truth. It is a living and funded internal project, that will not directly generate revenue.
The Trap. Dom calls it ‘the baby trap’. We obsess about the first 9 months of pregnancy, and forget about the next 18 years.
Design systems are designed by people, for people. People should be the central concern for a healthy design system.
Four pillars to sustain a design system:
- Track success
Conway’s Law paraphrased – a good design system is made up of a lot of different people. That’s what a community is all about. So how do you build a community?
Dom’s team created an open day called “design system love day”. Amongst other things it was an opportunity to reach out to people who had doubts, and engage with them on their fears.
Create a space for research – publish rationale as well as components. Elevate design arguments into research, which allowed them to head off the HiPPOs (highest-paid person’s opinion) by directing the decision to research. Spread empathy with research.
Do your research! Do user research, involve the design system team in customer contact. Do design and content research, include accessibility experts, even the legal team.
Excitement levels… this surprised Dom. Usually devs are far more excited about design systems than designers! But you need to aim for 50/50 excitement levels, don’t let the devs take over or the designers fade out.
Do frequent showcases. Show people what’s been going on, what’s working and what isn’t. Bring people into the process.
Keep up the momentum. MPV generates buzz, but once you’re up and running you have to keep pushing or people can really drop off.
Donation model – design system team often sits in the middle and there aren’t many people in that team. They are meant to solve everyone’s issues, but don’t have anyone to do the work. At Westpac they brought people in from design teams for a month to really learn how it worked and the challenges of supporting multiple products. They also provided a fresh perspective for the central team. Then after a month or two they’d go back to their usual teams as champions for the design system. Maybe they even wear some swag tshirts. This is how viruses work! Learn from the best when it comes to spreading something…
- one team, one dream – some people will get that immediately
- exchange for time saved
- exchange for code built
- exchange for upskilling people
- great onboarding experience – get people early so they are ready to work on the product
Community building is not new. Other industries like science have been doing this for decades.
Nathan Curtis published a great article about “team models for scaling a design system”:https://medium.com/eightshapes-llc/team-models-for-scaling-a-design-system-2cf9d03be6a0; federated, central or individual.
What’s important is curation. Curation provides consistency, gives confidence to users, helps with communication.
It’s important to really listen. Most people struggle to listen, it’s a skill that is under-rated. Note what people tell you – literally write things down and internalise them later. Repeat things back in your own words, to demonstrate you understand them. Then you make those issues into a sprint goal or KPI, which creates authenticity and a welcoming environment.
Alphas – create a space within a design system to be really creative. Show in-progress components. Things that aren’t done. Create a space to encourage feedback and test drive assumptions. Use tools like Slack and Discourse for this.
Meaningful collaboration is not a solved problem. A study in 2017 came up with five points around this:
- make it meaningful
- upfront engagement
- create fertile soil for engagement
- deal with problems head on
- handle ownership fairly
A cautionary tale from Westpac… during research for GEL they discovered many projects didn’t want to adopt the system because they didn’t know what was in it, what code was being used. So they open sourced GEL. Later on an internet mob went nuts because they believed GEL was making it easier to build scam systems. It’s not true, because there are actually far easier ways to scrape a perfect design. Ultimately they had to close the source again. They should have educated their users about security.
Track success to…
- make yourself accountable
- help the team to work towards a clear goal
- help your project remain funded
But what is success for a DS? Asset downloads? Design consistency? Time saved? Lost in translation issues between design and dev? Or is it just attendance of your design system love day?
Frame metrics to be meaningful. Focus on the impact of your metrics, rather than the metrics themselves. If you avoid reinventing the button, you save taxpayer money! If more devs are using the DS, you have less devs who don’t know about design. If you have more consistent interfaces you have less users have to learn how to use your sites/products.
Celebrate your wins. At Westpac they published a design system love publication – an email that explained things in non-technical terms. Track milestones and metrics on the DS website, demonstrate adoption. Build trust and authenticity by publishing.
Be fabulous as a team so people want to join you.
Communication is both really important with humans, and really flawed.
Over-communication is always better than too little. Write docs. Docs docs docs and more docs.
Remember who you are writing for. Do you do separate docs for designers and developers, so you can tailor it for each audience? Or do you combine them so you expose each group to the concerns of the other? …no matter which you choose, stick to it.
What should you document? Your research, alpha releases, your processes, roadmap… and delight your readers. There is an opportunity to make someone smile when they see something from the team. Make publications entertaining. When you write error messages you can make them fun! Put easter eggs in. They’re silly but they’re fun!
Show that you’re proud of what you do!
These things made a huge difference to morale and happiness.
The big summary
…then finally, iterate.
But the most important thing is to keep playing. Break things if you need to, but communicate it… because design systems are for people.