The Intent Ledger
← All articles

Design Narrative: How to Write One That Holds Up

Design Narrative: How to Write One That Holds Up

A design narrative is a short written account of what a project is, why it takes the form it does, and which decisions got it there. In architecture it usually runs from a single sentence to a few pages. It explains the idea in plain language, ties that idea to physical choices, and gives clients, reviewers and your own team something to test later decisions against.

This guide covers what the term means, how it differs from a design intent statement and a design intent document, how to write one in five steps, and what good examples look like. It also covers the part most guides skip: keeping the narrative true as the project changes.

Theintentledger
theintentledger.com
Keep the Reasons Behind Design Decisions
The Intent Ledger turns project conversations and feedback into source-backed records, helping your team trace narrative claims to the decisions behind them.
Explore project memory software

TL;DR

  • A design narrative explains the idea behind a project and links it to specific physical choices. A design intent statement is the shorter, goal-focused cousin.
  • Start with one sentence that almost anyone can understand, add a sentence on what is distinctive, then prove both with concrete design elements.
  • The narrative changes as the project moves from brainstorming to concept to specification. Write it again at each stage instead of freezing the first version.
  • A narrative only stays credible if you can trace its claims to the conversations and decisions behind them.
  • Use the template below as a starting point for a one-page version.

Table of Contents

What a design narrative is (and what it is not)

The phrase covers a few different things, so it helps to separate them.

In architecture and interior design, a narrative is the story a project tells through its form, materials and sequence of spaces. An academic study from the Glasgow School of Art describes narrative architecture as architecture that, like a book, tells a story through morphology, construction choices, materials and the arrangement of spaces, while leaving visitors some freedom in how they read it. Another academic paper frames narrative as a meaningful sequence of events, signs, places and spaces, where each part gains meaning from its relation to the others.

As a document, a design narrative is the written version of that story. It is what you attach to a competition entry, a planning submission, a client presentation or a studio review. This is the meaning this article focuses on.

It is not a narrative designer’s job in games, a brand story, or a marketing blurb. Those are different disciplines that happen to share a word.

The useful way to hold the idea: a narrative is an argument. It claims that this building, with these moves, answers this problem. Each claim should be checkable against the drawings.

Design narrative vs. design intent statement vs. design intent document

Readers often use these three terms interchangeably. In practice they do different jobs.

Design narrative Design intent statement Design intent document
Main question What is the story of this design and why does it look this way? What must this design achieve and protect? What are the goals, criteria and decisions we are building to?
Typical length One paragraph to a few pages One to three sentences, sometimes a short paragraph Several pages, often structured sections
Voice Descriptive, persuasive Declarative, testable Reference, procedural
Audience Clients, juries, reviewers, planners The whole team, contractors Project team, owner, commissioning and construction teams
Changes over time Rewritten at each stage Rarely, and deliberately Updated with logged revisions

The term “design intent” itself is slippery. The Designing Buildings wiki notes that ASHRAE’s guideline defines it as a detailed explanation of the ideas, concepts and criteria the owner considers important, and that the term is also loosely used for early designer thinking. That ambiguity is why it pays to say, in your own document, which meaning you use.

Formal versions exist too. In Wales, a Design and Access Statement is required for certain planning applications. Its job is to communicate what is proposed, demonstrate the design process and explain how access was handled. It typically covers the brief and vision, site and context analysis, design development, and proposal sections on character, access, movement and sustainability. US practice has its own counterpart in commissioning: the Basis of Design is created by the design team in response to the owner’s project requirements and includes narrative and specification addressing the owner’s goals.

These are not the same thing as a studio’s narrative, but they share one habit: they state the problem, then show how the design answers it.

What a design intent statement should explain

A design intent statement is the compact core of the narrative. A good one does three things.

  1. Names the purpose. What is this project for, and for whom?
  2. Names what must not be lost. The qualities, relationships or performance targets that later decisions must protect.
  3. Is testable. Someone reviewing a change can ask, “does this still do what the statement says?” and get a clear answer.

