本文主要内容是关于互联网产品策划过程中的设计方法总结，是我这几年实战留下了的些许心得，通过问答的形式，来说明产品设计和项目过程中需注意的问题，可作为自检思考工具。
包括内容：需求分析、文档输出、体验细节优化、异常防错处理等。
根据美国哈佛大学教授雷蒙德·弗农(Raymond Vernon)的《产品生命周》理论，产品周期可分为：导入期–成长期–成熟期–衰退期。互联网产品在这个四个阶段，对应的产品规划重点：拉新、活跃留存、付费、自传播优先级比重也不同。
启动需求之前，先问自己，你所负责的产品，当前处在哪个生命周期阶段，当季度、当月的项目重点是什么？你可以根据产品当前的周期，来选定需求的优先级，一般可将需求分为4类：P0.重要且紧急，P1.重要不紧急，P0-P1.紧急不重要（性价比高的可提至P0），P2.不紧急且不重要。跟进产品当前重点需要解决的问题，来确定产品研发方向，以及当前需启动的需求。
大部分关于产品经理的文章，都在写此部分内容，一般都会问：用户是谁，需求目的是什么，满足用户哪方面诉求或心理需求，比如：懒得、虚荣、贪婪等……最常引用的是《马斯洛五大需求理论》，但大部分都说的比较虚。
我个人认为，一个产品面向的用户群是相对固定的时候，不需要花太多时间在问用户是谁，用户有什么特性。这一点上，我挺认同张小龙的理论（虽然他不一定说过），一个真正好的产品，无论用户是谁，都会用的顺手，都觉得好用。在产品设计过程中，特别是APP类的设计，功能的简洁，大气，操作普适性，我会比较认同。当然，在界面设计上做的有个性不能说是错，但个性不等于花哨，也不等于流程隐晦繁琐。
在过滤需求时，除了问需求目的之外，结合阶段目标，研发性价比也是非常重要的。来自用户反馈的过于具体的需求，需要多思考有没有更好的路径来达到用户诉求。例如，游戏公会会长，想在游戏过程中，也可以及时审批会员申请，因此提出希望游戏过程中，可暂时返回到管理页面进行操作。这个需求看似合理，但其实经过简单评估后，会发现，研发成本非常高，且会长离开游戏房间后，需考虑一系列如自动操作、超时托管等处理，且若会长长时间不回来，是否会对一起游戏的对手造成不好的体验等等，都是需要考虑的点。因此，需要发散考虑是否有更好的办法来实现会长的这个诉求，比如说，可以增加副会长来协助会长管理，或在游戏中增加快捷操作入口，都是可以考虑的方案。满足需求的方式不止一种，要权衡性价比和功能可能造成的后果，来决策。
有时候，因为竞品做了某些功能，无论是团队抑或是boss都会有想要快速跟上竞品的想法，最终需求会落到产品经理手上。对于此类需求，我个人比较不建议照搬竞品功能。原因有2：
1、你与竞品的用户群属性、产品周期、运营模式必定有差异，照搬很大可能会水土不服；
2、每一个产品、功能肯定都有做的好的地方和做的不好的的地方，学其精华去其糟粕才是王道。习惯于抄袭，不是什么好事。产品需要有自己的调性，哪怕只是微创新。
对于产品规划来说，有一个清晰的阶段目标以及明确的deline非常重要，这样整个团队的士气才能被鼓舞起来。有了目标之后，版本拆解也很重要，2到3周是一个比较合适的迭代周期。需求文档需在研发前2-4周确定好，并进入美术设计阶段。
研发层面，一个迭代一周开发，一周联调并进入测试，在测试阶段，可开始下个迭代需求评审，评审之后，需要预留一个方案调整的时间。尤其是对于技术实力不够强大的团队，产品在某些时候，需要更多的考虑技术实现成本问题。当然，哪些东西可调整，哪些要坚持原则，这个点本文后面会详细讲解。
每个版本内容包括：新功能+基础功能+小优化点+BUG修复（紧急BUG会独立安排人力及时解决，不会排入常规迭代），这样来保证产品整体迭代的均衡，不至于每天都在救火。
在给建议之前，我想说一下自己的一个研发团队。我的上一任产品在交接时，跟我说，恭喜你，要入坑了。确实，用坑来形容，不为过。市场同事的评价很中肯：功能做完上线，完全不是我们想要的功能，用户不会用，还把其他功能搞出一大堆BUG，然后又花了几天回退。搞了两个月，啥都没搞成。确实，我接手后的第一感觉就是：乱。无论是产品逻辑、还是团队管理，都非常乱。在爆BUG前，没有人知道风险点，也没有提前预防；整个研发团队每个人每天都忙于应付线上不断复发的BUG，像热锅上的蚂蚁，但研发效率极低，且质量不稳定。
我们通过一个季度的不断尝试和总结，摸索到几个比较有效的办法，让整个产品、研发团队的效率和质量得到提升：
1、信息高效互通，对应负责人及时反馈：采用石墨共享《需求收集表》、《BUG反馈表》、《版本规划表》。表格作为整个团队信息互通的桥梁，包括：市场、运营、产品、研发等都可以随时查看，每个人清楚我们当前还有多少BUG要解决，有多少需求待开发，市场的声音怎么样，每个需求的优先级，以及后续需求规划。
《需求收集表》、《BUG反馈表》：所有人均可在需求收集表、BUG跟进表表格中填写自己的需求，和发现的BUG或体验问题，产品经理需每天查看表格，并备注每项需求、BUG的处理意见和进度。研发同事在保证完成自己分内工作后，可自行认领想挑战解决的陈年BUG（重要不紧急），并计入绩效贡献。《版本规划表》则由产品负责人来按周更新，我们一般要求产品负责人提前两个月以上做好品规划，拆解成季度、月度、周的计划。在每个月最后一周，集中收集并确定下个月版本研发内容，并事先同步给全员。所有团队成员可直接查看最近一个月至一季度的需求规划情况，可提前准备或预研。
2、强化开发者的全局思考能力，无论是团队成员自发组织体验产品，还是严格要求技术评审时每人都需要提问，都让研发人员更熟悉产品需求。让研发团队的每个人都了解到产品全局的设计框架，也多了解其他人做的模块，同时整个团队对阶段目标、产品现有全局功能逻辑有透彻了解。逐步提升研发人员的全局框架思维能力和产品思维能力。做到提前预防，而不是出了BUG再来救火，也避免很多低能的BUG出现。
3、提高每个团队成员的owner心态，并配合及时奖励机。每周研发组周会每人发言自己所发现的问题，简单轻松，无所不谈，同时设置月度研发标兵奖励，对于有贡献的同事进行及时鼓励。事实证明，简单的奖励效果明显，团队上进心不断被激发，甩锅心态也渐渐被消除。
首先，在开始输出需求方案之前，一定要先回答3个问题：
1、需求方提出这个需求的目的是什么，也就是这个需求为了达到什么效果，你们是否对需求出发点、需求目的、预期效果达成共识？你能否预估需求上线后的数据效果？
2、是否有竞品已经实现了此功能，至少看3个以上竞品，且每个竞品实现的细节差异点是什么样的，他们为什么会做成不同/或相同的样子？你是否了解竞品功能的市场反馈或数据？
3、核心流程是否有技术难点，是否需要提前对可行性进行评估或预研？核心逻辑选定，需与研发快速确定可行行、选定最高性价比核心方案，事先全局思考，切忌边做边改，做到一半，发现方案行不通，或者技术成本过大而放弃。
在方案输出过程中，建议先做好竞品分析，同时提前咨询研发人员关于方案核心流程的可行性以及研发难度，这样可以很好的帮助你判断需求是否拆分版本，如何拆分版本，避免等到需求全部输出后，在评审会上被彻底推翻。因此，事前沟通非常重要，它能帮助你获取更多信息，并结合研发成本、时间规划做出最合理方案。
核心逻辑确定之后，方案的方向和主干基本确定，接下来就是细化方案，输出文档。在细化方案的过程中，主要会涉及到功能流程框架，页面交互设计、细节处理等。下面总结几个很重要的点，来提升易用性和用户体验：
1、把用户假设成一个聪明但是很忙的人，不要指望让用户记住任何操作流程，而是随时提供清晰的指引和尽可能自由的页面跳转入口。
2、用户的高频操作，应尽量减少操作步骤，而低频操作，则无需刻意关注步骤数，更应该关注的是每一步的操作难度和界面信息是否易于理解。应尽量降低选择难度，别让用户花时间去理解。
3、一个页面只突出一个重点，用大小，颜色，形状来做分类，让用户一眼可分辨到重要信息。
4、扁平化和渐进披露相结合，视场景而定，而不是机械化执行扁平化。流程扁平化的好处是，可以让用户提前感知流程，页面跳转的成本也比较低，但是比较考验对页面信息的整合处理，渐进披露是预先把次要信息隐藏，当用户触发了对应操作，进入对应流程，才给出相应反馈或指引，好处是让用户更专注，减少理解成本。
5、页面一致性也是这个道理，就我理解，一致性的是为了让用户形成习惯，进而减少理解成本。比如，确定操作永远在右侧，选中状态永远高亮，红色代表严重警告等等。当用户已经形成统一认知，则会大大降低每一次操作的理解成本。但有时候设计师会过于信仰一致性，导致失去个性，我建议在不影响习惯的前提下，可适时打破所谓一致性的束缚，让设计更加出彩。
6、让用户有反悔机会。误操作后，可恢复，且重要操作需二次确认，并强化感知严重性。
7、避免依赖文字说明，多用图形化的方式让用户直接感知，而不是通过理解文字来感知。且文案使用的格式、主语建议统一，这有助于营造整体调性。另外一点，即按钮文案的使用，建议明确告诉用户该页面的目的和功能，同时引导行为，而不是陈述性文案。用动词+宾语的格式来引导用户操作，如：“去购买”比“商城”更清楚，“去玩牌”比“游戏”更清楚。
8、需同时考虑多平台的用户操作习惯，如ios系统上的应用，页面需提供返回按钮，而安卓上的应用，按钮应避免过于靠近手机底部操作栏，以防误操作。
1、在开始描述详细功能点之前，先说明该功能的核心功能逻辑，让读者先了解整个文档核心。可借助脑图（xmind）、表格（excle）、逻辑图来辅助描述；
2、交互流程图（axure）：将每个关键流程统一展示在一张交互图上，并注解重点交互细节及规则，这样读者可以直观感知页面跳转逻辑以及判断逻辑，可以极大提升评审效率；
3、描述功能时，分模块来划分文档会是比较好的做法，可避免重复。
需考虑极限情况和异常情况处理：
1、列表为空情况处理，网络异常拉取失败处理，进行中强退考虑断线重连、进行中强退后如何处理玩家进度；
2、数据超上限规则：保存数量上限、保存周期上限、分页条数数量；
3、完整的编辑权限需具备：增、删、改、查；
4、重连次数以及如何触发重连：若进行3次重连尝试依然失败后，显示重连按钮，让玩家手动触发刷新；后台推送失败如奖励发放，推送失败，需让玩家可以手动触发领奖的地方；
5、加载频率考虑：是否需要预加载，或者进入页面时才加载，会影响到切换速度；
6、切后台、断网、玩家频繁切到微信的场景，会造成APP短暂收不到正常数据推送。要考虑页面数据是否会延迟，是否需真实刷新，或自动触发刷新。
7、发放奖励需考虑防刷机制，要做到即使出现功能BUG，系统也会在达到阈值时，自动预警或直接熔断。防刷规则可简单分为：
8、完整的需求文档，需配备配置后台以及数据埋点需求，在功能上线后，可持续监控跟踪数据表现，进而分析效果以及迭代优化方向。
1、明确需求目的：拉新、活跃、留存、付费、体验、逼格调性……开始需求输出前，需提炼，过滤需求，避免机械照搬竞品功能；
2、明确核心逻辑并先与研发商定可行性、性价比，若性价比过低，需快速调整方案，同时，输出完整方案时，需完善考虑异常处理、防错设计等细节，做到“带脑子”做事；
3、确保研发人员对需求理解透彻，且能从全局角度设计技术方案，需求描述越清晰，越细致，研发效率越高；
4、大功能分迭代，分版本做，第一步先实现核心功能闭环，上线验证并收集反馈，再启动附加功能开发。
本文由 @Ada冰 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。