Article | Back to articles
Design System failures - Getting satisfied with your communication
15/10/2022 by Benoit Rajalu
This is a short series about failures I've seen or made in the design system space. It is not about self-pity or drama, and it is not reproachful. It is a list of insights (hindsights, even) on two and a half years spent working on design systems, one of which was spent in a dedicated team. Its aim is to help you avoid my mistakes, and to remind me of them later on.
A design system aims to be part of your infrastructure: it wants to be everywhere and it wants everyone to use it. The road to get there is often an obstacle course.
We've got two main hurdles. We need people to work with constraints, and we need them to own something that is secondary to their main task.
The first struggle comes from a system's nature. At their core, design systems are contracts between designers, engineers and content writers. Contracts are... constraining and constraints are perpetually challenged. Must we use design tokens? Do we have to use that component? The content guideline says to use a verb, but my idea sounds better without, etc...
The further the design system's consumers are from the reasons behind the constraints, the more they will resent or discard them.
Design system promoters must communicate about those constraints. They have to convince others of their usefulness: they are a cost, but what do they buy us? When the rules are constantly challenged, communication also involves listening. Why should the system change? How should it adapt?
The second struggle comes with scale and the distribution of tasks. If your team is small and you don't have a dedicated full-time team, then you'll need people to do the work of one. Priorities are bound to be conflicting then, especially if the benefits of working on a design system are not clear (and agreed to) by everyone. When those people need to choose, they'll likely pick tasks that are on their main track.
Let's assume your team is large. You have dedicated people working on the system. Now the reasons why this team requires external contributions also become harder to grasp. There's a dedicated team, why isn't it doing everything? Why should their targets affect other people's priorities?
The less ownership the design system's consumers have over the system, the less likely will their contribution or adoption be.
There too communication is mandatory. If we want to push requirements, we need constant promotion. Promotion of the design system needs, of course. But promoting what satisfying those needs would achieve is a better point to stress.
Communication is an obvious way past these hurdles, it is unavoidable even. The pitfall is not only in not communicating, but in believing you no longer need to. Convincing people is not something that you can consider to be permanent. They might change their mind, or come across a situation that turns their perspective around. They may not have been part of the initial communication wave. Never assume, never take understanding for granted.
The short version: never stop communicating. It's easy to forget that your knowledge doesn't instantly transfer to your colleagues' minds. Nor theirs to yours.
The cost-saving outlook: use the current team rituals to spread the gospel. Chapter meetings. Your dailies. All-hands demos. Make it normal and expected.
The paradox: over-communicating gets on peoples' nerves. Repeating the same points over and over again doesn't help convince people. Making it a routine should not make it boring.
Illustrations credit: Dlubacz over at Whoooa.