The people using your design system don't work here

Most writing about design systems assumes a particular kind of user. They sit somewhere in your organisation, they have access to Figma, they can find the Storybook instance, and if something is unclear they can ask in Slack and get an answer before lunch. The system is a shared reference between people who share a workplace.

I build brand systems for a different situation: mid-sized companies whose brand is executed almost entirely by people outside the organisation. The systems have the same components you would recognise, a defined type scale, fixed colour values, a spacing grid, rules for how the logo behaves. What changes is who consumes them, and that turns out to affect almost every decision about how the system is specified.

Picture the consumers. A sign maker lettering forty trailers. A printer producing packaging in another country. A freelancer the marketing coordinator found last week. An agency hired by a subsidiary two years after handover. None of them read documentation. None of them use the design tools. Most of them will never speak to whoever built the system, and by the time their work appears in the world the decision that shaped it was made months earlier by someone who has since left.

I have been testing this on my own publishing network before selling the approach: fifteen B2B titles sharing one codebase and one set of brand definitions. It is a useful test bed precisely because the failure modes show up fifteen times instead of once.

If your system depends on being able to reach the people using it, you have built a process rather than a system. That distinction is easy to miss when everyone is reachable.

The artifact has to survive being handled by someone who does not care about it

A vehicle wrapper working through a queue of jobs will open the folder you sent, find something that looks like a logo, and use it. He is not being careless. He has a bay booked, a van waiting, and four other jobs that day, and the file either works or it does not.

This is the argument against shipping a folder of twelve variants with a PDF explaining when each one applies. The folder guarantees that someone will pick the wrong file, and the PDF guarantees nothing, because the PDF will not be opened. What works better is a smaller number of files whose names make the wrong choice difficult, and whose construction makes the wrong use visibly wrong rather than quietly wrong.

I have started treating file naming as part of the specification rather than as housekeeping. A file called logo-final-2.png will be used for everything. A file called logo-horizontal-print-cmyk.eps gets used for print, and when someone needs it for a screen they notice that this is not the file for that.

None of this is elegant. It is closer to labelling a fuse box than to writing documentation, and it works for the same reason.

Constraints that live in a document are not constraints

In a product system, a rule about minimum clear space is enforced by the component. The developer cannot easily violate it, because the padding is part of the thing they are importing. The rule and the artifact are the same object.

Outside that environment the rule and the artifact separate immediately. You write that the logo needs clear space equal to the height of its counterform, that instruction sits in a document, and the artifact travels on its own to someone who will place it against the edge of a business card because that is where it fits.

The response I have landed on is to stop describing the constraint and start building it into the file. Clear space becomes transparent canvas around the mark, so that placing the file flush against an edge still produces correct spacing. Minimum size becomes a decision about which variant exists at all, so that the version that breaks below a certain scale is simply not among the files that were handed over.

You lose flexibility doing this. Someone who understands the system and wants to place the mark tightly for a legitimate reason now has to work around your canvas. That trade is worth making when almost everybody touching the file has no idea what the rules are.

Negative rules decay faster than positive ones, and nobody notices

Positive rules are reinforced every time somebody follows them. Use this colour for primary actions, and every correct use makes the next correct use more likely, because the pattern becomes visible in the product.

Negative rules have no such feedback. Do not use the mark on a photographic background. When somebody violates that, nothing happens. There is no error, no failed build, no complaint. The violation ships, it looks acceptable in isolation, and it becomes a reference point for the next person who is looking for an example of how the brand is used.

The asymmetry compounds. After two years of unenforced negative rules you do not have a system with some exceptions. You have a system where the exceptions outnumber the rule, and the original specification reads like an account of something that used to be true.

I do not have a good general solution to this. What has helped is reducing the number of negative rules to the two or three that actually matter and stating them where the artifact lives rather than in a separate document. A rule you cannot enforce is worth writing down only if you accept that its function is to settle arguments after the fact, which is a real function but a much smaller one than most brand guidelines assume.

Distribution is a larger problem than specification

Product teams solve distribution once. There is a package, a registry, a version number, and a way to pull the current thing.

For an external supply chain there is no equivalent, and most attempts to build one fail for reasons that have nothing to do with the quality of the system. A shared drive requires access management that nobody maintains. A PDF gets forwarded and becomes the version of record on somebody's desktop for the next four years. A portal with a login is a portal that a printer will not use, because he is not going to create an account to do a job he was paid for on Tuesday.

