UI components as Lego: an analogy too far, or not far enough?

The UI Lego analogy is always good for an eye-roll. Components are bricks. Product teams build things with them. An apple a day. Red sky at night.

But if it wasn’t valid, it wouldn’t have persisted long enough to grow stale.

Is it still useful? We say it is — if you extend it, that is. Because having a nice set of bricks is no longer enough.

An incomplete picture

Here’s a common model for building complex things on the web:

1. A central UI team builds the components
2. Product teams assemble experiences from them

This scenario can reduce the design system to a fixed library of components.

Product teams choose from the box of pieces and fit them together. But it only includes pieces for the product needs you can see this side of the horizon.

A Lego set is perfect for building one thing. But when you’re finished, someone’s going to want to turn it into something better. There comes a time when the product team will need something that doesn’t exist yet. What then?

Beyond the manual

A good design system doesn’t only provide components. It enables teams to create new ones.

This raises an obvious tension: if product teams can build their own things, how do you maintain quality and consistency? Who maintains it? Who prevents chaos?

There's no one answer, but there is a continuum of options. At one end, you have complete lockdown: the UI team controls everything, making outside contributions difficult, if not impossible.

At the other, you have federation: anyone can add anything in the name of community ownership — which tends to mean no ownership. Quality becomes inconsistent and the system fragments.¹)

We find that successful systems start out with strict controls. Clear standards facilitate the rapid progress you need to show early on.

But to grow well, they need to gradually open up as they mature. That doesn’t mean phasing out control. It means putting governance systems in place. Create documented processes and controls for ownership, contribution and deprecation.

Maintaining over-rigid control indefinitely creates problems. Product teams build what they need anyway, outside the system. Shadow components proliferate. The design system becomes gradually less useful in enabling the work being done.

When you add means of both enablement and governance to your collection of components, you elevate it to a full-fledged design system. That is, it becomes a system of systems.²

In the shadows

Shadow components aren’t to be feared. They’re useful signals, not least that you have a motivated team that wants to get things done.

But they also signal that the system isn’t meeting all needs. That could be because the contribution process is hard to understand, onerous to follow, or both.

Ask what problem they were trying to solve and why the existing system didn’t work for them. The answer will reveal gaps to fill.

Making it work

Your design tokens, icons, and foundational elements need to be available in every format the teams use, be that CSS custom properties, JSON, JavaScript, or any other.

Documentation should cover both how to use and build components, structured around different user needs.³

Everything should live in one place rather than scattered across repos, wikis and Slack channels.

The payoffs are substantial:

• Teams stop wasting time rebuilding primitives.
• Consistency becomes the default rather than an aspiration.
• Brand identity holds together.
• Development speed increases because new problems are only new once — when they arise again, you’ve already solved them.

Building on the Lego analogy

These benefits only materialise when you move beyond the component catalogue model.

The Lego analogy holds – but only if your teams can tool up and make new bricks. The goal isn’t to provide every possible component. It's to provide foundational components plus the means to create more.

In other words, you’ve built a beautiful Lego factory. Now it’s time to hand out the golden tickets.

---

1. See Nathan Curtis’s The fallacy of federated design systems, on the “damage and distress of glorifying the wrong model”. ↩

2. Brad Frost's The design system ecosystem breaks down how design systems are ecosystems of interconnected parts all working together. The component library is just one piece. ↩

3. The Diataxis framework structures documentation around four distinct user needs: tutorials, how-to guides, explanations of concepts, and reference material. It’s a great starting point for planning documentation. ↩