Surviving Design Systems
Keeping yourself and a Design System alive long-term with effective maintenance and some fresh motivation.
There’s a huge amount of passion, excitement and energy in the Design Systems community. Personally I’m obsessed, and it’s clear others are too – yet in our work I keep on seeing people running into fatigue and burnout.
From four years working on the SG Design System, I’ve watched exactly the same happen to colleagues around me and even at times to me.
What’s going on, and what can we do about it?
A Shift in Work
The beginnings of a Design System are exciting. Exciting but, stressful? There’s the peak of excitement which is the launch of this shiny new product — but then the nature of the work changes.
There’s still just as much work to do (and just as much stress), but the new topics like governance and contribution, road-mapping and prioritisation, feedback and bug fixes might not be the most exciting work, especially when you’re used to just focusing on the craft.
What’s more, they sort of go on… forever?
Long term, this post-launch period seems especially hard on system maintainers. In our team we’re calling it Design System maintenance mode, and here’s how we’ve actively been trying to keep motivated through it:
1. Celebrating ongoing work
Let’s be honest, that first Design System version you’ve just released is probably pretty dodgy. Acknowledging that is important. A lot of the work in maintenance mode is, after all, going to be fixing all those (suspicious) things that you did in the release rush.
When we first released our ‘Picker’ component (a search and select input), we were rather pleased with ourselves and celebrated it a little! Then no one wanted to actually use it… Despite significant testing and a few months of careful design work, in practice it just wasn’t that friendly to use. It was hard to hear that feedback.
We learnt that that we needed to adjust our definition of “done”. We now celebrate launches with the knowledge that there will be continuous work — not just a completion. Unlike pre-release, The maintenance mode mindset towards approaching work should be to focus on making everything usable, both for consumers and end users.
Celebrating also isn’t just to make you and your maintainers feel good— there’s a practical side too.
Communicating the value that you’ve added is essential, especially to stakeholders. Budgets are something that can always be cut (even when well validated), so it’s a nice safeguard to be able to show a list of valuable achievements.
2. Making things a little more fun
Do people even read release notes? Writing release notes is probably the best way to suck all the joy out of releasing something (at least, for us it is). After all that work can’t we just release it? No. Release notes are important.
So to make things more enjoyable we started trying to write as many jokes into our notes as possible.
Aside from having fun writing some extremely un-funny jokes (which probably brought us the most joy), we found that our jokes were having some unintended side effects: people were actually reading them!
After we started the jokes, word spread and we almost doubled the number of people subscribed to them. So the lesson here is that puns have business value? Anyway, even the most tedious, energy-sapping tasks can be made more fun, and might even have some unexpected value.
3. Rotating the team
The fast pace grind of the start of a design system is already un-maintainable on its own — and with the shift to less free, more ‘serious’ long-term work we found that people who enjoyed that early work tended to not enjoy maintenance mode as much.
Even those who do enjoy the work might end up not enjoying it from time to time so, if possible, giving them a break from Design Systems work can be a solution.
As we don’t have a centralised team set up, rotating people off our Design System council and back onto a project is straightforward. In fact, all of our maintainers also work on other projects along-side the system. Personally I’m currently working on two non-Design System projects. Aside from being a refreshing break, it’s also amazing to collect first hand feedback from using the system in the wild.
4. Finding and keeping contributors
Contributors can bring a few especially essential things during maintenance mode: enthusiasm, fresh eyes and another (willing) pair of hands. These things tend to be exactly what a tired Design System Maintainer needs.
To enhance these benefits and to attract more contributors we try and make the work as easy and enjoyable for them as possible, in the hope that they might want to contribute again or convince others to have a good time contributing.
We usually target people who are an expert or who have a specific use case for the topic in their projects to be contributors. We then ask them to focus on the more typically enjoyable things: initial research, ideation, design iterations and testing, before taking over and doing things they might find boring: documentation, UI assets, even additional states etc.
“The whole systems thinking mindset is something that’s not easily understood.” — Erin Rademacher (Zeroheight Hiring Report 2023)
As Erin points out, onboarding non-systems contributors can be a bit of a challenge anyway, so there’s also an added time-save by removing that friction for them.
Once they have contributed, don’t forget to celebrate their win — give them a big thank you in the release notes!
5. Brutal prioritisation
We recently passed 4000 tickets in our Feedback repo.
Getting feedback can be absolutely overwhelming. Having a prioritisation system is the best way to make it more manageable. As far as our main prioritisation method goes, I can’t put it better than Dan Mall (and Ian Fleming):
Once three projects have the same request then it’s pretty much guaranteed that we will be prioritising it. For cases where there are under three requestors we have a few more factors, like the importance of the project and the size of the request.
For those things you can’t prioritise, communicate it immediately. People tend to be ok even with an extreme delay, so long as they know about it. We usually use an “On hold” label, and a reply that goes something like:
For those things that you don’t prioritise, do everything you can to not do.
Yes, we do literally everything we can to not have to do something. Not in a lazy way — in a strategical one. We try to be as creative as possible when it comes to finding solutions to people’s problems:
- Is there an existing component or design pattern that they can use? Perfect. Close that feature request immediately. We manage to close about 30–40% of feedback tickets this way. Personally I pride myself in finding existing answers for just about any request.
- Is their request something that you don’t really want in the system? Tell them to build it themselves and mark it as a snowflake (or whatever name you give to one off/unofficial components).
- Can they contribute it themselves? You may have noticed the last sentence in the image above, “If you’d like to work on it yourself and contribute we can assist you with that!” This is also a great way to find new contributors who you can delegate to.
This strategy has also encouraged us to write more documentation. After 5–6 tickets in a month asking why a menu isn’t working, it’s nice motivation to write something that you can just send a link to.
Acceptance
How often have you written to your WiFi or Water company telling them what a great job they have done? Probably never. But if they aren’t working? Immediately.
Well, now our Design System seems to be treated just like that: as a utility, where consumers are using it as a constant service but ONLY ever giving us feedback for when something is isn’t working for them.
In some ways, this shift is great! A utility is exactly what we want our Design System to be and it’s a good indicator of mature adoption.
Accepting maintenance mode and all that it changes is important, as it means we can manage both how we organise and personally deal with the work that we have to do.
To echo Lauren Loprete at Clarity conference 2021 — Design System work can be thankless. But with a bit of care, I think we can preserve that passion, excitement and energy that makes it all worth it.
Look after yourself.
This article is part of our Design System series: a 5-year overview, 4 false assumptions, getting buy-in, governance & chaos (part 1), governance & chaos (part 2) and adaptive colour systems. Watch this space for more!
