今天小编给大家带来一篇关于如何设计B端后端表（table）的文章。 本文干货较多，篇幅较长，记得先看完哦~
（全文共6908字，阅读时间约17分钟）
介绍
目前在一家制造软件提供商工作，我处理的大部分软件产品主要是承载数据信息。 为了保留原有的底层数据逻辑，同时也有开发工作量，整体接口需要具有高度的可复用性和可扩展性。 因此，大多数接口都是以表格的形式展示。
1、可承载大量相似信息和数据，结构简单，分类清晰，方便用户浏览；
2、横向关联、横向比较的信息处理方法，帮助用户快速理解和简单分析信息的差异和相关性；
3、对于大量数据信息，在保留现有可视化结构的情况下，可以直接使用其他通用功能进行搜索、过滤、编辑、批量操作等自定义选项操作；
4、表中各栏目内容相对独立，可以根据业务需求或用户关注点进行定制和调整。
一般来说，表格组件中的功能比较复杂（常见的功能包括：单个对象操作、排序、多选、翻页、抽屉扩展、合计等；特殊场景需要支持：单元格编辑、单行编辑、调整显示栏目、多重分层嵌套、分类等）为了提高效率，一般根据需求找到合适的组件嵌入到页面中。 后台界面有很多常用功能，考虑到视觉和代码一致性，会直接使用后端框架进行开发。
在我加入公司之前，所有的产品都没有前后端分离，风格只能按照原来的界面进行优化。 涉及交互和用户体验优化的部分非常抵触，表示无法实现。 经过多次沟通，领导决定实现前后台分离，考虑到UI框架的选择。
1.UI框架介绍
目前国外主流的以及个人工作中已经使用过的UI框架有：
以及其他不太常用的框架（链接跳转到表格组件）：
实际投资开发时，一般只考虑三大主流。 一位资深后端D朋友说：学好三大框架，走遍天下都不怕。
一些不太常用的框架有很好的UI视觉，国外应用广泛的是【Vuetify】，交互丰富，基本上所有操作也会给出过渡动画效果。 [延伸]很有年代感。 公司之前用的是这个2.0版本，现在新版本可能不难看了。 【飞冰】整体风格与【蚂蚁设计】类似； 【layui】的组件看起来有点单调，基本的后台界面我觉得还是比较满意的。
—
作为设计师，我个人更喜欢使用【蚂蚁设计】。 资源非常齐全。 下载的sketch源文件基本可以满足大部分通用功能。 很多控件（如：各种选择器、穿梭框等）的视觉和交互体验相对较好，可以直接复制组件并粘贴到设计稿中。
但后端的朋友更倾向于【Element】组件封装简单易改，对于没有接触过框架的朋友来说也方便无障碍。 [iView]的组件封装得太严密，而且要收费，所以我不喜欢使用它们。 大名鼎鼎的【蚂蚁设计】也支持Vue，但是Vue版本表的行高不能拖拽。 改编了大量文档，学习成本比较高。
—
经过综合考虑，项目组决定使用【元素】。
2、主流框架中[Table]组件对比
① UI风格对比：
每个官网显示的默认组件样式略有不同。 【Element】和【iView】直接列出不同类型的样式，而【Ant design】则是结合功能进行综合展示。 可以根据相应的参数改变样式。 开发过程中，前端朋友可以直接根据设计稿更改样式。 个人认为，如果样式一致的话，直接使用组件的默认样式也是可行的。
截取各官网Table的基本界面风格，如下图：
从上图可以看出，三个表格的内边距的定义是不同的。 实际工作中，后台不同数据字段的表格会出现列数极少（2-4），或者列数较多（10多）的情况，无法像设计稿那样完美、美观。 Web端的后台界面，除了根据网格系统定义模块区域外。 一些组件化交互需要和开发者沟通定义一个基本规范，最好有大部分全局场景。
在前后端没有分离的时候，我发布了一个版本的基本表格样式规范。 组织需要发现几乎所有的表都有序号和检查操作，因此直接集成到基本用法中。 如下：
使用组件时，不需要设置宽度等规格，直接选择一个通常问题不大。 更加关注表中携带的数据数组类型。 例如：
文本数组：可点击数组、普通文本类型、数字和字母等。如果长度不均匀，最好给予左对齐；
预定数组：日期、时间、部分枚举类等，如果字符数一致且较短，可以与表头标题居中对齐；
特殊数组：对于金额、状态标签、类型标签等业务功能较强的，可以根据相关特点和阅读习惯确定对齐方式。
无论采用哪种对准方法，都需要考虑阵列可能出现的极端条件。 例如：如果普通文本太长，可以在键盘处于悬停状态时展开单元格以列出所有数组信息。 或者使用提示来显示键盘位置后面的所有信息。
当数据信息扁平化、单一时，直接使用表格的基本用法也能满足需求，而视觉和交互只能满足大众的审美和习惯，一般不会有太大问题。 之前公司是一个C端门户网站，后台管理系统直接使用【蚂蚁设计】作为数据统计展示，完全足够了，操作的朋友在使用时也表示满意。
但B端后台界面不仅仅承载着信息，还有很多相关的操作和处理。 公司产品供厂家使用，数据文件庞大且种类繁多，相互之间存在不同的关系。 很多情况下，需要根据需求重新设计，并在设计中尽可能找到折衷方案，以适应开发工作量。 这就要求框架组件能够衍生出最好的，用最少的改动满足更多的需求。
② 组件功能对比：
因为我们已经决定使用[Element]，所以下面所有的比较都是基于这个框架中的Table组件功能，针对是否有功能以及相关差异进行一些比较。
在后台开发的实际工作中，以上功能基本可以满足所有需求。 其中，【Ant design】【iView】的示例组件中一些未在上表中列出的功能也相当实用，例如：【Ant design】可编辑单元格和单行，这是一个体验非常好的功能。后台表格，简化用户体验操作； 【iView】自定义导入表格中的数据也很常见。
必须要注意的是：
无论什么样的交互风格和功能需求逆天，开发朋友都可以完美解决。 这里列出只是为了让设计者了解和熟悉相关组件，以便在工作中更好的配合开发，尽量减少开发朋友的工作量。 毕竟，在一家为传统制造业提供软件的公司里，相比底层数据处理和套接字的联调，前端的样式展示就显得微不足道了。 很多人甚至认为这就足够了。 这也是设计工作难以加快的一点。 。
从上面的对比可以看出，【Element】和【Ant design】的功能基本相同，但是相同的功能又存在一定的差异，这里不再赘述，类似的功能基本相同。 至于具体的风格和交互方式，可以根据个人审美或者企业需求综合选择。 当我们在工作中遇到框架之外的组件，而我们只是发现某个组件完全可以满足需求时elementui表头样式，我们也可以考虑嵌套它。
作为公司第一个也是唯一一个设计，老朋友不明白需要给设计师什么样的需求原型和文档。 很多时候，我收到的需求是一堆属性项名称、一张纸质表格、一句话、或者一个函数名称。 在没有任何业务闭环和数组描述的情况下，并且很明确，最好以表格的形式展示。 为了赶上工期，很多时候我们只能集思广益后直接选择组件，与开发和业务人员沟通，然后根据组件的功能进行设计，相当于需求、设计和开发的并行工作流程。
以下示例列举了一些近期的工作案例，供大家参考。 大致从需求分析、元件选型、设计实现三个方面进行适当的说明。 （与公司特殊业务相关的部分将以其他文件代替）
1. 报销表格
当时收到的需求是报销收据，需要粘贴到财务部门，类似右图：
主要是长途交通费，其他相关费用可以标明金额标的，并附上收据。 项目组确认，网上补报时无需上传收据照片，即无需上传附件。 补贴等其他相关信息可以通过表格或其他流程直接带入，并在后台手动获取各种金额汇总。 所以表格中只需要设计费用相关的说明即可，而且我司已经取消了同城出差和补贴，基本上长途费用已经成为主要内容。
添加任何一行内容，必须填写时间、出发和到达、交通、金额。 显然Table组件需要支持单行编辑，并且可以添加多行。 在【Element】示例组件中，没有相关显示，但下载的UI资源中有相关样式，并且表单样式可以与表格样式结合使用。
与开发者沟通后，决定使用该组件。 编辑框直接将表单样式嵌套在【Element】框架中，最终设计稿如下：
其他相关费用通过另一组表格展示，遵循长途运输费用的表格风格，并给出默认状态供开发参考。 尽量用最少的界面，展示最完整的状态。 当然，你也需要提醒开发者在审核时注意。 这里，我们点击添加一行后，会直接关注新行的第一个编辑框。 虽然这个功能很常见，但是如果没有向后端显示交互动态效果的话，这个功能可能会被忽略。 至此，设计稿完成。 需要一定的设计规范和交互说明。
报销单样式编辑完成后，领导和用户的反响都比较好。 而且Table组件在后续的行情、组织成员、二维表格属性等功能模块中复用率很高。
2. 项目管理
做这个功能的时候，收到的需求只有几十个属性项，整个业务闭环和数组描述都没有。
前期我和相关业务朋友多次沟通无果，因为他没有收到明确的任务目标，对产品需求规划也不太了解，所以我根据自己的项目经验初步梳理了整个流程，并给了一些数组指令，他理解后就成立了。
通过整理流程闭环及相关数组进行确认，并要求以表格的形式展示。 大致整理一下表设计需要考虑的几个功能：
1.所有关键属性项必须显示在表格中，如果有垂直滑动，需要支持固定表头和垂直列；
2.阶段扩展是一个任务，任务下有子任务，那么表格支持树形结构显示；
3、阶段和任务属性项不同但显示在同一个表格中，部分单元格会为空；
4、类似的数组样式需要区分，单元格样式需要自定义；
5、完成后上报的任务，可以更改部分数组，需要支持单元格编辑，最好能够筛选、批量初审。
【Element】官网的Table示例中没有能够满足以上所有要求的组件。 但是所有的功能都是支持的，所以我们可以直接使用，前端的朋友可以设置相应的参数。
有的表单属性项较多，但大部分组都不长，需要固定列，所以我选择带边框的样式； 树形结构支持多重选择。 基本上，它结合使用以实现以下功能：
其中，虽然官网示例中没有给出单元格编辑样式，但资源中有显示的版本如下：
个人觉得交互操作有点繁琐，所以继承了报销单类似的编辑操作。 根据需求的不断建立和组件的确定，可以先发布一个版本的接口进行开发。 至于尚未确定的数组、数据处理等相关需求，可以直接让前端朋友socket控制。 主要形式的落地吃水图如下：
① Items：这种形式通常用于没有太多操作的样式。 主要是相关数组的显示。 有些数据需要进行区分，以增加识别度。
与常规组件使用相比，关键在于区分各个数组的显示方式，根据不同的状态，数组会有一些相应的变化。 例如：
多个与时间相关的数组：持续时间、开始/结束时间、接受时间等。为了提高每个数组的识别度，可以在一定程度上改变数组的样式，不一定要使用纯文本样式。 减少用于识别的图标并根据状态确定要显示的副本类型是一个更好的方法。 当界面滑动到左侧数组时，还可以一目了然地看到订单项的状态，无需向左滑动查看状态栏。
②阶段任务：列表相对复杂，根据不同的用户权限，列表顶部的按钮和表格左侧的操作栏也不同。 这里仅给出表中的总体设计以供展示。
阶段和任务属于此列表中的两个不同对象。 默认情况下，只有阶段以图块形式显示，因此表头列出的属性项主要是根据阶段来显示的（这里考虑到一些数组的重要性，还显示了任务“优先级”）； 非任务属性项显示在一般用“-”进行标记。 “状态”等常见属性通过不同的标签来区分。
任务列表的风格与此列表基本相同，只是属性项有所不同。 特殊的数组样式还根据其业务特点采用不同的数组展示方式，这里不再赘述。
③工时报批：与任务清单的属性项没有太大区别。 工作报告列表顶部减少总工时（此功能在[Element]示例组件中有显示样式），然后去除结构级别。 所有任务 进行平铺显示。
不过我报的名单和领导初审的名单功能有一定的区别：审核过的名单是可以编辑的。 一般来说，初审工作时间与申报工作时间没有区别。 为了减少初审工作量，您可以在列表顶部筛选后选择所有通过初审的批次，无需任何操作。 因此，这一类两边的操作都改为“修改工时”，直接在单元格中进行更改。
当然，编辑单元格的交互是不一样的； 也可以参考【Ant design】中编辑单元格的功能，悬停显示编辑框，点击后可以直接编辑。
无论是项目、阶段还是任务，一旦表格组件确定，设计者基本上不需要重复设计。 可以花更多的时间研究业务特征。 以这个界面为例，当然我最后输出的只是各个属性项的数组样式和相关描述。 例如：
1、三类对象的状态标签是否可以共享，部分属性需要突出显示，标签样式是否与之前相同；
2、功能颜色（正常、成功、警告、提醒、静音、失败等）的使用是否规范、统一；
3、看似相似的数组：开始时间、计划开始时间、后台逻辑是否一致，可以使用相同的风格； （例如：项目一开始需要经过审批流程，开始流程的时间定义为开始时间。该阶段的计划开始时间由创建者自动填写，无需经过过程。因此，两个数组的样式是不同的。）
虽然很多时候用户可能无法注意到细微的差别，但它会在一定程度上减少开发朋友的工作量。 但最终呈现的疗效远比纯文本展示的效果要好，体验也会更好。
3、零件结构
界面制作的时候，需求就明确了，参考了一些原来的界面，主要是为了减少匹配关键词和高亮单元格的搜索需要。 然后根据现有组件优化样式交互。
设计比较简单，可以根据要求直接按照相应的规格提供相关款式。 只是对原来的交互方式进行了整体修改，去掉了表格包含的结构，两侧以树形结构展示。 由于涉及到一些业务，不方便将整个界面截图。 零件的结构相当复杂，关系也很多。 接口功能就不过多介绍了。
在后台表格的设计中，除了表格中的操作（一般放在最右边一栏）之外，还有很多其他的操作按钮和过滤项等，框架【Element】和【Ant design】都放置了它表格的左上方，原来界面的布局基本上就是这样，我没有做太多的改变。
当然，还有很多后台界面设计没有模块定义elementui表头样式，操作很少。 整个界面基本上是一个表格图块，按钮可以直接显示为图标，与标题在同一行，右对齐。 如下所示：
除了上面列出的部分之外，还有其他类型的桌子设计，例如：
1. 对于相关文档列表，展开抽屉以获取更详细的信息。 一般情况下，直接选择框架中的Table组件即可满足需求。 根据不同的文档类型，扩展的细节有所不同；
2、与一个对象关联的其他对象按照关联类型进行分组，直接下一行组标题，两侧提供图标进行标记，可以控制展开或折叠。 与其他筛选组件一起使用也很常见；
3. 比较多个对象，更改标题和属性项的排列：左侧为属性项名称，上方为对象标签名称。 可以根据需要删除或添加比较对象，并可以区分相同项目和不同项目的表格行的背景颜色。
以上涉及的业务内容较多，效果图暂时不一一展示。 仅给出部分样式：
不同对象的属性不同，其字段和比较方法也会不同。 上图是系统中最常用的样式。 有成组的属性项，可以展开、折叠，也可以通过比较前的过滤来控制。 当比较数据量太大时，可以优化性能。 当然，你也可以全部比较然后筛选，主要是根据业务信息量，与开发朋友沟通，综合制定最优的交互方式。
后台界面对业务呈现和实用性有较高要求。 我公司特别负责制造数据的管理。 总体特点是表格和表单占据了大部分界面，需要在大量信息中更快地找到目标对象。
在提高开发效率的同时，需要根据每个企业的特点定制产品。 因此，在开发之前，整个项目组都需要对业务有或多或少的了解。 作为设计师，在没有产品总监的情况下，基本上就是承上启下。 对于表格相关的设计，需要注意以下几点：
1、充分了解业务，包括现阶段是否实现了内容、未来可能减少的内容等，并考虑采用形式是否合理；
2、确定界面的基本功能阵列和交互方式，梳理完成业务整体闭环；
3、熟悉各个框架的基本内容，与后端沟通表单中功能实现的难点，确定组件；
4、设计时，尽量使用原子设计方法和透明规则，更好地控制整体风格和交互；
5、显示高保真表格时，充分利用视口样式，更好地统一表格的色调、文字等； 使用组件定制特殊的元胞数组样式，尤其是枚举类数组；
6.对于一般表单的输出，可以直接将源文件的视口样式上传到Blue Lake，并添加文字描述，非常方便。
以后有时间我会总结一下后台设计规范以及组件视口样式的使用。 以上只是我最近设计大量表格的个人经验，也是我第一次做这种后台系统设计。 希望大家能在评论中指出不足，共同成长。
编辑：@Kerr Xu
