Build fast, forget faster

Most of my design work now runs through Claude Code. The prototypes I build there are working apps that look and behave like the real product. And the prototype is only part of it: the brainstorming, the research, the back and forth about what a feature should do, all of it happens in the same place. I talk through directions with Claude and make the call. Critique notes and call transcripts get dumped into the thread too, because that’s where the work is happening. More of the reasoning behind my decisions sits in one place than ever before.

A thread is a bad place to keep reasoning. It scrolls away, and once it gets long enough, the tool starts summarizing it for you. A review comes around, someone asks why we never tried the other direction, and you remember trying it, but not why it died. The nuance is the first thing to go. So alongside the work, I keep two documents. One records the past. One describes the present.

The log is a dated record of decisions, written when they happen: what we picked, what we rejected and why, who said what in critique, the exact values that made it in. If the wording matters, it goes in as a quote, attributed. If a direction got killed in the back and forth with Claude, that goes in too. Nothing gets tidied into a summary, because a summary is what I’ll have in my head anyway. The log holds what I won’t.

It pays off in the situations I used to lose. A decision gets reopened, and instead of reconstructing from memory, I ask Claude to read the log, and it tells me what we tried and what killed it. A case study needs writing, and the log is the source material rather than whatever I still remember six months later. And if a project ever changes hands, the next designer inherits the reasoning, not just the files.

[Decision] [AI] One ease-out curve for all reveals.Mizan: "can we use a ease out of cubic-bezier(0.33,0.74,0.58,0.97)" for the expandable rows + "tell me where else we can add this"Built a shared Collapsible (animates grid-template-rows 0fr↔1fr, 300ms, that curve).Then, after Mizan pushed back on my "needs a different technique" framing — "can we use my ease out curve for all of these?" — extended it everywhere: 150ms on dropdowns, 200ms on newly-added rows.Deliberate exception kept: the Toast's back-out spring (450ms cubic-bezier(0.34,1.56,0.64,1)).

The second document is dev handoff notes: how the prototype works right now, written in the developer’s language. It exists because detail slips out of a handoff in two ways. Annotations pinned to screens get missed. And what does get read is written in my words, a designer describing behavior, which leaves room for interpretation. The notes leave nothing to interpret: the logic, every state, every interaction, and which parts of the prototype are fake. localStorage is standing in for an API, and the notes say so, and say what plugs in instead.

The notes travel with the prototype, and the pair has changed what handoff looks like. Developers used to reconstruct a feature from static screens, which never told their tools how any of it fit together. Now they run the prototype, point their own coding agent at the repo and the notes, and it understands how the whole thing works. Technical design docs get written from it, and the early conversations are about data modeling and how the feature ties into existing systems, not what a screen means. One developer told me “the notes are as valuable as the prototype itself.” Less gets lost between my intent and their build.

The two documents don’t overlap. When the prototype changes, the notes get corrected so they stay true, and the log gets another entry so the change is remembered. One keeps the why, the other keeps the what.

Behaviour:* Auto-focuses the input on open and selects all text.* Resets to the latest `initialValue` on every open — covers re-opens for different entities without remount.* The Save button is always enabled. The handler no-ops on empty / unchanged input (closes the modal without mutating) so a stray click can't blank the name.* Enter key submits.

The reason both documents became skills is that the failure mode is the model itself. Ask an LLM to update a log and it will merge three decisions into a paragraph, paraphrase people into its own words, and replace exact values with tidy descriptions. It is built to summarize, and the log only works if nothing in it gets summarized. So I wrote the discipline down: what a faithful entry looks like, what a spec is allowed to contain, what must never be smoothed over. Both are now Claude skills, and they run every time I say “log this” or “update the handoff.”

They’re public, and they work with any prototype, any stack, and any coding agent:

This system changed how I work. I hope it does the same for you.