设计不止于代码

作者：Karri Saarinen

关于“用代码做设计”的争论由来已久，最近又吵翻天了。这已经是我第三次写这个话题了。我之前写过 “设计是一种探索，而非流水线”；也讨论过 “工具本身带有观点”，这些观点会潜移默化地塑造我们认为哪些尝试是“合理”的；我还谈到了为什么过早引入限制会扼杀尚未被发现的可能性。

坦白说，我对行业里这种追求“大一统”的趋势持怀疑态度——试图把一个充满细微差别的过程全部坍缩成代码，并称之为“进步”。

最近的讨论焦点主要集中在：设计师到底该不该写代码？代码是不是设计的正确媒介？代码是否呈现了设计的“真相”？等等。但我认为，把辩论的中心仅仅放在代码和工具上，是把路走窄了（Reductive）。

对我来说，更大的问题在于：在未来，尤其是当 AI 和新一代工具普及后，我们如何看待设计师的贡献？角色将如何演变？我们对彼此的期望又会有什么变化？

设计师现在算是工程师了吗？背负着同样的期望？工程师会开始对设计师有同样的要求吗？未来我们还会有“工程负责人”和“设计负责人”吗，还是会变成一个统一的“匠心负责人”（Head of Craft）？头衔本身并不重要，但这背后的问题很有价值，因为它们揭示了我们真正看重什么，以及我们要如何把工作做好。

这就引出了一个实际问题：如果设计师被推向工程领域，直接用代码进行设计，这真的是个好方向吗？我们会因此失去什么，又得到什么？

这场讨论之所以容易变得混乱，部分原因在于“设计”这个词对不同的人意味着完全不同的东西。你的看法取决于你从事哪种设计，以及你如何理解设计这项实践。

我相信设计有多种风味。它受个人、领域、市场和客户的影响。在消费级产品（C端）中，你可能需要快速测试想法，因为用户的动机很难预测；在企业级服务（B2B）中，你通常拥有更多的上下文背景，可以据此进行设计。有些行业需要极致的可靠性和清晰度。环境也很重要：利益相关者、客户、公司文化，以及你作为设计师的技能。如果你擅长视觉，你会以视觉为主导；如果你代码能力强，你可能会更早地使用代码。

而对另一些人来说，设计无非就是把按钮画到屏幕上，然后完事。

所以，软件设计是一个广阔的领域，里面包含了各种各样的工具和方法。“代码 vs 无代码”的争论往往搞错了重点，反而成了一种制造对立的力量。

我想表达的是，我想把这场讨论提升到工具之上，确保工具不会反客为主，接管设计的未来。我不希望我们仅仅因为新工具让“执行”变得更容易，就毫无必要地贬低“概念性思维”和“发散性思维”的价值。

即使是整天与代码打交道的工程师，也会时不时从代码中抽身出来。他们会画架构图、规划系统、推演权衡。虽然代码是软件栖息的地方，但它并不总是做出所有决策的最佳场所。

为了解释我的意思，我必须从我如何理解设计以及我如何实践设计开始说起。

首先，我不是科班出身的设计师。过去二十年里，我通过数百个设计项目自学成才。所以我不是在搞“看门人”那一套（Gatekeeping，指设立门槛排斥他人），也不是在鼓吹某种唯一的“正确”设计方式。但我确实认为，设计很少是线性的。你需要在不同的抽象层级上工作，并在它们之间来回切换。虽然结果是最终目标，但在过程中花费的时间往往能让结果变得更好。

通过这些工作，我学会了一件事：首先质疑问题本身，而不是把它当作既定假设。 如果有人让我做一个东西，我会先问：这是一个真问题吗？如果我们不做这个会怎样？是谁定义了这个问题？

这听起来有点哲学，但我发现，设计项目拖延或失败的最常见原因，就是问题本身没搞清楚。人们无法在解决方案上达成一致，是因为他们脑子里想解决的问题根本就不是同一个。于是，解决方案变成了针对许多不同问题的妥协产物，而不是针对一个核心问题的干净利落的解法。当利益相关者（Stakeholders）太多时，这种情况会更加恶化。

为了解决这个问题，我会做两件事。第一，按照我的理解把问题写下来，并询问谁是利益相关者。第二，当向这些利益相关者展示方案时，我会重申这个问题，看看是否会引起反应。如果有异议，我会停下来，先让全屋子的人在“问题”上达成一致。你可能会问，这跟设计有什么关系？这听起来很像公司管理那一套。

但你总是会有利益相关者的，如果不是同事，那就是客户。你必须搞清楚，收到的反馈是因为你的方案不够好，还是因为大家对“问题是什么”没达成共识。有时候，你是在为一个错误的问题做设计。“问题”是等式的第一部分，它是你设计和构建一切的基础。

