Documentation vs. hypothesis

Have you ever bought LEGO?

Every set comes with instructions on how to assemble it. You follow the instructions and — et voilà! — a mini pixel-like Millennium Falcon sits on your shelf.

In your opinion, how many times did the LEGO team assemble this set before writing instructions for you?

Brand identity guidelines are no different from the assembly instructions. They show you how to recreate what has already worked.

"What has already worked" is a key phrase here. It means that:

1. The type stack described in the guidelines is already being used on the website, in the app, or the pitch deck, or the whitepaper.
2. The color palette described in the guidelines is exactly the palette that has already been used in the released app, or the presented pitch deck, or the published blog articles.
3. The imagery described in the guidelines was already tested in social media, and performed well. And so on.

Very often, I see brand guidelines that capture design hypotheses, or I-believe-it-will-work concepts. But here's the thing:

Brand guidelines are the documentation of the field-tested visual language. Just like your dev documentation. (Would you write instructions to requesting proof from your API without testing these instructions? Unlikely.)

Here is a flow chart that will help you identify the right moment to request the guidelines delivery:

I hope that one day this issue will help you.

To your smooth design process!
Ira

P.S. (in case you wonder why I linked the website launch step straight to the guidelines, skipping the pitch deck design)

A pitch deck and a website share the same complex elements – the same type hierarchy, the same layout, and the same imagery usage. In fact, you can create a pitch deck by slicing your website into screens and filling it with new content.

That is why having done and tested one of them is enough for the guidelines.