业务项产品，如何做需求分析?设计前期这样做

业务项产品，如何做需求分析？（设计前期这样做）

做业务产品时，如果接到了含糊不清、关键信息不全面的需求汇总，你会不会十分头疼，甚至不知道如何下手？而面对同样的难题，作者进行了思考，并给出了建议。

lonlonago，我还很天真地以为PRD都是产品经理汇总好的业务需求，我再进行下一步的需求分析，理清主次功能、主次流程并转变为可执行操作的产品界面……

事情并没有那么简单……

交付性的项目产品，产品经理往往是这么一句话：

“这个产品我们以前有个类似的平台，就做一个类似这样的平台产品，多了几个XXXX功能，然后原有的xx流程去掉，有问题再问我”

许多交互/UI在接需求时也会遇到这种情况，是不是感同深受？

每次有新业务就有新产品设计的我，意识到并不是每个需求方都有能力将需求描述的符合我意。甚至于做产品设计时，每一个平台的行业、功能、业务需求也不一样，很多设计规范和组件并不能复用。我之前也跟很多做业务向设计的小伙伴讨论过，设计价值在交付性产品中很难被界定，而且设计环节在整个开发流程的夹缝中很难做人。

可能我们理想中的开发流程，如下↓↓↓↓↓

理想状态：大项目，长周期

可以根据功能迭代排期，合理安排产品开发进度、设计进度。低保真原型还原需求是否合理，高保真原型还原功能表现是否合理，并进行优化体验。除非是企业级/工具类产品做大版本更新，不然很少会有这种情况出现。

但实际遇到的项目流程是这样：

常见状态：大项目，短周期

看到这个流程是不是很懵逼？

这种流程结构，交互在进行产品设计、开发进行底层架构时都很痛苦。交互需要把整体产品的功能用低保真表现出来方便测试和底层架构；然后再根据功能优先级和排期，与产品、视觉一起对核心功能进行再设计和细节功能优化、删减。

近期项目真的是经历了一场大型砍功能现场：

• 合同里没有这个小功能，砍；
• 前端实现不了，砍；
• 底层没架构，砍；
• 时间来不及了，砍；

项目按照复杂需求设计的功能流程，因为开发周期的缘故砍了很多功能，导致甲方对最终产品反馈说使用木