我是丹仙仔，我是要成为站在产品顶端的那个男人。
近来，逐渐熟悉产品的我也设计了不少大功能需求，但也发现我在设计需求时考虑不全面，故现在要重新梳理我目前这个阶段拿到需求后需要考虑到的方面。
1.从mentor拿到需求，肯定不是一手需求了，至少是二手需求，那需要了解到需求背景以及需求价值，一定要把这个源头追溯到，不明不白的设计需求只是空中楼阁，与用户的距离过远，设计出的产品也不适用于用户，所以这一步一定要把用户、场景、动机拿到。
2.接下来 mentor会给我一个大致的设计方向，要静静的聆听，了解怎么做，为什么这么做。
3.把mentor的idea先搁置一边，从0开始考虑，如果拿到这个需求的话，我会如何进行产品化，每一步都要考虑原因，这时候如果是一个大需求的话，在构思的时候，可以先描绘信息架构、功能架构图，再去构思流程，最后就是输出原型，每一步都可以与mentor进行碰撞，前提是你必须要有自己的思考。每一步都要考虑为什么这么做；如果是小需求的话，可能不用定义流程，了解清背景和价值后，直接进行原型设计，此时要注意的是影响点分析！！！
4.产品设计可能针对的是流程的优化、也可能是界面的优化、也有可能是新功能的设计。但终究是各个字段组成的，所以不建议在做需求的时候，由上至下的进行设计，最好是先根据信息架构确定字段级别的信息，再根据这些字段一点一点组合成功能
5.产品设计的过程中，也要注意一个点：影响点分析
为什么要做需求影响点分析
首先需要理解系统是一个有机的作用链网络。
支撑一个组织/公司业务的系统可能有很多个，多个系统构成了一个有机的系统群，每个系统又由很多个功能构成。从最微观的角度讲，系统是通过提供的功能来支撑业务的，而系统中每个业务都不是单独存在，系统中每个功能和周围的其他功能有关联和联系，A——>B——>C/D，这样一路关联下去，形成了一个有机的结构体和作用传导链。每一个对系统功能的操作，都会对其他的功能按照一个作用链产生影响。同样的对系统的一个调整也会对这个作用链产生影响。
如果不提前对这些影响点进行分析，会导致开发错误估计开发量，甚至遗漏掉影响到上线后用户使用；也可能因为没有提前考虑到导致后续需求到来时没有留足够的可扩展性，返工量巨大。
如果我们提前做好需求影响分析，则可以使开发迭代管理更准确，评审更高效，也可以为产品后续设计留下足够的可扩展性。
比如对于电子档案系统影响点分析：
基本影响点分析：
1.是否需要考虑增加BOSS开关
2.是否需要增加角色与权限的开关
3.功能交互路径是否可逆
4.历史数据影响和处理方式
5.标准数据接口是否有影响
再配合功能模块影响点分析 就更ok了
6.做完以上分析后，理论上来说需求已经分析透彻了，在跟设计过的时候可能只是交互设计这方面，但现实中我所遇到的事，需求考虑可能并没有那么透彻，跟UI过的时候，可能还会有需求的讨论导致原型和设计稿会出现不一致的情况，要解决这个问题：我觉得可以进行设计师需求前置，也就是说需求设计已经考虑充分的情况下，或者出原型图的时候有关大型交互的问题，就需要和UI设计师进行沟通，首先讲明的还是需求的背景和价值，这个时候原型和设计稿的可以大体同步，因为在我需求设计已经考虑充分的情况下，与UI沟通之后就可以确定产品的界面形态，不会出现特别不一致的情况；而且如果已经在出原型图的话，遇到特别大的交互提前沟通，可以避免不一致的情况。总的来说，原型图标注的是功能细节，设计稿体现的是设计细节，如果某些功能细节无需用图展示，则原型图也无比要画，直接交给UI。 去实践把！
7.考虑完后可能同步的就是需求文档了，敏捷中对需求文档的规范没有这么重，重点是与研发对接功能细节要讲清楚，沉淀下来，之前研发会吐槽我们细节考虑不充分、异常流程没有考虑、产品未来形态没有规划，那有个文档的沉淀将会有据可溯。
