最近参加了一次关于 AI 时代设计师变化的讨论。一位设计主管又提到了那个熟悉的观点：执行可以越来越多地交给 AI，对产品、用户和业务的理解，才是设计师最重要的能力。

讲道理，从 2023 年听到现在，这句话已经快让我产生PTSD了——我们都知道理解业务很重要。问题是这句话常常只说到这里。有人把它当作经验的总结，有人把它当作资历的证明，却很少继续解释：什么叫理解？理解到什么程度？它究竟怎样影响一个设计决定？当我继续追问，得到的往往还是那句“你要多理解业务”。

一个需要被解释的概念，最后竟然成了解释所有问题的答案，这相当荒唐且空洞。

我想把这句话拆开。既然大家都说业务理解在 AI 时代变得更贵，那至少应该说明白：理解业务到底为什么贵，贵在哪里了。

一句话可以介绍业务，却未必能支撑一个决定

很多产品的业务，都可以用一句话介绍清楚：帮助企业完成电子签署，帮助用户管理知识，或者帮助消费者做出购买决定。这样的概括非常有用，它让一个不了解产品的人，迅速知道你在做什么。

但概括会省略细节，也会省略细节之间的关系。

“帮助用户做消费决策”，只有九个字。真正开始做产品时，却必须回答：用户在决定要不要买，还是决定买哪一个？他希望解决什么问题？什么样的帮助才算有价值？为了得出结论，需要哪些信息？这些信息又凭什么足以支持判断？一句话介绍的是业务的轮廓。这些问题，才开始触及业务如何成立。

不过，我也不想由此得出“业务其实很复杂，所以必须深入理解”的结论。那只不过是绕了一圈，又把原来的大道理说了一遍。有些业务的确容易理解，规则明确、边界清楚，熟悉领域的人很快就能掌握。没有必要为了证明设计有价值，先把业务讲得高深莫测。

理解的深浅，也不能只用讲了多久、记住了多少术语来衡量。一个人可以把行业背景讲得津津乐道，却依然说不清，眼前这个方案为什么值得做。

业务知识要成为设计的依据，中间还需要分析：弄清目标、规则、条件之间的关系，知道哪些差异会改变判断，哪些信息不足以支持结论。

理解的地基，是知道判断凭什么成立

我理解的业务，是产品为谁解决什么问题、通过什么方式创造价值，以及这个过程必须遵守的规则。理解业务，则需要进一步弄清：这些目标和规则如何相互作用，在具体情境里，对我们的选择意味着什么。

知道用户是谁，只是一个起点。我们还需要知道，他为什么来到这里，他要完成什么，什么会阻碍他完成任务。知道某条规则，也只是一个起点。还需要知道它适用于谁，依赖什么条件，遇到例外如何处理，与另一条规则冲突时应当怎样判断。

没有目标，就无法判断一个优化究竟改善了什么；没有规则，就无法区分一次简化是在减少负担，还是遗漏了必要步骤；没有对价值的理解，就无法决定哪些体验可以暂时让步，哪些必须守住。

所以，业务理解是地基。它未必是每个项目最费力的部分，但没有它，后面的判断就失去了落脚点。再漂亮的方案，也可能只是替一个没有被弄清楚的问题，构建了一个空中楼阁。

这里尤其需要一种克制：分清我们知道的、推测的，以及尚未确认的——用户查询了一款高浓度护肤品，这是行为；他想购买，这是对意图的推测；他属于“耐受油皮”，则又跨到了个人特征。三者可能有关联，却不能直接画上等号。他可能在替别人查询，也可能正因为担心不适合，才想多了解一些。

如果产品直接把推测当成事实，再把它存进记忆、用于推荐，错误就会逐渐获得一种熟悉的面貌：系统一次次重复它，仿佛已经越来越了解用户，但其实和用户真实画像差的十万八千里，南辕北辙。

因此，理解也包含对自身边界的认识。一个关键前提没有确认，就应该追问，或者限定结论的范围。不能因为方案需要往下走，就把缺失的信息自行补齐。

分析，让熟悉变成可以检验的理解

很多设计师并不缺少业务经验。他们做过项目、处理过例外，也积累了相当敏锐的直觉。问题在于，这些经验有时停留在“感觉应该如此”的层面——问一个方案好不好，可以很快回答；问为什么，也能说出几个理由。但继续追问：这些理由成立需要什么条件？换一个场景是否还成立？如果两个目标发生冲突，哪个应该优先？那些原本顺畅的判断，可能就开始露出空白。

分析的意义，是把这些空白找出来。

做一个辅助决策的产品，我们很容易从报告的形式开始：应该有几个维度，要不要增加引用，怎样让结论看起来更专业。但在此之前，更应该问：用户究竟要决定什么？什么信息会影响这个决定？产品提供的帮助，怎样才算有效？

