刚入门接触后台产品的时候。

A说：你来吧，这个流程顺下来，你对后台的设计和这块的业务流程就基本熟悉了。

B说：三天吧，把原型出一下，给到设计。我们下周直接开发。

我：这么快？有点难度吧。后台产品既要给客户使用，又要给运营使用，涉及多个用户和系统的对接，印象中好多后台系统都不是上手就会使用的，这…有点复杂吧？

不知道你是否也有过这样的经历和体会呢？普通的后台产品往往是给到公司或客户的运营人员使用的产品，它不像前台产品，需要体现产品定位、突出设计感，而且能给到很多设计资源。后台产品的设计过程，公司内部往往会要求快速、效率且符合实际业务需求。

如果你参与设计的后台产品不是一个新产品，任何流程和业务都需要重新梳理。那么大概率，你的后台产品设计会围绕着字段和表单的设计进行。这篇文章会通过介绍后台产品设计中的重要元素：字段的设计，帮助你更加高效地设计后台产品。

 

一、字段的类型

用最直观的方式分解后台系统字段的设计，深度剖析每一种字段类型存在的价值和意义，还原后台系统字段设计的本质。

 

1. 操作型

名字决定命运，操作型字段，就是在表单中实现具体操作的字段设定。更准确的说法是，操作型字段作为一个触点，未来触发了具体的操作功能，改变具体某一条信息的状况。

这类字段常常放在表单的最后一列，通过点击即可触发对应的功能。常见的比如说删除、修改、查看详情、调整顺序，状态修改等。通过增加操作类字段，可以快捷地实现单条数据的快速操作。

当表单中含有大量的待操作信息时，这些信息又需要操作人员一个一个进行验证操作，这时在表单中增加操作类字段，就可快速实现单条数据的删除、修改、改变顺序、状态切换等操作。

另外， 在这类大量数据的表单中，此类操作字段最好能用更多的使用图标来呈现，这样能够帮助频繁使用功能的用户更加快速地找到操作入口，毕竟文字往往不如图片的表达更直接。

 

2. 序号或者ID

序号或ID作为计算机系统中最常出现的一类字段，给系统和原本复杂的业务赋予了顺序和编码。序号通常按照数据的时间序增长，这样能看出数据序列。编号和ID常常由每条信息生成特定的数字序列，在系统中做唯一标识。

这类字段往往和实际的业务没有什么关系，但是不可缺少。技术有了这个编号可以精准的对数据和信息进行定位。相当于你通过订单编号才能和客服人员快速建立起沟通的对象和基础。客服人员也可以通过订单编号快速地查看和操作你的订单信息。

在运营人员使用系统出现问题，或者请求数据支持的时候，直接说出编号能提高沟通的效率。实际设计过程中，这类字段最好放在表单的最左侧，习惯实际使用系统的人也会非常适应这种布局。

附图如下：

 

3. 内容主体

这类字段是较为关键的字段，需要放在唯一序号ID类字段的旁边，代表单表达内容的主体。这类字段描述一定要清晰，需要符合专业的业务情况和操作人员的认知。

后台管理系统重在管理。这一字段最主要的作用就是清晰管理的对象。通过给每个表单确定内容主体的字段，更加清晰表达表单存在的意义。最能代表主体信息的内容放在这最合适不过了。比如说：商品管理的商品名称。操作人员打开商品管理的页面，马上就能看到具体是哪些商品需要调整和运营。如下图，班级管理中的班级名称就是内容主体：

一个新的业务呈现出来的时候，内容主体常常是需要梳理探索的。我们要逐步确认、逐步舍弃，最终梳理出能够代表内容主体的字段。

 

4. 基础属性

属性其实是一个科学名词，鉴于这个词不是很好理解，我找来了百度百科上关于属性的定义一起学习一下：

一个具体事物，总是有许许多多的性质与关系，我们把一个事物的性质与关系，都叫作事物的属性。事物与属性是不可分的，事物都是有属性的事物，属性也都是事物的属性。

一个事物与另一个事物的相同或相异，也就是一个事物的属性与另一事物的属性的相同或相异。由于事物属性的相同或相异，客观世界中就形成了许多不同的事物类。具有相同属性的事物就形成一类，具有不同属性的事物就分别地形成不同的类。

关于属性在科学界的二级分类大家可以通过搜索去了解一下。这里给出的二级分类仅为方便后台系统字段的设计服务：

基础属性，主要是指的是内容主体在系统内，或本身具有的属性类信息字段。通过在后台呈现这些字段帮助决策人更好的了解内容主体的信息，使得概念性的内容名称变得鲜活具体。

比如说一个人作为内容主体，那么相关属性就有性别、年龄、城市、时间等，我们可以称之为基础属性 。

 

5. 关联属性

关联属性：

特指在系统中既能够代表其它内容主体的字段，又能作为该内容主体的基本属性的字段。存在的意义就是，使各个主体内容的字段之间能够建立起关联关系。

比如说，教师作为主体字段，可以有的属性是一些基础属性，如性别、年龄、工号等。而在主体内容为班级的表单中，呈现一个教师（班主任）的字段，这就代表着这个班级的班主任对应的是信息表中的教师，这个教师此时就是关联属性呈现。

关联属性，能够更加灵活的体现内容主体之间多对多的关系，没有一个主体内容是独立存在，不和其他主体互相联系的。

后台的设计中，为了方便后续业务的调整，往往会追求较低的数据耦合。那么在低耦合数据的情况，关联属性类的字段，就能够帮助系统的数据之间建立起关系和连接。

 

6. 标记

