Brand Constitution

Give a brand book to a team that did not build it. Ask them to work on a new product, a new audience, or a change in the business. Can they tell which parts of the system still serve the company and which need to change? Can they explain their choice to the people commissioning the work?

That is the handover test I care about. A brand book may contain excellent examples and precise rules while leaving the next team unable to answer either question. Six months later, the team may still have every file and no reliable account of why a particular choice made sense.

In the previous article, I argued that some brand rules can now be applied during production by a machine. That makes a familiar problem more pressing: what should happen when the next request falls outside those rules?

I think a brand needs to preserve its current principles and their dependencies, alongside a history of the decisions that established them. I use Brand Constitution for the first and Decision Log for the second. This is a working model I have not yet run end to end. It comes from situations we encounter in projects, including the one below.

The new brief already contains an answer#

We developed a brand for a CRM serving small businesses. An important premise of the work was that potential customers found CRM systems intimidating. The product could help them, but its communication first had to make it approachable.

Individual features had their own icons, visual treatments, and colors within a shared system. We gave them comparable weight, limited the total palette, and used friendly 3D icons to help explain them. We also defined how new features should enter the communication without disrupting its flow. Those choices were connected: adding capabilities should not make the product look progressively harder to use.

Later, a new marketing team returned with a brief to give AI features much greater prominence and a more independent presence within the brand. There were good reasons to revisit the balance. The product was developing, competitors were talking about AI, and the team needed to make the new capabilities visible.

A brief like this can arrive with a creative answer already attached: make AI feel magical, a result in one click. Within the immediate task of communicating AI, that is an understandable direction. It suggests ease and a large reduction in effort.

Consider it against the earlier audience premise, though, and further questions appear. Does magic make this CRM feel easier, or less predictable? Could AI itself sound like rocket science to someone already wary of complex software? That is a hypothesis to investigate, not something the old brand strategy can settle. What exactly can the customer now accomplish, and would showing that task explain the value better than emphasizing the technology?

There is also a question about the size of the claim. AI might fundamentally change the reason to choose the product. It might improve familiar tasks. Or the immediate communication need might be to show that the company is keeping up. Staying current is a legitimate objective, but it does not automatically call for the same changes as a new product proposition.

The project and the new request are real; I am leaving the company unnamed. The questions and possible directions here illustrate how I would use the proposed model. They are not a report of a completed Constitution process or its results.

Following the decision into the design#

The original guidelines can tell a new team how much visual independence a feature gets. The reasoning behind them explains why that limit existed. With access to both, the teams can examine the request in the context of the whole product, even if nobody in the room worked on the original brief.

They might conclude that AI deserves more prominence while the approachable character of the brand still matters. They might find that the product has changed enough to reopen the feature hierarchy itself. The earlier decision to give features comparable weight should be available for reconsideration, with its original purpose visible.

That discussion reaches quite concrete design choices. Suppose a star represents AI and a telephone represents calls. A standalone star presents AI as something the customer can encounter in its own right. A small star beside the telephone suggests an AI capability within a familiar activity. Both could belong in the system: the standalone symbol when explaining AI across the product, the combined symbol when showing what it does for calls.

The choice affects what customers think they are being offered. A separate AI character, a property shared by existing characters, and a completely new visual treatment each describe a different relationship between AI and the product. We need to understand that relationship before deciding how much of the website to recolor.

This is where I would want the documents to earn their place. A short account of the original audience premise and the decisions it shaped gives both teams a common starting point. They can identify what the new brief changes, which questions remain open, and how far the consequences might reach. The answer may require amending the brand.

Brand Constitution: the current logic#

A Brand Constitution describes the logic currently in force: the audience and strategic choices the brand is built around, the relationships between its major decisions, and the boundaries within which new work can develop. It also specifies how those commitments can be reconsidered and who needs to be involved.

Thomas Marzano also uses the term in his work on brands in an agentic economy.¹ My focus here is on how teams inside the company and its agency can recover the reasoning behind a brand and use it to make new decisions.

Positioning, messaging, visual guidelines, and component libraries can stay in their existing documents. The Constitution connects the relevant decisions across them. In the CRM example, it would make the relationship between audience anxiety, an approachable product story, and the treatment of features explicit.

For a consequential principle, I would want to find three things:

1. What are we currently committed to?
2. Which assumptions and other decisions does it depend on?
3. What does it require of the work that follows?

These connections help a team judge how much of the system a new request puts into question. A change in an icon may concern only execution. A change in the status of AI could reach the message hierarchy, the product story, or the audience the company wants to serve. Following the dependencies helps locate the scope of the decision.

I use the word constitution because the procedure for change belongs inside the system. If a premise no longer holds, the team needs a way to revise it and review the decisions that relied on it. If the premise still holds, a new execution may be possible within it. The designer can resolve some changes; a change to the main product promise needs the people responsible for that promise involved.

