决策日志:为什么顶尖设计师会记录那些没人问起的决定

资深设计师和中级设计师可以交付同一个界面。资深的那位记得为什么。中级的那位只记得做了什么。

这道差距只来自一份产物。一份简短、带日期、有结构的记录,把每个设计决定连同理由一起写下来。也就是决策日志。大多数设计师没有写,因为学校没要求,上一个团队也没人写。这种习惯不会自己传播开来。

2026 年定下标杆的团队早已在用。Linear 有设计 RFC。Vercel 在工程规格旁边同步发布产品规格。Anthropic 发布研究笔记。Stripe 运行设计评审文档。Brian Lovin 把自己的日志放在公开的个人网站上。Jordan Singer 发布小产品时附带公开的设计日记。每个房间里都是同一种产物。

这就是这份手册。日志是什么,为什么招聘经理先看它,这种做法从哪来,六字段模板,存放在哪里,真实案例,失败模式,以及明天怎么开始。

大多数设计师不写的那份产物

设计里最被低估的产物是决策日志。不是案例研究,不是 Figma 文件,不是演示文稿。而是一份简短、有结构、带日期的记录,把每个设计决定连同理由写下来,并且在作品上线之前写完。

不写的代价悄悄浮现。半年后,设计师说不清为什么表单字段是堆叠而不是行内排列,谁拍的板,砍掉了什么。三年后,作品集里有六个项目,却没有一个站得住脚的决定。这位设计师一辈子都是中级。

决策日志到底是什么

一份结构化的记录,包含设计选择、考虑过的备选方案、当时的限制条件、决定背后的理由、负责人和结果。六个字段,带日期,具体,链接到相关产物。定义就这么多。

它不是案例研究。案例研究把每个选择都呈现得理所当然。日志展示的是决定被做出时的样子:备选方案摆在桌上,限制条件把它们排除,结果由设计师自己承担。

它也不是会议纪要。日志记录决定了什么、为什么,哪怕那个决定只是三十秒的 Slack 消息。路线图向前看。日志向后看每一个已经做出的决定,有日期,有签名,随时可以辩护。

为什么招聘经理看重它胜过效果图

精致的效果图展示的是产出。决策日志展示的是判断力。2026 年的资深招聘经理先看日志,因为产出在 AI 面前很便宜,判断力不便宜。

模型八分钟就能交出一个精致的落地页。招聘经理盯着那个页面,对做出它的设计师一无所知。同一个模型,同一个提示词,同样的 Dribbble 参考。日志是唯一能扛住 AI 把精致感商品化的产物,因为日志不是产出,而是一串选择的轨迹,说明为什么最后是这个结果,而不是另外十八种。

阅读只需两分钟。招聘经理打开日志,扫五条记录,就看出这位设计师怎么思考。具体的备选方案,点名的限制条件,实在的理由,自己承担的结果,还有愿意写下“我现在会换个做法”的坦率。整场面试被压缩进了一份文档。

这种做法从哪里来

决策日志比软件更古老。Christopher Alexander 写的模式语言,放在建筑尺度上读起来就是决策日志,每个模式都有日期、名称、论证,并注明备选方案。建筑师几个世纪以来一直保存设计簿。

软件界通过 RFC 文化继承了它。IETF 自 1969 年起就发布征求意见稿。Spotify、Pivotal 和 Thoughtworks 的 ADR(架构决策记录)是同一种产物的小规模版本。最近的继承者是研究实验室。Anthropic 发布的研究笔记,读起来就是模型层面的决策日志。

三条血脉,同一种产物。设计师是迟到的采用者,而门槛涨得很快,迟到已经开始被看成资历尚浅。

六字段模板,直接抄

六个字段。Decision(决定)、Alternatives(备选方案)、Constraints(限制条件)、Reasoning(理由)、Owner(负责人)、Outcome(结果)。模板故意做得很短。功夫在于写,而不在于设计模板。复制这一块,明天就用。

Date: 2026-04-30 Project: Acme Onboarding v3 Decision Stack email and password vertically on the signup screen, no inline social login row. Alternatives 1. Inline social login row (Google, Apple, GitHub) above the fields. 2. Two-step flow, email first then password on screen 2. 3. Magic-link only, no password field. Constraints - Mobile-first, 360px min width, single column. - Engineering will not ship social OAuth this quarter. - Support flagged 14% of tickets as password reset confusion. - [Brand voice](/paper/glossary/brand-voice) rejects "Continue with" social patterns as generic. Reasoning Vertical stack ships fastest and matches the brand register. Two-step tested cleaner in 2024 but added a screen we cannot afford given the 38% drop on screen 2. Magic-link only blocks the password manager flow 22% of paid users rely on. Owner Maya Chen, design. Reviewer: Jordan Park, eng lead. Outcome (filled 2 weeks post-ship) Conversion +6.1% vs v2. Password reset tickets dropped 9%. Re-evaluate magic-link as v3.1 when OAuth lands in Q3.

