Article | Back to articles
Design System failures - Targeting the wrong champions
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.
I've been talking about "people" and "consumers" from the start, but design system stakeholders can be more defined.
It's crucial to get the designers and developers on board. You want them as champions because the contract is binding them together. The design system is going to be a massive part of their workflow and output. You would logically assume they must receive the largest amount of attention from the system's promoters.
What of our managers then? Aren't they the ones that set our objectives? Aren't they responsible for those workflows, for organising the way we work? They too must need convincing. It is their responsibility to enforce methodologies, even if it's not always their role to design them. Management is the corporate coercive power channel. So you want them as champions as well. You need them to ensure people are working for the design system...and you need them to let you work on it as well.
But the real power is the directive power. It's the one that actually steers the product, and it matters the most. Which group of stakeholders holds it, I can't tell you. It depends on the company. But in my experience, product managers and product owners are incredibly powerful. They can have a deathgrip on the sprint planning, set on a punishing roadmap. Tasks that do not immediately get the product closer to these targets are easily dismissed.
My mistake has been in thinking that because managers have the coercive power and the developer / designer pair have the productive one, I could rely on them to champion a design system. It may be true in some companies, in some situations, but I don't think it's a safe bet to influence the directive power.
Developers sometimes have this realisation that the product doesn't exist without them. That nothing customers pay for happens without them. It's hard to argue against and it's at the root of many power conflicts in the workspace. Most designers will tell you that this imbalance is really not fun and that because of it, they feel quite powerless.
It's understandable then that dev teams overall don't use that card too often. It's the nuclear option, the end of debate. They trust instead that their productive power is steered in the correct direction by their PMs and POs. They negotiate technical refactos and indulgences along the way. But they often are, for better or for worse, their squads' or feature teams' tool to use.
Because of this, devs and designers can't independently invest in a design system. They only do when the ones holding their directive power consent. Don't expect others to work on something you're not doing yourself: production teams won't try to convince their PMs and POs if you're not investing in that effort yourself.
Takeaways
The short version: find the real power-holders. Convincing consumers and contributors may be crucial, but it's wasted if they are not allowed to consume and contribute.
The cost-saving outlook: use the roadmap as a backdoor to everything. Accept that you're not doing other crucial things for the sake of providing immediate value to key leaders.
The paradox: the least you invest in converting the debt and legacy, the farther you'll be from fulfilling the systemic promise. Failed promises break the trust champions build.
Illustrations credit: Dlubacz over at Whoooa.