设计系统和设计规范是一回事吗？
1，这本书讨论了如何系统地推进设计过程，如何围绕具体的产品目标和团队特征构建设计体系。
2.设计系统由各种模式、组织结构、团队文化、产品类型和设计流程组成，其中设计模式是我们要探讨的重点内容。
3.设计模式不是设计规范。传统的设计规范是字体、颜色、图标等的定义，更侧重于风格。设计模式是指任何可重用的接口组件。按照便宜大叔的理解，模式不是抽象的，而是你具体的业务和产品。比如登录注册，每个产品都有，但是你的产品可能因为某种原因注册的时候要提交头像，那么你就可以基于你的产品建立一个注册模式。
我相信很多人都和抠门大叔一样，为公司做了设计规范。翻翻之前的历史，从1.0.0到今年的4.0.0，一共四次迭代，但其实变化大的只是两个版本。第一版成立时，吉焦叔叔是助手，主要由公司的一名设计师制作。她用ps建立了公司的第一版设计规范。当时只有两三个人。看一看，记下几个关键的颜色值就行了。规格问题也很明显:
1.基本规范只适用于阅读，不能直接访问。
2.规范中控件、组件和零件混杂在一起，组件经常根据业务变化，导致规范变化频繁。
3.整个规范不利于合作、维护和迭代，但由于当时只有两三个人，这个问题并不明显。
所以在2.0.0版本中，便宜大叔根据使用情况优化了几点:1，将文档与草图源文件分离，允许文档查看，草图源文件直接使用；2.将基本控制与业务控制分开。所谓基础控件就是系统控件，比如弹出、吐司，业务控件就是基于业务场景沉淀的控件；3.添加修订记录。现在来看，也有问题:
1，修改起来比较麻烦，需要更新两个文件才能改一个地方；
2.协同工作效率差，需要通知其他人更新，否则信息不对等；
3.业务控件越来越多，几乎各种场景风格都有。？
这些是熟悉的设计规范吗？字体、颜色、图标、控件等的标准化。基本上是一个设计团队的所有标准。我们定义的基础控件无非就是过滤iOS和材质设计的控件。后来蚂蚁设计出来后，我们意识到有些页面是Web的，结果我们的基础控件只是在三个平台之间寻求一个平衡，稍微定义一下，让它更符合我们的产品需求。
我们在设计什么？
其实2.0.0版本中做的业务控制，就是有意识地总结一些设计时已经做过的页面，让你不用在同一个问题上反复思考解决方案。模式库存的意义也是一样的。我们的产品有四五十个功能，六个设计师同时在不同的功能上设计。谁能保证设计出一个大家都能设计的一模一样的信息展示页面？但是，虽然信息展示页面可能面对的商家不一样，但是设计的不可以一样吗？书中说，相同的信息架构和相同的功能都可以归入相同的设计模式。虽然在不同的业务场景中可能会有不同的外观需求和行为，但这只是模式的变体，而不是不同的模式。
我粗略的收集了一些列表页面。当然，列表只是它们的表达式。而他们的目的就是展示类似于社区公告牌的信息。根据我在书中写的内容，我将页面按功能分类，分解其信息架构，并给这个模型取了一个好记的名字“窗口列表”，如下:
为什么叫窗口列表？名字在书里写明了。它应该易于记忆并与功能相关联。与列表1和列表2相比，窗口列表显然更容易记忆。
所以回到最初的问题:我们在设计什么？
抠门大叔认为我们应该了解真正的需求。设计不仅仅是为了解决问题，更要看到真正的问题。就像大厂喜欢动不动就建一个大而全的功能控制库，其实在一定程度上减少了不必要的重复工作，我们更应该注重了解用户和需求。
我们是什么样的团队？
什么样的团队和组织结构实际上影响了我们的设计体系。具体体现在设计制度的三个方面:实用规则(严与松)；建设模式(模块化、集成化)；管理机制(集中式、分布式)。(译文摘自译者C7210，附链接。后来，书中引用了Airbnb、ted和Future Learn的例子。
这个抠门大叔很有洞察力。当初建立规范的时候，有团队成员担心规范太细，会影响设计师的发挥。但是书中这一章写的很清楚，最终目的是为产品服务，包括团队的风格建设。我们可以根据自己的需求，量身定制属于我们团队的设计体系。
其实还有很多小点没写下来，因为怕文章太长太啰嗦，剩下的就看大家自己看了。我只写了我认为最重要的东西。感谢您的阅读。
翻译版本链接:
/s？_ _ biz = mjm 5 MDC 0 mdiyma = = & amp；mid=2650619728。idx=1。sn = 292 caed 44 c 7 f 985 ca 52 ab 0 c 18f 357 c 7 f & amp；chksm = be 49 a4c 3893 e 2 DD 57d 13 f 23 A8 d 0 cdecb 28 ab 3 e 2 c 67 b 37 b 894628 E4 e 7670 CDB 263 b 0 e 98187 CBC & amp；MP share = 1 & amp；场景= 23 & ampsrc id = 1219 scj 6 pdpxjkdz 68 x 1 pt9o % 23日