设计体系和设计规范是一个东东么？

最近看了一本实用性很强的书，恰好也正在做这个。因为时间刚刚好，因为书刚刚好，因为抠脚大叔也刚刚好（深情状），咳咳，大叔在甚为兴奋的状态下很快的读了一遍，后来因为要做分享，所以又多读了两遍，每一次读都有不同的理解和感悟。但总结一句就是：规范也好，系统也罢，我们要记住做这件事的最终目的是为了提高团队效率，服务于最终产品，形式方法都可以因地制宜。后面附了这本书的中文翻译链接，希望大家也能有所收获。（因为是总结感悟，所以不做过多剧透）

Smashing Magazine上可以购买：

https://www.smashingmagazine.com/printed-books/design-systems/

总结的话写前头：

1、此书所探讨的是如何以体系化的方式推动设计流程，以及如何围绕特定的产品目标及团队特质来构建设计体系。

2、设计系统由多种模式、组织架构、团队文化、产品类型、设计流程等构成，其中设计模式就是我们所要探寻的重点内容。

3、设计模式不是设计规范，传统的设计规范就是字体、颜色、icon等更偏重于风格的定义。而设计模式指的是任何可复用的界面组成要素。在抠脚大叔理解看来，模式不是抽象的，而是你具体的业务和产品，例如：登录注册在每个产品里都有，但你的产品可能因为某种原因，一定要在注册的时候提交头像，那么你就可以基于你的产品来构建一个注册模式。

之前走过的路

我相信很多人跟抠脚大叔一样，给公司做过设计规范。翻阅之前的历史，从1.0.0到今年的4.0.0，总共迭代了4个版本，但其实大的改动也就是两个版本。第一版建立的时候，抠脚大叔是辅助，主要是公司一个设计师弄的，她用ps建立了公司最初的一版设计规范。当时只有两三个人，稍稍看看，记下几个关键色值就行了，规范问题也很明显：

1、基础规范仅适用于阅读，无法直接取用。

2、控件、组件、部件混在一起放在规范里，部件经常根据业务变化，导致规范变动频繁。

3、整个规范，不利于协作、维护、迭代，但因为当时人就两三个，这个问题暴露的也不明显。

所以抠脚大叔在2.0.0版本的时候，根据使用情况优化了几点：1、将文档和Sketch源文件分开，文档供查看，Sketch源文件供直接使用；2、将基础控件和业务控件分开，所谓的基础控件就是系统控件，如弹框、toast这类，业务控件，就是基于业务场景所沉淀下的控件；3、增加修订记录。现在看看，问题也是有的：

1、修改麻烦，改动一处需要更新两个文件；

2、协同工作效率差，更新需要通知其他人，不然会造成信息不对等；

3、业务控件越来越多，差不多的场景样式各式各样。 

这些是不是我们很熟悉的设计规范？字体、颜色、icon、控件等规范出来，基本上就是一个设计团队所拥有的所有标准了。我们所定义的基础控件，无非是将iOS和Material Design的控件做一个筛选，后来Ant Design出来后，我们因为有些页面是Web实现，结果变成，我们基础控件就是在三个平台之间寻求一个平衡，稍加定义让其更加符合我们的产品需求。

这本书的启示：

我们在设计什么？

其实在2.0.0版本做的业务控件，就是有意识在设计的时候把一些做过的页面收纳总结起来了，这样不用在同一个问题上，反复想解决方案。模式库存在的意义也是这样的，我们产品有四五十个功能，六个设计师同时在不同功能上做设计。谁能保证设计一个信息展示页面，大家能设计的一模一样？但是，虽然信息展示页面面对的业务可能不同，难道就不能设计成一样的么？书里说到，同样的信息架构，同样的功能，我们都可以将之归为同一个设计模式，尽管在不同业务场景可能有不同的外观需求和行为方式，但那只是模式的变体，而非不同模式。

收集的一些列表页面

我粗略的收集了一些列表页面，当然，列表只是它们的表现形式。而它们有的目的就是类似于小区公告栏一样信息展示。按照书中所写，我将页面按功能分类，分解它们的信息架构，给这个模式取了一个好记的名字“橱窗列表”，如下：

橱窗列表

为什么叫橱窗列表？起名在书中说了，要好记，跟功能挂钩，比起列表1、列表2而言，橱窗列表显然让人更容易记住。

所以回到最初的问题：我们在设计什么？

抠脚大叔认为，我们要理解真正的需求，设计不只只在解决问题，他还要看到真正的问题。就像现在大厂动不动就喜欢搞一套大而全的功能控件库，其实在某种程度上确实减少了我们做不必要的重复工作，我们要将更多的重心放在理解用户和需求上。

我们是什么样的团队？

什么样的团队，什么样的组织结构其实也影响着我们的设计体系。具体体现在设计体系的三个方面：实践规则（严格、松散）；构造方式（模块化、整合化）；管理机制（集中式、分布式）。（翻译取自译者C7210，文后附链接。）随后书中举出了Airbnb、TED和Future Learn的例子，

 维度划分

这个抠脚大叔很有感悟，一开始建立规范的时候，就有团队成员担心规范过于细致会影响设计师的发挥。但是在书中的这一章写的很清楚，规范也好，模式也罢，最终目的都是为产品服务，包括团队的风格建设，我们可以根据自身需求量身定做属于自己团队的设计体系。

最后的话：

其实还有很多小点我没有写下来，原因怕文章太长太啰嗦，其他的就靠大家自己去看看了。我只把我认为最重要的写了出来，谢谢阅读。

翻译版链接：

https://mp.weixin.qq.com/s?__biz=MjM5MDc0MDIyMA==&mid=2650619728&idx=1&sn=292caed44c7f985ca52ab0c18f357c7f&chksm=be49a4c3893e2dd57d13f23a8d0cdecb28ab3e2c67b37b894628e4e7670cdb263b0e98187cbc&mpshare=1&scene=23&srcid=1219sCj6pDPxJkDz68x1pt9o%23rd