案例复盘:浅析数据统计APP的制作思路
作者根据自身的经验,描述了自己制作一款产品的主要过程,从中总结了一些经验方法与大家分享。
无论是C端还是公司内部用户,都可能会有数据统计的需求。我个人认为,单从产品层面上看,数据类的需求其实并非需要特殊的思路去解决,仍然和其他解决需求时的方法一致。唯一区别在于内容交互、布局方面,数据内容与其他图文内容的不同,大多体现在突出数据的查阅体验。
去年时做了一个公司内部数据统计的APP项目,整个项目前端并不复杂(但在后端几乎把整个电商部门的后台数据倒腾了个遍),这次给大家分享的整个项目中产品层面的一些经历、复盘总结。
用户的场景、需求
用户群角色
首先思考的是我接手的这个项目是面向哪些群体的,在需求讨论会上,我见到了各个业务部门的人,从职位角度归纳了一下,大体上可以分为:销售部(总部&地方)、B端客户部(总部&地方)、总部领导、地方分总等角色。为何从这个角度予以区分呢?是因为两点:1、公司内部一般而言职位相同,对数据的需要就会非常相近。2、公司后台中普遍使用的是这种角色区分维度,容易和后台底层接轨。
然后,不同的角色,意味着对数据的需求、权限是不同的。
用户群的需求
需求采集:由于是公司内部人使用,所以采集这类数据需求的方式就是比较简单直接,开会、私下邮件、当面讨论,即可确定下具体的数据需求项了。遇到大家不一致的地方,会把不一致的人员拉上来,开会进行讨论、辩证的分析:哪些数据是有意义的,有必要的,哪些是不需要的,可以初版不做,后期讨论的。
需求采集其实就是确定需求范围,比较类似于“体验五要素”中的“范围层”。
需求分析:其实在采集的过程中,多多少少能够感觉到需求方对数据项的重视程度了。再加上格外的需求分析这个阶段:对所需的数据进行重要程度分析、实现难度分析(也会和技术进行讨论),经过这一系列的分析,基本上心中大体有数了。哪些高频重要的、哪些低频次要的,哪些简单可做、哪些复杂延后……
需求决断:需求分析的结果一定是需求的判断、抉择,这也是分析的目的、意义。判断、抉择异常重要,它关系着后续产品经理跟进项目的整个大局。决断的结果,就几乎定下了后续产品经理需要多大的精力、成本去跟进项目的进展,项目周期多长,是否能满足领导的上线需求。所以,产品经理不妨也站在自己的角度上,该砍的需求,要毫不留情;该做的需求,要有心理准备;该豁出去时,要豁出去(顶着压力,短时间内加班加点完成项目)。
需求管理:数据这类需求,非常需要对其进行有条理的维护、管理,最好详细的列一个表格,记录数据的类别、逻辑含义、重要程度,面向角色,调取来源。这样的好处在于,以后数据出现问题,可以很好的翻箱检查,也可以在此基础上进行优化、迭代版本。例如:我个人的这次项目中最终确定下来的需求包括:楼盘项目数据、客源数据、财务相关数据。
系统层面的考虑
1、为了灵活配置数据指标,需要权限系统予以支持。可以将该功能纳入后台统一的权限管理系统中,不需要多余的开发。
2、由于大家需求不同,所以在权限中全部列出全部的需求数据项,然后业务人员为每一个角色进行勾选。
这样做的好处就是大大的提高了为角色配置数据指标的灵活度,另外就是减少了产品、研发的维护成本,勾选权限的任务交给业务部门来做。
功能流程、页面结构
整个需求阶段走完后,那么就是页面的流程、结构了。这个阶段强调的是把决断后的需求内容转化成一个可视化的流程、架构。这个阶段非常类似“体验五要素”中的“结构层”,但我个人的描述要比这个“结构层”更实用一些,更具有实践性(王婆卖瓜,自卖自夸 :-D)。
在这里,我想自问自答一下:为什么要把功能流程和页面结构放在一起思考?其实我个人理解,流程和页面是密不可分的。如果仅仅是脑中构思,一般而言可能是一个形象化的构思过程:把功能的入口放在哪里?先操作什么再操作什么?这样便捷度如何?整体流程乱不乱?页面跳转的多不多等等。功能流程必定会和页面结构息息相关。两者分开的话,容易思路不完整;综合考虑这两点,会更灵活、更快捷、全面。
重要思路过程:
1、如果功能流程较多,可以画一下流程图。先画流程图,理清了功能步骤,有哪些页面大体也就会应运而生。如果还不能想象出页面,那么就再细化流程,直到细化到—这段流程就是一个页面的程度,不信页面的感觉出不来(:-D)。
2、大体页面的形成后,就是把页面进行组织、构架起来,形成:首页、列表页、专题页、详情页、结尾页、个人中心等等,也就初步勾勒出了页面结构。
思路的重点:
1、重要的、核心的功能流程是什么?页面上要予以突显出来。先构架出这个核心流程的页面。
2、功能流程转化为页面的思考顺序,一般无非是:入口、列表、详情、结尾、个人中心。具体的要具体分析。也会有些大类别的独立页面,例如:天猫,京东,有很多的类别是有独立的汇聚页。
3、需求的关联性,也会影响到功能流程、页面结构。如果需求是关联性强,那么页面结构上可能会更密切。反之亦然。例如:电商中的购物流程,社区分享流程。两大功能虽然都是用户需求,但两者关联性不强,可以互相独立一些,没必要流程、页面交错一起。
我个人的数据统计APP的功能流程和页面结构,比较简单,就是“入口、列表、详情”,涉及到后台的是权限管理界面。这个是现成的,只要加内容即可。
内容的交互、布局
这个阶段非常类似“体验五要素”中的“框架层”。在这里,就不过多的描述啦,相信大家都看过“体验五要素”中对这段的描述。另外,其实我个人有时习惯把这个阶段和功能流程、页面结构一起考虑,具体看个人吧,也看具体的项目量。
对于我个人的数据统计APP的项目,我也不做交互、布局层面的原由、逻辑分析了。把之前做的保真原型图,直接放上来:
下图是“数据统计列表页”, 功能定位:对所有关键指标一目了然,点击可进详情页。
下图是“指标详情页”,功能定位:通过走势图、不同维度排行榜,展示某一指标的全部信息。
下图还是“指标详情页”, 增加一个时间的交互,快捷日期选择一步到位:
本次就到这儿了,把所有的干货都拿了出来。大家有什么不同观点希望在评论中讨论一下。
同时欢迎阅读我的相关文章,值得你来~
本文由 @中人PM 原创发布于人人都是产品经理。未经许可,禁止转载。
还有就是~if 计算事件量大的话,每次前端加载调接口会不会很多?
请教下~这些数据来源于数据库还是埋点啊
太干货了,同行业,方便私信我一下微信吗?一起交流沟通哈~
可以啊,我的是:hanzhansh