译自 Linear 官方博客《Design is More Than Code》，探讨"设计师该不该写代码"这一行业热议话题。作者认为把争论焦点局限在工具与代码层面本身就是一种降维，真正值得关心的是 AI 冲击下设计师贡献方式如何演变；并系统拆解设计"问题"与设计"解决方案"两个阶段，强调先定义正确的问题，再带着深思去构建——设计始终是关于找到正确的意图与愿景。
最近的讨论焦点主要集中在：设计师到底该不该写代码？代码是不是设计的正确媒介？代码是否呈现了设计的“真相”？等等。主流的作为认为，把辩论的中心仅仅放在代码和工具上，是把路走窄了（Reductive）。
写作背景
作者已经写过两篇相关文章（分别谈"设计是一种搜索而非流水线"、"工具自带立场，这些立场会影响什么是'合理'的尝试"），这是第三篇。他对行业里把"用代码做设计"当作大一统解法、把复杂的设计过程简化成写代码、并称之为进步的趋势持怀疑态度。
当前讨论热点集中在：设计师该不该写代码、代码是不是设计的正确媒介、代码是否能"呈现设计的真相"等。作者认为，把争论焦点局限在工具和代码层面本身就是一种简化/降维。
核心问题：角色会怎样演变？
作者认为更值得关心的问题是：在 AI 和新工具冲击下，设计师未来的贡献方式会怎样改变？
- 设计师会不会变成工程师，被同样的标准要求？
- 工程师会不会开始用同样标准要求设计师？
- "工程负责人"和"设计负责人"这两个头衔还会存在吗，还是会合并成"工艺负责人"（head of craft）之类？
- 职称本身不重要，但这些问题能揭示团队真正重视什么、认为工作该怎么完成。
实际问题是：如果设计师被推向直接用代码做设计，这是好方向吗？我们会因此得到什么、失去什么？
设计意味着不同的东西
作者指出，这场讨论之所以容易变得混乱，是因为"设计"对不同人意味着不同的东西，取决于：
- 你做的是哪种设计、你如何理解设计这门实践；
- 所在行业/市场：消费级产品动机难预测，往往需要快速试错；B2B/企业级往往有更多上下文可以据此设计；有些行业要求极端的可靠性和清晰度；
- 环境因素：干系人、客户、公司文化；
- 设计师自身技能：视觉型的人会先从视觉入手，代码能力强的人可能更早引入代码；
- 对有些人来说，设计就是"把按钮放到屏幕上然后继续下一件事"。
软件设计是一个很宽的领域，内部有各种不同工具和方法。"要不要用代码/无代码"这种争论常常抓错重点，反而变成一种制造对立的力量。
作者想把讨论提升到工具之上，避免工具主导设计的未来，也不希望因为新工具让"执行"变简单，就顺带贬低概念性、发散性思考的价值。他提到：哪怕是整天写代码的工程师，也会离开代码去画架构图、规划系统、权衡取舍——代码是软件"存在"的地方，但不代表所有决策都该在代码里做出。
第一部分：设计"问题"（Designing the problem）
作者自称不是受过正规训练的设计师，是过去二十年靠上百个项目自学出来的，所以他并不主张设计有什么"唯一正确"的门槛做法。但他认为设计很少是线性的——会在不同抽象层级之间来回移动，而虽然最终产出是目标，花时间走"过程"本身能让产出更好。
他学到的第一件事：要先质疑问题本身，而不是把问题当作既定前提。接到一个任务时，他会先问：
- 这真的是个问题吗？
- 如果我们不做这件事会怎样？
- 这个问题是谁定义的？
他发现，设计项目拖延或失败最常见的原因，是"问题"本身没弄清楚。人们对解决方案达不成一致，往往是因为大家心里想的"问题"根本不是同一个——最终的解决方案变成了多个不同问题之间的妥协，而不是针对一个核心问题的干净解法。干系人越多，这个情况会越严重。
他的应对方法：
- 把自己理解的问题写下来，并搞清楚都有哪些干系人；
- 向这些干系人展示解决方案时，先复述一遍"问题"，观察是否引发异议；
- 如果有异议，就先停下来，让大家先在"问题"上达成一致，再继续讨论方案。
他强调：你总会有干系人——不是同事就是客户——需要判断反馈到底是"方案不好"，还是"大家对问题的理解本来就不一致"。有时候你是在解一个错误的问题。问题是整个等式的第一部分，是你要设计和构建东西的地基。
Linear 的例子：公司很快就意识到客户需要"项目（projects）"这个功能，路线图上写"做项目功能"，大家都认同。但再往深想：为什么公司要把工作组织成"项目"？为什么不直接一个个做任务？如果没有项目会怎样？
项目管理本身是可以钻研得很深的一整套学科，做法五花八门。但如果你的愿景是为软件公司做一个专用工具，就要开始收窄范围，去搞清楚他们真正在意什么。简单说：项目是公司管理工作流的一种自然抽象，它帮助建立责任归属（accountability）、所有权（ownership）、跨团队协作、可预测性和可见性。
研究这么"基础"的东西看起来没必要，但了解整个领域的脉络和历史能给你定位感——你能发现哪些假设可以被挑战，或者该沿用哪些传统做法。最重要的是：先搞懂问题，能帮你决定接下来该往哪个方向走、想优化和影响什么。Linear 团队意识到"项目"可能是最重要的工作单元——产品由项目构成，组织围绕项目运转，项目上线时大家会庆祝。这个认知给了他们要解决的问题一个明确方向。
第二部分：设计"解决方案"（Designing the solution）
作者把设计解决方案分为两个阶段：
1. 概念阶段（Conceptual stage）
寻找设计将采用的整体形态。举例：在一个任务追踪工具里，"项目"可以被处理成：
- 一个带子任务的大 issue；
- 一个 issue 的文件夹/标签；
- 一个和 issue 相关联、但独立存在的实体。
这些都是在不往屏幕上放任何东西之前就能推演的概念性想法，最终选择取决于你对用户、公司的理解，以及你想要的产品愿景——每种概念在现实产品里都能找到对应案例，都是可行的。
Linear 团队因为认定"项目"很重要、且和 issue 性质不同，所以决定让它成为一个独立实体、有自己的形态：项目应该有可辨识的形式和功能，能传达状态、决策依据、用户反馈、优先级、时间安排，以及与更大规划的关联。把项目降级成一个标签或一堆松散关联的 issue，感觉是不对的。
这个概念阶段可以用文字、纸笔、设计工具，也可以用代码来完成——关键只是给想法一个形态，尝试不同方向，最终选出最能服务于问题和产品愿景的那个方向。一旦有了自己相信的方向，就可以拿出去获取更广泛的反馈——通过"把它建出来"去验证这个概念。
2. 执行阶段（Execution stage）
这是最接近最终产出的部分：把设计概念变成真正能运作的东西、把它塑造成真实存在的形态。代码，或者说"跟材料打交道"，在这个阶段是必不可少的。有时候在执行中会获得新的认知，需要退回去重新审视问题或概念。
在这个阶段用代码也有不同方式，比如用一次性代码"打草稿"——这样能去掉一些生产代码的约束，让过程更具探索性。作者的观点是：虽然执行阶段看起来才是设计"真正"发生的地方，但你在这之前已经建立好了一套上下文和信心基础——当材料给你"反作用力"时，你是带着这份信心去推进的。
类比 LLM：前期的设计工作，相当于你为 Agent 构建的目标、上下文和 prompt，用来让它去解决问题；执行阶段则是你引导 Agent 做出具体决策的过程。
关于"时间"的反驳：读到这里可能会想——谁有时间干这些？我们得赶紧上线啊，为什么不直接开始做、边做边想？作者认为这不是时间问题——他的解释可能显得很长，但这个过程本身可以很快，你只是花该花的时间而已。他的感受是：如果没有事先建立好上下文和目标，你可能确实在往某个方向迭代，但那个方向未必是有意选择出来的。
结语要点
这又回到了文章开头的担忧：这个行业普遍缺乏耐心，一旦"直接把设计建到生产环境"成为默认做法，那些促使团队去认真考虑问题、概念和意图的文化与组织性动因就会开始蒸发——我们开始为了"产出"而贬低设计背后的"为什么"。
作者的担忧不是代码或工具本身，而是"深思"的衰退——随之而来的，是独特、精心设计产品的衰退。真正的问题是：在新工具和新技术不断出现的同时，我们要如何让这种"深思"的习惯活下去。
对作者来说，设计从来不是关于按钮长什么样、按钮做什么、或者你用什么媒介工作——设计始终是关于找到正确的问题、正确的意图、正确的愿景。你今天设计和构建的功能，应该是朝着那个愿景迈出的、经过深思的一步。
本笔记为内容整理，非原文逐字翻译。完整原文（含配图）请见：
评论交流
支持作者