The AIA makes the underlying point about problem statements: a well-stated problem should be written before the design process begins, or very early in it, because intuition alone is not enough to express the problem clearly. An intent statement is the designer’s answer to that stated problem.

Design intent statement examples

These are illustrative drafts written for this guide, not quotes from real projects.

  • Community library: “A civic reading room that feels like an extension of the street: daylight, visible activity and no thresholds that say ‘members only’.”
  • Clinic renovation: “Keep the waiting experience calm by separating arrival, check-in and treatment sightlines, even if it costs us floor area.”
  • Residential addition: “The new volume should read as a quiet companion to the original house, matching its eave line and deferring to its front elevation.”

Notice the shape. Each states a purpose, a quality to protect, and enough specificity that a contractor or a client could say “that change breaks it.”

How to write a design narrative in five steps

The approach below draws on a young architect guide to project narratives, which recommends starting with a simple sentence that states the concept, following it with a concise angle on what the design does and what is unique about it, and then using specific physical design elements to support both claims.

Step 1: Write the one-sentence concept

If you cannot say the idea in one sentence that almost anyone could understand, the idea is not finished. Avoid jargon and avoid metaphors that need a diagram to decode. “A house that opens toward the garden and closes toward the road” beats “a dialectic between enclosure and openness.”

Step 2: Add the angle

One more sentence on what the design does and what makes your interpretation different. Many projects share the same brief. This sentence is where yours separates from the pile.

Step 3: Prove it with physical elements

This is where most weak narratives fail. Every claim needs something you can point at: a courtyard, a roof pitch, a material, a threshold, a view line. If you say the building is “welcoming,” name the elements that make it so: the deep porch, the glazed entry, the absence of a reception desk.

Step 4: Show the process

Reviewers and planners want to know the design was reasoned, not arrived at by accident. Briefly state what you considered, what you rejected and why. A Design and Access Statement formalizes exactly this by asking for design development alongside the final proposal.

Step 5: Match the length to the stage

Research on storytelling in design describes stories evolving from generative brainstorming, to expressive concept, to prescriptive specification. Your narrative should follow the same arc. An early narrative can be open and exploratory. A late one should be precise enough to guide a specification. The same source suggests treating stories as tools for exploring needs and grappling with messy, ill-defined issues, not as blueprints. That is a useful attitude: the narrative guides decisions, it does not replace them.

A one-page template you can copy

Use this structure and cut anything that does not apply.

  1. Concept sentence. One sentence, plain words.
  2. Angle. What is distinctive about how this project answers the brief.
  3. Context. Site, climate, neighbors, program, constraints. Three to five lines.
  4. Key moves. Three to five physical decisions, each with a one-line reason.
  5. What we are protecting. The two or three qualities the team must not lose in value engineering or revisions.
  6. Open questions. What is still undecided and who owns it.
  7. Source trail. Where each key decision was made: the review, the client meeting, the email thread.

The last two items are the ones most studios leave out, and they are the ones that save you six months later.

Examples of narratives in built work

Good narratives are visible in the buildings themselves. Two documented cases show how different a narrative can be.

Franklin Court, Philadelphia (1976). A historical account describes the site’s use of a spatial montage: archaeological remains, a ghost structure and an underground multimedia museum, offering visitors an open-ended experience of history, memory and time. The narrative is not told in words on a wall. It is carried by the arrangement of elements, and left open to interpretation.

Institut du Monde Arabe, Paris (1987). A general architecture guide notes that the building combines Western and Islamic architectural elements to illustrate and nurture the relationship between France and the Arab world. Here the story is explicit and can be stated in one sentence, which makes it easy to teach and to defend.

Between them, they show the range. A narrative can be a clear thesis or an open invitation. Either way, it works when the physical moves and the written account agree. The philosopher Paul Ricœur treated time as the common ground between narrative and architecture, and a presentation of his ideas on architecture and narrativity describes built space as “condensed time.” That is a good reminder for the writer: a narrative is about sequence. What comes first, what follows, what the visitor or the client discovers along the way.

Why narratives drift, and how to keep yours honest

