认识达内从这里开始

我们都知道，每一个设计师在进行ui设计的时候都有自己的设计风格和设计习惯的，而把众多的设计师的设计风格和习惯与自己的企业产品相结合的话我们就可以创造出一个符合企业发展的设计模板库来方便以后的工作。

一年前，我们创建了一份风格指南。当时，团队刚刚起步，我们必须将多数时间分配到优先级更高的事务当中，因此没有太多精力去顾及风格指南的制定，最终的产出只是一页包含了常用UI元素的页面。

这份指南的目标主要侧重于前端开发角度，譬如帮助我们维护一个个独立的模块，避免在整合页面时出现CSS方面的bug等等。我们都希望页面当中互不相关的元素在样式定义上不会互相影响，然而这种事总是难以避免，而最好的办法就是创建一份标准化、可信赖的规范。

为什么会失败

这份风格指南是个不错的起点，不过从长远来看，它并不算成功，原因大致有以下几个方面。

所有元素都集中陈列在同一个页面当中，致使文档很长，查询起来非常耗时。我们在规划这个文档的组织架构时并没有采用很明确的方法，创建模块的方式也不统一，而且没有对这些UI元素的组合运用方式进行说明。

我们最初把这份规范视为前端开发方面的辅助工具，设计师们几乎没有参与到创作过程当中。文档当中的术语与设计师们所习惯的有所不同，因此在内容方面缺乏团队层面的普适性。此外，相关的设计原则和使用方法也没有被记录下来，对于在何时、以怎样的方式使用这些UI元素，文档并没有给到明确的解释说明。

文档中的代码没有保持更新，文档很快就失去了时效性。在设计方面也是如此，实际产品当中很快就出现了不同于规范的设计模式。与我们的预期有所不同，这份文档并没有在解决前端bug方面提供到可靠的帮助，同时也几乎无助于维护设计模式的一致性。

随着FutureLearn的发展，一份具有真正参考意义的规范文档逐渐成为越发显著的需求。于是我们决定创建一套全新的设计模式库。这一次，设计师与开发人员都参与了进来。

UI清查

我们做的第一件事，就是对Futurelearn网站进行了一次全面的UI清查。我们在页面截图上裁切出大大小小的模块与组件，然后汇总到GoogleDoc当中。这样做可以确保所有的组件都能被囊括进来，无一疏漏;同时，对于不一致性的问题以及冗余的状况也可以做到一目了然。幸运的是，由于之前或多或少使用过第一版风格指南，所以在不一致性等方面所存在的问题相比于很多同规模产品来说已经少了很多。

完成了全部的UI清查之后，我们开始对所有的设计元素进行梳理和归类。首先是配色、字体等最基础的部分，然后是一些基本的交互元素，接下来是更为复杂的组成部分，例如导航和页面布局等等。

原子化设计(AtomicDesign)

很显然，如果不通过合理的原则与方法对UI元素进行归类，那么最终的模式库仍将是一盘散沙。我们希望参考其他团队的做法，不过看起来大家都有各自的组织方式。

在评估和比较这些方式的过程中，我们发现了BradFrost提出的原子化设计理论-将UI分割至基础元素层面，即“原子”，然后逐步组合成更为复杂的设计元素，通过这种方式逐层构建设计体系。

原子化设计的思维方式简洁而有效，在“如何对UI元素进行组织归类”的问题上提供了详尽的答案。最重要的是，这种思路适用于我们的状况-我们正希望寻求这样一种解决方案，帮助我们抛开“页面”的概念，站在“设计体系”的角度，对不同层面和颗粒度的UI元素进行组织管理。

同时，我们也认为不应该再将这套新的文档称为“风格指南”了，因为我们开始将越来越多用于诠释交互模式及相关设计理念的内容加入其中了。

文档的组织与呈现

文档的内容及架构准备就绪之后，我们需要通过合理的承载方式将其呈现出来，使其易于导航和查询。像过去那样通过一个长长的页面进行展示的方式一定是不适用的。我们考虑过基于页签或下拉列表的页面组织形式，不过最终还是选用了类似MailChimp模式库那样的侧边栏导航模式，因为你可以在不同的类别之间快速切换，而页面内的页签导航则可以帮你便捷的定位到针对特定组件的内容。

团队共享与协作

很多人共同参与到了这次的模式库项目当中。设计师与开发者们密切配合，以实用价值为主要目标来实现产出。另一方面，将模式库共享给没有直接参与项目的相关团队也很重要-只有充分融入到团队协作流程甚至是组织文化当中，设计模式库才能真正体现其价值。

我们将产品团队的所有成员召集在一起，通过乐高积木的概念演示了原子化设计的原理及运用方式。我们还利用FutureLearn自身的产品形式，制作了一系列有趣的教程，帮助团队成员充分了解模式库的使用方式。

动态性与持续性

对于我们这样一个团队来说，打造设计模式库的过程本身就是对于UI元素的正确使用方式的学习。我们现在更加善于识别产品当中存在的不一致性的问题，也更加理解特定的UI元素在表现与行为方面的特质。

在设计和构建模式库的过程当中，我们修复了数不胜数的样式bug及不一致性问题。更重要的是，我们在项目期间始终保持着对设计模式相关话题的讨论，如此密切的沟通在无形当中弥合了设计师与开发人员在概念和术语方面的理解偏差。

我们的产品与品牌在不断地进化，设计体系/模式库亦该如此。已有的模式会发生变化，新的模式会融入进来。我们希望这样一份具有持续性的库文档能够始终承载着我们在创造它的过程当中所学到的东西，并能使我们保持对FutureLearn这一品牌的独到认知。

为了保持模式库的动态性与持续性，我们在开发工作中严格遵守着文档维护原则，始终保持着线上代码与文档代码范例的一致性。

当然，所有这些工作绝非一夜之间能够完成。我们选择首先聚焦于基础性内容的构建，然后再试验性地将一些UI元素“动态化”，使其成为能够展示真实样式及行为特质的动态组件。这些工作都还在进行当中;我们也会持续维护库的内容，并改善其呈现形式，使其保持不断进化。

作者：C7210

来源：beforweb

【免责声明】：本内容转载于网络，转载目的在于传递最新信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。