The Intent Ledger
← All articles

Project Diary for Design Projects: What to Record and How

Project Diary for Design Projects: What to Record and How

A project diary for a design project is a dated working record of what happened, what was decided and why. It is not a decorated journal. A good entry names the decision, the alternatives you weighed, the reason you chose one, and who said what. Keep entries short, date every one, and link each to the conversation it came from. That is what lets you answer “why did we do it this way?” months later.

This guide covers what to put in each entry, a template you can copy today, sample entries for critiques and client feedback, and how to keep the diary alive without duplicating your meeting minutes. If you landed here looking for cover and page-decoration ideas, this page is about the other kind of diary design: the structure of the record itself.

Theintentledger
theintentledger.com
Keep the Why Behind Design Decisions
The Intent Ledger turns project conversations, critique feedback, and client comments into source-backed records teams can revisit as work evolves.
Explore project memory software

TL;DR

  • A project diary is a dated process record of a design project, covering inspiration, ideation and iteration, not just the final result.
  • Each entry should hold the decision, the alternatives considered, the rationale and the date, plus the source conversation.
  • Keep the template short, such as a two-column table or four short paragraphs, and log significant decisions rather than every tweak.
  • Students, junior designers, freelancers and small studios all gain the same thing: context that survives staff changes, long gaps and client memory drift.
  • Write entries so they point toward the next action, and mark open questions so they get closed.

Table of Contents

What a project diary is, and what it is for

Design research uses several names for the same idea. A 2020 paper on documentation practices describes process journals, also called diaries, workbooks, log books, sketchbooks, development folios and notebooks, as records used to document the stages of a design project, including inspiration, ideation and iterative development. A general definition from an evaluation resource is similar: a written record of significant activities, events or processes across the life of a project, kept so you can reflect and improve later projects.

In architecture and design education, the closest relative is the design decision trail. The University of Northampton defines it as a dated, visual narrative of a design project that shows the designer’s thinking throughout. Notice the two ingredients: dates and thinking. A folder of finished drawings has neither.

So what is the diary for? Four jobs come up again and again:

  1. Evidence. Purdue’s design notebook guidance says documentation gives usable evidence of the work, supports professional development and can improve communication with clients.
  2. Continuity. When someone new joins, or you return to a project after a gap, the diary explains how you got here.
  3. Reflection. Writing forces you to name your reasons, which makes weak reasons visible.
  4. Follow-through. Entries that end with an action or an open question keep decisions from evaporating.

Why design teams in particular need one

Design work produces decisions faster than it produces paperwork. A wall changes in a pin-up, a client asks for a different entry sequence in an email, a consultant raises a constraint on a call. The drawing set shows the result. It rarely shows the reason.

That gap is where projects lose time. Someone redraws a detail that was changed for a reason nobody remembers. A client disputes a choice they approved verbally. A junior designer inherits a task and cannot tell where it came from. A diary closes the gap because it records the why next to the what.

Centralized documentation also helps beyond the design team. LogRocket’s guide describes it as a single source of truth that helps teams understand design history, onboard new members, support future design audits and stay aligned across functions. The same logic shows up when design hands work to builders or developers: a shared record reduces the back-and-forth, which is the argument behind guidance on design-to-dev handoff.

There is a cost, and it is honest to name it. A Chalmers University study of student diaries found that forced pauses for reflection can interrupt creative flow, yet the same pauses made designers more aware of their decisions and better able to judge them. The practical lesson: keep each entry small and write it at a natural pause, such as the end of a review, not in the middle of sketching.

What every entry should capture

The research on design decision records is consistent. A decision record should hold the decision, the alternatives considered, the rationale and the date. For iterations, UK government design teams advise recording the change made and the reason for it, ideally tied to research insights, regulation changes or technical constraints. Another UK government guide breaks it into three parts: what prompted the change, exactly what changed, and the outcome.

For a design practice, we would turn that into the following fields.

Field What to write Why it matters
Date The day the conversation or decision happened Gives you a timeline you can defend
Decision or change One sentence, in plain words Lets a reader scan the log
Alternatives What else was on the table Stops the same debate returning
Rationale The reason, tied to evidence or constraint This is the part memory loses first
Source Meeting, critique, email or call it came from Lets anyone verify the record
Owner and next action Who does what, by when Turns a note into follow-through
Open question What is still unresolved Keeps loose ends visible