This leaves considerable room for creative judgment. Several concepts may fit the same position, and compatibility alone tells us little about how memorable or compelling they are. The Constitution helps establish the problem and the constraints. The team still has to make good work.

Decision Log: how we got here#

The Constitution needs to remain current. The Decision Log preserves history, including decisions that have been replaced. It records what the team knew at the time, what it chose, and the consequences it accepted. An old premise should remain findable after it stops governing the work.

Michael Nygard described a useful precedent in his 2011 proposal for Architecture Decision Records: short notes that preserve the context and consequences of significant technical decisions. When a decision changes, the old record is marked as superseded and linked to its replacement.² A brand team could use the same approach.

For the CRM, a short record could look like this. This is a retrospective illustration of the format, based on the reasoning described above; we did not keep a formal log at the time.

Context

The branding work proceeded from the premise that potential customers found CRM systems intimidating. Features needed to be understandable individually while still feeling like parts of one approachable product.

Decision

Give features comparable weight within the communication. Differentiate them through friendly 3D icons and a shared, limited palette. New features should enter this system without fragmenting the overall product story.

Consequences

Features can have distinct identities within a common hierarchy. Giving one a substantially more independent presence requires reviewing whether that hierarchy still serves the audience and the product.

A later entry could document a change to that hierarchy, why the new role of AI justified it, and which parts of the approachable visual language remained useful. Keeping both entries would help a future team distinguish a forgotten agreement from an assumption that no longer holds.

Dates, the people responsible for the decision, and links to the work would make these records usable. So would the basis of the claim: a customer research finding, a client observation, or a design team's hypothesis should be identified as such. Otherwise, an interpretation can harden into a supposed fact simply by surviving in a document.

There is another risk in preserving reasons. Creative work rarely follows the tidy order in which we later present it. In The Reflective Practitioner, Donald Schön examines an architecture studio exchange in which design moves reveal consequences that reshape the understanding of the problem.³ A team can discover an important principle while making the work.

That principle may belong in the Constitution once the team accepts it. The Log should distinguish an explanation developed during or after the work from an intention that preceded it. Recording that difference would be particularly important for a system like this, which could otherwise turn every intuitive discovery into a falsely orderly story.

Why this is more practical now#

Preserving the reasoning behind a brand has always been desirable. In the projects I know, the obstacle was the work of collecting it: someone had to follow discussions across calls, messages, and design reviews, then keep the record useful as decisions changed. That could become a job of its own, so much of the context stayed with the people doing the work.

Now AI can help with that clerical part. In the workflow I have in mind, it extracts candidate decisions from transcripts and comments, connects them to existing principles, and drafts short records for review. A person checks the reasoning and decides whether it deserves to be kept. A fluent explanation of a meeting is not necessarily an accurate account of why a choice was made.

At the start of a new brief, the system should make it easy to retrieve the few relevant decisions. The new marketing team needs the reasoning behind the feature hierarchy, not a complete archive of the branding project. The cost to test is the whole loop: capturing, checking, maintaining, and retrieving the record, against the time spent reconstructing context without it.

Where this goes wrong#

I would record decisions that constrain future work or would be expensive to reconstruct. The reason for limiting feature differentiation qualifies. Most feedback on an individual layout does not. The useful record contains context that the finished artifact cannot show, with a link to the artifact for everything it can.

A report looks enough like a result that a team can finish documenting its decisions and feel the project has advanced, even when the work is no better. That is how documentation starts replacing the activity it was meant to support. If a designer spends two hours designing and another two explaining what they designed, the method has failed. I would judge it by whether it helps the team reach and carry through a sound decision with less repeated work.

The case for maintaining this becomes stronger as change and team turnover become routine. For a stable brand with infrequent new work, a lighter record may be enough. AI makes the clerical part worth testing again; it does not establish the value of the method in advance.

Back to the test#

I would return to the opening test with a brief like the AI request. Can the team explain why the old system took its shape? Can it identify what the new request challenges, examine the assumptions involved, and develop an answer with the client? Can it change an earlier rule without losing track of the consequences?

A few years after a branding project, both teams may have changed and the product may be doing something nobody anticipated. They need enough of the earlier reasoning to decide what to carry forward and what to revise. That is the continuity I want a Brand Constitution to make possible: a new team can take the brand somewhere new and give a considered account of how it got there.

If you have seen a brand rule outlive the reason it was written, I would like to hear what happened when the team tried to change it.

References#

1. Thomas Marzano, Brand Constitutions: The Legible-Lovable Standard for Building Equity in an Agentic Economy, Brandingmag, 2026. ↩
2. Michael Nygard, Documenting Architecture Decisions, November 15, 2011. ↩
3. Donald A. Schön, The Reflective Practitioner: How Professionals Think in Action, Basic Books, 1983, chapter 3, “Design as a Reflective Conversation with the Situation.” ↩