陷阱三：假设需求——你以为用户要A，其实他要B，如何避免先入为主

这个陷阱，我踩过太多次了。

刚入行那会儿，我总觉得用户说不清楚需求，得靠我「帮他们想」。结果呢？做出来的功能，用户看一眼就说：「这不是我要的。」

为什么会这样？说白了，就是我们脑子里有个「默认答案」。用户刚开口说「我想要个报表」，你心里已经画好了柱状图。可人家要的，可能只是个简单的数字列表。

先入为主的三种典型表现

我在项目中总结过，假设需求通常分三类。你看看自己中过几枪：

为什么我们总爱「替用户做决定」？

我个人习惯反思这个问题。后来发现，根源在于——我们太想证明自己的价值了。

你想想看，如果用户说什么你就做什么，那跟传话筒有什么区别？所以潜意识里，我们总想加点「自己的理解」。这一加，就加出了偏差。

我记得有个项目，用户说「想要个提醒功能」。我立刻想到短信、邮件、App推送全套方案。结果人家只是想要个Excel表格里标红。嗯，我白忙活了三天。

如何避免先入为主？四个实操方法

方法一：用「5Why法」追问到底

别停在用户的第一句话。他说的「要A」，背后可能藏着「要B」。

举个例子：

用户：我想要个导出功能。
我：为什么要导出？
用户：要给领导看。
我：领导看什么？
用户：看这个月的销售额。
我：领导只看销售额吗？还是要对比？
用户：要对比上个月。
我：那导出后你们怎么处理？
用户：在Excel里做透视表...

你看，问到第四层，真相出来了——用户要的不是导出，而是带对比分析的报表。

方法二：做「反向验证」

别急着点头。把你理解的需求，用用户的话复述一遍。

我建议这样说：

• 「您说的是不是这个意思：……？」
• 「我理解一下，您想要的是……对吗？」
• 「如果我没理解错，您希望实现的效果是……」

这一步，能筛掉至少一半的误解。我在项目中试过，用户往往会说：「不对，我不是这个意思，我是想说……」

方法三：用原型说话，别用文档

文字描述太抽象了。你写一千字的需求文档，不如画个草图给用户看。

我习惯用Axure或Figma快速搭个低保真原型。不用好看，能点就行。让用户亲手点一点，他立刻会发现：「哦，这里不对，我要的是点完直接跳转，不是弹窗。」

方法四：区分「目标」和「手段」

用户说「我要A」，A往往是手段。你要找到他的目标B。

举个例子：

找到目标后，你会发现实现方式不止一种。有时候，一个简单的排序功能就能解决「搜索」的需求。

避坑指南

总结一下：

• 别信第一句话——用户说的，往往只是冰山一角
• 多问为什么——问到第五层，真相才浮出水面
• 用原型验证——让用户看到、点到、感受到
• 区分目标与手段——用户要的是过河，不是非要你造桥

记住一句话：需求分析的本质，不是听懂用户说了什么，而是听懂他没说什么。

下一章，我们来聊聊「需求变更」这个老大难问题。说实话，这块我踩的坑更多……