全国服务热线:
文字游戏
当前位置:主页 > 文字游戏 >
那么我要做的第一件事情就是全盘体验梳理整个
添加时间:2017-12-11
 

《以实例讲产品改版方法论》系列,是一个时间跨度接近半年的全站改版大项目,留下的一点经验,共分为两个部分。本文为上篇,主要讲改版准备与驱动,下篇为改版语境下的产品设计实操技巧。

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

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

第一是以前整个产品都没有文档体系,包括产品定位与规划、产品页面结构图、信息架构图与规则说明、后台角色与权限图表。前面的很好感知和修正,后面的都是体力活。这么一套东西,做了大概三周,精细到每一个列表的分页、特殊布局位,每一个字段的取值范围、来源与关联关系。前端很好处理,开着web查看器挨着试,后台逻辑就需要先记下问题,找个时间集中问问开发了。

第二个,建立了需求池。在体验的时候发现了很多问题,一些是关于功能定位的,会发现有些功能没做起效果来,或者和自己的想像不一致。一些是发现细节纰漏,交互体验上的,流程引导上的。这些统统记录在需求池里,大概有一百来条,加上找一些同事聊过的,加起来120条左右了,都是有名目、有场景的优化需求,有些也记录了需求方直接提出的解决方案。

第三,结合数据表现,来看每个功能的使用量、频度、时间分布,还有用户轨迹、产生的内容特征,进一步摸清楚每个场景下的用户画像。

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

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

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

开发似乎是有重构意愿的,也有性能/代码优化的想法。设计师改版意愿也很强烈,毕竟上线产品就是带链接的作品集。

在一段时期内,把一些需求池中记录的疑难杂症,向关键人物一点一点地提一遍,也可以IM+口头。关键点是要把握适当的频度和时机,如在开发资源紧张时做绵长而有频度的铺垫,维持话题在领导心中的热度到60分左右,然后抓住一个窗口时期全盘托出。

展示用户反馈的统计数据,点出反馈集中的某个板块,讲讲优化后的预期效果(向上画饼,或者叫“灌输理念”),全站改版没机会的话,至少可以拆解出这一块先改。

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

对于内部质疑性反馈,一定要非常耐心且及时地解释清楚改动的目的,解决了什么问题,让所有未直接参与改版前讨论的同事,也能最快理解改版目的。这样,我们树立了一个正确的靶子,让大家的讨论意见跟着牵引,不至于失控。

对于个性化的需求,要讲明该功能所服务的人群是哪几类,比例分布如何,对哪些人影响更大,哪些人的意见更为重要。

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

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

苏B2--10 增值电信业务经营许可证:苏B2- 在线数据处理与交易许可证:苏B2-

2005-2017徐州八方网络科技有限公司 版权所有PoweredCmsTop苏公网安备 号