B端设计总结（二）：基本字段 Basic Fields

高拉 2023-08-06 22:28:39

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

01 字段 Field

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

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

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

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

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

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

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

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

B端设计总结 03：基本字段 Basic Fields

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

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

02 输入类字段 Input Type Fields

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

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

B端设计总结 03：基本字段 Basic Fields

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

其中有两个通用的是：

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

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

1. 字符串 String

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

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

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

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

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

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

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

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