互联网产品思考互联网科技0岁的产品经理

产品设计实用思考工具--8个问题

2018-12-27  本文已影响0人  Ada冰

本文主要内容是关于互联网产品策划过程中的设计方法,是我这几年实战留下了的些许心得,通过问答的形式,来说明产品设计和项目过程中需注意的问题,可作为自检思考工具。包括内容:需求分析、文档输出、体验细节优化、异常防错处理等。

第 1 问:需求优先级应该如何排布?接下来应该优先启动哪个需求?

根据美国哈佛大学教授雷蒙德·弗农(Raymond Vernon)的《产品生命周》理论,产品周期可分为:导入期--成长期--成熟期--衰退期。互联网产品在这个四个阶段,对应的产品规划重点:拉新、留存、活跃、付费优先级比重也不同。

启动需求之前,先问自己,你所负责的产品,当前处在哪个生命周期阶段,当季度、当月的项目重点是什么?你可以根据产品当前的周期,来选定需求的优先级,一般可将需求分为4类:P0.重要且紧急,P1.重要不紧急,P0-P1.紧急不重要(性价比高的可提至P0),P2.不紧急且不重要。跟进产品当前重点需要解决的问题,来确定产品研发方向,以及当前需启动的需求。

第 2 问:如何做需求过滤,形成需求池?

大部分关于产品经理的文章,都在写此部分内容,一般都会问:用户是谁,需求目的是什么,满足用户哪方面诉求或心理需求,比如:懒得、虚荣、贪婪等……最常引用的是《马斯洛五大需求理论》,但大部分都说的比较虚。

我个人认为,一个产品面向的用户群是相对固定的时候,不需要花太多时间在问用户是谁,用户有什么特性。这一点上,我挺认同张小龙的理论(虽然他不一定说过),一个真正好的产品,无论用户是谁,都是用的顺手,都觉得好用。在产品设计过程中,特别是APP类的设计,功能的简洁,大气,操作普适性,我会比较认同。当然,在界面设计上做的有个性不能说是错,但个性不等于花哨,也不等于流程隐晦繁琐。

在过滤需求时,除了问需求目的之外,结合阶段目标,研发性价比也是非常重要的。来自用户反馈的过于具体的需求,需要多思考有没有更好的路径来达到用户诉求。例如,游戏公会会长,想在游戏过程中,也可以及时审批会员申请,因此提出希望游戏过程中,可暂时返回到管理页面进行操作。这个需求看似合理,但其实经过简单评估后,会发现,研发成本非常高,且会长离开游戏房间后,需考虑一系列如自动操作、超时托管等处理,且若会长长时间不回来,是否会对一起游戏的对手造成不好的体验等等,都是需要考虑的点。因此,需要发散考虑是否有更好的办法来实现会长的这个诉求,比如说,可以增加副会长来协助会长管理,或在游戏中增加快捷操作入口,都是可以考虑的方案,满足需求的方式不止一种,要权衡性价比和功能可能造成的后果,来决策。

有时候,因为竞品做了某些功能,无论是团队抑或是boss都会有想要快速跟上竞品的想法,最终需求会落到产品经理手上。对于此类需求,是我比较不建议照搬竞品功能。原因有2:

1、你与竞品的用户群属性、产品阶段、运营模式必定有差异,照搬很大可能会水土不服;

2、每一个产品、功能肯定都有做的好的地方和做的不好的的地方,学其精华去其糟粕才是王道。习惯于抄袭,不是什么好事。产品需要有自己的调性,哪怕是微创新。

第 3 问:产品规划怎么做?大需求如何进行版本拆解?要小步快跑吗?

对于产品规划来说,有一个清晰的阶段目标以及明确的deline非常重要,这个整个团队的士气才能被鼓舞起来。有了目标之后,版本拆解也很重要,2周是一个比较合适的迭代周期。需求文档需在研发前2-4周确定好,并进入美术设计阶段。

研发层面,一个迭代一周开发,一周联调并进入测试,在测试阶段,可开始下下迭代需求评审,评审之后,需要预留一个方案调整的时间。尤其是对于技术实力不够强大的团队,产品在某些时候,需要更多的考虑技术实现成本问题。当然,哪些东西可调整,哪些要坚持原则,这个点本文后面会详细讲解。

每个版本内容包括:新功能+基础功能+小优化点+BUG修复(紧急BUG会独立安排人力及时解决,不会排入常规迭代),这样来保证产品整体迭代的均衡,不至于每天都在救火。

