b端设计小技巧（B端设计总结二）

在一些B端后台中，最基础的就是字段了。除了“系统字段”、“业务字段”、“管理型字段”、“规则型字段”之外，还可以在通用的业务场景中按照输入类和系统类再细分，本文作者从这两个方面进行了分析，一起来看一下吧。

输入和选择控件果然鸽了，写点偏业务的。

01 字段 Field

前阵子在一个群里参与了关于「字段（Field）」的讨论。

无论是在黑帕云、飞书多维表格、维格表、Airtable 还是在一些 B 端后台中，最基础的就是字段。

有个文章对字段做了区分，分为“系统字段”、“业务字段”、“管理型字段”、“规则型字段”，定义是：

• 业务型字段：体现业务要求的字段，承载业务信息的展示。
• 系统型字段：系统交互之间的的请求日志信息字段，如系统主键、业务 ID、创建时间、创建人、版本号、最后修改时间、最后修改人等。以及系统之间的交互的请求编号、请求时间、请求相应信息等。
• 管理型字段：为了管理需要设置的字段，如操作时间、操作人、日志信息、操作意见、备注等。
• 规则型字段：系统为了某一规则而存续的字段。比如商品是即将下架的产品，可以设置下架时间、库存量等，自动触发后将商品下架。

这样的方式非常适用于一些后台产品设计，很好和技术去沟通需求。

在这个基础上，我想补充一些更通用的字段类型和字段格式。

在通用的业务场景中可以按照输入类和系统类两个大类去往下根据不同业务来再细分。

这两个很好区分：需要业务人员填写的就是输入类，自动计算的则是系统类。

一般来讲，系统字段都是指自动生成的，比如说修改时间、创建时间、流水号、创建人、操作人。

输入类字段都是可以编辑的。

02 输入类字段 Input Type Fields

输入类字段再往下分，首先是根据数值进行分类。

常见的数值类型有以下几种：

在确定了数值类型之后，可以对数值进行一些格式填写的校验，不同的数值类型有不同的校验方式。

其中有两个通用的是：

1. 「必填」校验：是否允许这个字段为空。
2. 「重复」校验：是否允许这个字段值和其它值重复，如果不允许重复则无法保存或提交，常见于录入线索联系人手机号或身份证、商品编码等场景，比如要求身份证号码必填并不允许重复，避免了重复录入。

其它的校验要根据字段值的结果进行区分。

1. 字符串 String

字符串通常可以一些正则表达式用来做以下业务常见格式的校验：邮箱手机号身份证号码网址。

这几个类型都很好理解，其中要特殊说明一下「身份证号码」类型。

大家知道，身份证号码最后一位可以是 X 的，当时我们在做这个校验规则的时候没有了解正规的身份证号码的 X 应该是大写还是小写。

有用户就问了，这个 X 是否大小写敏感？我看了一下，当时没有做大小写敏感。正规的身份证号码 X 应该是大写，也就是说我们输入小写 x 也是会通过校验可以顺利提交的。

如果不校验的话，会发生什么？——用户因为按照身份证号码字段设置了自动化的触发，用“线索表”的身份证号码去自动查询“机会表”客户的身份证，如果已经存在，就不会在机会表中新增这个联系人，而是直接更新这个联系人的其他信息。而自动化查询时是大小写敏感的，也就是说如果在“机会表”中， 假设有一个 “61010119941120003X” 的身份证号，如果销售再在“线索表”录入了“ 61010119941120003x”就会把这条数据自动触发重复录入到机会表中。

现在的问题是要解决重复录入，重复的根源是身份证格式校验要更精确。一拍脑门的做法可能是会告诉开发，在校验身份证时，要大小写敏感，必须要填写大写”X”才能通过校验。

但是站在用户的角度思考，这种处理方式就很恶心，因为“X”要大写这件事不是一个热知识。我们需要保证效率，而不是我们知道用户错了，我们会改，但我们就是要让用户自己改。

所以，我想到了更优雅的解决方式：如果用户输入了小写的“x”，在存数据时，我们主动帮用户修正为大写的“X”。

2. 数字 Number

对数字进行数值校验时，首先需要设置数字的格式。

其次，如果业务需要，可以用最大最小值来限制数字的输入范围。

3. 货币 Currency

货币字段和数字字段很像，都是只允许输入数字，区别是货币没有百分比显示的开关，货币字段能够设置货币符号，小数点位数至多只允许设置四位。

4. 日期和日期时间 Date&Date Time

在不同的业务场景中对日期还是时间有不同的需求，比如在一些会议时间中就需要「日期时间」，在一些合同签订场景则需要的只是「日期」。

二者都可以参与如 DateAdd、DateTime_Diff 这样的日期运算。

关于多时区协作的问题可参考之前这篇文章《多时区协作如何保证时间不会产生歧义》。

默认值、支持时间、必填都比较基础，就不用再写了。

简单写一下关于日期格式校验一些总结。

当时在做这个功能设计的时候，模拟了以下场景：

• 某旅游团只允许 18 岁-65 岁购买，出生日期早于 2003 年，晚于 1956
• 某博物馆门票预定只能购买第二天门票
• 酒店预定开始日期只能预定最近 7 天（不含今天）
• 管理发票的回款，在填写回款明细的时候，回款日期不能超过今天。
• 机票回程日期不能早于启程日期
• 酒店预定结束日期不能早于开始日期

比较清楚的是，可以将以上场景收敛为三个分类：

1. 某个具体的日期参与的校验范围
2. 动态的“今天”参与的校验范围
3. 其它日期字段字段值（动态值）参与的校验范围

从业务的角度和成本考虑，对“今天”的需求概率会更高并且成本适中，所以在 Phase1 中， 做了前两个分类的功能。

在应用管理员设置校验时，可以设置这些规则：早于晚于在范围内是不是

范围可以选择为：

• 指定日期：可以根据字段类型设置指定的日期或日期时间
• 填写日期（“今天”）
• 填写日期前（“今天”）：选择这项后，可以动态设置范围是填写日期前[1,3650]区间的整数
• 填写日期后（“今天”）：选择这项后，可以动态设置范围是填写日期后[1,3650]区间的整数

提供以上几种的规则和范围，就能覆盖除了需要其他日期字段值的任何校验场景了。

5. 选择 Select

选择在表单中非常常见，可以分为单选和多选。

单选的表现形式有以下两种：Select 和 Radio Button。

03 系统字段 System Fields

对于系统类字段再细分下去是系统自动生成的基础信息，就是创建人、创建时间、修改人等，但是还有几类，一个是公式计算的，比如商品价格*数量这种公式。

如果已经接触了关系型数据库，知道表和表之间的关系，那就需要了解以下两个字段：

1. 「聚合（Rollup）」：用于计算所选数据的汇总、求平均值、最大、最小值
2. 「引用Lookup」：引用它表的数据

04 写在最后

以上就是基本的字段的几种类型，在 B 端产品中，这些字段类型非常常见。

复杂高级的字段后续会继续再写，比如地址字段（Address）、多级选择（Multi-Select）、动态关联（Dynamic Link Record）。

作者：高拉，高拉

本文由 @高拉 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。

,