Sets that don’t know about each other: building on a client’s design system

Sets that don’t know about each other

In mathematics, two sets may sit side by side without sharing a single element. They don’t affect each other, and they owe each other nothing. Large projects often look like that from within. The client’s team has its library, each vendor has its own portion, and each of them names, solves and ships as though the others did not exist.

That only works for as long as nobody notices the overlap. The moment you recognise that your work and theirs share the same components, the same patterns and the same users, you are no longer a separate set. You are in the intersection, and whatever is broken there is now, in part, yours.

Why the naming fails first

When a system lacks a component registry, there is no authoritative place that states what exists. Each team therefore names what it builds on its own terms. A card becomes a tile in one product and a panel in another, each with subtly different behaviour. Developers copy whatever they encounter first, and designers lose faith in the library because it no longer reflects what is live.

Poor naming is the symptom people notice. The underlying condition is that nobody decides what belongs to the system, so it grows in every direction at once.

The two easy ways out

The first is silence. You assemble a small library of your own beside theirs; it suits your deadline, and nobody has to endure an awkward conversation. A year later, the client owns two systems, neither of which works.

The second is complaint. You list everything that is wrong and send it upwards. It may all be accurate, but nobody enjoys hearing it from a supplier, and a list of problems without an offer is merely more work on someone else’s desk.

What I do instead

When I find myself in that intersection, I consider it my responsibility to say so and to offer help, because at that point we are one team, whatever the contract says about who builds what. I ask before I fix anything. It’s their system, so the offer has to come first.

I then begin a simple registry of what already exists: every component, what it is called, where it lives and what it does. I present it as a map rather than an inventory of mistakes, and most clients have never seen their own system set out in that way. Whatever my part requires on top, I keep thin and name so that it can move back into their library later, rather than growing alongside it.

Every discrepancy I find goes back as a proposal. Not “your button is wrong”, but “here are three buttons doing the same job, and this is the one I would keep”.

What changes

The client gains a registry it never had, and every other vendor benefits too, including those who stayed silent. The naming begins to settle, because there is at last a single place to consult. And you cease to be regarded as a supplier delivering a component, and come to be seen as someone who cares about the whole. In my experience, that is also the vendor clients call again.

When the offer isn’t taken

Sometimes the answer is no, or not yet. That is their right. I then document what I found, keep my own layer clean and reversible, and renew the offer when the timing is more favourable. Being responsible for the intersection does not mean taking control of it.

No client is pleased to hear that their system is broken. Every client is pleased to receive a registry they never knew they were missing.