第 4 问:如何提升团队效率?如何把更多时间花在产品设计上而不是跟进执行上?

在给建议之前,我想说一下自己的一个研发团队。我的上一任产品在交接时,跟我说,恭喜你,要入坑了。确实,用坑来形容,不为过。市场同事的评价很中肯:功能做完上线,完全不是我们想要的功能,用户不会用,还把其他功能搞出一大堆BUG,然后又花了几天回退。搞了两个月,啥都没搞成。确实,我接手后的第一感觉就是:乱。无论是产品逻辑、还是团队管理,都非常乱。在爆BUG前,没有人知道风险点,也没有提起预防;整个研发团队每个人每天都忙于应付线上不断复发的BUG,想热锅上的蚂蚁,但研发效率极低,且质量不稳定。

我们通过一个季度的不断尝试,和总结,模式到几个比较有效的办法,让整个产品、研发团队的效率和质量得到提升:

1、信息高效互通,对应负责人及时反馈:采用石墨共享《需求收集表》、《BUG反馈表》、《版本规划表》。表格作为整个团队信息互通的桥梁,包括:市场、运营、产品、研发等都可以随时查看,每个人清楚我们当前还有多少BUG要解决,有多少需求待开发,市场的声音怎么样,每个需求的优先级,以及后续需求规划。

《需求收集表》、《BUG反馈表》:所有人均可在需求收集表、BUG跟进表表格中填写自己的需求,和发现的BUG或体验问题,产品经理在每天需查看表格,并备注每项需求、BUG的反馈和进度。研发同事在保证完成自己分内工作后,可自行认领想挑战解决的陈年BUG(重要不紧急),并计入绩效贡献。《版本规划表》则由产品负责人来按周更新,我们一般要求产品负责人提前两个月以上做好品规划,拆解成季度、月度、周的计划。在每个月最后一周,集中收集并确定下个月版本研发内容,并事先同步给全员,所有团队成员可直接查看最近一个月至一季度的需求规划情况,可提前准备或预研。

2、强化开发者的全局思考能力,无论是团队成员自发组织体验产品,还是严格要求技术评审时每人都需要提问,都让研发人员跟熟悉产品需求。让研发团队的每个人都了解到产品全局的设计框架,也多了解其他人做的模块,同时整个团队对阶段目标、产品现有全局功能逻辑,功能逻辑有透彻了解。逐步提升研发人员的全局框架思维能力和产品思维能力。做到提前预防,而不是出了BUG再来救火,也避免很多低能的BUG出现。

3、提高每个团队成员的owner心态,并配合及时奖励机。每周研发组周会每人发言自己所发现的问题,简单轻松,无所不谈,同时设置月度研发标兵奖励,对于有贡献的同事进行及时鼓励。事实证明,简单的奖励效果明显,团队上进心不断被激发,甩锅心态也渐渐被消除。

第 5 问:如何减少方案返工,提高方案合理性?

首先,在开始输出需求方案之前,一定要先回答3个问题:

1、需求方提出这个需求的目的是什么,也就是这个需求为了达到什么效果,你们是否对需求出发点、需求目的、预期效果达成共识?你能否预估需求上线后的数据效果?

2、是否有竞品已经实现了此功能,至少看3个以上竞品,且每个竞品实现的细节差异点是什么样的,他们为什么会做成不同/或相同的样子?你是否了解竞品功能的市场反馈或数据?

3、核心流程是否有技术难点,是否需要提前对可行性进行评估或预研?核心逻辑选定,需与研发快速确定可行行、选定最高性价比核心放安,事先全局思考,切记边做边改,做到一半,发现方案行不通,或者技术成本过大

在方案输出过程中,建议先做好竞品分析,同时提前咨询研发人员关于方案核心流程的可行性以及研发难度,这样可以很好的,也可以帮助你更好的判断需求是否拆分版本,如何拆分版本,避免等到需求全部输出后,在评审会上被彻底推翻。因此,事前沟通非常重要,它能帮助你获取更多信息,并结合研发成本、时间做出最合理方案。

第 6 问:如何提升方案可用性,易用性?

核心逻辑确定之后,方案的方向和主干基本确定,接下来就是细化方案,输出文档。在细化方案的过程,主要会涉及到功能流程框架,页面交互设计、细节处理等。下面总结几个很重要的点,来提升易用性和用户体验:

1、把用户假设成一个聪明但是很忙的人,不要指望让用户记住任何操作流程,而是随时提供清晰的指引和尽可能自由的页面跳转入口。

