产品设计的“节奏感”该如何把握?

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

661581-b86805bcde530866

Ps:说明一下,这里的产品设计主要指的是APP开发。在APP开发中,版本迭代的“节奏感”很重要,每个大的版本迭代时结合产品计划、用户规模、市场环境要改进什么功能,这些该如何把握?有没有什么优秀的产品案例可以探究参考?

@朱晨

从 鹅厂到ThoughtWorks两年了,从原来的只是画画线框图到现在可以带领团队一起交付产品,对产品节奏感的体会与日俱增。在“骚窝”里浸润着学到的 敏捷开发也让我明白如何从技术执行层面支撑产品的有序发布。做产品就是在用户需求的战场上攻城略地,而节奏感就是每一次冲锋时的默契。

为什么产品成长要有节奏感

在 开始讨论之前,我们可以先将“产品的节奏”定义为“产品更新的时间间隔以及每次更新的内容”,以便让大家对频率有一个统一的概念。一个成长中的产品需要不 断根据业务需求和用户需求来更新产品。形成稳定的产品更新节奏无论是对产品的成长、对用户、还是对团队都会有很大的益处。

对于用户来说,以稳定的节奏感来更新产品可以:

  • 把团队新实现的产品价值周期性地交付给用户使用;
  • 让用户感知到产品的不断成长,容忍暂时的不足,对新版本形成期待;
  • 重新激活部分已经流失掉的僵尸用户。

对于团队来说,稳定的节奏感带来的好处也很多:

  • 保持稳定更新的责任可以督促团队尽早展示新功能,避免闭门造车太久,走偏了方向;
  • 产品经理可以不断推出一些新功能给用户做实验,验证猜想;
  • 团队可以持续地收到用户的反馈,好的反馈可以鼓舞士气,差的反馈可以激发调整的动力;
  • 团队内可以形成有默契的合作方式,产品经理、设计师、开发、测试都明确地知道什么时候该做什么什么事情。

节奏感应该怎么控制

既然刚才已经将“产品的节奏”定义为“产品更新的时间间隔以及每次更新的内容”,那么控制节奏其实也就是这两点了。确定产品更新的时间间隔相对容易。对于移 动端的产品,由于每次更新都需要iOS版审核,用户每次更新都需要重新下载,所以定在3~6周发布一个对外的版本比较合适(紧急修复严重bug不算)。如 果产品处于快速增长期,这个时间还可以进一步缩短。比如“打车大战”时的滴滴和快的,新功能晚一步发布就是个死。

更关键的其实每次更新哪些 内容。如果定好4周一个周期,那就意味着一年也就12次更新的机会。产品经理的职责就是要想好如何带领一帮兄弟们打好这12张牌。如果每次更新都像 adobe reader一样,净都是些个让用户提不起兴趣的bug fix,畏畏缩缩的,那这产品也还是不要做了的好。如何筹谋好每个版本,体现了一位优秀的产品经理运筹帷幄,决胜千里之外的掌控力。

在规划 每个新版本的内容时,可以有两种选择:开疆拓土持续优化

开疆拓土是指产品要完全开辟一个全新的疆域,覆盖全新维度的用户需求场景,野心勃勃,酣畅淋漓。刚刚把一块地占稳了后,这块土地上还很荒芜,后续还需要做很多持续改进的工作来搭建关联辅助的功能,优化产品体验,把这块荒芜土地上的生态系统建立起 来。只要妥善处理好这两种形式的新版本,让它们相辅相成,产品成长的框架就有了。

开疆拓土是最能体现一位产品经理创造性的地方。它往往意味 着从0到1( Zero to One (豆瓣) )去创造出一个有价值、有市场、为产品带来广阔成长机遇的新空间。Facebook圈完关系链然后搞社交游戏;GoPro先做运动摄像机,然后摇身一变成 为媒体公司搞体育直播;滴滴/快的搞完打车再搞专车;微信先搞定了熟人通讯,然后用摇一摇来打陌生人加好友,接下来是朋友圈分享,再来搞公众账号、支付、 游戏分发。这些都是积极进取,从无到有创造价值的典范。同时,开疆拓土也意味着在走少有人走的路,没有经验可以借鉴,风险的坑遍地。千万不要抱着“憋个大 招,打磨完美再拿出来吓死他们”的心态来做开拓性的新功能。务必遵照精益创业的思想,用尽量低的成本在短时间内先发布基本能用的版本,然后再看后续的反馈 做调整。你看微信的对讲机、视频聊天、小视频这些,不也都不温不火的嘛。

持续改进是从0到1之后的从1到n的过程。这部分比较简单,因为只 要前面从0到1这一步走对了,后面就可以根据用户反馈来被用户推着走了。用户们缺乏足够有深度的思考,想不到更快的马可以被福特汽车所取代,但坐过福特汽 车后吐槽减震太烂了、太TM费油之类的能力还是有的。在改进型版本里,主要是做好这几类事情:

