我在互联网大厂做产品（需求设计篇）

公众号新闻

2023-07-21 00:07

关注并将「人人都是产品经理」设为 ★ 星标

每天早上更新，与你一起成长

产品经理要如何保证自己能够在复杂的协同工作中展开正确的需求设计、并实际地解决用户问题？在本篇文章里，作者就总结了自己的需求设计经验，并总结了7个步骤。一起来看看吧，或许会对你有所启发。

作者：memeda，大厂产品经理

题图来自 Unsplash ，基于 CC0 协议

全文共 3763 字，阅读需要 8 分钟

作为产品经理需要对结果负责，我们要推进产品落地并实际解决用户问题，但是在实际工作中我们会遇到很多质疑的声音，各种指点以及横向纵向的需求，作为产品经理我们应该怎么正确的开展一个需求的设计呢，确保每个需求都能在正确的产品路线上？

深挖用户背后的问题

用户的需求不管是用户直述，他人传达或者上级要求，我们都需要对用户进行进一步的分析，用户口述的不一定是真实需要的，需要产品经理站在用户的角度去思考问题，我在大厂挖掘用户问题主要通过沟通与观察的方式。

在与用户沟通的过程中不需要直接去问用户遇到的问题，而是需要清楚地去了解用户做的每一件事情，每个细节的步骤，这样真正了解用户后，产品经理可以不断模拟用户进而感受到用户在实际场景下遇到的问题（深入了解用户后，我一般都是在脑海中不断重复用户的场景，来亲身感受用户会遇到哪些问题，提升自己的用户同理心）。

站在用户角度去思考问题，是挖掘到真正问题的有效方式，这里举一个我在工作中遇到的例子。

当时公司有个部门要做一个民航飞行员排班的系统，主要帮助飞行员查看自己的班次与未来的安排。该产品经理组织研发团队在web端开发了一个排班日历，每个飞行员都能登录web端来查看自己的飞行计划。

这个产品经理其实忽略了一个很严重的问题，就是飞行员去看自己的飞行计划的话，需要打开电脑登录到web端后才能查看自己的飞行计划，明显不合理。

比较合理的方式应该是优先开发移动端的排班日历产品，随时随地方便飞行员随时随地查看自己的飞行计划。出现以上问题的核心原因，就是产品经理没有优先站在用户角度去思考问题，脱离了用户本身。

确认用户问题或价值后，需要判断该问题是通用问题还是个别场景下产生的问题。通用问题就需要安排在主路线上迭代，优先级会高一些，个别场景下的问题则优先级会低一些。

这样当我们被输入需求时，由于产品经理站在了用户角度去思考问题，就会发现有很多的被输入需求是没有必要做的，或是并不紧急的，也会避免成为只会接收需求的工具人。所有的有效需求都需要进行管理与跟进（我们用的是内部的需求管理工具），这样我们在工作中才会有持续性，保证产品稳定的向前发展。

这里引用一个讨论思考，“什么是问题（痛点），什么是需求”。

有个回答我还是比较认同的，说的是问题（痛点）是客观存在的，而需求就是药方，产品经理是开药方的人，每个产品经理开的药方可能都会有出入。

需求的有效性就需要看产品经理的同理心能力了。提升同理心的有效方式就是不断观察用户并成为用户，所以当你遇到问题时，就回归用户本身去思考，就会找到对应的答案。

确认最优解决方案（最小MVP）

当我们确认问题后，就需要制定解决方案。解决方案可能会有很多种，但是我们需要找出最优解决方案同时是最小的MVP来解决当前的用户问题，避免大而全的情况。这样上线后能根据用户的反馈来快速迭代，避免过度设计的情况。

最优解决方案也是需要站在用户的角度去思考，用户的使用成本越低，越简单易懂，也就越接近最优的解决方案。

再回到飞行员排班系统的案例上，解决方案是在移动端开发排班日历工具，我们当时公司是有自己内部的协同工具（市面的协同工具有飞书、钉钉、美团大象、企业微信等），在协同工具上有相应的日历产品，民航飞行员也属于公司内部员工，平时也都在协同工具上进行日常办公。

所以整个事情的一个最优解决方案应该是民航排班系统与公司内部的日历协同工具做对接（借用日历的能力），将排班计划直接显示在飞行员的日历上。这样用户能比较方便的获取自己的飞行计划安排，也无需再去开发一个移动端的排班日历页面，避免重复造轮子，减少了研发周期提升了用户体验。

