表单的复杂，来自于多业务场景、规则的叠加。
为了让表单规范真正具备指导意义，我们需要由小到大，由静到动的来创建表单规范。
在上次的期刊里我们聊了如何更全局的看待表单的设计，思考如何正确的使用表单这个工具。所以本期的文章里我们假设表单的需求已经明确，那么接下来我们就要运用这个工具来创建表单、收集信息。
既然是工具，那么它就需要一套完整的体系和使用规则来辅助我们工作。这也就意味着我们需要一个明确的使用规则来让设计师正确、高效的搭建表单，也就是我们今天需要讨论的主题 - 如何创建一套合理的表单设计规范。
在过去的两周里，我们接手了一个极其复杂的后台系统，与技术同学一起打造一个能够高度复用的 Design System。而这套系统里使用频次最高的就是表单，所以这期的文章我们将以此为原型来与大家聊表单设计规范。
表单规范的背景
我们之前聊到过，一旦涉及到规范那么就需要具备明确的指向性。它应该能对一个具体的领域、业务提供直接的设计参考和约束，这也是设计规范能够提供质量 & 效率保障的基础。所以，在开始表单规范的工作之前我们需要明确它服务于哪一个具象的业务，这个业务场景中用户的核心诉求是什么。
有些时候大家会拿 iOS、Google 这类的系统级规范或者 Salesforce 的 Lightning Design、SAP 的 Fiori 来作为自己的前期参考，但在实际操作的环节中却发现总觉得有些别扭或不清晰。这其中的原因其实就是大家各自创建的背景是完全不一样的。
iOS、Google 这类本质上是操作系统规范，平台希望提供更多的可能性来“生长”出各种各样的产品，在其基础之上能够百花齐放。因为这些不确定性和不同行业的差异性，它们必须要将自己的 Guideline “往下沉”，相对的做得更抽象。所以它们往往会更关注设计理念（设计世界观）的建立，并将它们作用到最小的基础元素上。
Salesforce 和 SAP 这类的产品则恰恰相反，它们面向的是非常明确的自有业务。Guideline 要解决的是非常具体的通用问题，因此我们还会看到一些变种或组合的复杂组件。所以在设计理念部分这类 Design System 则没有那么抽象，更加强调对这个行业领域的设计期望。
对于大部分设计师来说，我们的工作都是服务于某一个领域的产品以及它背后的一类用户。这类领域以及用户的特性所提炼出来的设计目标就是我们在设计时的约束，而这些约束则是我们在设计过程中进行决策的判断依据。
这次所面对的产品是一个典型的后台系统，且会扩展到几十个子产品，核心关注的是严谨、高效和可扩展。基于这些诉求我们给表单的设计定义了几条约束（如下），大家可以带着它们接着往后来看。
1. 信息展示优先
2. 减少操作成本
3. 兼顾国际化场景
4. 正向推进任务的完成
设计的策略
在确定好对设计的期望后，接下来就是具体的分工。因为工期的紧迫性和资源问题，我们不得不设计、技术部分的并行。而在设计端我们将复用度最高的表单和表格基于第一个子产品最先进入了设计。
由于对业务领域的陌生和子产品的繁多，直接基于某个产品页面的需求进行设计必定会给自己埋下不少的坑。因为还有很多未知的场景和功能是我们一时之间很难覆盖到的。在后期大量复用的时候一定会遇到很多无法解决的问题，如此我们的表单规范必将是失败的。
所以这里我给大家的策略建议是由小到大，由静到动。
由小到大
表单之所以复杂，很重要一点是来源于它所服务业务（特别是后台产品）的复杂度。各种业务逻辑的组合，不同“层级”的信息透出，一大达到一定的复杂度就会导致混乱，最后失控。
为了让我们自己先不混淆，我们需要把表单的最小单元、单元组合、静态展示、动态反馈拆看分别一步步的递进处理。
什么是「小」
在之前的文章里我们聊过，表单是用来向用户获取一组信息来用于与系统进行交互。那么这里我们可以先不把它看成组件，换成问题的角度，表单其实就是由一个个问题所组合起来的。
如果我们将表单问题还原成日常对话，这里则是提出问题、给出回答、系统再给予反馈，这就是表单的最小的一个单元，我们就先从这里开始，将表单的基础组件搞清楚。
如果所有的问题都通过输入框来让用户来完成回答，这效率显然是不高的，也不利于我们数据的收集整理。比如这里我们希望了解用户当前是在读书还是已经工作，我们一般都会通过一组 radio box 来给用户选择；如果希望获取用户生日，会给出一组Calendar；如果希望获取用户的自我介绍，会给出一个 Text area…
所以，基于一个完整问题的角度，我们把 Input 、Text area、Dropdown、Radio/Check box、Calendar… 这些不同的组件看做用户回答问题的方式，我们需要为不同类型的问题提供更适合的回答方式。
当然有些业务比较复杂，基础组件并不不能很好的满足需求，所以也就出现了业务定制的组件。比如在 Salesforce 中用 Radiobox （下图）衍生出来的工作日选择器。这部分就是需要根据我们自己业务定制的部分。
注：独立问题单元的设计还涉及到提示文案、hint、即时校验反馈，这部分问题我们会剥离出来在“动”的部分来单独讲。
以上是 PinDesign 设计期刊的第 113 期的节选内容