Copy

每个真实的决定写一条。每个项目五到十条。不要封面页。上面这一块就是工作本身。

每个字段怎么写,不含糊其辞

每个字段都有规则。不守规则,日志就变成了作秀。

Decision。一句话,现在时,具体。“邮箱和密码垂直堆叠。”而不是“我们觉得垂直也许行得通”。如果决定还没做出,就先别写这条记录。

Alternatives。编号列表,两到四个真正摆上过桌面的选项。不要稻草人。如果只考虑过一个,就写那一个,并解释为什么没再继续找。

Constraints。项目符号列表,有名有出处。工程人力、品牌规则、客服工单、无障碍底线、性能预算。没有这些,日志读起来就是在给个人口味洗白。

Reasoning。三到五句话,不要写“我们觉得”。用“因为”。用“相比之下”。引用起决定作用的限制条件或数据。链接相关产物。

Owner。写上设计师的名字。写上评审人的名字。匿名日志经不起资深评审人的检验。

Outcome。上线后两周到两个月之间填写,标注日期。指标怎么变化,哪些被重新审视,下次会改什么。愿意写下“我对 magic-link 的判断错了”,是日志里最能建立信任的信号。

日志存在哪里

日志放在团队真正会打开的地方。存储位置不如节奏重要。

Notion。最容易在全团队铺开。一个数据库,一个决定一条记录,六个字段做成列。大多数产品团队已经在付费使用,一个设计师一小时就能搭好。

Linear 文档。如果工程和设计本来就在那里,这是对的选择。决定紧挨着触发它的 issue,转成工程 RFC 只需一次点击。

仓库里的 markdown 文件。适合设计工程师和设计系统负责人。仓库根目录的 decisions.md,或者 /docs/decisions/ 下的文件,看起来很正式,因为它和代码一起做版本管理。工程师一眼就认这种格式。

小型私人博客或个人网站。适合想建立公开轨迹的个人设计师。Brian Lovin 就是这么做的。静态站点,带日期的条目,公开链接。这些内容同时是作品集门面和招聘曝光。

选一个。跑一个季度。头一个会失败的动作,就是选了工具然后再也没打开过。

Linear 的设计 RFC 与 Vercel 的产品规格

Linear 把设计 RFC 当作文档里的一等公民。每一个有分量的设计决定都附带一份 RFC,在动手之前写好,由设计和工程负责人评审,随项目归档。RFC 是工作的一部分,而不是事后补的总结。

Vercel 在同一个仓库里,把产品规格和工程规格放在一起发布。设计决定和工程决定写在同一份文档里,有日期,有负责人,有评审。团队把规格当作契约。v0 发布新界面时,规格就是发布产物的一部分。

两个团队都把书面理由视为手艺的一部分。不是周三下午的补写。也不是可选项。这份产物就是工作本身,和 Figma 文件是工作本身一样,没带着它出现的设计师,看起来像是没做完。

Anthropic 的研究笔记与 Stripe 的设计评审文档

Anthropic 发布的研究笔记,读起来就是模型层面的决策日志。试了什么,什么有效,什么无效,下一步是什么。简短,带日期,有负责人,有链接。读三篇,这种做法就一目了然。笔记是记录,不是包装。

Stripe 运行的设计评审文档能跨越多个产品周期留存。Stripe Press 是对外的窗口,内部的实践更早。评审被写下来、归档,并在下一个周期遇到类似决定时重新翻出来。这种组织记忆逐年累积,而不会随着资深设计师离职而流失。

如果你想要帮助,把这件事融入团队的手艺,雇用 Brainy。BrandBrainy 交付 AI 伪造不了的手艺层。ClaudeBrainy 交付Skill 包和提示词库,让日志从一种自律变成默认动作。

Brian Lovin 和 Jordan Singer 公开保存自己的日志

Brian Lovin 运营着一个长期更新的个人网站,读起来就是他自己作品的公开决策日志。页面简短,文字直接,设计选择各用三四句话解释,带日期,链接到线上产品。多年的积累。这个网站同时是作品集和招聘曝光,正是反作品集手册所倚重的双重用途。

Jordan Singer 发布小产品时附带公开的设计日记。每个项目都有一份书面记录,写明背后的各个决定,公开发布,并且敢于大声说出“这个没成”。这份日记同时是营销、记录和招聘产物。