产品经理不要为了做产品而做产品，而是应该对用户负责，通过最简单的方式去解决用户的问题。

找到最优解决方案后需要横向纵向去同步当前的方案，最好设计比较简单的原型界面（需要精准但不用太细节，主要目的是要把事情说清楚），提高沟通的效率，推进相关干系人制定相应的计划。

作为产品经理我们是有义务去推进各方（横向与纵向的相关干系人，核心用户、上下级、同级等）针对解决方案达成一致性的。

这一过程也会遇到不同的阻碍与问题（兄弟部门不配合、方案有不同意见等），但是产品经理要坚持站在用户的角度去正确地推进事情（我们经常会遇到什么历史原因、时间紧张等问题，这些都是需要站在用户的角度去解决），只有正确地去推进事情，最终才能使用户满意，产品才会有价值。

产品交互设计

各方干系人达成一致后，开始进行详细的交互设计，在此之前由于已经确认了用户问题与解决方案，我们在设计交互的时候要根据解决方案去制定用户的交互流程，遵循“延续解决方案，先逻辑后交互，交互体验闭环”的原则。

有些公司是有交互设计师的（我们部门没有交互设计师，主要由产品经理承担该部分的职责），产品经理要把控整体交互逻辑（页面跳转、点击交互、界面文案设计、按钮位置等。这些与用户发生交互的点都属于交互设计的设计范围），要遵循前期整体的解决方案来进行设计。

不要为了交互而交互。交互设计也是需要遵循MVP的原则，不要过度设计。

这里举一个搜索的例子。

交互体验闭环就是从用户点击搜索的功能开始到结束，用户的整体操作分为：点击搜索-输入搜索关键词-查看关键词搜索结果目录-查看结果详情-关闭搜索（在准备PRD文档时也是按照这个路径去准备需求，这样能看到完成的用户路径，不会遗漏需求点）。

每个环节都是用户与产品发生交互的部分，需要设计用户在操作每个动作后的展示结果与路径。而且需要保障整体交互流程为最小MVP的流程，设计完成之后需要产品经理不断在脑海中模拟整个交互流程，看看是否还存在用户使用卡点。

模拟用户操作需要化身在用户的使用场景中去模拟，这样才能最接近真实的使用情况，发现当前交互设计中的问题并提前解决，当然此项技能需要产品经理不断的练习和提升的。

交互设计完成后可以找相关干系人进行沟通，有时我会直接给核心用户去演示，目的是提前通过交互原型去触达用户，看看是否能解决用户的问题，如果有问题也能提前优化解决，避免造成无效的研发投入。

协同UI进行视觉设计

视觉设计也需要延续解决方案与交互设计的整体逻辑，主要需要保证视觉的一致性，减少对用户的使用干扰。产品经理需要把控整体的逻辑，设计负责整体视觉与规范，产品与设计思路不一致时要进行同分讨论共同寻找解决方案。

此时的设计可能会针对交互、逻辑提出相应的疑问，产品经理则需要始终站在用户角度去分析解答问题。

此阶段要遵循“先逻辑，后视觉”的规则，不要为了设计而设计，避免造成过度设计。

设计完成后可以找相关干系人进行讨论确认，视觉设计能呈现最终的产品交付效果，相关干系人也能直接看到交付物，其实在每个关键阶段与核心干系人进行讨论后及时发现问题，最终就不会产生需求偏差，就把问题牢牢控制在需求设计阶段，提升产品整体的研发效率。

完善需求PRD文档

交互与视觉都完成以后再最终完善PRD文档，产品经理从用户的问题挖掘就已经开始准备PRD文档了，整个过程都在调整与准备，直到视觉设计完成后再最终将PRD文档完善。

我一般在设计解决方案的时候准备第一个版本，交互设计的时候准备第二个版本，UI完成以后再进行收尾准备第三个版本，研发评审后会准备第四个版本，开发与测试过程中优化第五个版本（比较小的需求可能就需要1到2个版本就ok了），每次都是逐步完善（修改或补充的部分需要与相关干系人同步确认，尤其是研发阶段，更改的内容一定要告知对应的研发，达成一致后再进行更改），补齐相关的内容，PRD文档是逐步迭代，最终与上线内容保持一致。