A brand someone else has to run

Most brand guidelines are written for designers. They say things like "use the primary green for emphasis" and assume the reader knows what emphasis means, which green is primary, and what to do when the green does not have enough contrast against the thing behind it.

Then the guidelines get handed to a volunteer who joined six weeks ago and needs to post an event tonight.

I have built brand systems for two organizations where nobody applying the brand is a designer, and where the people doing it change. That constraint is not a smaller version of the normal problem. It is a different problem, and most of what I would normally do makes it worse.

The failure is drift, and it is invisible

Here is the thing that actually happens, from an organization I work with.

They have two sets of official colors. One is a seven-color swatch set linked from their public press kit. The other is the palette their newsletter template has been built on for over a year. None of the hex values match. Both sets are in active use, and one of them is published for any journalist to pick up.

Nobody did anything wrong. A palette was set, a newsletter was built later by someone working from what looked right, a press kit was assembled later still from a different source. Every individual step was reasonable. The result is an organization that cannot answer what color it is.

I found it by writing the brand down and noticing the two sections disagreed. It had been true for months. Nothing on any screen looked broken, which is exactly why it survived.

That is what brand failure looks like when non-designers are operating the brand. Not an ugly logo. A slow divergence nobody can see from inside any single decision.

Take away the decisions, not the quality

The reflex is to write more guidance. Longer document, more examples, a decision tree. It does not work, because the person you are writing for is not going to read a decision tree at nine at night before an event.

The thing that works is removing the decision.

On a collaboration product I built for volunteer groups, an organization can brand its own space with exactly three things: a logo, a square icon, and one color. That is the whole system. There is no secondary color, no accent, no typography choice, no layout option.

Three is not laziness and it is not a limitation of the software. Every additional knob is a way for a volunteer to produce something that fails a contrast check without knowing they did. One color, applied by the system in places the system controls, cannot drift far.

Make the system refuse bad input

The single most useful thing in that product is not in any brand document. When someone saves a brand color, the software checks it against the surfaces it will actually appear on, and if the combination fails, it refuses the color and says so.

This matters more than it sounds. The alternative is a guideline that says "ensure sufficient contrast," which puts the work on a volunteer who has no way to do it and no idea it is expected of them. A rule nobody can follow is not a rule, it is a way of assigning blame later.

The same principle shows up in the content tools I built for the nonprofit above. Their species profiles are not a blank rich-text box. They are named fields: scientific name, habitat, diet, status. A volunteer fills in fields. That is the difference between a set of profiles that stay consistent and a set that drift apart as different people write them, and it required no guidance at all, because the form is the guidance.

If a brand rule matters, build it into the thing people touch. If it cannot be built in, be honest that it is a suggestion.

Tell them what normal looks like

One more piece, and it is the one I see skipped most.

That nonprofit's newsletter is set in Montserrat. It renders in Apple Mail and iOS Mail. It falls back to Arial in Gmail and in Outlook for Windows, and there is nothing to be done about that, because email clients are email clients.

So the brand documentation says that. In writing. Along with the note that it is expected rather than a bug.

Without that line, here is what happens: a volunteer opens the newsletter in Gmail, sees the wrong typeface, and either reports a defect that is not a defect, or quietly starts "fixing" it, or loses confidence in the whole system. I have watched all three. A brand system for non-designers has to document its own imperfections, because the people using it cannot tell the difference between a flaw and a normal fallback.

What this actually costs

Less than you would think, and the savings show up in a place people do not expect.

Building the brand takes about the same effort. Building the system around it costs more up front: the validation, the named fields, the documentation of what is normal. What you get back is that nobody has to police it. There is no designer reviewing every post, and there is no annual cleanup where somebody discovers the two palettes.

The test I use is simple. Hand the brand to the newest volunteer, give them a real task, and leave the room. If what comes back is fine, the system works. If what comes back is fine only because that particular person happened to have good taste, it does not.

If you run an organization where the people producing your materials are not designers and never will be, that is not a constraint to design around. It is the design brief. Tell me what you are working with.