A few months ago, design system consultant Nathan Curtis published an update to an article he wrote almost a decade ago. In the original article, he described 3 models: solitary, central, and federated, with the implication that a federated was the most desired. In the updated article, he clarifies:

Favoring federated was and is wrong.

I wholeheartedly agree. I shared the article with design systems teams I‘ve been working with and talking to—many of them who operate in a federated structure—and it was met with two competing sentiments.

First: relief and validation. It sounded something like this:

Yes! This explains why we’ve had such a hard time getting traction.

Second: despondence.

Are we doomed? How are we supposed to power all of our organization’s user interface elements especially if our team structure doesn’t set us up for success? What can we do?

It’s a legitimate question.

The problem to solve is in our own assumptions. Who said we were supposed to “power all of our organization’s user interface elements” in the first place? Unfortunately, we did. We made compelling arguments. And people believed us. But that remit is too large for many fully-staffed, dedicated, cross-disciplinary design systems team to accomplish. How much more of a federated team, especially one that’s working on the design system “in their spare time” as so many are?

The typical inclination is to ask for more: more resources, more time, more patience to get more work done.

That rarely works.

Don’t ask for more. Commit to less.

The best strategy I’ve found is to start resetting expectations about the output of the design system team as soon as possible.

Design systems don’t have to power all of our organization’s user interface elements. That’s not the goal, and it never was.

If you can collect a handful of specific, common elements that truly save designers and engineers some time—easier said than done, but still doable—that is amazing. That is work well done.

I recommend picking a subset of interface elements, one that feels achievable and connected to your organization’s mission. If you work for a data startup, don’t pick all interface elements; pick all table elements. If you work for a B2C apparel company, don’t pick all interface elements; pick all marketing elements. A federated team couldn’t possibly tackle all of an organization’s user interface elements in any timely manner, but a federated team could tackle all table components or form components or marketing components.

One of the last organizations I worked with—yes, a federated team—focused solely on iOS messaging components for the last year. This subset was both strategic and achievable.

This strategy often surfaces a natural question: if we’re only working on form components, who will supply the table components that everyone’s looking for?

👀

Not us.

The designers and engineers who need it will have to create it on their own.

That’s ok. It’s a perfectly fine answer.

That’s their job.

That’s what they would do if their was no design system team.

That reality gives you the freedom to do something small, and do it really well. Then figure out how to scale it.

It’s better to spend 1 week to save others 2 weeks than spend 1 year to save others 2 years.

That’s how you win at design systems.