“用户只管提需求，才不管你怎么实现！”是不是听着很熟？产品经理天天在“你得给我整出来”的语境里打工，但这到底是用户的问题，还是我们没听懂？本文带你拆解用户“想要”的真实含义，教你如何从混乱中提炼出可执行的产品方案。

坦然面对开发者的疑惑

曾有个前端程序员充满疑惑的找我，原来是产品设计里出现了一处界面反馈设计不同于背后程序实现逻辑的地方。原服务端技术设计为兼顾用户对数据的实时感知，一旦用户点击切换数据就会立即提交服务端保存，并计算返回最新加工结果。

但是产品设计上倾向给予用户清晰的窗口任务流体现，以及最后全部处理完毕的操作反馈，就增加了一个虚拟的提交步骤（使用”完成“名称的按钮，代替了实际上是关闭功能的”关闭“）。

作为向来逻辑上严格的开发者，对于这里看到的代码“实现模型”≠交互“呈现模型”的现象，就出现了上述不能自已的情形，开发者无法说服自己。

模型不同，刀法自然不同

这里要引申出来的就是：技术的实现模型、用户的心理模型、产品的呈现模型，这三种模型在产品研发过程中微妙的区别和应用。

用户的心理模型——是用户基于自己的背景、约束、环境等所呈现出来的心理预期和反应。比如：用户看到一个满是按键的相机时（普通用户可能想要的是到底哪个按钮是按一下就能拍照/怎么才能够翻页查看相片/怎么放大缩小），以及面对智能手机上的照相机界面上几乎只有一个拍摄按钮时，用户会产生不同的心理预期；

用户心理模型，就好比小红想拍好看的风景照，她心里期待的是按下快门就能捕捉到美丽画面，还希望照片色彩鲜艳、构图好看，可能她对摄影技术不太懂，但有自己对好照片的设想。这也就是为什么傻瓜式的数码相机、auto档这么流行的原因，这也是为什么iPhone当年的拍照被用户吹的那么牛逼。用户不管你怎么做，他们只管自己怎么想。“我不要你以为，我要我以为…哼哼”

这是谓“用户只是提出来想要，才不管你怎么办！”，那我们到底该怎么办？你想要满足用户需求，你想要得到市场价值的回报，你想要搭建供需的桥梁、实现连接。

哪怕你不是一个产品经理，你也可以具有的“产品思维拆解方法”，接下来一起看看。

技术的实现模型——代表的是对现实世界（用户模型、产品模型）研究抽象后，基于产品模型/框架，建构出来的二进制世界实现路径。这里会面临当代技术能力约束、底层技术框架约束、开发者不同实现逻辑的约束。技术实现模型是相机内部的构造和程序，像镜头如何捕捉光线、图像传感器怎么工作、算法怎么处理照片的色彩和清晰度等，这是实现拍照功能的技术支撑。

不难看出来，用户心理模型和实现模型很容易就产生分歧、存在不可逾越的对话鸿沟。如果将实现模型给到用户，可能你看到所有数字产品的界面上只会有：输入框、按钮这2样东西。

问题不只是信息和界面的呈现方式，比如：模拟物理世界的滚动、滑动、拖动、翻页，如果让用户使用实现模型操作，那就得给定位坐标输入不同的数值实现界面的滑动。更严重的在于突破用户认知世界的原有逻辑，出现了错误还非要用户确认（承认自己的错误）、用户付出了成本（操作）后不知道自己得到了什么，这些是更为可怕的情形。

产品呈现模型——就是我们看到的相机外观和操作界面啦，像按钮的设计、屏幕上的取景框、各种拍照模式的选项，这些都是为了方便用户使用，把复杂的技术藏在背后，让用户能轻松拍出符合期待的照片。也是当年搜索引擎为人熟知的孤零零的一个“万能输入框”，你想要的都可以输入进去搜索一下。更是如今LLM遍地，可以和你随时开启的ai对话。

产品如人，它也有诚实与善良，诚实也可以理解为将实现模型毫无折扣的给到用户，但这是极其不负责任的，严重伤害用户目标、商业目标。而善良，要求我们要以用户为中心进行产品设计，时刻看一看用户的目标是什么，用户有了动机/目标，才会进而产生基于产品的活动/任务/操作。

不要过度要求用户

别指望奢求用户理解你的实现模型（用户只有自己的期望desire，清醒点的用户有一些模模糊糊的need，可是这个need，距离feature也是十万八千里啊宝子们！我们指望用户帮我们清楚的描绘出来实现的路径、策略、框架、信息结构吗？当然不可以，用户也没有责任这样做。）用户只会从自己的期望出发，你能够做的就是尽可能提供一套无限接近用户心理模型的模型，也就是产品呈现模型。

前面说到的这种意识，可以应用到很多行业具体的case中，不论是你在做一个策划case、在研发一款面食、在做一次谈判准备，尽管它在本应该应用最丰富的软件产品行业依然存在众多忽视上述问题的从业人员。