The fuller version of this idea, with eight fields for formal decisions, is in our guide to the record of decision. If your team prefers a lighter structure, the decision log template shows a compact version.

Capture the source, not just the summary

A summary says “client prefers timber cladding.” A sourced entry says the client said so in the second review, after seeing two options, and gives the reason they stated: maintenance cost. Months later, when the budget changes, you know which reason to revisit. That traceability is the difference between a diary and a list of facts.

A short template you can copy

The same guidance that recommends these fields also recommends restraint: keep templates short, such as four paragraphs or a two-column table, so people actually use them, and focus on significant decisions rather than every micro-adjustment.

Here is a version in that spirit. Copy it into whatever tool you already use.

Entry title: (short, specific, e.g. “Entry sequence moved to north side”)

Date:

Source: (which meeting, critique, email or call)

What was decided: (one or two sentences)

Alternatives considered: (one line each)

Why: (the reason, with evidence or constraint)

Next action and owner:

Still open:

That is it. If an entry takes more than five minutes, the template is too heavy or the decision was too small to log.

What a fuller template can add

For studio or course settings with more process to show, City College of New York’s teaching material suggests a diary can include problem understanding, observations, prototype sketches, testing procedures and results, pin-up session notes, a decision grid for comparing strengths and tradeoffs, rules of thumb and gallery-walk notes. Add these sections only when the project calls for them. A small residential job rarely needs a decision grid on every choice; a competition entry or a studio crit often does.

Purdue’s guidance adds habits that make any template work better: consistent dates, format and terminology, references to credible sources, records of client interactions, conclusions and recommendations, and notes that point toward future action rather than merely recounting what happened. For a ready-made layout aimed at design teams, see our design documentation template.

Sample entries: critique, client feedback, decision

The three entries below are illustrative samples we wrote to show the format. They are not drawn from a real project.

A critique entry

Date: Week 6, Thursday. Source: Midterm crit, reviewer panel. Feedback: Reviewer questioned why the stair sits at the center of the plan, since it splits the studio floor. Response agreed: Test the stair at the east edge in the next model. Why it matters: The split floor was blocking the shared critique wall, which was the main design intent. Next action: Build the east-edge option by Tuesday. Open: Does moving the stair break the egress distance?

The entry keeps the feedback, the response and the reason in one place. Student diaries serve this purpose well: the Chalmers study reports that regularly completed diaries helped students develop terminology and arguments for design choices and gain a more critical understanding of their decisions and outcomes.

A client feedback entry

Date: March 12. Source: Client call, recorded notes. Decision: Kitchen island reduced from 9 ft to 7 ft. Alternatives: Keep 9 ft and shrink the pantry; remove the island. Why: Client wants a clear walking path from the garden door, and said the pantry matters more than seating. Next action: Redraw the plan and send it before the next call. Open: Seating for four still needs a solution.

For a freelancer, this is the entry that settles a later “I never agreed to that” conversation, because it names the date, the source and the reason.

An internal review entry

Internal reviews belong in the diary too. An Architects’ Journal piece on design review describes pre-emptive crits inside the design office early in the process as a way to surface gaps and inconsistencies, such as a plan that does not match its section, before they reach stakeholders. Log what the internal review found and what changed because of it. Our 3-phase design review checklist and our templates for design review notes show how to structure these sessions so the outcomes land in the record.

Structuring the diary so you can trace things

A diary that cannot be searched is a diary nobody opens. Three structural choices make the difference.

Chronological first, then tagged. Keep entries in date order, because the timeline is the evidence. Then tag each one by topic (cladding, egress, budget) and by type (decision, risk, action, question). Tags let you pull every decision on one subject without rereading the whole log.

One decision per entry. Bundled entries hide their reasoning. If a meeting produced five decisions, write five short entries that share a source.

Attach the raw material, summarize the meaning. The Northampton source describes a decision trail as an edited narrative that can combine research data, the brief, design-journal material, development drawings, sketchbooks, sketch models, prototypes, CAD and technical reports. The word edited matters. The diary does not store everything; it points to where everything lives and says what it means.

Structured records also help the group think together. Peter Dalsgaard’s paper on reflective design documentation reports that structured documentation can support shared reflection and discussion among participants in an ongoing design project. A diary that the whole team can read becomes a discussion tool, not a private archive. If your decisions also need an audit-friendly chain, our six-field decision audit trail walks through critique-driven work.

