设计组件化

设计

我们在设计一个系统的时候会不可避免的与各个不同的角色互动：不同的设计师、不同的前端工程师，这其中不可避免的会出现大量的沟通和协作问题，如何在这类多角色互动中提高效率，降低沟通损耗就不可避免的成为一个问题。「组件化」可以在某些层面帮助我们更好的解决这个问题。在复用和设计过程中，与 Brad Frost 提出的 Atomic Design 有相似之处。

什么是组件？

组件是一个个不可再被拆分的基本设计元素，例如一个 Button、一个 Input 等。每一个组件都应该有自己的迭代和设计过程，组件属于平台设计的一部分，与业务设计互补，每次设计迭代也正是在迭代这一个个组件。

组件化的好处是什么？

良好的组件化在应用时能够带给我们三个好处：

复用

我们可以以非常低的成本得到一个完整功能的组件，组件本身与业务逻辑无关，产品设计师无须过多关心组件本身的逻辑。以 Button 组件为例，我们设计了 2 种样式，分别适用于默认场景（.Button）、主要场景（.Button-primary），产品设计师只需要针对不同的场景分别使用适合该场景的 Button 即可，他不需要关心这个 Button 自身的 padding、margin、size 等。

一致

这种高复用可以让整个系统一致性更好，当我们想要修改 .Button 的 padding 时，所有使用了 Button 组件的位置都会变更。之前开玩笑说判断一个网站的组件化做的是不是足够好的方法是：你能否用 StyleBot 很快的帮它换一个皮肤，同时在它之后的迭代中不会出现本该一致的地方却不一致的问题。这种一致性会直接反馈到用户的使用中，不会被各种不一致的操作迷惑。

效率

高复用和一致性最终产生的结果就是设计和开发效率的提升，我们可以通过搭积木的方式很快的得到一个基本可用的界面，产品设计师可以更加专注在问题的解决上，而不是花了大把时间在基本组件的设计上。同时开发也可以直接利用已经做好的组件进行开发，开发效率直线提高。甚至我们可以直接基于浏览器设计，使用组件库可以更快的得到一个可交互的高保真的设计稿。

针对平台设计的好处有二：

平台设计迭代落实到人

基于不同特性的组件可以交由不同的设计师进行维护，例如 Animation 组件会对动画更有要求、TextEditor 需要对富文本处理更有了解、icon 部分则需要对不同浏览器 icon 解决方案有研究，这样每个人都会负责一部分组件的迭代，不会出现设计很久没有被迭代过、一个组件被随意设计未经全面考量等等。

组件迭代更系统

基于不同的组件特征将他们分配给不同的设计师，这些设计师可以站在更高的平台角度而非业务角度来思考这些组件应当被如何设计。可以更加全面的思考一个好的组件应该是什么样的、当组件无法满足业务需求时进行更加完整的扩展和升级。更系统的迭代不代表脱离业务，大部分的组件设计师同时也是业务设计师，他们会更了解业务的需求是什么，在此基础上抽想出更加通用的组件设计。

组件的类型和粒度

一个组件一般有三种状态，例如同样的一个 Button：

默认：最常见的一种状态，纯界面区别。如 .Button、.Button-primary
交互：交互后发生的变化，与该组件交互后的状态一般有两种实现方式：
1. 样式（.Button-primary.is-active）；
2. 伪类（:focus），可根据不同的需求采用不同的实现方式。
子组件：该组件是其他组件的一部分，如果该组件作为其他组件的一部分时样式有所变化，则需要单独定义样式，如 TopNav--AddQuestionButton、TopNav--SigninButton。
当该组件可能会成为另一个组件的一部分时，需要明确该组件的子组件状态和常规状态时的区别和联系是什么。下面是一个常规的 input 组件：

.input {
  padding: 8px 10px;
  font-size: 13px;
  line-height: 15px;
  box-shadow: 0 1px 1px rgba(0,0,0,.1) inset;
  border-radius: 3px;
  background: #fff;
  border: 1px solid #ccc;
  color: #222;
  box-sizing: border-box;
}

当我们在一个新的 dialog 中使用到了这个 input 组件，但在场景下 input 有些许变化，这时需要明确几个问题：

1. 变化是否有必要：大家都喜欢抛弃旧的搞新的，这样没有历史包袱，但这种变化对于整个系统而言并不一定是好事。
2. input 之间是否还有关系：
3. 两者的使用场景分别是什么；
4. 哪些样式会被共用。
5. 变化幅度有多大
   基于之前的共用样式范围，一般有两种情况：
   5.1 少量样式不共用；
   5.2 大量样式不共用。第一种情况一般会复用旧的样式，同时写新样式覆盖掉原来 input 中不需要共用的部分，例如.Input.DialogInput。第二种情况的少量样式共用，比如只有 border 一样，其他的都不一样，那基本上会重写整个组件样式。
   我们在组件开发和设计前明确清楚两个组件的关系是什么，这样可以降低设计和开发成本，提升迭代效率。

组件设计应该如何迭代

两个大原则：
1. 组件迭代不应该 block 业务迭代；
2. 任何组件改动都应由该组件负责人负责跟进。

当现有组件无法满足业务需求时，业务设计师应及时与组件设计师及时沟通确认需求，如果可以在当前方案中快速调整适应业务需求，则在组件调整完毕后使用新的组件方案；如果存在折衷方案：折衷方案如果违背组件设计意图，则不能使用该方案。如果不违背设计意图，则可以采用该方案。如有必要，组件设计师需要事后重新调整组件方案兼容该需求。

每次组件迭代应该关注以下几点：

视觉表现：是否与平台主视觉一致
业务兼容、扩展性：当前已知的业务需求能否在该组件下被良好满足，是否有足够好的扩展空间而不至于迭代时需要重新设计
逻辑一致性：该组件在不同设备下的操作逻辑是否一致和友好（可根据平台特性有所变更）
极端情况表现：文案过长、屏幕过宽、空状态…
视障用户友好：使用键盘 tab 时友好、样式正常、色盲用户友好…
浏览器和性能限制：微信浏览器滚动过程中无法执行 JS、尽可能不要用 JS 动画…
如何管理和呈现组件？

采用 Sketch Shared Style（Text Style & Layer Style） 维护设计组件样式，Symbol 维护 icon 和大型组件，Symbol 内可以嵌套 Shared Style，采用 Git 协作。每一个组件需要包含如下内容：

组件使用规范
视觉样式（组件规则：size、padding、margin 等）
状态变化：hover、disable 等；内容变化：空状态、报错等
交互逻辑（界面变化时的转场逻辑：切换、出现消失）
动画（CSS 和效果展示：需要附上关键数值）
迭代历史：每次组件迭代时遇到的问题、思考过程、最终方案、数据表现（如果有）
最佳实践和注意事项：该组件的正确用法、最佳实践和目前已知的缺陷。
将组件以目录形式组织在 Git中，每个组件单成目录包含上述内容，每次迭代另开分支，不应该在 Master 上直接修改，修改完主模板文件并测试通过文档补全后再合并进 Master 并周知其他设计师全平台升级。