标记(signature)是通过为数据贴标签的方式，高效快速对内容主体进行差别管理。简单来说，就是标记作为一种表达，有效对信息进行区别。计算机常用的做法就是给信息加标签。用现在比较流行的说法就是贴标签。最普通的标记是在序号的前面统一放上一排选择框，通过选中这个标记，可以对数据进行集体操作。

还有根据数据的特点，给数据加上特定的标签。比如说运营人员通过观察用户的表现，为用户贴进行 标签分类，方便后续运营活动的进行。大数据系统，通过用户在产品中的操作和习惯，能够给用户及时推送相关的服务和内容。

属性是针对内容主体进行的维度补充，标记则是对具体信息和内容主体的类别划分。

 

7. 状态

我们平时最常听到的一句话就是，这个产品出BUG了。这句话的含义其实就是产品此时不能正常运转，处于异常状态。既然产品可以用异常和正常两种状态来形容，那么在系统中每天跑通的各种业务，是否也可以用相应的状态来表征呢？

状态这种类型的字段存在的意义就是，体现表单中具体数据在动态变化中的意义，能够根据具体的状态临界值和状态区间，做出符合用户需求的状态展示。比如说订单管理中的订单已完成、订单已创建，这都是不同的状态。

业务状态一定要处于一个范围内，而不是瞬态，也就是说不能有中间态。比如说“订单创建中”这种状态 ，系统是无法进行判断和描述的。判断一个表单是否需要状态字段，最直接的方式就是考虑内容主体是否有需要管理员决策的决策点。比如说日活低于100万，状态字段的值就是：低活跃；高于200万，状态值就是：高活跃。

状态字段的存在很直观地将业务实际的情况以及进行的阶段展现出来。这类字段对决策而言是非常重要的字段，常常放在较为中间偏右的位置。

 

8. 时间字段

时间字段代表的是内容产生的时间和变更的时间。系统内的每一个操作都是能够用具体的时间进行记录的，那究竟是哪些类型的信息需要定义时间字段呢？

1. 内容产生的时间有意义，比如说：订单产生的时间、用户注册的时间、评论提交的时间，具体某个内容发布以后，管理员需要监管内容发布时间是否符合预期的时候就需要时间字段记录内容产生的时间。
2. 内容变更的时间有意义，后台需要追踪具体某一内容的的变化。比如说具备商品管理的后台系统，后台修改商品价格等信息的时候，就需要记录具体价格修改的时间。
3. 做系统内部低成本的信息安全系统时需要时间字段。后台管理系统的用户权限，通常包含更改用户密码、为用户充值等。如此私密性的操作，当然要有修改的记录时间，共同对操作进行监控。

 

9. 数据字段

这部分专门指的是数据统计类型的字段。如果问后台管理系统最大的意义是什么？那么就是数字化了。随着人们对大数据的追赶热潮，数据统计这一部分也就成为了后台系统的兵家必争之地。

虽然短时间后台系统无法用大数据的技术和形式辅助用户做科学的决策，但是任何一个后台系统都是需要对系统内现有数据做一定的统计对比，来给管理者提供必要的决策依据的。比如说一个销售系统的后台管理系统，就会有具体销售联系的用户数量和处在各个销售过程中的客户数量。还有用户运营管理中，用户在平台上的下单次数以及消费金额等等数据的展示。

不同类型的的后台管理系统容纳的数据量常常是不一样的。这部分字段对于技术逻辑要求较高，要定义清楚需要何种类型的数据，方便技术对相关数据进行埋点获取。

 

二、字段设计的注意事项

1. 定义字段宽度

如果是需要用户键盘敲进去的文字字段的长度，通常是需要给出字段的最大和最小字符数。通过对字段长度的定义，UI可以提前规划页面宽度的分配，使得最后展现出来的页面是能够符合实际业务情况而且美观的页面。这不管是站在开发或者UI的角度，都是非常有意义的。

如果随意定义，那便毫无参考价值，也会造成开发资源的浪费。更严重的，不对字段的宽度做限制，就会出现昵称或者数字过长而导致页面错位，甚至会导致程序死机。

 

2. 字段是否为必填项？

在用户场景下考虑的话，如果字段作为必填项，用户如果不填写该项，那么这一条数据都无法保存。但关键字段如果不进行必填设定，就会影响技术的实施方案，且会导致逻辑漏洞以及隐藏BUG。

比如某必填字段，未进行填写，就可能产生大量为空的错误数据，从而影响到其他的业务逻辑。像用户昵称，如果为空，就会影响一些展示用户昵称的页面显示出的错误值。

 

3. 字段值的校验反馈

这指的是部分字段，比如说手机号码，那么用户写入正确的情况下只可能是11位的数字，当检测到用户输入其他类型的字段，需要用特殊标识去提醒用户，这样可以降低后台使用的错误率。

我之前接触过一次这样的乌龙事件（不是我设计的后台）：一个游戏后台中的充金币填写金币个数的字段。这个字段由于没有做数字的校验，客户运营一段时间就总是发现用户金币数量和预期不符。因为是数据问题，金币数量错得越来越离谱，很影响平台用户的使用及客户的收益。技术人员连续两个礼拜加班找BUG，后台才发现是因为应该在填写金币个数的地方，因为当时的后台个数后面没有单位，客户直接填写了“100个”，而系统没有报错，但是数据却一直不正常。

 

三、写在最后

希望通过这篇文章，能够帮助你更好地理解后台字段设定的意义，通过对不同类型字段价值和意义的拆解，让你在对字段取舍和设计过程中更加有方向，进而可以更加快速高效地完成后台产品的设计。