A narrative written at concept stage is accurate for about a month. Then the client asks for more parking, a cost review removes the skylight, a consultant moves a shaft, and the story in the document no longer describes the building.

Three things usually go wrong:

  • The reasons live in conversations. The decision to drop the skylight happened in a call. The reason (a roofing warranty issue, say) was said out loud and never written down.
  • People leave. A junior designer inherits a drawing and cannot tell whether a odd detail is deliberate or an accident.
  • Nobody updates the narrative. It gets revised for submission and then abandoned.

The fix is a habit, not a better template. Record each significant decision when it is made, with its reason, its source and what it affects. Then the narrative becomes a summary of a decision trail, rather than a story you reconstruct from memory at the end.

If you want to build that habit, these pieces from our blog go deeper on specific parts of it: a design documentation template that captures decisions and not just tasks, a guide to design intent drawings with a copyable record format, and a walkthrough of capturing design intent with ADR discipline. For the meeting side, see our notes on traceable design meeting notes and a three-phase design review checklist.

Our perspective

We build project memory software for design teams, and the pattern we see most is simple: the narrative is rarely wrong at the start. It is wrong a year later, because the reasons behind changes were never kept.

We think of a narrative as the visible tip of a much larger body of reasoning. The decisions, the rejected options, the client’s concerns, the risks someone flagged in a critique: that is the real story of a project. When it is captured with its source, a narrative stops being a chore at submission time and becomes something you can assemble in an afternoon, because every claim points back to the conversation it came from.

That is why we focus on the why and not only the what. A list of decisions tells a new team member what happened. A record of why tells them what they are allowed to change.

For students, the same applies. A critique produces a dozen comments, and a month later you remember three. Keeping the comment, who said it and what you did about it turns feedback into a defensible design story.

, Rajas

Turning conversations into a narrative you can defend

The Intent Ledger converts meeting notes, transcripts, critique feedback and client comments into ILM Records: structured entries for decisions, design intent, risks, actions, commitments and unresolved questions, each traceable to the conversation it came from. When you sit down to write the narrative, the “key moves” and “what we are protecting” sections of the template above are already there, with their sources.

If you want to try it on one project, the one-off Project Record pack at $29 is a practical starting point, and monthly plans begin at $29 per month for ongoing work. Full details of every pack and plan are on the pricing page. You can also see the overall approach on our home page.

Common mistakes to avoid

  • Adjectives instead of evidence. “Light-filled, dynamic, welcoming” says nothing unless you name the elements that deliver it.
  • A story that cannot be falsified. If no change could ever contradict the narrative, it is decoration, not intent.
  • Writing it only at the end. The reasoning is easiest to capture while the decision is fresh.
  • Mixing audiences. A planning officer, a client and a contractor want different emphasis. Keep one core narrative and adjust the cover.
  • Hiding the open questions. An honest list of unresolved items builds more trust than a polished story with gaps.

FAQ

What is the difference between a design narrative and a design intent statement?

A design narrative tells the story of the project: the concept, the context, the key moves and the reasoning. A design intent statement is the short, testable core of it, stating what the design must achieve and protect. Many teams write the statement first and expand it into a narrative.

How long should an architectural design narrative be?

It depends on the audience and stage. For a competition board or client deck, a paragraph is often enough. For a planning submission, a few pages with context, process and proposal is typical, and formal documents such as a Design and Access Statement follow set section headings. Start with the one-sentence concept and add only what supports it.

Is a design narrative the same as a Design and Access Statement?

No. A Design and Access Statement is a formal planning document used in places such as Wales, with required content on the proposal, design process and access. A design narrative is broader and used informally and formally across studios. A narrative can be the backbone of such a statement.

How do I keep a design narrative accurate as the project changes?

Record each significant decision with its reason and source at the time it is made, then revise the narrative at each project stage from that record. Treat the narrative as a summary of the decision trail. That way, changes in scope or budget update the story deliberately rather than leaving it stale.

Sources

Design Narrative: How to Write One That Holds Up: The Intent Ledger Blog