产品研发过程中，不奢求完美主义，能够在产品生长的每一步中将产品设计做到恰如其分，同时也能避免一些常规陷阱，已经是很不错了！

近几年大大小小接触过的软件产品少说也几十款，产品交互设计能够做到“恰如其分”的着实少之又少。基本的一些产品思维，想必不论是开发团队、产品团队、设计团队都会多少具备的，比如：一款产品可以面临不同类型的用户基本上是一种共识，甚至于同一款产品内部不同的模块面对不同的用户。

不过我们仍然经常见到下面这种现象：

1、各个模块间出现对于用户的不同假设定位，一会儿认为用户是专家用户，一会儿认为用户是新手，给出来的框架+表现层参差不齐。

这还不是最可怕的，虽然这已经足够让用户感到苦恼了，如果你是商业产品，还好。如果你是消费产品，那这一条基本上就拜拜了。用户在屏幕后面距离产品设计者十万八千里，早就用脚投票和产品say byebye了。

2、最为可怕的是自我代入：产品经理自我代入、程序员自我代入、测试工程师也自我代入。（令人意外的是，观察后发现自我代入通常竟然还要求极高的洞察力和微观体感。）

后果会出现多层的矛盾——产品呈现与用户心理期望的矛盾、产品呈现与底层实现的矛盾，底层实现如果自我代入了，基本意味着重建的必然性。开发实现自我代入是高危行为，作为产品经理这里必须留意再留意！警惕再警惕！（这里要求的是产品逻辑和程序逻辑的一致性，产品经理要确保和开发团队达成共同的认知水准）

什么是B端产品经理？和C端产品经理有什么区别？

B端产品经理中的B是Business，商业的意思，B端产品经理首先就要理解这个职位的重要性，要设计出更适合这个项目需求的产品方案，B最终产品经理在日常工作中...

查看详情 >

如果实现模型（软件的程序层面）冲突于呈现模型（用户的体验层面，也即产品功能/界面/信息），且在未来的演进思路上（演进是跟随着用户模型、市场模型的共同变化）已经南辕北辙，那么这款产品会很快感受到成长的无力感。

看清问题，才能做到“恰如其分”

第1个问题出在产品研发团队，甚至于市场团队、管理团队，这些人员中心里住着不同的“用户”，你说的用户和我说的用户，并不是一个用户。

大家对于“用户模型”并没有达成一致，而用户模型，一定是一款产品成功的基础。不论是对于产品设计、交互设计、技术架构设计、编码实现、市场营销。

用户模型的构建，需要前期一系列的研究工作，在常规的团队里面，这些工作通常都是隐型的、不被okr/kpi包含的，重视程度基本靠自觉、靠个人的市场/业务理解支撑。大到新设计一款产品、或者一个新增功能模块/视觉体系改版，小到一个按钮的调整，都可以参考到用户模型。

用户研究里面，人物模型的建立又是一套复杂而完整的体系，如果没有有充足的资源以及时间的情况下，即便通过专家知识、过往积累知识的了解，自己来拟定一个临时人物模型，即使是这样，也胜过没有任何人物模型的，仍然会在产品设计研发过程中起到良好的指导作用。（但这并不代表任意不经过仔细研究的临时人物模型就可以拿来就用，虽然有胜有无，但一定要避免误入歧途）

第2个问题，涉及到产品设计逻辑和代码构建逻辑的一致性。也许有的产品/设计团队会说，我的方案如此，要求开发团队交付出来满足当前方案/文档的项目成果即可，而往往测试团队也是对于标的物的产品需求文档交付测试为主。但最终产品要为用户/客户负责，除非我们的用户/客户是不变的。

产品/设计团队应该能够根据业务的发展 、产品路径的演进，判断出来一些核心逻辑的设计、区分和预留。这个基调引导了代码的架构，这也就是产品设计逻辑、功能逻辑、到代码逻辑、数据逻辑的层层衔接了。（参考之前分享的这篇文章产品设计逻辑能否引导代码构建逻辑？）

绝对不是简单的我想要什么，剩下的交给开发者。想要什么很重要、路径演进的可能性同样也很重要，表达清楚绝对是为自己的产品路线铺路。

相信都不愿意看到产品极速发展的过程中，代码逐渐臃肿不堪、跟不上发展的步伐，最终不得不面临重构，要不就是产品的妥协、用户价值和商业价值大大折扣。