Your design system needs authority

Design systems need champions, but champions need support. Without incentivised managers backing the work, even the most passionate advocates will hit a wall.

This chain of enablement applies to federated and dedicated teams models alike: for the system to be adopted it needs to be the tool people need, but that requires the authority of "someone" to let it become that very tool.

Authority in the early stages

Design systems are often "bottom-up" initiatives. Designers and / or developers notice a friction in the UI process, an obvious lack of industrialisation and want to fix it.

If the overall organisation is permissive enough, they may even self-organise to start building it together. Some even manage to convince management that a dedicated team is necessary and, in the rare cases where that can be budgeted, turn the grassroots initiative into a bonafide island within the company.

Now comes the hard part: adoption. How do you get teams to use it? To contribute to it? How do you prevent consumers from ejecting when the system can't keep up with their needs? Without authority, you can't.

Authority is the ability to enforce organisational alignment. You need the larger organisation to acknowledge that the system needs everybody's engagement. You need the process-makers and process-police to both enable and enforce the directive: we are building a design system. Get on board, or stepping out of this train will cost us: missing OKRs, growing debt, missed deadlines as projects don't count as done if not compliant etc....

You get people to use the system by giving them empirical adoption objectives. From these you can directly build momentum to solve your backlog issues: being driven to use a system will rapidly lead to being motivated to contribute to it (dedicated teams work better with contribution). You don't oppose business priorities and design system, you compound them: how can the system help that priority? Ensure both are built together. And if a link in that enablement chain fails, then authority must act.

We're often uncomfortable with authority, because we're so used to self-organisation and agile teams we often don't see larger entities enforcing policies at scale. But without them, without the large-scale enablement authority provides, your budding system will struggle.

For adoption to stall, it will only take one designer "not feeling it"; one business unit choosing not to use the right component once, then twice, then "why bother"; one dedicated team buried under a never-ending backlog with 0 contribution yet disproportionately understaffed. Design systems struggle when there is no drive behind them.

Authority post adoption

Teams that have broken the wall of adoption are (perhaps unsurprisingly) faced with the exact same issues.

There's a tendency to loosen workflows once teams have built up steam. Workflows are here to "make things work", but once they do work teams tend to find workflows too restrictive and not "organic enough". Aren't we seeking continuous improvement, trying to be always more efficient?

But here's the catch: design systems thrive on workflows. Who checks for compliance? Who files the requests for change? Who commits to migrating the deprecated components? There is a lot of mental burden involved to keep the system healthy and relevant, and nothing alleviates that more than a well-oiled workflow.

Some teams are self-organised and conscious of the design system's role enough to maintain that discipline over time. But if the authority above them pushes for change, there will be little they can do to keep the design system overhead.

A mature design system therefore requires the same authority enablement to be sustained. Without it, as teams evolve and change (turnover helping), the good practices that led to the successful adoption will crumble and eventually vanish.

The consequences build up over time. Product leads are taken by surprise when the growing systemic debt throws a wrench in their plan. The sync between designers and engineers lessens. Maybe design keeps its dedicated staff, but engineering doesn't. Adoption becomes harder to generate as ICs are no longer incentivized to participate.

Authority from within

If you are a manager or a lead, your job is to protect the system through strategic prioritization backed by real consequences and support, not top-down control. It might be tough, as you probably know first-hand the difficulty of exercising your authority, of creating friction. But everything has a price, and the continuous success of the design system costs friction.

That is your prerogative as a leader. You can include design system objectives in your teams' goals, you can prioritise design system work over feature work when necessary, you can enforce workflows that keep the system healthy.

In the (maybe more likely) case you do not wield enough authority to implement workflows or objectives globally, you may be able to do so locally. Be proactive, be insistent. Focus on local wins: enforce reviews in your squad, allocate bandwidth for contributions, demonstrate delivery power. Authority is the kind of power we recognise best, but your ability to deliver is the most effective. It's the power dedicated teams and federated models both require in abundance, so wield it.

Costs vs benefits

Design system conversations inevitably return to ROI arguments, and this is no different. If you are in a position of authority where you can set objectives and enforce workflows, you will expect this friction to yield results. But this is more of a "cost of inaction" thing.

Without processes and incentives to build, use and maintain the system, we will inevitably either make it fail or let it die. That is the cost of inaction here, one that is already dependent on the company's appreciation of a design system's ROI.

But the ROI case is proven: Nathan Curtis documents teams improving velocity drastically, Nielsen Norman Group shows how systems eliminate redundant UI work at scale. The question isn't whether the system is worth it. It's whether you're willing to exercise authority to sustain it.

Further reading on design system ROI:

• Nathan Curtis - "Measuring Design System Success"
• Knapsack Design System ROI Calculator (referenced by Brad Frost)
• Nielsen Norman Group - "Design Systems 101"