两者都是任何在职设计师本周就能照抄的模板。静态站点,六字段条目,带日期,公开,有链接。每条十五分钟。每月三条。一年之后,这份公开日志显得资深,是任何 Behance 案例研究都做不到的。

警示:事后合理化

在作品已经上线、结果已知之后才写的决策日志,不是日志,而是推销稿。资深招聘经理两分钟就能读出区别。

破绽在备选方案字段。真实的日志列出的是真正摆上桌面的备选方案,往往有一个听起来很强。事后补写的日志列出三个作者从没认真考虑过的选项,专门用来让选中的那个显得理所当然。招聘经理做过一百遍同样的练习。他们知道包装长什么样。

另一个破绽在结果字段。真实的日志会包含与预期不符的结果。“我预期转化会提升,测试结果持平,问题出在这里。”作秀的日志只有胜利,而且提前修饰得比实际更好看。

解决办法让人不舒服。在作品上线之前写条目。标上日期。交给一位会反驳你的评审人。两周后补上结果,哪怕消息很糟。尤其是消息很糟的时候。诚实的条目会产生复利。

如何在面试和评审中使用日志

日志的价值要兑现两次。一次是作品上线时,另一次是设计师向招聘经理或资深评审人讲解那个决定时。

在面试中,日志取代案例研究的讲解。打开文档。挑三条。每一条,读出决定,点出最强的备选方案,点出起约束作用的限制条件,用两句话解释理由,分享结果,包括下次会改什么。每条五分钟,总共十五分钟。招聘经理对判断力的了解,比四十五分钟的案例研究演示多得多。

在资深评审中,日志就是对话本身。评审人读条目,对理由提出反驳,追问为什么砍掉了最强的备选方案。讨论在下一个决定做出之前就让它更锋利。好的设计评审就该如此。不是对渲染出来的像素给反馈,而是辩论像素背后的那个决定。

能为日志辩护的设计师,就能为作品辩护。没有日志的设计师,什么也辩护不了。

新门槛:没有日志的资深作品,读起来像初级

决策日志不再是资深设计师的加分项。它是设计师能交付的最便宜的资深判断力信号,而不写的代价正在上升。

带公开日志的资深作品集,读起来就是资深。没有日志的,读起来像是“可能很资深的作品”,很难判断。招聘经理两种都看。前者会收到回电。一位在三个小项目上写了日志的初级设计师,看起来超出了自己的级别。一位有十二张完美 Dribbble 作品却没有日志的初级设计师,看起来和一年前一模一样。

品味是最后的护城河,在 2026 年成立,因为生产已经商品化,而日志是证明作品里确有品味的公开产物。如果你以设计工程复合角色交付,日志就是设计层的工程 RFC。如果你正在攀爬新的设计职业阶梯,日志就是这个阶梯所依托的产物。

FAQ

什么是设计决策日志?

一份简短的结构化记录,把设计选择连同理由一起写下。每条记录六个字段:Decision、Alternatives、Constraints、Reasoning、Owner、Outcome。带日期,具体,链接到相关产物。

它和案例研究有什么不同?

案例研究把每个选择都呈现得理所当然。日志展示选择被真实做出时的样子:备选方案摆在桌上,限制条件束缚着决定,结果由自己承担。案例研究是销售。日志是记录。

我该把它存在哪里?

存在团队真正会打开的地方。产品团队用 Notion,已经在用 Linear 的团队用 Linear 文档,设计工程师用仓库里的 markdown 文件,想建立个人公开轨迹的用小型私人网站。

每条记录应该多长?

要短。完整模板一屏就放得下。每条十五分钟。

如果我的公司不愿采用怎么办?

自己单干。设计师个人的日志会跨工作累积。Brian Lovin 和 Jordan Singer 都公开保存自己的日志。这种做法属于你,而不是你的雇主,产物会跟着你走。

本周就开始写日志

三步。先搭好存储。在 Notion、Linear、仓库或小型网站里选一个。三十分钟搭好。选你明天会打开的那一个。

针对已经做出的决定写三条记录。本季度的真实决定。每条六个字段。诚实的备选方案,真实的限制条件,不含糊其辞,结果标注日期,不加修饰。头三条最难,后面会越来越快。

把日志给一位资深评审人看。请他们对你的理由提出反驳。把反驳当作信号。更新条目。第一次评审,就是日志开始产生复利的地方。

如果你想要帮助,把决策日志的实践融入团队的手艺,雇用 Brainy。BrandBrainy 交付 AI 伪造不了的品牌与手艺层。ClaudeBrainy 交付 Skill 包和提示词库,让日志从一种自律变成默认动作。已经在用的团队正在拉开差距。门槛在上升,而本周开始的设计师,就是那些知名团队一个季度后会读到的人。