【功能重构实操】以虎扑APP球队页重构后台搭建为例

公司足球业务终止与A的数据供应合作关系,之后和B达成合作关系,因两个供应商提供的接口字段不同且面临接口java化的背景,所以决定直接重构底层数据和前端样式:其中主要需求包括球员详情页、球队详情页重构以及修正后台搭建。

首先整理了球队页整体的DAU、PV、浏览时长、前向来源等数据以及各个子tab下的点击、访问、曝光情况。以PV为标准:新闻tab>

赛程tab>

球员tab>

数据tab>

资料tab>

转会tab、以CTR为标准:新闻tab>

球员tab>

转会tab>

数据tab>

赛程tab>

资料tab。球队详情页产生之初,出发点是我们能提供什么样的能力和服务,所以逐渐把页面做的繁冗复杂,同时维护资源跟不上导致用户反馈激增,这次重构就是需要获取到各层级的用户数据,并根据数据去推测用户需要的是什么以化繁为简。(球队页结构见下图)

这次主要是选择了腾讯体育、懂球帝、PP体育、直播吧、球会体育、雷速体育做为竞品来拆解,会发现各家对球队页的子tab拆分都无外乎是从资料、数据、阵容、赛程、资讯和转会维度出发(我理解这是用户浏览球队页最基础的需求,也是理解成本最小的一种分类方式),但不同的是各家对球队页的header以及子tab中放置的字段与排列样式有着不同的想见解,组件间的交互也迥然不群(例如切换到赛程tab,锚点定位在哪个赛程卡片)。球队页作为一个信息聚合页面,它既需要具备数据展示和查询的工具属性,也需要具备新闻和讨论的社区属性。

所以这次的重构也是以此为切入点,需要贯彻以下两个原则:高效的数据信息展示效率,流畅清晰的交互。

第三点还是一个老生常谈的方法就是去收集用户反馈,我一直认为现在市面上没有几家公司可以做到产品给什么,用户就用什么。大多数的我们还是需要去“认真聆听”用户的吐槽并服务好他们。用户骂得越凶,骂得越多,重构的方向就越明确,也就越证明重构本身是正确的。

例如用户会“告诉”我:右上角的关注按钮有什么用?我点了可以干嘛?也没有toast提醒我?专区的入口这么小,我哪知道可以点?点击排名会跳转至二级页面,为什么点身价就不会跳呢?怎么有的球队页新闻都没有,我明明看到有很多新闻报道这个俱乐部?为什么中超球队改名后详情页的新闻就没有了?为什么有些新闻里的球队标签点击不会跳转至球队详情页?有这么多问题是因为球队页单独来看是很简单,但是把它放在整个App中的时候就会发现他的链路之长,牵一发而动全身,有一些问题是bug,有一些问题是当初的产品设计问题,所以我们在重构的时候很重要的一个任务就是需要去处理掉它们。

以之前的资料页为例,当时它的定位是对球队基本信息的整合,包括成立时间、所在地区等和荣誉记录,用户浏览的情景无非是忘了或者不了解这个球队的基础信息,然后来看一眼就走了,然后再对应之前拉过的数据也发现这个tab的用户浏览数也只有两千多,从数据上来看其实是完全可以把这个tab下线或者合并至其他tab中。

但是在新版中(见下图,左旧右新)我们赋予了这个tab新的定位-“主会场”。从锚点上来看,老版默认定位在新闻tab,新版定位在主页tab;从内容上来看,新版的主页主要包含了四个模块:第一是赛程卡,因为我们希望用户可以在进来的第一眼就可以实时且重要的信息,具体赛程卡显示哪一场比赛以及样式就不展开来说了,其中的逻辑也是相对复杂; 第二个模块是转入转出球员,老版本中转会是有个单独tab的,但是浏览的用户数过低,所以我会判断这个板块并没有持续浏览需求,只会在交易前后的那段时间激增,所以把这模块按照转入球员和转出球员区分展示,用户既可以在主页中看到最近转会的球队信息,也可以点击头像进入球员页获取更多的信息。第三四个板块才是之前老版的基本资料和荣誉,同时在展示上也做了一些更快获取信息的样式变动。

包括数据tab的改动,都是围绕着“高效的数据信息展示效率”原则来进行的,将数据项划分为不同的类型,关键球员的展示效率提升了超过50%同时兼具美感。这次重构中,除了解决部分历史问题和反馈,同时也没忘了做一些“秀肌肉”的功能,例如赛季和赛事的筛选,用户可以看到球队的历史数据。

首当其冲就是我们为什么要去搭建这个后台,原因主要是新接入一套数据源的时候,我们无法去预估实际数据出问题的频率,直接去联系数据源修改接口的时间链路太长,若是故障型的bug出现是来不及解决的,开发也不可能时刻联系改库,特别是国际足球的比赛都集中在凌晨的情景下,所以我们需要一套运营和产品可以直接修改球队详情页的后台,这也就要求了这个后台需要在前端上线)后台架构梳理

因为这个后台的搭建是做在已有的大后台中,所以省去了很多用户、权限、节点的工作量。我这边只需要梳理足球通用配置后台如何实现球队详情页的修改生效。(见下图)

虽然后台设计的时候,定义的是一个后台。但是拆解任务的时候会发现一期完成这个庞大的工作是不太可能的,除了工作量大这个原因外,还有一个更重要的原因就是数据也有不同的类型,对不同类型的数据处理方式是不唯一的,我们把整个后台拆为了三期来完成。

仅初始化同步一次,后续的管理需要人力来维护,主要原因也是因为足球球队数量极多且是相对静态的,这样只需要人力维护一次,以及球队改名需要少量的维护就可以完成,而不再受数据源影响。第二期是完成对动态数据的后台管理

,例如赛程、球员球队榜和积分榜等数据,这部分数据更新频率普遍在1min-10mins,这也代表着不能和静态数据一样靠人工维护。那这一块我们做数据覆盖控制问题的时候,还需要确认一个问题是:新覆盖的数据需要【先审后发】还是【先发后审】。先审后发的实现方式是对比前后两个字段,若有不一样的时候,在钉钉群和后台发送提醒信息,运营需要点击通过或不通过来确认是否需要覆盖,这样保证的是准确性;先发后审是供应商的数据先覆盖,运营再去处理同步错误的字段,这样保证的是实时性。

。在重构前端页面的时候要尽量去满足用户浏览和产品秀肌肉需求,不要被接口提供的能力给限制了。在前期理前端页面需求的时候,会对照着接口文档提供的字段画原型,这样一是速度特别慢,二是页面就局限了。因为当方案足够合理(符合用户需求),即使数据源没有提供该字段也可以通过其他路径满足,例如爬虫、向数据源提需求、合作其他数据源……

我接触产品经理的这个时候,一直接触到的都是c端的产品,刚开始接触后台的时候,对后台的设计总是会漏洞百出,这也是需要我们不断的取试错,快速的积累。(下面是整理的后台用例表格)重构的工作是不容易的(前人埋坑后人泪目)所以这要求我们在产品设计之初的时候,一定要把视线放长远,预埋好足够的扩展空间避免重复造轮子。

You May Also Like

More From Author

+ There are no comments

Add yours