正文
所以，在开始表单规范的工作之前我们需要明确它服务于哪一个具象的业务，这个业务场景中用户的核心诉求是什么。
有些时候大家会拿 iOS、Google 这类的系统级规范或者 Salesforce 的 Lightning Design、SAP 的 Fiori 来作为自己的前期参考，但在实际操作的环节中却发现总觉得有些别扭或不清晰。这其中的原因其实就是大家各自创建的背景是完全不一样的。
iOS、Google 这类本质上是操作系统规范，平台希望提供更多的可能性来“生长”出各种各样的产品，在其基础之上能够百花齐放。
因为这些不确定性和行业的差异性，它们必须要将自己的 Guideline “往下沉”，相对的做得更抽象。所以它们往往会更关注设计理念（设计世界观）的建立，并将它们作用到最小的基础元素上。
Salesforce 和 SAP 这类的产品则恰恰相反，它们面向的是非常明确的自有业务。Guideline 要解决的是非常具体的通用问题，因此我们还会看到一些变种或组合的复杂组件。
所以在设计理念部分这类 Design System 则没有那么抽象，更加强调对这个行业领域的设计期望。
对于大部分设计师来说，我们的工作都是服务于某一个领域的产品以及它背后的一类用户。
这类领域以及用户的特性所提炼出来的设计目标就是我们在设计时的约束，而这些约束则是我们在设计过程中进行决策的判断依据。
这次所面对的产品是一个典型的后台系统，且会扩展到几十个子产品，核心关注的是严谨、高效和可扩展。
基于这些诉求我们给表单的设计定义了几条约束（如下），大家可以带着它们接着往后来看。
-
信息展示优先
-
减少操作成本
-
兼顾国际化场景
-
正向推进任务的完成
设计的策略
