If you do graphic design for a living — branding, packaging, editorial, web, agency staff or independent — the design itself isn't usually what eats your week. It's the feedback handling. A client sends notes in an email. The art director marks up a PDF. The marketing manager has a Loom video. The CEO chimes in on the third round with a fresh direction. Three weeks in, the version everyone refers to as "the latest" is different on each person's laptop, and nobody can remember why a decision got made.
This guide is about getting the feedback, the versions, and the rationale into one vault where an agent can read across them. The actual files stay in Figma or InDesign or Illustrator. The thinking around the work — that's what moves into the vault.
The actual job of a designer's notes
A design project's notes carry four loads, each of which fails in a particular way when it lives in the wrong place:
- The brief — usually delivered as a PDF, a long email, or both. By the time you're three rounds deep, half the team has forgotten what was originally asked for.
- Feedback rounds — written notes, marked-up PDFs, screenshots with annotations, video walkthroughs. Each round arrives in a different format, in a different app.
- Version history — what changed between v3 and v4, why, and who asked for it. Usually lives nowhere, then becomes a problem when the client says "wait, why did we change that?"
- Project context — brand guidelines, asset libraries, client-specific quirks, past work for the same brand. Lives in your head and dies when you forget which client wanted the warmer palette.
A vault holds all four together. Plain markdown for the text. PDFs auto-converted to searchable text. Audio (the Loom reviews, the client calls) transcribed automatically. Inline databases for feedback rounds and version logs. The same client-side shape applies to many creative practices; see AI notes for client work for the broader version that's not design-specific.
Briefs you actually keep referencing
Most projects start with a brief. A startup wants a full visual identity in three weeks. An editor wants a feature spread for the spring issue. A product team wants packaging for a new SKU line. The brief arrives as a 12-page PDF or a long email — you read it once, and by round three you're working from a half-remembered version.
Drop the brief PDF onto a project page in your vault. It auto-converts to markdown via docstrange, so it becomes searchable text. Now you can ask: "Read the brief. Pull the must-have constraints, the brand color guidelines, the deliverables list, and any constraints around timing or budget I should be tracking against." You get the relevant slices back in plain English.
For client briefing calls, drop the recording onto the same page. It transcribes with speaker labels — useful weeks later for picking out exactly what the creative director said about mood versus what the marketing manager said about timeline. The brief and the call sit side by side, and the agent can quote from either.
When you're three rounds in and the client says "wait, the original brief asked for a more playful direction" — you don't argue from memory. You ask the agent to pull the relevant passages from the brief and the briefing call, and you check what was actually said. That's a calmer conversation than "I remember it differently."
Feedback rounds, captured in one shape
The hard thing about feedback isn't getting it. It's getting it in a usable form. Round one comes as an email. Round two as a Figma comment thread. Round three as a screen share where the CEO talks for forty minutes. By the end of the project, the feedback trail is scattered across four apps and three formats.
The shape that works: a "Feedback" sub-page per project, with one entry per round in an inline database. Embedded directly in the markdown via the :::database::: directive. Columns for date, source (email, Figma, call), participants, the round number, and a status (received / addressed / pending discussion).
For each round, a sub-page holds the actual feedback. Paste in the email. Drop in the marked-up PDF — it auto-converts so the comments are searchable. Drop in the call recording — it transcribes with speaker labels so you can later see who pushed for the warmer palette versus who held the line on the original direction.
When the client circles back two months later asking "what did we end up deciding about the secondary palette?", you ask the agent: "Find every time we discussed the secondary palette across the feedback rounds. Pull the moments where decisions got made and who was in the room." You get a real answer, with quotes, in seconds. Not "I think we landed on the desaturated version?"
Version tracking that doesn't depend on file names
Every designer has been here. The folder of files with names like Acme-Logo-v3-final.ai, Acme-Logo-v3-final-CLIENT.ai, Acme-Logo-v3-final-FINAL.ai, Acme-Logo-v4-after-meeting.ai. The version chronology eventually becomes incomprehensible, and worse, the rationale for each version is nowhere.
The actual file management still belongs in Figma or your asset library. But the version log — what changed between versions, why, and who asked for it — moves into the vault.
A "Versions" sub-page per project, with an inline database via the :::database::: directive. One row per version. Columns for version number, date, summary of what changed, who requested it, and which feedback round it responded to. Two minutes of typing per version, after you save the file.
Six months later when the client comes back for a refresh and asks "why did we move the logo to the upper right?", you ask the agent: "When did we move the logo to the upper right, and which feedback round drove that decision?" You get the version, the date, and the original feedback in plain text. You don't have to scroll through eight Figma versions trying to remember.
For projects with many parallel deliverables — a brand identity might have a logo, a wordmark, a set of icons, a color system, type, and patterns all evolving in parallel — sub-pages per deliverable each with their own version log keep the chronology straight.
Brand context that compounds across projects
If you work with the same client over time, or across multiple sub-brands, the context compounds. The CEO who insists on never using sans-serif. The marketing director who has strong feelings about red. The creative director who wants every layout to feel "premium but not cold." Most designers carry that context in their head and slowly forget the parts they don't use weekly.
A "Clients" section in the vault, with a page per long-term client, captures it. Brand guidelines (PDFs dropped in and auto-converted to markdown). Style preferences you've learned through work. The internal politics — who has approval authority, who tends to come in late with a fresh direction, who's the actual taste-maker. Project history with links to the project pages.
When you start a new project for an existing client, the agent reads from the client page first. "Read everything we know about Acme Corp's brand preferences and past projects. For this new packaging brief, what conventions should I respect, what's worked before for them, and where have they pushed back in the past?" You start the project with two years of context in front of you.
Asset libraries, handoffs, and the business side
Designers accumulate reference. The hand-lettered logo from a 2008 jazz album you keep coming back to. The packaging system that nailed information hierarchy. Most of this lives in screenshot folders and bookmark tabs that are functionally a write-only archive. A swipe file in your vault changes that. Drop in the references with a few words about what makes each one work. The agent can search across the file when you start a new brief: "Pull every reference I've saved that uses an oversized serif as the primary brand element." The build-and-retrieve discipline is its own pattern; see how to build a swipe file in your notes app for the deeper workflow.
When a project wraps, the deliverable handoff matters. The client gets the files, but they also need the brand guidelines document, the rationale for the major design decisions, and the logo usage rules. If the rationale, the version log, and the brand context are already in the vault, the handoff writes itself. Ask the agent: "From the project page, draft a brand guidelines doc that covers logo usage, color system, type, and the rationale behind the three major design decisions we made." You get a draft handoff. You spend an hour editing it instead of a day building it from scratch.
A practical note: the vault is the place the thinking lives. It's not a project management tool. The actual files stay in Figma. For pricing context — past quotes, hourly rates by project type — a small "Business" sub-vault is useful. When drafting a quote: "Pull my last five quotes for branding work in the same range. Draft a new quote for this prospect referencing what I charged for similar scope." For storage and upload limits if your vault holds many large client recordings, see pricing.
A vault you actually open
The system pays off when you open it consistently. The habit that makes it stick is small: five minutes after each feedback round to log what came in and what changed. Five minutes after each version to update the version log. Ten minutes at the end of each project to write the lessons learned. Over a year, those small entries become the most useful pages in the vault.
Design work is going to be intense whether your notes are good or not. The cognitive load between rounds — remembering what the client asked for in round one, finding the call where the secondary palette got decided, tracking which version was the one they actually approved — that part is fixable. Move it into a vault, let the agent handle the boring searches, and the project stops eating evenings.
Try Docapybara free — sign up, pick one active project, drop in the brief, the latest round of feedback, and your version notes, then ask the agent for a one-page status summary you could send the client tomorrow.