百姓网Wap发布项目的上线历程

项目的起源:

一个平常的工作日里面,我们负责开发的工程师羊羊羊(以下简称羊)找到了我,和我说Wap发布不能用了,当时我震惊了一下以为出了什么大Bug呢,坐下来详细了解之后原来羊想表达的意思是我们现在Wap发布的页面交互与视觉都太老套了,用户填写错误的时候也没有明确告知用户错在哪里了,所以羊说不能用了;聊完之后我把自己变成小白用户实际使用了一下Wap发布发了条信息,发现确实存在许多的可用性问题,当时身背数个项目的我决定和羊把这个项目做下去

 

项目的思考与设计:

与做其他项目一样,把现有的基本数据与竞品看了一遍,出了Blog(百姓网内部的产品文档的形式)与交互;也确定了本次优化的范围,发布分为前中后的环节,我们这次会优化最重要的发布中的环节,就是发布表单页,如下二张图就是输出需求的部分截图

发布页面

屏幕快照-2015-12-16-下午5.10.28

需求输出就很正常的进入开发阶段了,这时候我们信心满满,因为我们知道目前的发布确实不好用,改完了之后很大可能会好于目前的情况

 

此处有波折:

在2016年2月份的时候羊开发完毕了,于是做了AB测试,第二天我们看数据惊人的发现发布成功率下降了10%!这是一个非常大的下降,如果真的全量上线了发布量会减少许多,这会是直接的经济损失,为何会这样?询问了客服部门也没有用户反馈发布有问题,陷入了自我怀疑,咱们这次运用了许多JS,是不是JS影响了加载速度或者控件的使用?是不是新的设计与交互用户使用不习惯?

因为这次是代码性能层面与交互设计一起优化上线的,我们无法锁定是哪个部分出了问题,我们对于设计比较有信心,那就先将问题锁定在代码性能层面;我们在加载页面的环节打了许多的数据监测点,之后我们得到了数据,老版本的平均加载时间为2.6秒,新版平均加载时间为4秒+,于是我们对于新版本的加载时间优化到3.6秒,再进行数据监测,发现发布成功率毫无变化!事实证明想要发布的用户多等上1秒多是不在乎的,但是我们还是要做的越短越好

既然性能没有问题难道是设计问题??我们不敢相信,老的设计用户更加喜欢?在接下来的几天时间里面我们没有找到任何解决方案。有一次我找到羊聊天,羊已经没有什么信心了,当时是周一,羊说如果周五我们还没有起色我们只能回滚到老版本了然后去做其他的项目,我和羊表达了我的意思:不能把这个项目做成烂尾的项目!目前主要的责任在我,作为产品经理没有找到解决方案的源头,我相信我们很快就能找到问题的根源,咱们肯定行!

虽然口头上很有信心,作为产品经理在数日时间里面没有找到问题的根源,内心是有挫败感的;于是把自己当成小白用户不断的发布信息,发现了一个重大问题:用户在没有登录情况下填写发布表单之后跳转到登录页面,用户登录好了之后并没有发布,而是重新回到发布页面,用户下拉之后再次点击发布按钮才能发布,而老版本中登录好了就直接发布了,我赶紧找到羊让他把这个问题修复,晚上加班到家10点多了,我就拿我爸爸的手机中的UC浏览器尝试发布流程,没想到这时候就发现的了一个重大问题,在安卓4.4以下的系统里面不支持Flaxbox的css属性,界面错乱导致不可使用;当时我心理就一阵暗喜,这二个问题修复之后发布成功率很大可能会提升,事实证明就是这样!

 

顺利上线:

经过二个重大Bug的修复,发布成功率提升上来了并且比老版本的略高,于是我们全面放量,放量之后也没有出现报错或者用户反馈,数据表现也很正常;并且成功的挡住了机器人来Wap发帖,不过机器人的因素在一开始没有考虑到,上线期间才意识到的

 

做的好的地方:

  • 这是自发的项目,没有人要求我们做这个项目,我和羊都是身兼数个项目,在整个过程中遇到了许多困难,都没有退缩或者放弃,在项目推进过程中拥有十足的热情
  • 没有测试与BI;测试和BI的工作是我们自己担起来的,特别是羊,在页面上打了N多的点并看数据分析

做的不好的地方:

  • 发布是一个大项目,本次改版涉及到了代码性能与交互界面,我们的做法是开发好一起上线的;刚开始上线AB测试的时候发布成功率是下降的,我们无法锁定到底是代码性能层面还是交互界面层面的问题;应该先调整交互界面,等确定没有问题之后再上线性能
  • 对于发布的用户了解不够深入,项目最初没有拉取用户手机,分辨率,浏览器等数据;导致后面我们自己测试的环节中忽视了UC这样的“恼人”浏览器
  • 对不发布产品本身考虑不够周全,忽视了“机器人”的这样的因素