Keeping it current without duplicating meeting minutes

The fastest way to kill a project diary is to make it a second set of minutes. Minutes record who attended and everything discussed in order. The diary records only what changed the project and why. A simple division of labor works:

  • Minutes answer “what was said?”
  • The diary answers “what did we decide, why, and what happens next?”
  • The drawing register answers “which version is current?”

Some habits keep the diary light:

  1. Write within a day of the conversation. Details fade fast, and reasons fade first.
  2. Log only significant decisions. If reversing the choice would cost time or money, or someone might ask about it later, log it.
  3. Link, do not paste. Point to the recording, transcript or email thread rather than copying it.
  4. Review open questions weekly. A five-minute scan keeps unresolved items from aging silently.
  5. Close the loop after delivery. LogRocket advises integrating post-launch learnings and metrics so the record shows what worked and what did not. In a building project, that could be a post-occupancy note on a decision made at design stage.

Tool choice matters less than team agreement on where the diary lives. If your team is deciding between a wiki and a notes workspace, a governance checklist for choosing between Notion and Confluence can help you settle who edits, who approves and how records stay findable.

How students, juniors, freelancers and small studios can use it

Design students. The decision trail is built for you. Northampton describes it as a tool that can communicate progress quickly and let students reflect on their performance, and it may help present your qualities to potential employers. After every crit, write down the feedback, what you will change and what you will deliberately keep, with your reason. That last part is what turns critique into an argument you can defend at the final review.

Junior designers. When you receive a task, write down where it came from: whose comment, which meeting, what outcome they want. If the origin is unclear, that is your open question, and asking early beats redrawing late.

Freelance architects. You carry the whole client relationship alone, so the diary doubles as your memory. Log each client instruction with its date and source, and summarize it back to the client in writing when it affects scope or cost.

Small studios. Turnover, leave and parallel projects mean knowledge walks out the door. A shared diary lets anyone pick up a project and see its reasoning. Studios that handle handover often borrow from adjacent trades, where project handover documentation is treated as a shared source of truth for everyone who touches the job.

What we have learned about project memory

We built The Intent Ledger around one belief: the hardest thing to recover on a design project is not the drawing, it is the reasoning. Teams rarely lose the final decision. They lose the conversation that explains it, and with it the design intent that should guide the next choice.

That is why our approach turns conversations, notes, transcripts, critique feedback and client comments into ILM Records, structured entries that hold the decision, the risk, the action, the commitment or the unresolved question, each traceable to the conversation it came from. A diary written by hand is a good start. A diary that is built from the source conversations, and stays linked to them, is one that teams keep using.

Our view is that a project diary should preserve the why, not only the what, and that it should grow into a living project memory over the life of the work. That is the standard we hold our own product to.

Rajas

Turn your conversations into a project diary

If you would rather not write every entry from scratch, The Intent Ledger turns your project conversations, meeting notes, transcripts, critique feedback and client comments into ILM Records: structured, source-backed entries for decisions, design intent, risks, actions, commitments and open questions.

Theintentledger

You can start with a one-off record pack, from the Working Set at $12 to the Studio Ledger at $119, or choose a monthly plan: Working Memory at $29 per month, Living Record at $79 per month or Shared Ledger at $149 per month. See what each includes on the pricing page, or look at the platform overview first.

FAQ

How do I write a project diary for a design project?

Start with a date, the source of the conversation and a one-sentence decision. Then add the alternatives you considered, your reason and the next action with an owner. Write it within a day of the event and keep it short enough that it takes a few minutes.

What should a project diary template include?

At minimum: date, decision, alternatives, rationale, source, next action and open question. Research guidance suggests keeping the template short enough that people actually use it. Add sections such as test results or pin-up notes only when your project needs them.

What is the difference between a project diary and meeting minutes?

Minutes capture what was discussed, in order. A diary captures what changed the project and why. Link the diary entry to the minutes or recording instead of copying them, so you keep one record of the conversation and one record of its consequences.

Do I need to log every design change?

No. Log significant decisions: those that are costly to reverse, that a client or colleague may question later, or that shaped the design intent. Minor adjustments clutter the record and make people stop reading it.

Can a project diary help me in a design school critique?

Yes. A dated diary of feedback, responses and reasoning shows how your thinking developed. The Northampton source describes the decision trail as a way to help students and tutors understand the depth and breadth of the project, which is useful at reviews and in portfolios.

Sources