从0到1的背景产品设计(4):交互设计和数据回放

主要介绍设计背景产品时应该注意的背景产品交互设计，以及如何复制背景产品的数据。期待能给你启发，好好享受~
我们刚接触后台产品设计的时候，对整个后台产品的交互并没有一个特别清晰的概念，尤其是我们面对的大部分产品都是各种C端产品，后台产品除了列表可能都是表单，似乎并没有给设计留下太多的设计空间。
当我面对我的第一个大型后台项目3354 Fresh ERP的时候，我们的产品设计和研发；d实际上创造了一套设计规范。不仅浪费时间，而且相关设计还不如Antdesgin等成熟的UI框架。
随着接触的产品越来越多，不同业务逻辑涉及的功能越来越复杂，你会发现，有时候当一个产品功能不知道如何抽象其成功的功能时，一个好的交互组件可能一下子就解决了你的问题，因为这个问题可能是别人踩过的坑。
比如当你因为数据很多而不知道如何选择的时候，Element或者Antdesign已经为你提供了几十个树选择器和穿梭盒；当你设计一个上传图片的小功能时，Antdesign的插件其实是有查看大图和删除的功能的，但如果你没有经验，可能会错过这两个小功能。
所以做后台产品的时候，不需要反复造轮子。多了解一些市面上的优秀框架，不仅有助于我们拓宽思路，还能锻炼产品功能的抽象能力。而且可以节约成本和时间。
特别是后台设计框架——Antdesgin不仅为我提供了一个优秀的设计框架，还将我自己的设计语言总结成了一个丰富详细的文档。当我们在日常工作中了解到这一点，就能充分理解整个后台产品的交互设计思路；具体文件如下：https://ant.design/docs/spec/introduce-cn.
Antdesgin的文档不仅介绍了设计的基本原理，包括脱胎于《写给大家看到设计书》的亲密、对齐、对比、重复四大经典理论，以及Fitz法则的应用，还介绍了视觉和设计模式，以及Antdesgin的Axure和sketch的模板下载。
总之，看了这篇文章就足以学习后台产品的交互设计了。
书中提到的用户体验五要素《用户体验要素》:战略层、范围层、结构层、框架层、呈现层。我们把它从头到尾粗略地梳理了一遍。一个背景产品，经过这样一个过程，其实大致成型；产品初步成长后，要考虑以下几件事。这个产品——怎么样？设计合理不合理，后续还有哪些需要改进的地方。
这时候数据的意义就很重要了，但是对于后端产品来说，在DAU、MAU、流量转化漏斗、流失率等等方面都和C端产品不一样。
在后台恢复产品的数据时，需要注意以下几点：
1.相对值比绝对值更有意义。对于后台产品，我们不能更多的去衡量一个产品的绝对值。比如一个C端营销活动上线后，有多少人参与，有多少人下单，发了多少券，核销了多少券等等。这些是营销活动的核心指标。对于后端产品，可能你服务的对象只是公司某个部门的几个人。整个使用的量级不会有大的变化和波动。
所以一个背景产品要关注的指标是它的相对价值，也就是投放前后的对比。
2.核心指标数据：成本和效率。那么，我们更应该关注那些指标的相对值呢？
大部分后端产品的初衷，其实都是为了某个业务流程的降本增效。所以要关注的核心指标也是成本和效率；你设计的产品上线后为公司降低了多少成本，提高了多少效率？是核心指标，也是设计产品是否合格的关键因素。
比如物流运输管理系统上线，我们拆分不同的业务环节，看每个环节的成本降低了多少，效率提高了多少。
比如可以具体列出一个表格：拍照，加载后保存。之前没有系统的时候，链接都是发图片到微信。整个环节是：司机拍照发给司机定时运维统一采集录入Excel评估存档备份；估计每个点的大概时间。
系统上线后，这个环节是：司机拍照上传系统运维检查异常信息处理。
通过对比各个环节的数据，可以直观的展现产品设计中的突出点和不足。
3.非核心指标的数据有哪些？和成本效率是后台产品做数据分析和统计时的两个核心指标。除此之外，后台产品中还有一些其他指标需要我们注意。
非核心指标可以结合业务流程确定一些专属指标。例如，建立一个凭证发放系统，凭证发放业务场景的满意率可以作为一个指标。
另外，一些专业的系统，有些指标会有一些专业的要求，比如一些大企业的费用控制系统，员工的报销准确率是比较重要的指标之一。
另外还有一些指标，比如哪个流程关联度最大，一个流程的及时性对另一个流程的影响最大；哪个过程花费的时间最多，步骤最多，等等。这些数据是我们可以考虑挑选指标的点。
4.如何利用数据在我们有了数据分析结果之后，我们可以从以下几点来改进我们的产品：
1)对每个环节进行分类，根据不同的比例确定指标效率。
由于业务逻辑的复杂性，每个环节的效率提升可能不同；比如链接A，你上线后可能马上升级20%；而link B由于更多的线上线下联动和更多的输入数据，优化和重新优化后可能只有5%的增长。
所以不能一概而论数据的作用。每个环节需要根据其特点分类一次；这类需要更多工时优化效果但不尽如人意的，可以在后续的产品设计中给予较低的优先级。如果线上多，可以节省大量人力成本和资源，优先考虑；
2)圈出高频操作的最小范围，从操作层面进行优化。
我们在设计产品的时候，很多业务流程和操作内容往往不是特别准确，无论是业务方的需求分析，还是我们自己研究的结果；一些不重要但是高频的业务流程，在业务端的描述中有时会被忽略，所以我们在设计产品的时候会把它们放在不显眼的位置。
这时候，每个业务操作的埋点就更重要了。它可以检测出哪些行为是高频行为。在我们得到这些结果之后，我们需要做的就是降低高频行为的操作层次，优化高频行为的操作路径。
同时，在进行高频优化时，需要确定高频操作的最小范围，因为一个流程可能会很冗长繁琐，如果把这个流程的操作层次全部升级，可能会得不偿失。
比如在TMS系统中，司机交付后拍照只是一个分支业务流程，电缆敷设作业确实是核心环节。所以很有可能在业务的描述上花了大量的笔墨来描述接线过程，而司机交付后拍的照片可能只是路过。
但在实际操作中，虽然业务端排线时间长，流程复杂，但一个流程可能只有一次排线。
而司机的交车后拍照，整个行程中每次送到一个房子都需要拍照，一趟可能要操作十几次。如果我们在听完业务描述后，将这个操作深埋地下，无疑会增加操作时间和复杂度，降低实际操作中的效率。这时候我们可以在后期的优化和恢复过程中第二次梳理流程。在订单页面右上角保留拍照按钮，可以快速拍照。
3)整理常见表格的信息，设计成模板。
在积累了一定的数据之后，在一些业务场景下的很多操作，或许可以总结出几个通用的标准，尤其是一些表单的操作内容。要创建的10个记录信息字段中，有6个可能与场景a中填写的信息相同，在这种情况下，我们可以将表单的信息作为模板，简化填写流程，提高效率。这里有一个SQL的想法。积累了一定的数据后，就可以用符合这个特征的表单内容来整理数据了。
挑选
Count (*)为“每种类型的数量”，
计数(不同的业务场景)为“分布式业务场景”，
特定的表单元素
从
要查询的表1，
要查询的表2
在哪里
需要提出的一些因素
分组依据
要组合的元素1，
要合并的元素2
以.排序
伯爵(*) desc
得到业务数据后，我们要做的远不止这些。业务流程优化原则实际上可以作为数据分析的一些指导原则。您可以在这里再次查看：
简化高频操作：操作频率越高，越值得优化流程。举个例子，如果一个系统的运行频率是一个闭环任务总工作时间的1%，每个闭环任务会有30个操作，那么当流程效率优化10%时，一个闭环任务的效率整体会提高3%。紧密流程合并的操作：如果两个流程联系紧密，可以在流程中合并。精致的流程，尽量系统化：如果是人工操作的复杂繁琐的流程，可以抽象成系统化的流程，即减少内部交互，提高操作效率。整理工作流：整理流程中与工作流相关的内容(工作流介绍见上一篇)。整理异常流程：整理主流程后，输出主流程中可能出现的异常流程。关键节点按照流程的六个要素进行排序。以上系列文章是我平时设计一个后台产品时的整体思路。首先我会对自己一段时间的知识做一个总结和回顾，让自己在平常的工作中对业务有更深入的了解，完善产品设计。除此之外，也是对自己的一个阶段性回顾，以免后续工作中遇到同样的问题时忘记一些之前的坑，留给自己作为别人的教训。
另外，分享这些也可以分享一些设计产品的思路，避免自己踩过的一些坑。
阅读从0到1设计背景产品(1):对背景产品进行分类。
从0到1设计后台产品(2):如何定义业务需求？
从0到1的后台产品设计(三):产品功能的解构
#专栏作家#痴迷，微信微信官方账号：痴迷，每个人都是产品经理专栏作家，都是后台产品经理。
本文由人人作为产品经理原创发布。未经许可，禁止复制。
来自unsplash的图像，基于CC0协议。