产品经理怎么处理好需求来源

本片文章是接触于B端G端,市场部运营部们经常提起的需求,我们该如何去把他们的需求作为功能需求呢?为什么要把他们的需求作为功能需求?怎么把他们的需求转换为功能需求,我们这么做有什么目的,可以实现什么,对我们现在的项目可以打造成什么?有什么预期,预期的标准是什么,等等,一大推问题,接下来小编就给大家来好好说到说到这个需求;

第一步:


对业务需求进行分析是设计需求分析的第一步,你需要明确业务目的和业务目标。

业务目的:我们为什么要这样做业务目标:我们这样做了,要获得什么样的成果

用户体验的核心就是用户需求,一个需求功能如果设计失败,很大程度上是因为没有很好了解用户需求。

第二步:


业务需求的地层逻辑,你要明确业务人员为什么要提这个需求,多问问需求方为什么,但在问为什么的时候一定要说出自己相对应的答案,保证需求方有自己的思路,而不是一味的问。

第三步:


有可能谈需求需要好久的时间,第一步和第二步都做完了就要问,需求方想要看到什么,然后里面有涉及到的字段都是什么,在这个期间不要先画原型图,先把思维逻辑画出来,然后根据你的思维逻辑和需求方再次进行统一,

以上都是大白话,下面开始总结:


业务需求分析(业务目的、业务目标)

用户需求分析(明确目标用户、分析用户需求)

分解关键因素(了解关键因素:动机、担忧、障碍)

总结归纳(分析用户体验路径)


其实在满足需求方的时候,我们能不能在加入自己的想法来满足我们的产品,可以从这几个维度:

有用性。面对的用户需求是真实的。

可用性。功能可以很好地满足用户需求。

满意度。涉及情感设计的方面,比如图形、品牌和形象等。

可找到。用户能找到他们需求的东西。

可获得。用户能够方便地完成操作、达到目的。

可靠性。让用户产生信任。

价值。产品要为投资人产生价值。


附加:(行业流程图)

一:系统架构图


二:逻辑架构图


三:物理架构图:


四:功能架构图


五:信息架构图


六:组织架构图


七:业务流程图


八:泳道流程图


九:行业关系图


十:PEST分析图


十一:SWOT分析法


小编的文章就写到这里了,这段时间听说了很多奇奇怪怪的段子,比如:上知行业走向,下晓体验细节,左通技术架构,右解刚需痛处,前能写文档,后能画原型,进能与数据共舞,退能与运营齐飞,与研发共进退,和UI齐存亡,陪测试耍bug,同市场看未来;看似很牛逼,其实小垃圾。其实小编文能提笔舒骚情,武能切图画交互。(有哪里不足的地方希望大家积极的和我讨论)

推荐阅读更多精彩内容