前几篇把一条链走完了：从用户的原话问出真实场景，把场景写成用户故事，把定不下来的决定落进 PRD。走到这里，很多人就直接开始写方案。但从“问题定义清楚”到“决定先做哪一个”，中间还有一步有它自己的做法。

第一个想到的方案，为什么通常最不该直接用

接着用上一轮的门店报表页。问题已经定义清楚：店长每周一早上要在三个页面之间手工抄数、核对，既慢又容易出错，目标是把准备时间降下来。

这时会议室里最先飞出来的方案几乎一定是同一个：在页面上加一个“一键生成周报”按钮。

一旦这个词上了白板，讨论就转向了按钮放哪、导出成什么格式。原本那个问题——“我们怎样才能让店长更快准备好材料”——有很多种答案；“这个按钮该怎么做”只有一个答案。这个转向几乎不可逆，剩下的时间都花在打磨第一个想法上。

这不是自制力问题，它有名字：设计固着（design fixation）。一项针对初学者的实验发现，就算不给任何参考例子，人也一样会固着——固着的对象是自己想出来的第一个方案，而且这种固着比外部例子引起的更强12。人偏爱自己先提出来的东西，为它投入得越多越舍不得放手。

固着真正的代价不是“想法不够有创意”，而是 你失去了比较的能力。只有一个方案时，“这个方案好不好”没有参照物。这跟上一篇是同一条道理：单个东西无法自证，得有对照才看得出差别。所以问题不在于第一个想法够不够好，而在于你没办法判断它够不够好。

看起来提了三个，其实只有一个

团队通常不会只写一个方案，而是列一串：一键导出、批量导出、导出后自动发邮件。这三个看上去是三选一，实际上都建立在同一套假设上——店长需要的，是把这些数字更快地塞进报告。拿它们互相比，比出来的是界面细节，说明不了更根本的事。

判断两个方案是否真正不同，有一条硬标准：它们成立所依赖的假设是不是不一样。 三个方案共用一套假设，对比实验就是拿三个几乎一样的东西互相比。

还有一个陷阱：把不同问题上的方案放在一起比。把“一键导出”和“给区域经理做个大盘”并列讨论，它们其实在回答两个不同的问题，争论到最后会变成“哪个问题更重要”，而这本该在定义问题那一步就定了6。所以发散必须锁在同一个已经定义清楚的问题上——前几篇花力气把问题和用户故事写清楚，也是为了这一点。

三个把解法逼出多样性的动作

一、把问题改写成“我们怎样才能……”。 把“店长准备材料太慢”改写成“我们怎样才能让店长在周一早上不把时间花在准备材料上”，然后检查这句话：它有没有指向某个具体方案？如果它本身就是“我们怎样才能加一个一键导出按钮”，那就是框窄了4。IDEO 常用的检验是：几分钟内能不能想出五个不同的答案？想不出五个，多半是框太窄5。

二、强制换层。 一个改动的落点通常在这几层里：功能（在现有页面上加点什么）、规则或流程（改掉那条逼人手工抄数的规矩）、内容（少给一点，或只给对的那一点）、人（让别人替用户把这件事做掉）、不做（先确认这件事是不是真的每次都在发生）。

逐层各想一个，就得到五个完全不同的方案：加一键导出；周会模板改成只报三个关键指标，不再要求全量数据；页面顶部直接显示“本周异常”，正常数字不展示；由数据同事统一出一份材料，店长不再产出；先记录两周，确认这事的发生频率。它们的假设几乎完全不同，其中任何一个成立，其余的可能都不必做。这就是“真不一样”的价值——它还会让你发现，有些问题压根不需要靠功能解决。

三、限时、限量，先要数量再要质量。 Google 设计冲刺里的 Crazy 8s，要求 8 分钟画 8 个草图，规则里专门强调：是 8 个 不同的 想法，不是同一个想法的变体或步骤，目的就是推着你越过第一个想法7。数量本身也有用：先把想法攒足，因为最明显的想法被用完之后，不常见的方向才会冒出来8。

生成和排序是两件事，要分开做

上面三个动作都在解决“多”，接下来才是“选”。两步必须分开，因为规则正好相反：生成时不能评判（一评判，人就只提安全的）；排序时必须用一个统一标准评判（不评判就排不出来）。混着做，结果是既不敢提，也不敢砍。

中间有个顺手的过渡——点投票：先把重复的想法合并成一簇，每簇用一个“谁在做什么”的说法命名，再让每人投几票。有个细节值得注意：如果票最高的三个恰好是同一思路的变体，要故意舍掉其中两个，把位置留给走别的路径的方案，否则你会用投票把好不容易发散出来的多样性又收回去8。

收敛的时候，比的不是“哪个方案更好”

到这一步，团队最自然的做法是讨论“哪个方案收益最大”。但这个词在这个阶段几乎算不出来：每个方案的收益都要做出来才知道，而做完全部再比，等于把三个都做了。这跟讲优先级时是同一件事——值不值得做没有绝对答案，只有在有限时间和人力下的机会成本。

换一种比法：不比较完整方案，比较每个方案 成立所依赖的假设。比如：

  • 一键导出：店长愿意改掉手工核对的习惯；导出格式能覆盖他的汇报要求
  • 只显示异常：店长汇报时真正需要的是判断而不是全部数字；异常判断算得准
  • 改汇报模板：区域经理同意放宽报表要求（这条假设不在团队手里）

拆完会发现，最危险的假设常常落在完全不同的层面：有的关于用户行为，有的关于技术，有的关于别人的决定。验证它们的代价差得很远——“店长愿不愿意改习惯”，找五个店长各聊半小时就有大致判断；“区域经理愿不愿放宽要求”必须去谈，做多少原型都解决不了。

于是取舍的问题从“选哪个做”变成了：哪一个方案里最危险的那条假设，是现在能用最小代价验证的？ 上一篇讲过，验证一条假设常常一两天就够，做完一个方案常常要几周。所以收敛的结果往往不是“挑一个做完”，而是“从三个方案里各挑最危险的一条假设，先花小代价验一轮，看哪个跑得出来”。

这里有个常见的收尾动作值得警惕：把两个方案的优点拼成“综合方案”。听上去是取长补短，实际上你造出了第四个谁也没验证过的东西，它同时背上原来两套假设，而且通常更复杂。

比较本身是有成本的。它最值钱的情形大致有三种：方案风险高、这个机会是产品的差异化点、或者确实需要创新解法；如果时间很紧、方案风险很低，直接做也可以3。判断依据还是那一条：多花的时间，能不能换回一个更可能对的结论。

回到链条上

从问题到方案中间其实是两段：先锁在同一个问题上，强制产出几个依赖不同假设的解法；再把它们各自拆成假设，挑出最值得先验的那一条。跳过前一段，你会把第一个想法当成唯一选项；跳过第二段，你会一直卡在“哪个方案更好”这个算不出来的问题里。