前言

“前台重体验，后台重逻辑”，B端谈 UX 有没有价值？

一切电子化的今天，运营、审核、电销、账务……无数岗位依赖中后台系统来完成他们的日常工作，好的 UX 确实可以直接为这些产能提效

当中后台的工程师们花费了巨大精力沉淀出的一些技术产品，最终落地到业务上的时候，得到的是终端用户“XX系统简直就是狗屎”的抱怨，这就是一种极大的资源浪费

前端工程师的产出是直接对接终端用户的，前端工程师应该是人机交互的专家

UX是User experience的缩写，即用户体验，其核心是用户，体验指用户在使用产品以及与产品发生交互时出现的主观感受和需求满足。其中最重要的概念就是以用户为中心去思考人机交互

一些设计思路

实用先于视觉

通常情况下好看与实用并不会产生冲突，但有一些情况下也需要取舍

上图在视觉上看起来没有任何问题，符合对齐原则。但如果这个筛选器的宽度是自适应的，实际应用中就会存在一些问题。

当用户使用较大分辨率的显示器时，筛选器的宽度会被撑开，此时候项目名称和日期的左右对齐布局就会出现距离过远的问题。当用户需要在若干候选项中筛选数据时，视觉焦点需要频繁的左右横移，造成视觉疲劳。

以业务逻辑为准

交互逻辑的设计需要契合业务逻辑，在某些不能确定的交互场景下，不妨从业务角度去思考

一个典型的场景是表单默认值，比如一些必填项或单选项，是否需要给默认值？给哪个默认值？需要考虑终端用户的实际使用场景：

• 如果某个默认值是绝大多数场景下的最佳选择，默认选择该选项可以减少用户的重复操作，提升表单效率
• 如果是是长串文本如备注，而用户的大多数文本类似只有少数关键字不同，就可以考虑填充用户上一次的备注内容，甚至保存用户的常用文本作为模板
• 而如果是不可逆的操作，则宁可不设默认值，每次都让用户手动选择确认以避免出错。

可视化优先

相比数字和文本，人的大脑更容易接受图像，除了常见的图表之外，对于一些有逻辑相关性的数据我们也可以使用可视化的方式来表达

比如中后台系统的页面上往往充斥大量的table页面，在某些字段有业务逻辑关联的情况下，就可以使用可视化的方式来表达，既节省了字段空间，又增加了数据的易读性

费茨定律

费茨定律指的是：使用指点设备到达一个目标的时间同以下两个因素有关：

1. 设备当前位置和目标位置的距离越长，所用时间越长
2. 目标的大小，目标越大，所用时间越短

将列表的操作区域收束在尽可能靠近的地方，且给每个独立的操作区域划分合理的间隔，有效减少鼠标的来回移动，提升阅读信息与操作的效率，对比以下图片：

顺流而行

用户在执行一些需要集中注意力的任务时会进入心流状态，在此状态时不愿被打扰，我们给用户提供交互时应该思考一个问题，什么情况下应该顺应用户的心流，什么情况下有必要打断？

比如一些不那么重要或不那么复杂的扩展操作，应尽量避免使用遮罩弹窗，遮罩弹窗不但会打断用户的心流，而且增加用户的移动成本

一些行内编辑的场景，也应尽可能避免进入编辑状态时出现行、列宽高的抖动，打扰用户心流

一些弹出式的输入，可以直接帮助用户提前获取好控件的焦点，并提供快捷键方式的确认，减少用户的低效操作

而一些重要的、影响较大的、不可逆的操作，则需要有意打断用户当前心流，将用户的注意力转移到重要的确认事项上

明确、及时反馈

反馈的重要性不用多说，现在的UI库基本也自带各种反馈机制，在什么时候使用哪种程度的反馈是我们需要学习的

一种典型的反馈场景是长时等待，通常是某些后端接口需要响应较长的时间，需要用户等待一段时间，根据需要等待的时长，反馈的设计也不一样

4s内的反馈，一般是一个简单的loading就可以了；而超过4s的反馈，就需要有更加明确的反馈机制了，目的是让用户确信不是程序出了问题，也要让用户知道自己还需要等待多久

一般可以使用进度条，也可以是文本

如果是较长时间的等待，可以考虑让用户可以去做其他事，无需在界面上等待，在后台完成处理后再给用户一个延迟的反馈

好的反馈机制可以减少用户的迷惑，在下图的流程编辑器里，当连线被拉出后，会将可连入的节点高亮，并给出连入点，即使第一次使用的用户也能知道下一步该做什么

