组件库物语 - 通用性与易用性的权衡

C7210 发表于 2018-12-04 17:35

周日晚间，“猎户星座”，全家便利店的美式咖啡，酝酿着困倦与新一周的未知，初冬的天气却毫不冷静。“有时你乘起风，有时你沉没，有时午夜有彩虹”。

一周前上架了新的 Sketch 组件库，也就是聚焦于社交类产品设计需求的 WireframeKit “Social”，同时也开始以这样的形式进行总结，包括思路、原则、工作方法、细节技巧等等；复盘于己，分享于人。

“Social”库附赠《设计体系》全书译文，了解详情 ›

在上一篇“组件库物语 - 定义目标，以小为始”当中，我简单介绍了“Social”库的项目启动过程，包括早期规划、目标分析，以及“自下而上”的起步技巧等等；今天来聊一些细节实现当中的权衡问题。我个人在每一次的库相关项目中总会遇到类似的问题，相信对各位来说也不会太陌生。

通用性与易用性的权衡

先对这两个概念进行定义，避免含义宽泛造成误解。在本文范围中：

通用性：指组件库提供的元素（图标、按钮、组件、模块等）对于设计需求的适应能力，即能否以较少的元素实现较为多样的产出形式。
易用性：指组件库对于使用者的友好程度，即能否帮助设计师以较少的认知与操作成本来调用和定制组件。

具体到 Sketch 的实践层面，我们通常会将若干元素打包为 Symbol，构成一个可供复用的组件。其中，“通用性”与“易用性”体现在：

Symbol 内部元素的可控性越低，其用途就越单一，对于使用者来说也更易于认知和记忆。但要满足复杂的设计需求，所需 Symbols 的数量就更大，整体架构的复杂度更高，库的制作和维护成本也更高。
Symbol 内部元素的可控性越高，其用途就越广泛，需要配合“Overrides”面板控制的嵌套及样式关系就越为复杂，因此使用者对其用途的理解与记忆成本就越高，每次根据特定需求进行调整定制的复杂度也越高。而相应的，由于 Symbols 的高度整合，库的整体规模会相对较低，架构相对简单。

以上两种状况，任何一个极端都不利于构建高效实用的组件库，制作者需要针对每一个图标、按钮、组件、模块，考虑如何实现通用性和易用性的平衡。

以“Social”库当中的一些实现方式为例，来简单描述下这种平衡。

图标

如下图所示，“Social”库提供了40个常用的功能性图标，并以此为基础扩展出了不同形状样式的共计48个“Category”类图标（用于金刚位或消息列表等等）：

从实现方法上，后两类图标显然无需定义 24x2 共计48个 Symbol；将基础图标 Symbol 与背景样式 Symbol 进行嵌套，打包成一个 Symbol 即可解决问题。这个 Symbol 具有高度的通用性，使用者可以通过“Overrides”控制其图标样式与背景种类。但从使用角度，这种方式不利于一目了然地识别和记忆，不利于使用者在第一时间了解有哪些同类元素可供调用，需要依靠猜测及“Overrides”进行复杂的控制。分别定义成48个图标之后，无论使用者打开源文件进行参考，还是直接作为 Library 调用，都可以清晰地看到全部可用元素。

同时，这48个图标并不代表所有的可能性，你仍然可以通过 Sketch 52 提供的Symbols 样式定制功能实现更多的规格。

按钮

“Social”库提供的行动类按钮包括以下3类，5种风格共计15个：

除了左侧带有图标的按钮之外（这类按钮的自适应性需要用到一些有意思的 hack 来实现，单独找一篇聊），其他几种风格，包括圆角矩形或胶囊状，以及实色、Ghost 样式等等，从技术角度同样可以藉由一个 Symbol 实现，并通过“Overrides”控制实际风格。但同样，作为组件库，相比于技术逻辑是否极致，易于发现、识别并快速调用才是最为优先的。

Feed Header

“Social”库提供了8个 Feed Header 组件，用于构建信息流卡片当中的用户信息。

如果加以整合，这8个 Symbols 完全可以压缩成两个，甚至是一个；在调用时通过“Overrides”控制内部元素的呈现或隐藏。然而在那样的情况下，从“需要调用”到“完成调用”这个过程已然需要使用者付出大量的认知成本，需要反复调整元素的布局与呈现关系，才能调试出可能符合自己需求的组件。

结语

综上所述，对于“Social”库来说，我更希望使用者在调用其元素时，可以一目了然地发现所有选项，并能快速完成选择和调用；而非提供一系列极致整合的“通用”组件，使你不得不预先进行猜测、判断，并通过大量的定制工作才能达到目标。

当然，这种平衡性原则也和库本身的性质有关。如上一篇物语所说，“Social”库的目标本就包含“减轻甚至免除受众改造组件的成本，实现更快的使用速度”，因此会使天平更倾向于“易用性”的一侧，而非高度整合的“通用性”。如果你需要制作的库更在于体量的控制或是需要体现前端开发方面的实现逻辑，那么对天平倾向性进行相应地调整也是有必要的。