优化粗糙的界面设计的体验

可用性测试啊、用户反馈、转化率漏斗的追踪啊之类的都轮番上就行了,比如余额宝大受欢迎后余额宝主页对每日收益的优化

增加跟核心功能相辅相成的功能,比如微信里更快更方便地通过各种渠道加好友,滴滴里面加各种打车的优惠券。

增加让核心功能更好用的琐碎小功能,比如微信里聊天可以置顶、可以搜索聊天记录、可以免打扰。

其实很多中国的产品经理冠着“站在上帝身边的人”之名,也就是每天在做些个持续改进的事情,修修补补,做完发文字再做发照片、发视频、发网址、发投票、发文件。

控制产品节奏感所需要的支持

项目管理

依照传统的瀑布流方式来做APP的话,先花一周来规划功能,再花一周来设计界面,然后花上一周来实现功能,最后一周QA测试+改BUG,最理想的情况下也是 至少4周一个版本。但实际情况更可能是开发做了一半时产品要改个需求,QA测出一堆问题给开发改结果越改越多,最后一公里大家跑的磕磕绊绊然后受迫于所谓 节奏感的deadline把带着一堆BUG的包发掉,或者就干脆延期。这样势必是不行的。

如果依照敏捷方式来推动项目,情况会完全不同。首 先可以将每1周或每2周定做一个Sprint,将需求切分成合适颗粒度的story,然后在每个Sprint内设定好合适的工作量,团队里各个角色高效协 作、并行驱动,就可以确保在Sprint结束时得到可发布的新版本。这样的话,3~6周的对外版本发布是可以保障的。即便是MIUI这样的每1周做一次发 布,也完全没问题。

技术支持

想要稳定地控制产品中的BUG风险,其实是需要相当多的技术力量做保障的,否则很可能代码里总是会有无穷无尽的BUG,代码随着产品成长还会越来越复杂,想拿出一个稳定可发布的版本都难。在XP的敏捷实践里其实是有很多方法来保障代码稳定的。

TDD 测试驱动开发

TDD 会要求开发在写代码之前先仔细分析好需求,想好要实现的这部分功能对应的测试场景有哪些,然后基于此来先写好单元测试,再来写实现。这样做的好处是有了这 些单元测试的保护,代码始终是健壮的。即便以后代码变得复杂,或者要重构修改代码,只要单元测试跑不过时不要check-in代码,就不会引入BUG。

CI 持续集成

在每个开发的单元测试都能跑过的基础上,我们可以用CI来监控整体的代码。只要有Dev搞挂了CI,技术lead就可以打他屁股了。由于CI是完全自动化地 在实时run测试,所以只要任何人check-in的新代码有问题,就可以及时查出来,这样就可以避免Bug引入并积压,让我们随时都有可用的版本。那每 个Sprint结束时给一个稳定可用的版本还不是小意思。

想要有节奏地规划产品,挥斥方遒,其实挺不容易的呢,嗯哼~

@邹建波Kant

产品迭代的节奏感是非常重要的。

这里可能存在一些误解,节奏感我认为不是说要非常清楚未来每个版本该做什么,以及未来每一步的意图,正如苏杰老师所说,这是不现实的,即使有人说有,也更多是事后诸葛亮。

但是产品迭代的节奏感是的确存在的,并且很重要。

举个例子。

最典型的MIUI的一周一迭代。一个每周更新的紧凑节奏感,带给开发团队,内测用户和外界非常棒的感觉,各个方面如进化速度,用户预期,内测者成就感和开发 效率都因而大大提升。这就是典型的节奏感掌握得好。多提一句,MIUI当时的团队我觉得是不可能预测到几个月以后会做什么功能的(除非战略规划),但这个 节奏感并不矛盾。

如何实现产品迭代的节奏感?

我个人对迭代节奏感有这样的思考:

通过稳定的大致固定的迭代周期(且比较快),强化整个团队的意识,如非特殊情况,提需求做设计做需求相对错开。

保证每个迭代周期不是为了做个版本而做,每个周期要有切实有用有价值的功能。的确,许多时候我们不知道如何去考虑未来的功能,但是下一个迭代的需求是可以考 虑的(因为往往此前已有许多需求在等待排期了)。这需要考虑开发时间和需求优先级和需求的意义,具体方法更多需要实例来说。

确保每一个迭代 周期对用户预期的满足。许多产品的迭代周期控制得不错,但是经常很多版本的更新对用户毫无意义,不是修复体验若干,就是带来什么商家主页优化,这些用户不 在乎。每个版本都要给用户带来一些新奇,有趣,有价值的功能,确保用户感知得到你的迭代,和你的节奏感,这样,用户会和你们一起来控制和把握,甚至推动这 个节奏感。这一点MIUI和微信都做得特别好,可以多参考下。

以上。

 

原文来自:简书

作者:小百

您的赞赏,是对我创作的最大鼓励。

评论( 0

登录后参与评论
加载中