What I settled on is a single URL, no authentication, published on the client's own domain, containing the current specification and the current files. A new supplier receives a link rather than an explanation. This is a weaker mechanism than a package registry in every respect except the one that matters, which is that people actually use it.

The same reasoning applies to anything you publish for people outside the organisation. I recently moved a set of construction drawings from a gated page to a plain URL that returns the file directly, no form and no account, because the only people who were going to open them were suppliers with a job in front of them and every step between the link and the file was a step where they would give up and use whatever they had.

There is a real cost. Anything published without authentication is public, which constrains what can go in it. Pricing, strategy documents and anything commercially sensitive stay out. What remains is the part that suppliers need, which turns out to be most of what they need.

There is no rollback

This is the constraint that took me longest to internalise, and it is the one that most separates this work from software.

When a component ships with a defect you fix it and deploy. Existing consumers pick up the change on their next build. The defective version has a lifespan measured in days.

When a print run of forty thousand boxes ships with the wrong colour value, those boxes exist. They will be in circulation for two years. The supplier's prepress department has archived the file and will reuse it for the reprint, and when the reprint is ordered by somebody new who was told to keep it consistent with the last one, the defect propagates rather than resolving.

Everything upstream of that changes as a result. Validation cannot be iterative in the way it is with software, because there is no cheap iteration. The colour has to be right before anything is sent, which means the specification has to be exact before it is useful, which means the work is front-loaded in a way that feels old-fashioned and is not negotiable.

A short audit you can run this week

If you want to test this on your own system rather than take my word for it, five questions are enough. This is the audit I use, and it takes about an hour.

1. Pick your five most-used assets. How many files exist for each one?

Count what a supplier would find if you sent them the folder today. If the answer for the logo is nine, the number of wrong choices available is eight. Reduce until the wrong choice requires effort.

2. Take one constraint from your documentation. Is it in the artifact?

Minimum clear space, minimum size, permitted backgrounds. If the rule exists only as a sentence, it will be violated by everybody who never reads the sentence, which is most people. Ask what it would take to build it into the file.

3. Count your negative rules. Then ask who would notice a breach.

If the honest answer is nobody, that rule is documentation of an intention rather than a constraint. Keep it if you need it to settle arguments. Do not count it as enforcement.

4. Time the path from link to file.

Open your distribution in a private browser window with no session. Count the steps to a usable download. Every login, every form field and every folder is a step where somebody with a job to finish gives up and uses whatever they already had.

5. Look at your agreements, not just your files.

Find any clause that makes you a required participant in something you have described as transferable. That clause is telling you the truth about the system, and the description is not.

What this suggests for systems with reachable users

I am not arguing that product design systems should adopt these constraints. Most of them do not apply, and building for an unreachable audience when your audience is reachable would be a waste.

The useful question is a different one. If you removed the ability to reach your consumers, how much of your system would still work?

Not the parts that depend on onboarding. Not the parts that depend on someone noticing a violation in review. Not the parts that live in a Notion page that a new hire is told to read. What would remain is the part that is genuinely encoded: constraints built into the artifacts, names that make the wrong choice unlikely, and definitions that a machine or a stranger can act on without interpretation.

That remainder is the system. The rest is a process that happens to be working because the people running it are still there.

There is a version of this test you can apply to your own agreements rather than your own files, and it is uncomfortable. My contract used to say that the client could not alter the underlying construction without involving me. I wrote that clause believing it protected the integrity of the work, and for a long time it read as reasonable. What it actually did was make me a permanent dependency of a system I had described as fully transferable, which meant the transfer was conditional and the description was not accurate.

I removed it. After final payment the client can change the construction themselves or hand it to somebody else, without asking. The guidelines are advice now, not permission. If the system only holds together while I am reachable, then what I built was never a system, and finding that out from a contract clause is cheaper than finding it out from a client who has moved on.

Three things worth taking away

Constraints that live in documentation are suggestions. Constraints built into the artifact are constraints, and the difference only becomes visible when the person holding the file has never heard of you.

Negative rules decay without announcing it, because nothing fails when they are broken. Keep few of them and put them where the file lives.

Distribution beats specification. A weaker system that people actually reach will outperform a better one behind a login every time.

I would like to know whether this holds for teams working entirely internally. My guess is that the unreachable-consumer test is uncomfortable in most organisations and that a lot of what passes for a system is a process with good attendance. If you run those five questions on your own system, I am interested in what breaks.