Identity systems that survive contact with product teams

The forty-page problem

Most brand projects end with a PDF. It is careful work. Logo spacing, colour values, type scales, tone of voice.

We checked the download numbers on one of these once. Eleven opens in a year. Nine were new hires in their first week.

The brand was not ignored because people disliked it. It was ignored because opening a PDF, finding a rule, and copying a colour by hand is slow. Guessing is fast.

It is not laziness

This part matters. Product teams do not go off-brand on purpose.

Every off-brand thing we have traced back came from someone who could not find the right file, or found it and could not open it. Usually on a deadline.

If the correct path is slower than the wrong one, people take the wrong one. That is not a discipline problem. It is a design problem, and it is yours to fix.

Put the brand where the work happens

The fix is boring. Ship the brand as something a developer can install and a designer can drop straight in.

Tokens, not screenshots. Colours, spacing and type as named values the code can read.
Components, not pictures. A button they can use, not an image of a button.
One page of rules. The five things that actually matter, not forty pages.
Templates for the dull stuff. Slides, social posts, documents. This is where drift starts.

When the on-brand option is the easy option, the brand holds by itself. You stop policing it.

Write rules people can hold in their head

Long guidelines fail because nobody memorises them. Short ones work because people do.

On one identity we built, the whole system came down to four angles. Every line, crop and shape used one of them.

Every angle in the system is 0°, 30°, 60° or 90°. Nothing else.

A new designer learns that in a minute. And you can spot a mistake from across the room, which means the team corrects itself without you.

Test it before you leave

Before handover, give the system to someone who was not on the project. A junior designer, or a developer who has never seen it.

Ask them to make something ordinary. A social post, a settings page, whatever is normal for you.

Watch where they get stuck. That is your list. Fix those things, then hand over. Half a day of this catches more than another week of polishing.

The handover meeting that actually works

Most handovers are a presentation. Someone walks through slides, everyone nods, and nothing changes.

Ours are a working session. We bring a list of real things the team has to make that month, and we make them together, live, using the system.

It is slower and a bit awkward. It is also the only version where people leave able to use the thing. If nobody touches a keyboard during your handover, it was a presentation.

Signs the system is failing

You can usually spot trouble months before the brand visibly drifts. Watch for these four.

People ask you for files that already exist. It means they cannot find them.
Someone rebuilds a component that is already in the library.
New work looks right but is put together wrong underneath.
The system has not changed in six months. Living systems grow.

Every one of those is a usability problem, not a discipline problem. Fix the friction and the behaviour follows on its own.

What good looks like a year later

The honest test is not launch day. It is twelve months later.

Ask two questions. Has the team added anything to the system without asking you? And does the newest work still look related to the oldest?

Two yeses mean it worked. If the team stopped extending it, the system was too hard to use. If the new work drifted, the rules were too vague.

Worth remembering

In four lines

Ship code and tokens, not a PDF.
Make the on-brand path the fastest path.
Keep the rules short enough to remember.
Test the handover on someone who was not there.
Judge it at twelve months, not at launch.

Questions we get asked

Do we still need a guidelines document?

Yes, but a short one. It is for the decisions code cannot hold, like tone of voice and when it is fine to break a rule. Ours usually run under ten pages.

Who maintains the system after handover?

Your team should. If they cannot, it was built wrong. We hand over ownership, not a dependency on us.

What if we do not have engineers?

Then ship templates instead of code. Same idea. Put the brand inside the tool people already open.

Working on this yourself?

We help teams sort this out for a living. Tell us what you’re building, or see how it went for other people.