数据分析产品设计中，有哪些坑需要注意？

加关注，带你看世界

上一篇《数据分析产品设计中，有哪些坑需要注意（二）》，针对数据分析产品的上线后运行情况，进行复盘反思，主要围绕如何保证数据的正确性来进行迭代优化。那么本次，笔者主要是从数据产品的实用性的角度来谈谈如何保障数据产品具有较高的实用性。

愿景：在产品设计中踩过的那些坑，希望分享出来，给入门B端的产品新人一些提醒。

目标人群：产品人&年龄

idea：分享一些实际的产品设计案例

竞争对手：个人兴趣、时间、惰性

预计耗时：阅读本文预计耗时7分钟

不放原型图的原因：因为是政府涉密项目，不敢放出原型图，请见谅

产品基本情况：笔者为政府设计打造的数据分析产品，需要实现的5大公功能板块简要概述为风险预防、风险识别、风险处理（风险分类推送、风险处置、风险处置审核、风险归档）、风险结果运用（考评考核、监督通报、奖惩、个人培训）、风险指标融合分析等内容。

本产品主要监督覆盖的人群覆盖80%的“工作人员”，而产品的使用受众分为3部分：“基层工作人员”、“监督部门人员”、“xx部门人员”。

产品的使用场景主要有着几类：在基层工作人员的工作场景中；在监督部门的定时监督抽查工作场景中；在xx部门人员对风险的结果进行通报、纪律问责、奖惩的工作场景中。整个产品会形成一个环形的业务闭环，如下图所示。

所以本文将主要结合使用场景来进行说明，数据分析产品中应该注意的事项。

（ps：要特别说明的一点，这里笔者要讲的是，针对已有第三方的业务系统，要为客户建设基于业务系统的数据分析平台，这样的难度还要更高一些，其他的情况，如由一家公司统一建设，这里不作讨论。）

一、基层工作人员的工作场景中

在基层工作人员的使用场景中，需要考虑3个点：

第一，该数据分析产品需不需要基层工作人员进行操作使用，如果需要，那么开放的功能模块和数据权限如何？

第二，如果不需要基层工作人员进行登录操作使用，那么如何发挥数据分析产品在基层工作中的作用？

第三，产品上线后，对基层工作人员的工作负担如何？是否正面效果大于负面效果，以及如何改善正面效果？

这里挑选2个简单的例子，来说说笔者建设的数据分析产品的建设结果。由于笔者建设的产品服务的对象是政府部门，该政府部门的实际工作办理情况往往需要涉及多个业务系统（说明：每个业务系统都是由不同的单位承建，且需要单独登录使用不同的客户端），秉承的建设思路是在当前的工作实际基础上，不打扰基层工作人员的正常工作，因此笔者建设的平台是不需要基层工作人员进行登录操作使用。

主要从两个使用场景为基层工作人员进行服务：

场景一：执法风险预防。

通过数据分析的手段，提前知道基层工作人员的执法风险，通过短信预警的形式，为基层工作人员进行提醒（这里要特别注意短信预警的频率和内容，频率太多反而影响工作效率和体验，频率太少，及时性不够；内容上如果编写不当，基层工作人员无法得知具体的情况，内容过多，也会导致阅读障碍）。

场景二：执法风险处理。

基层工作人员在收到执法违规的短信警告的时候，根据短信内容指引，直接在自己的业务平台上进行处理即可，也无须登录本数据分析平台。在业务平台上处理完毕之后，本数据分析平台的异常数据自动消除，异常的历史行为数据作为归档数据保存在本数据分析平台中，用于个人绩效考评考核等内容。

本平台主要通过短信提示和引导的方式，构筑起平台和基层工作人员之间的联系。那么这样的方式对基层工作人员的负担的评估方式主要是两个维度：精力和效率。

本平台上线之初，一些基层工作人员反映一天要收几百上千条的短信，无法筛查哪些是紧急需要处理的，哪些是需要注意而不用处理的，每天的短信内容都看不过来，极大影响了他们的工作效率。严重增加了他们的工作负担，负面效果极大，降低他们对该平台的认可度。

因此，我们主要是针对这类基层工作人员的工作流程中的风险，优化风险内容和短信预警的方式、频率以及内容。比如：每天提示预防类短信只汇总发送一条短信，违规风险类短信也只汇总发送一条，如此每天可以针对不同类型的信息进行查看，问题聚焦。

二、监督部门人员的工作场景中

本身数据分析产品就是主要给监督部门的人员使用，主要考虑几个点：

第一，关心的风险内容有哪些？

第二，风险数据过多，如何有效展示分线数据更加直观地说明问题？

第三，作为数据分析平台，如何保证展示数据的正确性？

