Design Diary

A design diary is a public six-field record of every major design decision with dated entries that list real alternatives, binding constraints, unhedged reasoning, named owners, and post-ship outcomes. It lives on a personal site or versioned repo so the messy trail of taste stays visible for years. Brian Lovin treats his as a static site where short pages link directly to shipped features. Jordan Singer attaches one to every small product launch. The format forces concrete writing. Decision states the call in present tense. Alternatives numbers two to four options that actually competed. Constraints bullets the real limits such as engineering capacity at Vercel in 2026 or the 14 percent password reset tickets that shaped a signup flow. Reasoning cites tests data or brand rules that tipped the scale. Owner names the designer and reviewer. Outcome updates weeks later with metrics and admissions when the call aged poorly. The whole entry fits on one screen and takes fifteen minutes once the habit sticks. Christopher Alexander originated the thinking in his 1970s pattern languages where every architectural choice carried dated justification and rejected paths. Software borrowed it through IETF RFCs that began in 1969. Teams later built ADRs at Spotify and Thoughtworks. Anthropic publishes research notes that read like decision logs at model scale. Designers adopted it last yet the ones shipping diaries in public now pull ahead fast.

A design diary is not a case study that retells every choice as inevitable genius. Case studies sell the highlight reel. Diaries document the forks where strong alternatives died and the constraints that forced the winning call. It is not loose journaling or exported Figma comments or inspirational process posts. Those ramble and hide weak thinking. The diary stays structured on purpose so a hiring manager at Linear scans five entries and sees exact judgment in two minutes. It is not a post-hoc narrative written after metrics arrive. Those versions fill the alternatives field with strawmen no one considered and round every outcome into a win. The format collapses the moment it turns into theater instead of record.

Jordan Singer published a design diary entry in March 2025 for the FocusFlow beta that explained his choice to build the daily goal setter as one editable line with natural language parsing. The decision read simply. Build the daily goal setter as a single editable line with natural language parsing instead of a multi-field form. Alternatives listed a traditional form with separate inputs, a calendar drag-and-drop interface, and a pure AI suggestion engine with zero manual entry. Constraints named the no-JavaScript accessibility floor above 95, the single-engineer team that quarter, the 34 percent form abandonment from 2024 tests, and the brand rule against clinical interfaces. Reasoning explained that the single line won five user sessions for speed and matched the product tone of reducing friction. The form added cognitive load. Calendar broke on mobile. Pure AI removed agency and killed engagement in prior prototypes. Owner listed Jordan Singer with an external engineering reviewer. Outcome updated in May showed users setting 2.8 goals per week against a 1.9 target and dropoff falling to 11 percent yet the regex parser failed on 7 percent of complex phrases. Singer noted he would add example chips next version to teach syntax without a tutorial. That two-hundred-word block reveals more product sense than most thirty-page decks.

Brian Lovin documented a 2024 portfolio rebuild where he chose a static site generator over no-code tools. Alternatives included Webflow, Framer, and a full React app. Constraints listed his need for total code ownership plus a hard thirty-dollar monthly hosting ceiling. Reasoning linked to past dynamic-site performance headaches and his belief that designers must own the stack end to end. Outcome admitted the migration took three times longer than planned but cut costs to six dollars monthly and improved load times 40 percent. These public entries form the public trail that turns solo work into a compounding hiring asset. Linear runs the same discipline as design RFCs written before code starts and reviewed by both design and engineering leads. Vercel places product specs next to engineering specs in the repo so decisions stay attached to the work. Stripe archives design review docs that surface again when similar calls return years later. Each team treats the written rationale as craft not decoration.

Use a design diary when you want hiring managers or collaborators to judge your taste faster than any visual portfolio allows. Run it personally even if your company never adopts it. Write three entries this week on calls already made this quarter then keep the cadence at three per month. Post it publicly if you can. Link the entries from applications and tweets. The diary compounds hardest for independent designers and design engineers who drop the markdown file straight into the repo root. It works when you fill the outcome field with unflinching honesty especially on the projects that underperformed. Avoid the design diary when you plan to write entries after launch once you know which numbers arrived. That produces spin that senior reviewers detect instantly from the shape of the alternatives list. Skip it if you cannot name real constraints and instead invent them to sound smart. Never treat it as a one-off exercise or decoration. The practice only earns trust after six straight months of consistent honest entries.

Senior taste leaves tracks. A design diary is the track that hiring managers open first in 2026.