--- theme: smartblue --- 这是我们团队号工程化系列文章的第五篇，全系列文章如下： - [字节三年，谈谈一线团队如何搞工程化一（全景篇）](https://juejin.cn/post/7311596602249134106 "https://juejin.cn/post/7311596602249134106") - [⚡️卡顿减少 95% — 记一次React性能优化实践（性能篇）](https://juejin.cn/post/7314493192187265074 "https://juejin.cn/post/7314493192187265074") - [Modal管理-看这篇文章就够了 (实践篇)](https://juejin.cn/post/7315231440777707558 "https://juejin.cn/post/7315231440777707558") - [# 🍓中台表单技术选型实践(表单实践)](https://juejin.cn/post/7316723621292638246 "https://juejin.cn/post/7316723621292638246") > 团队尚有HC，感兴趣的小伙伴可以私信~（注明期望岗位城市：北京、上海、杭州） # 中台为什么要做用户体验提起中台体验优化，很多人的第一反应可能是“不重要、没意义、没事做，在瞎卷”，那我们来看一个真实的案例：

上述是一个中台比较普遍的的现象，但由于中台的特殊性（没有选择余地的，真的没得选），用户一般只能一边骂着娘一边继续用。那这种糟糕的体验也仅仅是内部用户的吐槽吗？结果远不止于此！！！这种糟糕的体验会给内部**合作带来裂痕**，使双方互不信任（研发觉得用户笨，用户觉得研发菜），影响后续合作（有需求也不找你们了）。还会直接**给客户和公司带来资损，** 迷惑的交互会使用户工作效率降低，工作错误率上升，各种隐患层叠不穷 **。** 所以**所有的系统只要它的用户是人就要做好用户体验，因为它的存在是为了解决问题而不是制造问题。** # 中台体验建设有哪些难点中台体验差难道是产研故意为之吗？答案肯定是否定的。中台在体验建设上有自己困境，相较于C端甚至更难： **不重视**，很多中台业务为了更快的解决用户问题，而不是更好的解决问题。一个需求过来，研发来个一把搓，没有任何交互设计，一切只为了尽快上线。 **价值难衡量，** 缺少明确的收益指标。中台不像C有转化率、收益率等明确的结果指标，中台更多依赖依靠用户反馈，但这些反馈通常是滞后的，带有一定主观性，很难从全局的角度给出设计建议。 **缺少行业标杆，** 中台通常都是企业内部用户使用，使用场景相对封闭，在设计理念上沟通先天不足，缺少全场景的标准解决方案，在具体的业务场景下全凭业务自我发挥，导致质量参差不齐。 # 什么是好的用户体验我们先来看下用户体验的本质是什么，下文是来自维基百科的定义： **用户体验设计**（英语：User Experience Design），是以用户为中心的一种设计手段，以用户需求为目标而进行的设计。设计过程注重以用户为中心，用户体验的概念从开发的最早期就开始进入整个流程，并贯穿始终。其目的就是保证： - 对用户体验有正确的预估 - 认识用户的真实期望和目的 - 在功能核心还能够以低廉成本加以修改的时候对设计进行修正 - 保证功能核心同人机界面之间的协调工作，减少BUG。总体的核心就是**以人为本**，打造**稳定好用**的系统，具体的实践我们我们可以参考《用户体验要素》来做表现层、框架层、结构层、范围层、战略层五个维度的拆解。接下来我们会从研发的角度重点从表现层、战略层详细展开。 **表现层：** 单个元素的实现，例如图片大小、是否点击可以跳转等。 **框架层：** 多元素布局位置，例如登录、注册按钮放哪里 **结构层：** 页面与页面之间的跳转关系，例如登录完成后，跳转至主页面，还是完善资料页面？ **范围层：** 产品的功能范围，就是具体要做哪些事情？ **战略层：** 要满足的用户需求和公司的商业目标

# 怎么做

截屏2024-01-02 15.31.45.png

## 表现层 ### 社区比较流行的交互规范 [介绍 - Ant Design](https://ant.design/docs/spec/introduce-cn) ### **以业务逻辑为基础** 一个交互模块的出现就是为了解决一类业务问题，交互模块的设计要基于当前业务场景去思考，比如： - 表单的填写，哪些是必填，哪些是非必填，哪些需要**默认值**。

- 数据的展示，哪些数据是重要数据需要**着重展示**，哪些是次要数据可以**弱化/折叠**展示。

- 哪些操作是关键且不可逆操作，是否需要加**二次确认**。

### 数据/文字可视化相比数字和文本，人的大脑更容易接受**图像**，我们可以用一些可视化的方式去呈现这些数据或者文案，比如： - 可视化图表

- 在某些字段有业务逻辑关联的情况下，就可以使用可视化的方式来表达，既节省了字段空间，又增加了数据的易读性，比如说**任务达成率**可以用以下形式展示：

- 一些常见工具类操作可以用 logo + tootip 去表示

### 给用户减负 > 费茨法则：到达目标的时间是到达目标的距离与目标大小的函数，具体： > >

> > 其中：1. D 为设备当前位置和目标位置的距离；2. W 为目标的大小。距离越长，所用时间越长；目标越大，所用时间越短。用户鼠标**移动距离越短**、对象**相对目标越大**，用户**越容易操作**。通过运用上下文工具（即：放在内容中的操作工具），使内容和操作融合，从而简化交互。 - 对于操作路径固定并且轻量的场景来说，在保证 UI 美观且合理的情况下，用户鼠标**移动的距离越短越好**。

- 当需要增强按钮的响应性时，可以通过增加用户点击热区的范围，来**增强响应性**，并且不降低美感。鼠标移入按钮附近，就可以激活 Hover 状态。

在使用 Table 时，文字链的点击范围受到文字长短影响，可以设置整个单元格为热区，以便用户触发。

### 保持用户心流 > 变化盲视（Change Blindness）：指视觉场景中的某些变化并未被观察者注意到的心理现象。产生这种现象的原因包括场景中的障碍物，眼球运动、地点的变化，或者是缺乏注意力等。 > 心流（Flow）：也有别名以化境 (Zone) 表示，亦有人翻译为神驰状态，定义是一种将个人精神力完全投注在某种活动上的感觉；心流产生时同时会有高度的兴奋及充实感。在一些不需要用户特别注意的场景，可以尝试用轻度的交互去解决问题，不要对用户带来干扰。 - 能够在一个页面解决的问题，就不要再跳转页面去解决。 - 在一些轻量的场景（删除提示、行内编辑），就不要再使用带蒙层居中的弹窗，让其能够**顺流而行**。

- 交互要保持**稳定性**，比如说在行内编辑场景不要出现行高抖动的情况，打扰用户操作。

### **过渡 & 反馈** 人脑灰质（Gray Matter）会对动态的事物（例如：移动、形变、色变等）保持敏感。在界面中，适当地加入一些过渡效果，能让界面保持生动，同时也能增强用户和界面的沟通。 > 当无法有效提升「实际性能」时，可以考虑适当转移用户的注意力，来缩短某项操作的感知时间，改善感知性能。 **过渡**的呈现形式根据用户需要等待的时长来决定: - 短短几秒

遮罩 loading

按钮操作 loading

骨架屏

- 用户可以接受的时间范围内

进度条

- 较长的时间等待，可以先让用户做其他事情，等事情完成后再给用户一个完成反馈

对于用户的操作来说，我们需要有一个明确且及时的反馈，帮助用户在第一时间得知其操作结果。 **反馈**需要根据当前操作的重要性，和用户需要关注的程度来决定。 - 轻量反馈

- 中度反馈

- 重要信息反馈

### **引导用户** 对于期望用户在下一个模块**高优**做的事情，可以提供一定交互上的暗示 - 静态提示

- 高亮 - 揣测用户意图，自动移动到该位置，或者执行某项动作 - 用户新建某个模块填写内容自动滚动并 focus 到填写内 - 用户打开弹窗填写内容，自动 Focus 第一个需要填写的元素内 - 用户表单报错自动滚动到该位置 - 引导式

### **区分度** > 对比是增加视觉效果最有效方法之一，同时也能在不同元素之间建立一种有组织的层次结构，让用户快速识别关键信息。

对于多层嵌套结构，可以通过以下方式去解决 - 可折叠 Card , 背景色 - 文字大小/颜色/字重 - 边距层次递进 - 分割线 ### **一致性** > 相同的元素在整个界面中不断重复，不仅可以有效降低用户的学习成本，也可以帮助用户识别出这些元素之间的关联性。这里指的是系统同类类型交互在系统中需要有一致的表现（让我们看起来是一个系统），我们需要在开发一个新系统或者旧系统持续迭代的时候，持续关注这一点。 ## **战略层** ### 了解业务

截屏2024-01-02 15.44.14.png

首先我们肯定对业务要有较深的了解，知道我们业务是干啥的，谁在用，我们有哪些场景，当前的这个交互模块是为了解决什么问题，才能去思考这个交互能不能实现这个功能，有没有更好的方式去实现这个功能。 ### 了解用户

截屏2024-01-02 15.45.34.png

在对业务有一定的了解之后，我们需要知道用户期望的功能是什么样子，我们也需要去站在用户的角度去进行思考，如果我们自己是用户想去完成这件任务，这个功能交互怎么设计才能让我们更轻松的去完成这一件任务。 # 如何落地-四步法

截屏2024-01-02 15.46.44.png

### 制定目标首先，我们需要给自己定一个能有明确收益并且可以落地的目标，比如： - 提升操作自助完成率 - 降低用户表单填写停留时长 - 降低用户客诉、Oncall 率 - 提升关键信息触达率 - 减少用户在系统操作时出错率那么我们在计划优化某个任务模块时，可以结合自身业务当前场景选取一个或者多个方向作为目标。 ### 发现问题当我们将目标制定好后，我们就需要结合目标，拆解现状，找到设计现状中存在的问题和可优化的设计点。我们发现潜在问题可以从以下几个方向入手： - 项目成员/设计师自查 - 用户反馈收集/分析 - 寻找用户众测 - 通过已有数据分析设计问题梳理完毕后，可以和团队成员一起将问题归类、确认优先级、并拆解成需求 ### 制定方案当问题确定并转化为需求后，我们需要针对这个问题制定合适的可执行的方案： - 结合上面的理论知识，找到一些基础问题的解决方法。 - 功能模块可以对行业内头部或者优秀的竞品分析，得到一些有用的 idea。 - 根据已有数据，分析用户行为，比如说某个功能用户基本不用，那么就可以淡化，某个功能是高频场景，就可以增加优先级，以此为依据来制作方案。 - 寻找目标用户，获取其对方案的建议。 - 在制定解决问题方案的同时，也需要考虑到相关指标如何收集，如增加业务埋点、用户访谈、用户 oncall 问题收集分析、接入用户反馈系统、用户关键模块录制回放等。 ### 落地追踪当方案经过开发并且上线后，需要有可行的方法去追踪落地的收益是正向的还是负向的，是否能达到当初设定的目标。 - 基于之前定下的目标，收集相关指标是否有所改善 - 用户反馈收集，正向反馈可以提炼成收益，负向反馈可以分析后持续快速优化 - 对我们优化的相关模块进行埋点（有条件的可以接入录制回放系统），上线后可以分析用户操作产生的行为数据相对于之前是否有优化 - 对于在上线前收益不够明确的方案，可以采用 A/B test 来进行对比，观察用户产生的行为数据，看看是否有正向收益 # 总结本文主要探讨业务中后台的**体验优化方法**以及如何将其**落地实施**，这也是本人近期在研究相关内容时，对查阅的资料和自己的思考的总结。业务中后台的体验优化确实挺难的，并非一蹴而就，需要我们在产品迭代的过程中**不断努力**。随着产品的发展，我们在做类似事情时也会越来越**得心应手**。能够打造一个稳定且好用的系统，无疑是一件**极具挑战性**且**富有成就感**的事情！接下来的章节，小编将会记录下自己在交互优化过程中遇到的一些**常见场景及问题**，并将这些内容分享给大家，希望能给大家带来帮助。 # 参考文档 [中后台UX优化之道](https://zhuanlan.zhihu.com/p/115572096) [基于后台产品的设计思考 - 掘金](https://juejin.cn/post/6844903669511651341) [B端交互设计过程中的思考-虎课网](https://huke88.com/article/4626.html) [常用中后台交互设计控件使用场景与规范总结 – 人人都是产品经理](https://www.woshipm.com/ucd/610792.html) [好的交互设计改版，应该如何进行？ – 人人都是产品经理](https://www.woshipm.com/pd/5619434.html) [介绍 - Ant Design](https://ant.design/docs/spec/introduce-cn)