总结:

  • 这是一个经过等于才见到彩虹的项目,给我们自身带来了许多价值与思考,让我们对于Wap和发布流程越来越了解
  • 项目中上线了N多个优化case,让我们对于判断上线case对于数据的影响越来越准确
  • 项目中看了许多笔数据,让我们对于看数据更加敏感

电商排行榜产品进化过程

简易而言,电商排行榜产品的意义在于:按照一定的算法将所有电商进行排名,可以凸显帮5买在电商行业的权威地位;本文将会讲述此产品的进化过程与细节。

第一版本:

下图就是我刚刚接手电商排行榜时候的界面(效果图,非真实数据),将商家按照收录商品数,流量占比,最低价商品数占比进行计算,得出一个综合的商家指数进行降序排列,为用户购物作出一定的指引。其中3大数据为机器自动抓取,平均每天可以更新一次,全部为真实数据,参考价值还是相当的。

商家可以提交自己的信息,可以申请被我们收录,若商家指数计算出来能进前100名,就可以被展示在界面上。

右侧也会提供一些热度和成交数最高的商品。

为了做这个界面,设计师足足设计了100多个Logo!

第一版本

第二版本:

产品在线一段时间之后,我们的老板(黄飞鸿)提出:这里面全部都是机器获取的数据,应该加入信任之类的用户产生的内容,使得商家指数变得更为丰满。

收到此需求之后,我们就开始策划产品,计划增加一列数据:可信度;按照美国学生的评分方式,从A+到D-,降序排列。

怎么评分呢?我和产品助理一起商讨着,结合帮5买自身产品的一些用户反馈、电商本身的名气,一些第三方网站的反馈;来进行综合的人工打分;一些不知名的商城只能拿到C以下的分数了。

一切妥当之后,就开发上线了,界面效果图如下。

第二版本

第三版本:

随着公司的不断发展,影响力也不断增加,公司投资人对此页面感兴趣了,老板也不断提升要求,老板希望能加入更多更新的东西,让商家指数更加的丰满,希望我们团队能够进行一次头脑风暴,相处更多的好点子。

当我接到如此抽象的改版需求之后,我并没有组织大家进行头脑风暴,因为此产品偏数字,偏现实,不合适进行头脑风暴,于是,我进入了个人的理性思考。

结合我领导提出的意见,我把指数的重新计算进行了如下的策划:

爬取数据需求

把可信度变成了用户评价,包括:好评度、印象标签、点评数量、投诉数量,并加入了帮5买评价,用户可以直接点击顶和踩对商家做出评价。这样的话商家指数就可以变得丰满。

用户评价类的数据我们自身是没有的,需要爬取,所以我们向Data组提出了数据爬取需求,如下图:

爬取需求

需求提出之后,Data组领导安排了一名工程师与我们对接,工程师分析了360印象网站的的数据结构,开始爬取,这之间的过程比较顺利,3天之后,就全部爬取完毕并顺利入库。

这次的要展示的数据明显增多,如果一次性全展示在页面上的话,用户很难找到重点,所以我们又开始设计界面交互来解决此问题,进行了草图设计,如下图:

草图设计

将第一层级的属性(如数据评估)与属性值放出来,其他的内容先隐藏起来,这样可以做到一目了然。

页面上还有一些细节的修正,我们看了数据,发现来此页面的人一般都是来看商家排行的,很少有购物的行为,左侧商品模块的点击率很低,索性就直接删除了。

商品排行

从页面上线至今,已经有不少的商家提交了收录信息,我们发现很多的联系人我们并不知道他们的职位,这让我们联系起来很头疼,所以我们就加入了职业的填写项目,但不做为必填项目。

申请表单

整个产品里面最核心的应该就是如何得出综合的商家指数了,构想的时候确实伤脑经,通过和商业智能工程师与产品助力的合力商讨,我们还是把这个艰难的阶段给攻破了。技术版权,关键部位已被我抹去,嘿嘿。

算法

 

界面的设计我们也在同步进行着,因我本人之前就是设计专业毕业,所以对于设计要求比较苛刻,不做到90分以上不罢休。我们的UI设计师被我来回折腾了好几轮,才最终定稿。效果图如下:

第三版本-数据展开

第三版本-评价展开

上线中的一个插曲,因为老板要展示给投资人看新版本,压缩了上线时间,前端的时间就不够,圆形的好评度那块我们足足切了101张图。

好在当天晚上12点20分左右,产品顺利上线!

奉上地址:http://www.b5m.com/jihe2

上线之后我发现banner不好看,又进行了更新

我们提前就已经加好了统计代码,经过一点时间的观察,我们发现经过我们的努力,产品受欢迎程度还是不错的,UV曲线越来越妖娆了。

UV趋势图