我推翻了自己的第一版方案

我的第一版：一主线 + 四支线

先说清楚第一版长什么样。

需求只有一句话：「希望有一个勋章。」

我的理解是：用户需要一个可见的成长路径。所以我按「一主线 + 四支线」搭了结构：

• 主线一条——综合等级。用户在这个系统里累计出来的一个总档位，看起来就是「你到了第几级」。
• 支线四条——深度、广度、奖励、隐藏。四条分支路线，各自独立推进，作为主线的补充维度。

深度、广度、奖励三条是明面上的：深度看用户问得多深，广度看他覆盖了多少产品，奖励看他的分值累积。隐藏那条不展示规则，靠用户自己撞见，用来做惊喜感。

当时我觉得这个结构是对的。主线保证方向感，支线保证丰富度，还有一个隐藏支线做惊喜——逻辑闭环，原型也能画。

现在回头看，它错的不是细节，是出发点。

那句话，我一开始没听懂

把方案讲出去的时候，客户那边提了一个疑问：这套主线的勋章名称，跟他们实际在用的业务等级体系高度接近。

我的第一反应很糟——我想去改个名字。

把引起疑问的那几个字换掉，绕开正面的问题，方案原样保留。这是最省事的处理方式，也是当时我下意识的选择。

真正的转折不在那句话本身，在于我后来坐下来问了自己一个问题：

如果只是名字的问题，那换个名字之后，这套机制会变好吗？

答案是不会。因为名字只是表面，真正在做判断的是结构——一主线加四支线，本质上是在给用户定档。

真正被推翻的是什么

把第一版拆开看，它有一个隐含假设：用户需要被评价，需要知道自己「到了哪一档」。

但这个假设本身是可疑的。

用这个系统的人，本来就在被业绩排名、被考核评估。如果新的激励机制又是一套「你在第几档」的结构，那它给用户的感受，和原来的压力没有区别——只是换了个地方被评分。

所以被推翻的不是命名，不是层级数量，是这个出发点：

从「评价用户」换成「激励用户」。

评价是往回看的——你已经是什么样的人。激励是往前看的——你下一步可以做什么。这两个方向决定了两套完全不同的设计。

想清楚这一点之后，方案自己就长出来了。从「一主线四支线」变成三条可累积的主线加隐藏路线——不是我在挑形式，是出发点变了，形式只能跟着变。

重做一遍，顺序反过来了

第一版的顺序是：先想结构 → 再画原型 → 最后想用户感受。

重做的时候，顺序完全反了：

• 先问：用户在这个系统里，最想要的感受是什么？
• 再问：什么机制能持续产生这种感受，而不是产生压力？
• 最后才落到结构上——几条线、几档、叫什么名字。

顺序一换，结论全变。同样一个「勋章」，从结构出发得到的是一套等级体系，从感受出发得到的是三条并行的累积路径。

这也是我后来做产品最大的一个变化：不要在需求上直接动手，先站到用户的位置上，把感受想清楚。

如果重来

我不会跳过第一版。

第一版做错的那一周，不是浪费——没有那个错误的结构摆在那里，那句提醒也没有落点。问题不在做错了，在于我没有在做之前先问清楚出发点。

所以现在我的习惯是在动手前加一个问题：

用户要的是被评价，还是被激励？

这一句能省掉一整周。

后来

回过头看，这件事训练了我一种能力：从别人的疑问里找背后的逻辑，而不是从字面上接话。

别人说「名字」，真正想说的可能是「这套机制让我不舒服」。需求分析不是翻译，是把对方没说完的话补全。

这个能力后来在别的项目里反复验证过——越贴近用户真实的使用场景，越容易发现表面需求背后的真实问题。我最大的收获不是学会了什么工具或方法，而是学会站在用户的处境里想问题，而不是站在系统的逻辑里想功能。