Désactiver le thème sombre

Article | Back to articles

Design System failures - Making it personal

18/10/2022 by Benoit Rajalu

A confused cat looking at a laptop.

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.

Now this is the hardest part to write because it's about pesky feelings.

A design system is an opinionated methodology. When you defend its processes, you end up defending those opinions. Some people will be quick to call it out as dogmatic, to undermine the argument by lashing out at a perceived lack of flexibility.

It doesn't matter to them that those opinions come from experience. That they stem from observable benefits relayed by organised teams around the world. Detractors experience an obstacle. If they do not share your trust in the systemic approach, it can be very tempting to see you as the obstacle.

This gets tiresome, to say the least. It's not the prettiest thing to admit, but the more invested we are in something organisational, the easier it gets to take things personally. We become avatars, torch bearers for a fire that not everybody wants. As such, we naturally shoulder the criticism, doubts and frustrations of others.

We often assume that the design system's mission of helping people build better products will garner goodwill. It's an easy mistake to make. It's not that people don't want to do better, but they do not have to trust that we know how to get there more than they do. Furthermore, these are people at work. All our banner-waving for “better things” mean nothing if we're making their work harder. Who wouldn't occasionally lash out?

I hope it's not one you relate to, but my mistake has often been to take that negativity to heart. To get discouraged. To be “that guy” who doesn't know when the issue is the methodology or the one pushing for its adoption.

Acknowledging that isn't particularly helpful. In the corporate world (and not just there), your problems are… yours. How you feel about a situation matters fairly little to your colleagues. It matters even less if they're frustrated by something you've added to their workload.

I don't have a solution for this. I don't think there's a card you can play each time.

My guess is that it's easier if the system itself offers an escape hatch. What if the disgruntled are right? What if you actually are making their jobs harder? Sure, it's important that the product meets the standards set by the system… But it's important that the product gets made, period. Compromising is never easy within a design system mindset. What are you compromising on? Cohesiveness? Documentation? Accessibility? Whichever you pick, it doesn't feel good. But feeling bad is better than burning bridges. So learn to take a bow, to document where and why you did and maybe there'll be a way to fix that later on.

Obviously this doesn't work if it becomes the norm. Then again, if conflicts around design systems guidelines are so commonplace, there are deeper issues to deal with. Aim for this to be an exceptional way out, and learn to identify the situations that call for it.

The product still gets made, and that's what we're all here to do. So pick your battles: you can't fight them all at the same time. Be patient: it's ok to let go, there will be other opportunities. And finally, trust your allies. It's not about (just) you.

Takeaways

The short version: opinionated methodologies can create conflicts. Make sure you give yourself a way out.

The cost-saving outlook: don't build a design system if you're not ready to play by its rules. Don't put people in impossible situations where they need to deliver something new while working as usual.


Illustrations credit: Dlubacz over at Whoooa.