编辑导语：当我们在某个场景遇到了想做的事情时，便产生了需求，根据需求，产品经理需要满足其需求并制定对应的解决方案。作者分享了他关于产品设计流程的一些思路，从场景、需求、解决方案的角度来思考产品的设计流程，希望对你有所帮助。
一、场景产生需求，解决方案满足需求
什么是场景呐？
- 场：指的是时间和空间；
- 景：在情景和互动下触发用户的情绪，使用户产生意见和想法或者身体上的反应。
场景作用于用户从而产生需求——想要做什么、欲望。为了满足需求需要制定解决方案——去做什么。
二、从场景、需求、解决方案的角度来思考产品的设计流程
产品设计是从发散到收敛，从抽象到具象，从宏观到细节的的过程。在设计新的产品时需要按照 【明确服务对象—梳理场景—判断需求—解决方案—功能落地】的流程来：
1. 明确服务对象
我经常把我的服务对象分为3种类型：客户、用户以及业务方（包括老板）——
①客户（买单的人）是谁，客户的特征画像、客户的需求、客户的细化目标是什么。
②用户（实际使用的人），用户的特征画像、用户的需求、用户的细化目标是什么，注意：其中用户不一定是客户，用户一般会涉及到多个角色，往往上下级关系要涉及到管理权限和流程的设置。
③我所在的业务是TO B的业务，所以我对接的业务为我们公司的销售，需要明确他们在对外销售的时候在产品功能方面需要展示哪些高大上的功能来吸引客户购买，哪些模块方便打包售卖等。
2. 梳理场景
场景的核心是在空间加时间的点上触发别人的情绪，如果你架构的场景不能影响别人的情绪，不能形成对别人情绪的触发，它就不是一个场景。例如同样是售卖书籍，如果是在知名作家的新书发布会上，激发了参会者的购买欲，图书一售即空；但是在书店里摆放着书就无人问津 ，无法激发用户的情绪，所以就不构成一个场景。
用户消费产品的本质是消费场景。例如爬泰山时，半山腰上的矿泉水的价格是平时的10倍，但是仍旧有很多人去买。
表象用户是消费的是矿泉水，本质消费的是 用户在爬泰山时身体对水的渴望以及不知道错过这家商店，下一家商店需要往上爬多久之后才会出现的对未知的担心。
前几天去滑雪，在滑雪场一桶泡面15元，如果放在平时，肯定会无人问津。但是当时没有其他的商店，小伙伴们需要吃饱饭才能补充体力来保证下午继续快乐地滑雪，所以即便是这个价位大家依然排队购买。所以说消费者购买的在某个场景下的需求。
梳理真实用户的使用场景，C端产品可以创建场景来引导用户需求，例如直播软件的主播PK功能、抖音的模仿功能。B端产品存在业务壁垒，必须还原真实的客户场景，才能解决客户真正想要解决的问题。
3. 需求判断
用户需求=目标用户（特征、经验） 用户场景
不同的用户在同样的场景下产生的需求是不一样的。例如乘坐地铁的场景，在从家到公司的路上乘坐地铁的碎片化时间内，触发了用户需要利用碎片化时间做点事情的想法。爱学习的用户需求是提升自己的专业知识，解决方案可以选择为读专业书；爱玩的用户需求是想要放松自己，解决方案可以选择为玩一会开心消消乐。
同样的用户在不同的场景下需求也是不一样的。例如同一个用户，在工作日午餐时间产生饥饿的场景中，需求是在较短的时间内补充足够的能量消除饥饿感可以支持下午的工作。在周末的午餐时间产生饥饿感的场景中，需求是吃大餐消除饥饿感奖励辛苦工作的一周，为了心心念念的美食，大家排队1个多小时等位也是欣然接受的。
分析场景中产生的需求，以及该需求是否有必要去满足从而界定需求边界以及优先级的规划。例如刚才提到的工作日吃饭补充能量的需求优先级远高于周末吃顿大餐奖励自己的需求优先级。
在我们平时和需求方沟通时，对方经常说自己看到竞品有什么功能，我们也要来一个。或者自己意想出一个什么什么功能，作为产品这个时候要思考挖掘的是 对方到底想要在什么场景下解决什么问题，最终达到什么目标。
举一个作为一个互联网人都快听吐了的例子：
福特公司的创始人福特先生到处跑去问客户：“您需要一个什么样的更好的交通工具？”
几乎所有人的答案是：“我想要一批更快的马。”
很多人听到这个答案可能立刻为客户寻找更好的马。
但是福特先生继续问：“你为什么需要一批更快的马？”
客户：“因为可以跑的更快！”
福特先生：“你为什么需要跑的更快?”
客户：“因为这样我就可以更早到达目的地。”
福特先生：“所以，你想要一批更快的马真实用意是？”
客户：“用更短的时间、更快地到达目的地！”
最后福特先生就发明了汽车，更好的满足了用户的需求。
4. 解决方案的设计
在设计解决方案时，要对需求中多个解决方案进行对比，界定系统边界，选择成本更低，用户体验更好，更利用产品长期发展的方案。
对于用户的体验路径来说，要搞清楚用户在使用前、使用中、使用后的各个出发点，确保设计方案形成完整的闭环（线上 线下）。
对于产品的长期发展来说，要平衡好产品的性价比，给用户提供良好服务的同时，要保证产品的收益持续化（金钱或者流量），这样才能为后续的产品迭代支持提供支持。通常解决方案的细化表现形式为——流程图或者线框图
5. 功能实施落地
功能的实施落地主要就是跟进开发，保证项目的正常进度。在此过程中，会涉及到技术问题或者成本问题导致技术方案替换的问题，时间问题导致功能简化或者放到下一期版本迭代的问题。
对于一些不在计划内的情况，产品岗尽可能 本着能实现最终的产品目标和业务目标的原则下，和各方合作人员开开心心把工作搞定的心态来处理。
三、使用“用户故事”分析场景和需求
提到场景、需求等概念，自然会关联到用户故事。用户故事是需求侧的概念，就是客观存在的需求产生（人 场景）和需求被满足的过程，直白讲就是不用身份的用户要达成某个目标需要做的一系列事情（时间、地点、人物 发展 …），是为了规划需求使用的工具。
场景产生了需求，在满足这个需求的过程中又会出现不同更细的场景。
简单来说就是在实施具体的解决方案实现需求时，在每个环节又有可能会细分产生多个小场景，每个小的场景又产生了对应的小需求。建议使用“用户故事法”来分析。
用户故事通常的表达格式为：作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>。
举个栗子吧：
某个场景——工作日早上很饿，但是还有半个小时就要上班了。
场景产生了需求——要在上班之前补充能量消除饥饿感。
为了满足需求选择了一个解决方案——去公司食堂吃早餐。
在执行解决方案时，产生了新的场景——食堂中不同窗口都排起了队&15分钟后部门就要开晨会了。
新场景产生的新需求——尽快买到饭不耽误按时参加晨会。
新需求的解决方案——找了一个排队人数比较少的窗口并打包带走了食物。
好的用户故事除了格式规范，要素完整外，还应该遵循INVEST原则：
- Idependent（独立的）
- Negotiable（可协商的）
- Valuable（有价值的）
- Estimatable（可评估）
- Small（小的）
- Testable（可测试的）
以后有机会了再详细分享。
关于用户此波此结束啦，希望能够帮助需要的小伙伴能够更好地分析场景，做出能真正满足用户需求的好产品。拒绝伪需求，从认真分析每个场景开始~
本文由 @Grace 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于 CC0 协议
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。