以实例讲产品改版:准备与推动篇



前期准备与铺垫

加入公司的时候,产品经过半年马不停蹄的持续丰富,刚刚进入稳定期,此时有足够的内容和数据积累,且各条功能线的体验均为最初版。我正好就此讲下,想要改版,产品上的基础工作准备:

上一版产品没有留下专业的产品文档,那么我要做的第一件事情就是全盘体验梳理整个产品前后台,并顺带把迭代路径和产品定位摸清楚。这个过程对我来说有三个关键产出:

  • 第一是以前整个产品都没有文档体系,我建立了,包括产品定位与规划、产品页面结构图、流程图、信息架构图与规则说明、后台角色与权限图表。前面的很好感知和修正,后面的都是体力活。这么一套东西,做了大概三周,精细到每一个列表的分页、排序、特殊布局位,每一个字段的取值范围、约束条件、来源与关联关系。前端很好处理,开着web查看器挨着试,后台逻辑就需要先记下问题,找个时间集中问问开发了。
  • 第二个,建立了需求池。在体验的时候发现了很多问题,一些是关于功能定位的,会发现有些功能没做起效果来,或者和自己的想像不一致。一些是发现细节纰漏,交互体验上的,流程引导上的。这些统统记录在需求池里,大概有一百来条,加上找一些同事聊过的,加起来120条左右了,都是有名目、有来源、有场景的优化需求,有些也记录了需求方直接提出的解决方案。
  • 第三,结合数据表现,来看每个功能的使用量、人群规模、频度、时间分布,还有用户轨迹、身份特征、产生的内容特征,进一步摸清楚每个场景下的用户画像

1. 改版和优化的区别?

先区分这个问题,我们再来谈改版还是优化的选择。

产品上讲,优化比改版的方向性更为清晰,问题产生的时候同步就有了可量化的上线指标,而改版则不一定,甚至可能往相反方向进行尝试,连产品功能的定位都可能改变。

技术实现上来讲,改版不一定重构,但如果是连定位都变了的大改,很难能保证原来的信息架构和页面流程不会重做,所以产品一旦确认是要改版,那么就会给研发团队一个暗示:这次改版方案决策,一定是解决问题 > 开发时间成本的,并会给开发重构代码的时间窗口。而我们如果采用优化的方式,实际上还是在产品目标内,尽量照顾现有的产品框架,考虑实现方案的性价比,做多个局部处理来实现优化目标。

2. 为什么要改版而不是逐步优化?

这个问题要想清楚,否则一定会被团队成员问到。这时候梳理了下这个需求池,发现事情并不简单:

  • 有几条需求同时指向一个问题的,不能独立击破,得跳出来提出一个整体解决方案。
  • 有些需求问过开发了,重构的时候来做吧,现在没法动,积重难返。
  • 部分功能是多个人在不同时间的意见简单叠加,不成整体。

概括的来说,通常有四种情况,我会认为有整体解决的必要:

  1. 多个问题指向一个板块。
  2. 能直接从现有产品中看出设计者和执行者之间的理解偏差。
  3. 三是能看出需求跟着时间变了,但产品只是简单做了加法。
  4. 四是需求深度不够,没有往下细想,上线后发现落地场景出了问题,数据很差。

这些毛病,病因清晰但盘根错节,大刀阔斧整体性解决反而划算,小步快跑容易变成打地鼠。

3. 推动改版的客观条件

无非是看看天时、地利、人和。

  • 正好目前没有排期中的新需求,且改版需求任务量大(100+条)。
  • 各部门的负责人好像都聊过了,都有产品诉求,各自的价值主张也比较清楚了。
  • 开发似乎是有重构意愿的,主动提过,也有性能/代码优化的想法。设计师改版意愿也很强烈,毕竟上线产品就是带链接的作品集。

4. 改版驱动的技巧

  • 在一段时期内,把一些需求池中记录的疑难杂症,向关键人物一点一点地提一遍,可以是口头,也可以IM+口头。关键点是要把握适当的频度和时机,如在开发资源紧张时做绵长而有频度的铺垫,维持话题在领导心中的热度到60分左右,然后抓住一个窗口时期全盘托出。
  • 展示用户反馈的统计数据,点出反馈集中的某个板块,讲讲优化后的预期效果(向上画饼,或者叫“灌输理念”),全站改版没机会的话,至少可以拆解出这一块先改。
  • 对于一些确实重要的问题,可以在话术上适当放大,把可能的极坏情况陈述出来。
  • 找到或者创造目标一致的伙伴,如设计师或者开发,多个职能一起贡献推进影响力。

5. 改版后的跟进与坚守

时间来得及的情况,改版后我们需要出具改版说明文档、规则变化说明文档(如新版广告位图片需求表格),有时候甚至要做后台使用培训。改版后,还需要时刻监控着改版关键指标的变化,及时发现问题,看看和自己的预想有无偏差。

另外一方面,作为整体负责改版的产品经理,要站出来面对所有的反馈。

  • 对于内部质疑性反馈,一定要非常耐心且及时地解释清楚改动的目的,解决了什么问题,让所有未直接参与改版前讨论的同事,也能最快理解改版目的。这样,我们树立了一个正确的靶子,让大家的讨论意见跟着牵引,不至于失控。
  • 对于合理的有效反馈,立即建表执行修改并跟进,及时通报进度。
  • 对于难以判断的主观意见,要阐明我们需要尊重设计师的专业意见和开发实现成本等。
  • 对于个性化的需求,要讲明该功能所服务的人群是哪几类,比例分布如何,对哪些人影响更大,哪些人的意见更为重要。

每次改版后一定会有争议。

但,只要前期经过充分论证和仔细推敲,我们就有坚守的信心,站出来,保护自己的设计,也保护UI和开发团队。

拿出耐心的态度,逐个处理反馈,控制并主导意见走向,避免陷于被动的局面导致返工,甚至新意见大量涌入后的需求失控。

 

作者:尘中之光,专注内容,关注数据、广告、机器学习

本文由 @尘中之光 原创发布于人人都是产品经理,未经作者许可,禁止转载。