2、用户的高频操作,应尽量减少操作步骤,而低频操作,则无需刻意关注步骤数,而更应该关注的是每一步的操作难度和界面信息是否易于理解。应尽量降低选择难度,别让用户花时间去理解。

3、一个页面只突出一个重点,用大小,颜色,形状来做分类,让用户一眼可分辨到重要信息。

4、扁平化和渐进披露相结合,视场景而定,而不是机械化执行扁平化。流程扁平化的好处是,可以让用户提前感知流程,页面跳转的成本也比较低,但是比较考验对页面信息的整合处理,渐进披露是预先把次要信息隐藏,当用户触发了对应操作,进入对应流程,才给出相应反馈或指引,好处是让用户更专注,减少理解成本。

5、页面一致性也是这个道理,就我理解,一致性的是为了让用户形成习惯,进而减少理解成本。比如,确定操作永远在右侧,选中状态永远高亮,红色代表严重警告等等。当用户已经形成统一认知,则会大大降低每一次操作的理解成本。但有时候设计师会过于信仰一致性,导致失去个性,我建议在不影响习惯的前提下,适时打破所谓一致性的束缚,让设计更加出彩。

6、让用户有反悔机会,误操作后,可恢复,且重要操作需二次确认,并强化感知严重性。

7、避免依赖文字说明,多用图形化的方式让用户直接感知,而不是通过理解文字来感知。且文案使用的格式、主语建议统一,这不仅,也有助于营造整体调性。另外一点,即按钮文案的使用,建议明确告诉用户该页面的目的和功能,同时引导行为,而不是陈述性文案。用动词+宾语的格式来引导用户操作,如:“去购买”比“商城”更清楚,“去玩牌”比“游戏”更清楚。

8、需同时考虑多平台的用户操作习惯,如ios系统上的应用,页面需提供返回按钮,而安卓上的应用,按钮赢避免过于靠近手机底部操作栏,以防误操作。

第 7 问:如何让策划文档更清晰易读?

1、在开始描述详细功能点之前,先说明该功能的核心功能逻辑,让读者先了解整个文档核心。可借助脑图(xmind)、表格(excle)、逻辑图来辅助描述;

2、交互流程图(axure):将每个关键流程统一展示在一张交互图上,并注解重点交互细节及规则,这样读者可以直观感知页面跳转逻辑以及判断逻辑,可以极大提升评审效率;

3、描述功能时,分模块来属性文档会是比较好的做法,可避免重复。

第 8 问:需求文档中,除了功能流程外,还需要考虑哪些内容?

需考虑极限情况和异常情况处理:

1、列表为空情况处理,网络异常拉取失败处理,进行中强退考虑断线重连、进行中强退后如何处理玩家进度;

2、数据超上限规则:保存数量上限、保存周期上限、分页条数数量;

3、完整的编辑权限需具备:增、删、改、查;

4、重连次数以及如何触发重连:若进行3次重连尝试依然失败后,显示重连按钮,让玩家手动触发刷新;后台推送失败如奖励发放,推送失败,需让玩家可以手动触发领奖的地方;

5、加载频率考虑:是否需要预加载,或者进入页面时才加载,会影响到切换速度;

6、切后台、断网、玩家频繁切到微信的场景,会造成APP短暂收不到正常数据推送。要考虑页面数据是否会延迟,是否需真实刷新,或自动触发刷新。

7、发放奖励需考虑防刷机制,要做到即使出现功能BUG,系统也会在达到阈值时,自动预警或直接熔断。防刷规则可简单分为:

a.周期内(每天、每小时、每分钟、每秒)发放次数、额度上限阈值限制;

b.周期内(每天、每小时、每分钟、每秒)用户行为(注册、获奖)频率上限阈值限制。

8、完整的需求文档,需配备配置后台以及数据埋点需求,在功能上线后,可持续监控跟踪数据表现,进而分享效果以及迭代优化方向。

总结

1、明确需求目的:拉新、活跃、留存、付费、体验、逼格调性……提炼,过滤需求,避免机械照搬竞品功能;

2、明确核心逻辑并先与研发商定可行性、性价比,若性价比过低,需快速调整方案,同时,输出完整方案时,需完善考虑异常处理、防错设计等细节,做到“带脑子”做事;

3、确保研发人员对需求理解透彻,且能从全局角度设计技术方案,需求描述越清晰,越细致,研发效率越高;

4、大功能分迭代,版本做,第一步先实现核心功能闭环,上线验证并收集反馈,再启动附加功能开发。

上一篇下一篇

猜你喜欢

热点阅读