除了长时等待之外，一些独立的小编辑项可以使用弱反馈，不打扰

常见的痛点场景

条件缓存

在带有条件查询的页面上将查询条件通过url的get参数保存下来，以便将当前的查询条件保存在浏览器书签或进行分享，在页面意外关闭或刷新后也可以第一时间回复，在服务端渲染的时代这是常规操作，但在普遍使用SPA的当下经常被忽略。

宽表

如果是表格的字段太多，可以参考《交互设计四策略》中的“组织”、“隐藏”和“转移”策略，可以是固定部分字段，剩余字段收起，通过滚动展示

缺点是windows客户端下使用鼠标的用户体验很差，需要鼠标拖动横向滚动条的操作很反人类，尤其是小屏下查看超过一屏的数据简直令人崩溃，可以提供快捷键来改善，但需要让用户知道有快捷键，会提升用户培训成本。

另一种方式是让用户自定义列头

或是将部分字段收纳起来作为二级信息展示

也可以通过合理的组织整理，提升cell的利用空间

通常越是庞大的数据表格，留白越少，也越需要border来加以区分，参考Excel；以上几种方案各有利弊，也可以结合使用，需要权衡业务场景来定夺

查询字段

查询表单是中后台系统最常见的页面，前面说的字段太多引申出另一个问题是搜索选项与字段数量成正比，导致随着功能的增加搜索选项也不断增加，丧失易用性

通常的做法是收起一些不常用的搜索项，需要时再展开

另一种更为讨巧的方法是将搜索条件直接放置于对应的表头上，可以节省很大一部分字段

不管使用哪种查询设计方式，都建议将当前的搜索条件直接平铺给用户，并提供清除功能

详情页

不同的业务对详情页的需求天差地别，无法一概而论，单从展示层面来说，详情页本质上需要解决的也是有限空间下的复杂信息展示

首先是需要对功能区域进行合理划分

其次是对多个大块信息的处理，通常会选择使用tabs来处理，但个人建议使用平铺+锚点的方式来代替tabs，主要是以下几点

• tab数量过多时tabs本身就需要翻页，增加无用操作
• 查看相邻数据时滚轮查看比移动+点击效率更高
• 当用户需要搜索某个关键字时，平铺的内容可以通过浏览器的搜索直接定位到，而tabs无法做到

从交互层面来说，一般详情页都有返回上级页面的需要，而由于详情页本身的复杂性（可能内部还存在路由跳转、锚点跳转等情况）无法依赖浏览器的回退来返回

可以将详情页以抽屉组件的形式直接在列表页上滑出

也可以将上级页面数据、返回入口以快捷方式的形式带入详情页，方便直接在详情页内做切换

长表单

过长的表单，可以让用户分步填写，如果要在一屏内展示，则最好控制住容器的max-height，这是为了让确认按钮组在页面上随时可见，且不会距离表单项太远。

让用户通过滚轮查看和填写表单，将视觉热区缩小在一片固定的区域内可以减少用户的阅读疲劳感。

有限空间下的复杂信息展示

如上图所示，在保证布局合理性的前提下，尽可能减少不必要的空间占用，这点是细节，在业务迭代任务较重的情况下最容易被忽略。

狭窄的场景需要放一些较大文本内容表单的，需要给用于显而易见的提示

确认按钮到底放在左边还是右边？

一个有趣的实验是无论确认按钮放在哪边，用户的出错率都相差无几，但如果一个系统中确认按钮的位置前后不统一，就会大大提升用户的操作失误率。所以我们要确保的是系统内的设计规范的统一，这一点在多人协作项目时最容易被忽略。

总结

UX 设计有很多法则，但在实际应用中我们不应该盲目遵循，很多时候我们需要从技术、业务、终端多个角度去做权衡，将自己代入到实际的用户中去审视。当然在知道系统的构造之后很难再去模拟一个小白用户，所以如果有机会还是应该尽量观察终端用户的实际使用场景。

除此之外也要对UX设计的结果进行追踪和验证，可以借助埋点，也可以对终端用户进行抽样调查。

碎碎念

一个应用和一堆功能页面的区别在于，功能页只关心你的数据查出来没有，而应用会关心你查数据快不快，看数据爽不爽，数据查出来之后要干嘛

使用中后台完成日常工作的用户，工作中通常会伴随着大量重复性的操作，并且通常没得选。由此即使是一丁点体验上的不便，在无数次的重复下也可能会使用户崩溃，得出这系统不行的结论。前端工程师向业务方负责的同时（能用），也有义务向系统的终端用户负责（好用）。