用户尚未决定是否购买，与用户正在两个商品之间比较，需要的是不同的判断。信息源可靠，也不代表信息与眼前的选择有关；商品适合使用，也不代表此刻值得购买。如果没有把这些关系拆清楚，增加再多维度，可能也只是让报告更长。

我觉得，一个有效的分析过程，应该能从目标推到判断，从判断追溯所需的前提，再从前提推导产品必须提供的能力。功能、内容和交互，沿着这条路径逐渐有了理由。当然，分析的过程经常很烧脑，这要求我们把那些已经用了很久、却从未清楚定义的东西说准确。也正是在这个过程中，经验才有机会成为可以讨论、可以修正、可以复用的判断方法。

取舍的前提，是坚守边界规则

有了业务理解，也有了分析，仍然未必能直接得到最终方案。产品始终存在于现实里：用户有自己的习惯，系统有已有的结构，团队有有限的工期和资源。我们需要把这些条件带进判断，选择一个能够成立的方案。这就是 trade-off，也就是取舍。

不过，实际工作中，取舍需要明确的优先级。有些东西可以延后，有些范围可以缩小，有些成本值得承担，还有些条件根本不能被破坏——业务理解提供的，恰恰是区分这些事情的依据。

工期紧张，可能意味着减少本期支持的场景；它不能自动证明，省掉一个必要的确认步骤也是合理的。系统暂时无法支持理想的表达，可以选择更朴素的形式，但必须判断，用户是否仍然能理解关键关系、完成核心任务。一个可用的取舍，需要说清楚：为了实现什么目标，我们选择了什么，放弃了什么，承担了什么代价。所谓“现实如此”，不能替代这段解释。

同时，也应该分清困难发生在哪一层。规则没弄懂，需要补充理解；信息关系已经清楚，却不知道如何表达，需要设计探索；方案明确，但系统不支持，需要讨论能力缺口；没有资源和排期，则需要协调优先级。它们都建立在业务背景上，却有不同的解决方式。不能把所有问题都交给“再理解一下业务”。理解可以让我们准确识别约束，却不会凭空创造工期。资历也不会让一种约束，自动变成另一种能力的不足。

也就是真正所谓的理解业务，是指理解业务，并能够基于业务及现实条件，做出有依据的产品与设计判断。业务理解决定判断的依据，现实条件影响可选的范围，而分析帮助我们辨认每一种选择的代价。

判断还需要回到现实，接受验证

讲得有道理，仍然不代表做得正确。一个方案经过分析，才获得了尝试的依据；它还需要回到实际使用中，检查那些依据是否成立。

我们预期用户会理解某种关系，他是否真的理解？我们认为减少一个步骤不会影响任务完成，实际是否如此？为了工期做出的让步，代价是否仍在可以接受的范围内？验证应该对应之前做出的判断，而不只是确认功能已经上线。

当然，也不能只凭最终结果评价决策。信息有限时，合理的判断可能遇到意外；缺乏依据的选择，也可能碰巧成功。一次好结果不足以证明方法可靠，一次坏结果也需要分辨：是前提错了、推导错了，还是出现了原先没有预见的变化。

这不是替失败寻找借口，而是让经验可以继续积累。如果只记住成败，却不知道成败从哪里来，下一次仍然只能凭感觉下注。

因此，理解与判断并不是在方案交付时结束的。验证会修正我们对用户、规则和条件的认识，再影响下一次选择。业务理解也在这个往返中，逐渐变得扎实。

AI 时代，到底什么是多了解业务

再回到开头那句“AI 时代，理解业务更重要”。诚然，AI 可以帮助我们整理材料、展开情形、发现矛盾，也可以帮助分析和提出方案。理解业务不会因为 AI 到来，就自动成为人的专属领地。人的判断同样可能草率，AI 的推导也同样需要检查。

但当文案、页面和原型更容易生成时，方案从哪里来，就更值得追问。过去，我们能看见大量执行的劳动，却未必看得见劳动背后的判断；现在，执行速度加快了，前提没有被确认、目标没有被定义的问题，也会更快地进入产品。

一句流畅的解释，不能替我们确认事实。一套完整的界面，也不能替我们决定什么值得做。生成能力越强，越需要把目标、依据和取舍说清楚，避免让产出的完整，掩盖理解的缺口。

如果业务理解在这个时代变得更贵，我认为它的价值就在这里：让我们能够确定问题、辨认条件、比较选择，并在现实中检验自己的判断。它作为地基，支撑着分析、取舍与验证；也只有进入这些具体的决定，理解才能真正转化为产品的价值。