体验至上的产品设计无为而治的数据分析

　　做产品的时候，产品设计和数据分析都是为了呈现更好地产品体验。然而，有时候我们会陷入一个怪圈为了呈现数据分析而做数据分析，从而导致了用户使用成本的增加。接下来，笔者就为我们分析了这一现象的原因以及解决之道。
　　一、基本概念介绍
　　1。产品设计
　　产品设计以场景为驱动。以为什么人在什么场景下解决什么问题为目标，作为产品功能设计的驱动因素。以定位的用户要解决的一系列相关问题，综合成先后顺序的一系列功能作为业务流程，完成产品流程的设计。相关业务功能组织到一起，方便用户根据要解决的问题和场景，快速找到想要的功能作为产品模块划分。消除困惑和阻碍，让用户在使用产品的过程中感受舒适、自然。
　　2。数据分析
　　数据分析是通过对业务数据的分析对比，协助产品经理了解相关业务和分析产品功能使用情况。
　　用数据分析统计的方式研究和认识问题，比根据经验或感性的直觉直观更加具有客观性，能避免一些人性本能的偏见。数据分析从想要了解的问题出发，制定合理的数据指标，围绕数据指标收集数据，处理数据，对比数据，从而达到认识并解决问题的目的。
　　想要了解的问题、合理的数据指标、高度相关元数据是一次数据分析的基本组成，对比是数据分析与人认知事物的方式的契合点，是数据能反应问题的唯一方式。
　　3。产品设计和数据分析相伴相生的关系
　　产品设计和数据分析往往是相伴相生。
　　产品经理通过分析数据了解单个产品功能的点击次数、一个产品流程的跳转路径和转化率、各个功能模块的用户占比等，用于优化产品功能的体验、减少用户完成一个流程的阻碍、衡量不同功能模块的投入产出等。
　　反过来，用户使用产品功能产生的数据，是产品经理书籍分析的元数据的主要来源，除去网络性能分析、闪退日志等技术性能层面的数据之外，用户行为的采集、用户用产品解决问题产生的业务数据，是产品经理数据分析的全部来源。
　　二、产品设计与数据分析本不该出现确又时常出现的矛盾
　　1。矛盾描述
　　实际工作过程中，产品经理偶尔会被这样一个问题困扰我想要一个特定的数据，这个数据对于分析业务和分析产品很重要，我想要在用户的产品操作流程中加一个功能，让用户去用这个功能，这样我就可以收集到这个数据了。
　　但是根据用户使用产品流程的场景及要解决的问题来说，用户本可以无需进行此操作或者不用关心系统数据的变化就能完成自己的工作。相反，如果加了这个功能，用户会被迫从连贯认知的场景作业流程中退出，做一件直接看上去和自己的直接工作没有关系的事情。
　　更有甚者，产品经理在后续的作业流程中加入了数据状态约束，强制要求后续作业的其他用户去完成本欲强加给前序作业的用户无需关心的数据状态更新工作。
　　举个例子：一个生产中产生的产品沿着线下生产流程流动，其所经历的生产过程信息在线上流动。产出的产品可能是合格品或不合格品。不合格品会有如下处理：
　　（1）返工为合格品；（2）粉碎处理成原材料，共其他生产使用。
　　我们的数据目标是：了解不合格品分别流向了（1）、（2）的占比，从而分析原材料的投入产出比，作业时间、生产设备资源的浪费情况。
　　线下作业的场景流程是：
　　一般情况下：产品作为线上信息的实体，会根据线上作业闭环情况流向（1）、（2）两个作业流程。在数据分析过程中，对数据做流向处理，通过数据处理出产品分别流向（1）、（2）的情况。
　　出现矛盾时：产品经理希望在产品信息实体上设计一个状态，给用户工作中增加一个流程，给用户一个功能，让用户手动把流向（2）的产品标记为一个特殊的状态。这样数据分析的时候只要查信息实体，不用做流向分析就能得出产品流向（1）、（2）的占比情况。
　　2。矛盾危害
　　经过刻意引导和规范的数据，得出的可能是预期想要的结果，但未必是真实的结果。
　　作为产品设计人员，这样设计产品功能是在视图把自己的认知强加给用户，而不是站在用户的角度为用户解决问题。这样的设计会扰乱产品功能、流程、模块划分的基本信息架构原则，扰乱用户对于产品的认知，或者用户很难或者无法建立起对产品架构的认知，使用产品功能时，一直处于困惑和谨小慎微中。这样的设计是一种傲慢自大的要求，而不基于客观现状的沟通。
　　在上面的例子当中，设计产品的人已经忘记了什么用户在什么场景下做什么事情。产品设计的目的成了想要在数据库中保存一条什么样的信息，用一个select查一下就出来了一个饼图了。
　　但是深入场景中思考下就会出现如下问题：
　　（1）用户核心的工作是线下的生产，增加在系统中查找报废物料这样的操作，是在增加他额外的工作量，会降低他的效率。而且新增加的操作从生产作业的角度看，并不是一个创造正向价值的操作。从精益生产的角度来看，是一个要被减掉的浪费。
　　（2）用户不做报废的操作，照样可以拿物料去做加工处理，那么他为什么还要做这个事情。如果用户跳过这个步骤了，我们做出来的数据分析占比将会是一个错误的结果，会更加有误导性。
　　（你或许会想，可以约束后面的加工处理只处理报废的物料，这会引出生产可以用什么原料的另一个问题，这里不展开讨论。但是不论如何，约束为只能加工报废物料，带来的系统配置的代价会更大，对于用户和产品设计都会增加很多不必要的工作。）
　　3。解决方法
　　坚持产品设计的基本原则不动摇
　　就像上面例子中的正常情况一样：
　　一方面，用户要做完自己的作业，就不需要让产品在业务中流转。产品功能和线下作业流程保持一致，契合用户的使用场景，用户使用产品的过程中不会有疑惑，不会觉得工作思路被打断。
　　另一方面，正如我在另一篇文章《四个方面，深解产品架构设计》中所说好的业务架构的各个系统的数据在业务整体上是连续的、完整的、完备的。通过组合提取分析，可以很好驱动业务运营，为企业发展规划及战略决策提供数据支撑。
　　所以，预期把关注点放在让用户来确保数据的完整性，更加应该把关注点放在确保产品架构在业务整体上的连续性、完整性、完备性。
　　4。解决方案所基于的基础分析
　　认为以上解决方案合理。
　　因为，一般来说，用户操作产品，产品为特定的用户在特定的场景中解决特定的问题而设计。用户在与设计模型相符的场景中的被使用解决着预期的问题，相关业务数据在用户完成作业的过程当中自然流转。这种自然流转的数据没有刻意的引导，拥有自然的异常，是对业务和产品体验最真实的反应。
　　想要分析一个作业流程中最后衍生了那些情况，沿着元数据最后走向的分支做分析对比，可以得出自然真实的结果。
　　这种结果，从用户体验的角度看，反应了用户自然的增长、自然的流逝、自然点击次数、自然的浏览路径。从业务的角度看，尽可能地排除了用户体验对业务数据的影响，比较纯粹地反应了业务本身的自然状况。
　　基于这样的数据分析，做出的是以人为本的业务和产品决策，让数据驱动业务和用户体验在让用户舒适的基础上做出改进和提升。
　　三、结论
　　体验至上的产品设计，无为而治的数据分析。产品设计时只考虑用户在场景中怎样简单方便的解决自己的问题。数据分析时，从未经引导的，反应用户实际操作过程的元数据中挖掘探索业务的流向、用户的行为，探索客观的数据相关关系，不为省力的数据分析增加用户的操作成本。