设想你走进一场需求评审会，原本准备和产品经理一起梳理用户流程，屏幕上却已经出现了一个能点击、能跳转的 Demo。“我用 AI 先搭了一版，你看看。”页面齐全，流程也能走通。你还没来得及问清需求的来龙去脉，讨论已经推进到了：“这里再调整一下，是不是就可以交给开发了？”
作为设计师，你可能会有些迟疑。眼前的方案确实不错，一些过去需要花时间推敲和绘制的内容，现在已经摆在了面前。但你也隐约觉得，有些问题还没有被讨论：用户真的需要这样操作吗？这个流程为什么要这么走？如果有更合适的方向，现在还来得及调整吗？
如果沿着 Demo 往下做，设计师的工作很容易被压缩成界面和细节的打磨；此时若设计师提议重新梳理需求并讨论，又要回答另一个现实的问题：方案已经做到这一步，为什么还值得多花时间？更棘手的是，即使设计师在这个过程重发现了问题，也得找到一种方式，让团队愿意回头审视已经成形的方案。
AI 加快了想法变成原型的速度，也让传统设计师需要面对更多挑战。
本期提纲：
• 挑战聚焦
• 一个挑战案例
• 回看这个案例
• 结语
1 挑战聚焦
一 、设计介入的价值在哪里？
如果 AI 生成的原型已经能够支撑当前项目的核心诉求，那么再增加一层人工设计的介入，价值在哪里？过去界面制作占据了设计师大量的精力，也成了设计工作最直观的护城河；当这部分工作可以逐步被 AI 替代，设计师到底能为当下的业务结果带来什么？ 哪些信息能够更容易被理解？哪些操作能够变得更合理？
二、方案已经具象化后如何介入？
AI 原型让团队重新讨论方案的空间和包容度变小了。一个可运行的原型往往具有很强的“视觉吸附力”，容易把大家的注意力牢牢锁定在现有界面上。AI 缩短了制作过程，但要让团队推翻一个已经具象化的方案，其沟通和协作成本依然很高。
2 一个挑战案例
这两个挑战点，我们在一次小程序违规举报的需求里都碰到了。
在这个需求中，对小程序举报的用户需要说明他们遇到的问题、选择举报分类，并补充证据，供平台进一步处理。产品团队希望解决两个问题：平台分类复杂，用户找不准；提交的违规证据信息不足，后台无法有效处理。
设计介入时，产品团队已经用 AI 做出了一个多轮对话原型。用户先描述遇到的问题，系统辅助判断分类，再继续追问，引导用户补充证据，希望减轻用户理解平台规则的负担，并收集完整信息（如下图左侧）。
而最终我们达成一致的方案是表单方案，把举报内容、材料和分类集中呈现（如下图右侧）。面对已经成形的原型，我们为什么提出另一条交互路径，又如何让团队接受这个调整？
解决思路
在这个案例中，我们先确认目标，再拆解用户任务，从传统表单与 AI 对话中寻找更合适的组合，最后通过方案比较和细节优化，与产品团队逐步达成共识。
一、追溯原始诉求，说明设计介入的价值
回看需求，用户希望尽快完成举报，平台需要拿到足够处理的信息。原型用辅助分类和追问补全信息回应这些诉求，但完成任务是否一定需要多轮对话？
我们沿着原型梳理流程，发现用户需要逐轮回答问题，并等待 AI 响应。流程本身就比较长，对于已经知道要举报什么、手头也有材料的用户，这些操作可能增加负担。目标值得保留，实现目标的路径却仍有提升空间，这就是设计需要介入的地方。
二、明确设计范围并对比方案，说明设计如何介入
1. 保留目标，梳理用户要完成的任务
这个需求解决的问题是真实的，目标也是明确的，所以需要调整的是用户完成举报任务的流程。我们先放下原型的交互形式，把举报流程拆成三项任务：说明违规事实、确定举报分类、补充并核对证据。设计需要重新考虑的是，怎样组织这些任务，才能让用户清楚需要提供哪些信息，并更高效地完成举报。
2. 回看传统表单与 AI 对话各自解决什么
按常规的信息收集方式，这些任务可以由表单承载：用文本框描述问题，通过选项确定分类，再上传材料。信息集中呈现，用户可以填写、回看和修改，表单因此成为我们考虑的另一条路径。
但传统表单仍留下了分类难题。用户未必理解平台的分类规则，平台却需要准确分类才能处理举报。产品团队引入 AI 多轮对话，正是希望通过理解用户描述、逐步引导来辅助分类，并补齐处理所需的信息。只换成传统表单，分类负担仍然存在。
3. 在表单中引入 AI 辅助分类
由此，我们进一步考虑：能否让表单承载信息填写，同时保留 AI 对用户描述的理解能力？用户先说明问题、补充材料，再由 AI 根据描述辅助识别分类，并保留手动选择入口。这样，用户不必先弄懂分类规则，也能查看和调整结果。
新的表单方案就从这里形成：保留信息集中填写、方便修改的特点，用 AI 辅助解决分类负担。
4. 再与原型比较完整任务
有了这个方案，我们再把两条路径放在同一个举报任务下比较。对话原型需要用户跟随提问，逐步描述、确认分类和补充证据；新的表单则让内容与材料集中呈现，由 AI 辅助分类，用户可以直接核对和修改。
从方案上看，新的表单保留了信息收集和辅助分类能力，也减少了逐轮问答与等待，为用户更高效地完成举报提供了可能。基于这次比较，产品团队认可了表单方向。
这个选择有明确的场景条件。如果用户难以组织信息、需要逐步引导，对话仍可能有帮助。是否更高效，需要比较完整任务中的理解、填写和纠错成本。
5. 确定流程后再优化语音输入
初步确定表单方向后，我们继续看输入细节。产品团队希望保留原型中的语音输入，让用户可以先说出问题。因此，我们又比较了强化语音入口与文字输入、语音辅助两种方式。
强化语音入口需要多一次跳转；举报内容较长时，用户可能还要回想和组织，长按说话未必合适。再次输入也可能覆盖已有内容，AI 识别或处理存在改变原意的风险，这些都需要继续检查。
我们最终选择文字输入与语音辅助的方案：用户围绕表单组织和修改举报内容，需要时再用语音补充。流程方向明确后，设计也随之聚焦到这些具体交互上。
3 回看这个案例
虽然不同设计师面对的项目和处境不尽相同 ，但当一个已经做好的原型摆在面前时，我们依旧可以通过这个案例中的一些方式逐步摸清需求脉络，从而更合理解决问题。
1. 追溯问题来源并区分目标与手段
先和产品一起回看原始反馈、问题记录或已有数据，弄明白用户想做什么、卡在哪里。再把必须实现的目标与原型采用的手段分开，判断当前做法是否必要。如果问题来源还不清楚，就先补充验证。
2. 判断介入层级并匹配改动范围
看见问题之后，不必马上重做整个方案。路径合理，只是信息难懂，就先改局部；目标明确，但流程给用户增加了负担，就重新组织步骤；如果需求本身缺少依据，就需要回到原始场景确认问题。
这三个层级不必逐级走一遍。原型已经适合任务，就做局部调整；当前路径妨碍目标，才有理由扩大改动范围，并说明预期收益和相应代价。
3. 把判断变成可比较且可实施的方案
把现有原型和替代方案放到同一个任务里，沿用户操作走一遍，比较理解、输入、等待和纠错的成本，再结合实现难度与排期作取舍。资源有限时，也可以保留已有实现中合理的部分，先调整关键环节。
形成共识也不等于验证了效果。应把方案预期改善什么、还存在哪些风险说清楚，后续再通过真实使用检验判断。
4 结语
再回到开头那场设想中的评审。一个能运行的 Demo，仍可能留下尚未被讨论的用户困难。设计师需要从原始诉求出发，把这些困难找出来，再通过具体方案，让团队看见改进的可能。
AI 缩短了从想法到界面的距离，也让设计师的专业判断变得更加重要：看见顺畅演示背后用户可能付出的理解、操作和纠错成本，把用户的处境转化为具体的设计选择。当一个方案已经足够完整、让人想直接往下推进时，设计师仍能帮助团队发现被忽略的问题，并拿出有依据的改进。这正是设计师在 AI 原型之后，继续创造价值的地方。
当然，实际工作未必总能留出充分讨论的空间。需求紧急时，团队可能来不及比较多条路径；产品对方向已有明确判断时，也未必愿意重新打开讨论。这套方法能帮助设计师提出更有依据的建议，却不能保证建议每次都被采纳。最终能推动多少改进，还取决于业务优先级、协作基础，以及设计介入的时机。
— The end —