在 Linear，我们很快就意识到公司需要“项目”（Projects）这个功能。路书上写着“构建项目功能”，每个人都同意这是必须的。但如果你再深想一层：为什么公司要通过“项目”来组织工作？为什么不直接做一个接一个的任务？如果他们没有“项目”会发生什么？

你可以深入研究项目管理。这背后有一整套学科，以及各种各样的方法论。但如果你的愿景是为软件公司构建一个专用工具，你就得开始做减法。他们真正关心的是什么？

简单来说，“项目”是公司管理工作流的一种自然抽象 （Abstraction，指在软件工程中将复杂系统简化为更易管理的概念）。它们有助于权责分明、归属感、跨团队协作、可预测性和可见性。

现在你可能会问，为什么要研究这么基础或众所周知的东西？有时候你确实不需要。但了解整个版图和历史能给你定位。你会发现哪些假设是可以挑战的，或者决定遵循哪些传统。

最重要的是，先搞懂问题有助于你决定要怎么处理它。产品愿景把你拉向哪个方向？你想优化和影响什么？

在 Linear，我们要么不做，要做就发现“项目”可能是最重要的工作单位。产品是由项目组成的，组织是围绕项目运转的，当一个项目发布时，你们会庆祝。这种理解为我们试图解决的问题指明了方向。

我把设计解决方案的过程分为两个阶段：概念阶段（The conceptual stage）和 执行阶段（The execution stage）。

• 概念阶段 是寻找设计将呈现的整体形态。

• 执行阶段 是将其构建出来并呈现在屏幕上。

以问题追踪工具中的“项目”为例，你可以把它处理成一个带有子问题的大号问题（Issue），或者一个文件夹/标签，或者一个连接到问题的独立实体。这些都是你不需要在屏幕上画任何东西就可以思考的概念性想法。决策取决于你对用户、公司和你想要达到的愿景的理解。所有这些概念都行得通，你可以在现实产品中找到它们的影子。

因为我们认为“项目”很重要，且不同于“问题”，所以它们需要成为一个独立的实体，拥有自己的形状。一个项目应该有可识别的形式和功能，能够传达状态、理由、用户反馈、优先级、时间安排，以及与更大计划的联系。把“项目”降级为一个标签或一堆松散的问题集合，感觉是不对的。

这个概念阶段可以用文字、纸笔、设计工具或代码来完成。关键在于赋予这些想法一个形状，尝试不同的方向，最终选择那个最能服务于问题和产品愿景的方向。

一旦我有了一个我相信的方向，就准备好接受更广泛的反馈了。你会通过构建它来测试这个概念。

这是最接近最终产出的部分。你让设计概念真正跑起来，把它塑造成真实的东西。代码，或者说与“材料”直接打交道，在这一步至关重要。有些时候，你会获得新的洞察，不得不回过头去重新审视问题或概念。

在这个阶段使用代码有不同的方式。你可以构建工具，或者用“用完即弃的代码”（throwaway code）进行“草绘”。这消除了一些生产环境代码的限制，使过程更具探索性。我想说的是，虽然你可能认为执行阶段才是设计的“本体”，但其实你已经建立了一个包含上下文和信心的基础。当“材料”开始反击时（意指在编码过程中遇到现实的限制或困难），你是带着那份信心在推进的。

我们可以用大语言模型（LLM）的逻辑来类比：

你之前做的所有设计工作（理解问题、确定概念），就像是你为了让 AI 智能体（AI Agent） 解决问题而构建的 目标（Goal）、上下文（Context）和提示词（Prompt）。而执行工作，则是你在引导智能体做出一个个具体的决定。

读完这些，你可能会想：谁有时间搞这些？我们需要发布产品啊！为什么不直接开干，边做边想？我不认为这是时间问题。我的解释可能很长，但这个过程本身可以很快。你只是花了必要的时间而已。

我的感觉是，如果没有内置那些上下文和目标，你可能确实在朝着某个方向迭代，但那不是一个经过深思熟虑后选择的方向。

这让我回到了文章开头。我们的行业非常缺乏耐心，一旦你开始默认直接把设计构建到生产环境中，那些去思考问题、概念和意图的文化与组织理由就开始蒸发了。我们开始为了产出而贬低设计背后的“为什么”。

我担心的不是代码或工具本身。我担心的是深思熟虑（Consideration）的衰退，随之而来的是独特、设计精良的产品的衰退。问题在于，随着新工具和技术的出现，我们如何保持这份匠心？

对我来说，设计从来不是关于按钮长什么样或它是干嘛的，也不是关于你用什么媒介工作。它过去是，现在依然是——找到正确的问题、正确的意图、正确的愿景。 你今天设计和构建的功能，应该是通往那个愿景的、经过深思熟虑的一步。

感谢 Charlie Aufmann, Tuhin Kumar, Ramon Marc, Conor Muirhead, Gavin Nelson, Raphael Schaad, Jeff Smith, 和 Soleio 对本话题的评论和讨论。

Karri Saarinen

来源: https://linear.app/now/design-is-more-than-code