第四，数据分析平台中，若缺失的数据内容，是否可以支持手工录入，生产部分数据？

第五，发现了风险，如何处理闭环？

第六，如何有效促进业务办理的水平提高？

在这里首先要明确，数据分析平台不是数据的第一生产者，只是数据的消费者，所以无法保证数据是否正确无误。另外就是，对于数据分析类的数据要求，和业务类的数据要求是不一样的，所以需要去平衡是否要自行生产部分数据内容。

最后就是，所有的发现的问题不能只是发现了，没有后续的处理措施，所以需要进行闭环考虑。关于整个产品的业务闭环，可以参考笔者的《案例拆解：B端的MVP你真的懂吗？》一文。

笔者依旧列举两个场景，来对以上的问题进行典型回答：

场景一：监督部门需要对某一块业务B进行监督，这里的业务B是由前置业务A流转而来的。

在这里业务B要关心的风险内容的维度由多种：如业务B的内部环节流转情况、各个流转节点的时限情况（又分为正常、预警、超期三类情况）、业务B的完成情况（又分为按期、超期）、业务B的流向情况等。

所以实际上要展示的数据指标多大10多项，如果仅仅是按照客户告知的按照这些维度进行一一排列。实际上，在使用的过程中直接存在的问题是：无法直接感知总体风险情况如何、和上下游业务的关联情况、和上下游业务的发展情况（主要是根据业务来区分不同的风险异常）。

因此，在这里，笔者是这么考虑的。将数据展示分为两部分：上下结构。

上部分是放业务B的总体风险情况；下部分，是根据业务B的总体风险情况，按照各个内部环节的流转以及结合业务A的流转情况，来进行展示的。从上到下，是一个业务B的流向布局，到最后一层，就是直接流向业务C的数据分析展示情况。

场景二：监督部门同样需要对某一块业务D进行监督，但是业务D在实际的操作过程中的数据存储方式是以非结构化的数据进行存储，数据分析平台无法直接获取该部分内容。

在这种情况下，我们考虑过用OCR识别的方式，但是目前商用的正确率只能到80%左右，如果对正确率要求不高的场景，可以尝试采用。但是由于笔者该模块对数据的准确性要求必须是100%，所以只能排除该方案。

无法用系统搞定的，只能采用人工结合的方式，人辅助系统去识别无法识别的内容，实际上就是需要人工去录入2个字段即可。这个方案就会涉及到人工输入，平台自行生产数据了，就需要考虑是否和平台定位不符合。

平台的定位只是数据运用，那么这个方案是否和平台冲突呢？

答案是不冲突的。我们这样去思考这个问题：

首先系统已经为用户将所有需要监督的数据筛选出来了，只是无法去判断这些数据是否存在风险，相当于这里就是采用人工去甄别风险的过程，这个过程和平台发现风险去核实的过程的本质是一样的；

其次是这里录入的数据并不与业务直接挂钩，不用于业务处理，所以可以认为，这个方案和平台的定位并不冲突，也是比较符合当前的大数据分析平台的现实，无法保证数据100%的准确。

所以在建设数据分析平台的时候，切忌为了数据分析而进行数据分析，需要结合具体的业务痛点，只有这样的才能建设出符合用户需要，且真实解决了用户痛点的数据分析平台。另外就是在建设过程中，一定要有闭环的思维模式，在适当的情况下，可以考虑采用人工的方式，要记住系统不是万能的，能减轻用户的部分负担，就是一个好的数据分析平台。

三、xx部门人员的工作场景中

作为数据分析平台，还有一个很重要的作用就是可以为每一个个人、部门进行数据化的量化考核，使得考核更加的公平公正，奖惩更有依据，所以需要将xx部门的考核及奖惩需求纳入到数据分析平台，完成整个的风险结果的闭环。

在这里，坑就比较少了。在这个部分的建设过程中，只要将线下部分的考核内容完整的挪移到线上即可，切忌千万不要自行发挥就好。另外该部分实际上有点偏向与业务工作了，xx部门的人员很有可能会将一些涉及到奖惩、通报、问责的工作流的需求给纳入进来，这个时候产品经理就需要好好斟酌这类涉及到业务的需求了。一定要秉持，我们是一个数据分析平台，不作业务流程处理。这里笔者认为最多就是提供一些报表内容、可供下载、打印即可。

总结

由于当前业内也没有很好的数据分析产品的建设经验，也没有很好的数据分析展示的经验。所以各位产品人，在做数据分析产品的时候，就需要依靠自己的判断以及对业务的理解，合理的设计数据分析产品，做到每一个页面都能讲述一个故事，每一个数据指标都有其意义，每一个数据描述都没有歧义。

数据分析产品做到新手一看就懂，就是一个好产品了。

#声明#