Post-Hoc Rationalization

Post-hoc rationalization is the habit of filling out your decision log after the launch metrics arrive and the outcome sits in plain sight. You already know which layout lifted conversion and which one spiked support tickets. With that knowledge you reconstruct the entire entry. The alternatives field lists options no one argued for in the actual meeting. The constraints pull from reports delivered after ship. The reasoning ties every call to perfect foresight and brand principles that align only in hindsight. The outcome section rounds every number up and frames misses as clever pivots. The log stops documenting thought and starts selling a version of you that never existed. Hiring managers at Linear Vercel and Stripe close the tab after two entries. They have read enough real logs to recognize spin on contact.

This is not an honest retrospective. Honest retrospectives name the exact gap between what you predicted and what shipped. They link to the original Slack thread where the call was made in 40 seconds and admit the stronger alternative got cut for a constraint that later proved expensive. Post-hoc rationalization deletes those gaps and installs a story where you saw the winning move from minute one. It is also not a case study. Case studies sell work to clients or portfolios. They have permission to simplify the mess. Decision logs exist to sharpen your next call and defend the last one under scrutiny. Turn a log into marketing and you lose the signal that separates senior judgment from output anyone can generate with the right prompt.

Take the checkout redesign at a payments company in late 2024. The team picked a single long form over progressive disclosure. Desktop completion rate dropped 9 percent in the first month. Three weeks later the decision log appeared in the wiki. It listed four alternatives including a wizard pattern it claimed failed usability tests with 12 enterprise users. It cited a 2023 brand principle that actually argued against long forms. The reasoning referenced Hotjar heatmaps collected post-launch. The outcome paragraph highlighted mobile gains and called the desktop drop a seasonal blip. The engineering lead who sat in the original meeting flagged it immediately. The real decision came down to one engineer refusing the disclosure logic because of React state management complexity ahead of a deadline. None of that appeared. Every alternative was invented after the metrics landed. The designer rewrote the entry with the actual Slack link and the real bandwidth constraint. That corrected version is still referenced in 2026.

A different case hit a design tool company in 2025. The team shipped a new comment system with threaded replies off by default. Feedback engagement fell 27 percent. The post-hoc log submitted for quarterly review listed alternatives that included full threading from day one. It claimed that option created noise based on a Notion study from the year before. In truth the decision was scoped down because the frontend lead wanted to ship before vacation. The writer had joined post-launch and filled the template with what a senior designer should have considered. The reviewer demanded the original product spec. It contained a one-line decision with zero alternatives. The gap killed the entry. The team instituted a new rule: decision logs must be started before any pixels reach production.

You slide into post-hoc rationalization whenever your ego or career feels exposed by the real record. The launch looked worse than expected. A stakeholder schedule a review. Your portfolio update is due and the last three projects show mixed results. The instinct is to sand every rough edge off the story so you look like the designer who always knew better. Never use it. The people you want to impress have written hundreds of logs. They know what real constraints read like. They know when the outcome field was written with perfect hindsight. Build the opposing habit instead. Open the six-field template the hour the decision closes. Write the alternatives while the conversation is still loud in your head. Set a calendar reminder for the outcome update exactly 14 days post-launch regardless of what the numbers say. Send the raw draft to the reviewer who sat in the original call. Their pushback keeps the entry honest.

Brian Lovin publishes every entry on his personal site the week the work ships. The public timestamp stops him rewriting history six months later when metrics look ugly. Jordan Singer attaches design diaries to his product launches with the same discipline. One 2025 entry admits a typography scale change he defended reduced readability on Windows by a measurable margin. He updated it with the v2 fix. That willingness to publish the miss is what reads senior. Teams at Stripe and Linear treat RFCs and design review docs the same way. Entries get reviewed before work starts and stay locked so they compound as institutional memory instead of personal press releases. In a world where AI generates polished mockups in minutes the only artifact left that signals taste is an unspun trail of calls made under real constraints.

The log only works when written before the outcome is known. Anything else is theater.