设计体系：数字产品设计的系统化方法

我的感悟这本书的标题比较宏大，一眼略过难以快速明白其主旨。其实，它的核心内容讲的就是——工作时挂在每一位设计师嘴边的“设计规范”与“组件库”。比如，AntDesign就是最知名且完善的组件库之一。围绕设计规范，作者提出了体系化的概念，并列出了清晰易懂的上手实践指南。 熟稔“设计规范”与“组件库”的设计师们是否仍有必要看这本书？仍然有必要。评论区的另一位朋友和我观点相似——如果我们把书当做是一位很久不见的朋友，和这位朋友聊聊天，即使聊的都是很简单的道理，你也会获得新启发，汲取到能量。 对我最有启发的点有： 1、在团队内， 共享语言（shared language）是非常重要的，即保证当我们使用同一个词语的时候，我们指的是同一个东西。 2、要理解一个模式的目的，需要关注它的作用是什么，而不是你认为它是什么。换句话说，要试着找到最能描述其行为的操作。用动词而非名词来描述模式。 3、如何为模式命名？有个性的名称更容易记住。它们不仅萦绕耳旁，还能启发其他名称。也可以维护一份术语表。 内容摘录◆ 第1章 设计体系 >> Web设计师开始拥抱更加模块化、模式驱动的设计实践。这样做是有充分理由的：我们需要为更多的屏幕类型、更多的设备类型、更多的场景和更多的用户创造非凡的体验。为此，我们开始将界面拆解为微小的、可复用的模块，并借助这些模式，以比过去快得多的速度构建产品、功能和界面。 >> 模式是一种用于解决特定设计问题的可复现、可复用的方案。 >> 从前端开发的角度来看，模块建立在HTML的基础上，而感知性模式则是典型的CSS属性。 >> 语言是协作的基础。如果你在一个团队中工作，你的设计语言就需要在所有参与产品创建的人之间共享。如果不共享语言，团队成员就无法有效地进行共同创造——每个人都对他们想要实现的目标有着不同的心智模型。 >> Abby Covert在她的How to Make Sense of Any Mess一书中指出，在开始构建界面之前，就应该通过讨论、审议和记录语言决策等方式建立起一套共享的设计语言。不仅高等级的概念需要这样处理，讨论设计决策的日常用语也需要如此。共享语言，便意味着我们能以相同的方法为界面元素命名，为设计模式下定义，并能让设计文件和前端代码使用相同的名称。仅仅做到这些还不够。有时，团队里的人以为他们形成了共识，因为他们建立了共享的词汇表并已付诸实践，但他们对这些词的理解其实根本不同。例如，团队的核心概念里面有“场景”（scenario）这个术语，但用了一年以后才发现，团队里不同的人对这个词的理解完全不一样。我们不仅要对语言形成共识，还要对语言的用法形成共识。仅仅对按钮这个词的含义达成共识是不够的，还需要对不同背景、不同目的下使用按钮的原因和方法形成共识。 >> 如果团队之间缺乏沟通，很可能导致只有一小部分人在用它，或者产生大量彼此割裂的模式。如果能保持更新，模式库便可以成为共享语言的词汇表。 用户的“十分钟”诉求让人印象深刻，是很适合植入团队成员心中的锚点。 >> 案例：“十分钟食谱”网站 我之前在写工作复盘时候，有提到一点：交互设计的灵魂是讲好一个故事。一个好的故事，会让项目中所有人都拥有同一个想象。让所有人心儿往一处想，劲儿往一处使。在学生作品集中，很多人会放上“用户画像”，却没有想清楚用户画像的意义，于是沦为一种摆设。其实，用户画像也只不过是帮助我们更好地代入想象用户，并且让团队所有人都拥有同一个想象的工具而已。 >> 为确保我们所做的所有事情都清晰地体现了产品目的，我们需要建立一些基本原则和价值观。可以非正式地讨论，也可以写下来形成宣言。重要的是参与产品创建的人都认同这些价值观，并承诺实践它们。例如，十分钟食谱网站团队的每个人都需要了解时间的价值。他们需要时刻谨记食谱是有时间限制的，因此他们会努力让网站的交互变得简短、快速和流畅。 >> 这些原则不一定是很正式的，甚至不一定要写下来。但是，团队成员应就这些内容达成一致，这对于让每个人的工作和优先级保持同步至关重要。这些内容还能辅助决策：从先实现哪些功能、使用何种方法，到制定用户体验流程、设计按钮外观、选择字体，等等。 ◆ 第2章 设计原则 >> Atlassian是一家企业软件公司。起初，他们针对市场营销和针对产品的原则是不同的。随着时间的推移，他们逐渐融合了这些原则，形成了一套统一的理念，弥合了市场营销、产品设计和服务支持等工作领域之间的裂缝。现在，他们正基于一套统一的原则开展各项工作。“这是一套统一的体系。设计原则将散落的点串联了起来。”——Jürgen Spangl, Atlassian公司设计负责人 >> 你可以设想自己是在做这样一件事：一个新人加入了你的团队，你需要向他解释，在你的项目中做设计时最重要的五件事情是什么。 >> 模糊的设计原则：“明确。”实用的设计原则：“第一优先级只有一个。什么是你希望用户最先看到的或最先用到的？”模糊的设计原则：“简单。”实用的设计原则：“把界面做到牢不可破。就像儿童玩具一样，确保用户可以随意探索，不会因为错误操作而崩溃。”[插图]模糊的设计原则：“有用。”实用的设计原则：“从需求开始。如果你不知道用户需要什么，就无法做出正确的事情。去做调研，去分析数据，去与用户交流，而不是做假设。”[插图]但是，即便是文字极佳的原则仍然存在多种解读方式。只有将原则与应用原则的真实案例结合起来，才是最为实际的做法。 >> 好的设计原则不会试图涵盖一切。它们有态度，并积极地鼓励设计师拥有自己的观点。 >> 首先为自己和同事而写，尤其是设计师、开发人员、内容编辑、营销专家、领域专家，也就是与产品的创建直接相关的人员。你们的目标应该是就“什么样的设计对你们的产品来说是好设计”这一问题达成粗略的共识，并提供如何实现共识内容的实操指南。 >> 牢记关键模式的目的，有助于了解设计体系的运转方式，防止设计体系在发展过程中碎片化。 >> 要理解一个模式的目的，需要关注它的作用是什么，而不是你认为它是什么。换句话说，要试着找到最能描述其行为的操作。用动词而非名词来描述模式，有助于扩展模式的潜在用例，并更准确地定义其用途。设想你有一个简单的推广在线课程的模块（见图3-7）。当你试着描述它是什么的时候，可以将其称作“图像标题”或“课程横幅”。 >> 但是用这种方式描述模式，就过于局限于其呈现和内容了，最终容易将模式的使用范围限制在特定的上下文中。相反，如果根据操作——从用户角度及你自身的角度——来定义模式，便可以发现它的目的：“推广课程”（对你而言）/“发现课程”（对用户而言），“从课程中受到启迪”（对用户而言）/“鼓励人们加入课程”（对你而言）。通过关注操作，可以将模式与行为联系起来，并兼容各种不同的用例。上面的这个模式除了推广课程还能推广什么？在线讨论区？还是一场新的活动？你给它起的名字也能反映这一点。在这个例子中，我们最终将模块命名为“广告牌”（Billboard），以反映其注重操作的推广功能。 >> 首先，列出让模块能够有效运行的核心内容元素。例如，你们可能都认可界面中像“广告牌”这样的推广模块需要以下内容：❑ 标题❑ 强烈的行动召唤❑ 吸引眼球的背景（无论使用纯色还是图像）接下来，试着确定元素的层次结构，并决定如何对它们进行分组。例如，图片是内容的一部分吗？标签页是一定要有的吗？在这样做的同时，可以画一些草图，从而让结构变得可视化。 >> 另一种思考方式是想象你的界面不是可视的，而是可以通过声音读出来的。这个声音什么时候需要增大音量并改变语调？思考如何通过模块内元素间的相互关系和层次结构，完成对音量和语调的视觉表达。当然，这样做还有助于提升对屏幕阅读器[插图]的可访问性。 >> 看过多个团队如何使用模块的案例之后，我们注意到，设计体系中最有效的名称往往具有这些特性中的一个或多个：它们使用了隐喻，它们是有个性的，它们能传达模式的目的。 >> 有个性的名称更容易记住。它们不仅萦绕耳旁，还能启发其他名称，甚至可以建立一个系列的名称。FutureLearn的“耳语框”（Whisperbox）模块旨在用于不会过分引人关注的促销区域。但当另一个团队需要更为醒目的东西时，他们创建了“轰鸣框”（Boombox）。“耳语框”和“轰鸣框”是一对儿，这有助于增强词汇的相关性，从而让人更容易记住。 >> 维护一份术语表是分享和发展设计语言最有效的做法之一。创建并维护一份术语表会让你有意识地关注自己所使用的词汇，因为你必须清楚地写下这些词汇。 运营活动频率高且需求急，通常是最需要模块化的产品类型 >> 通常，模块化方法适用于具有以下特点的产品：❑ 需要扩张和发展❑ 需要适应不同的用户需求❑ 需要大量重复的部件❑ 需要让多个团队能够并行、独立地开展工作这样的产品包括电子商务、新闻、在线学习、金融、政府等大规模网站——任何需要扩张和发展以及应对不同用户需求的网站。 通俗理解，功能性模式属于交互层面，感知性模式属于视觉层面 >> 最简单的划分结构的方法，是将模式库分为组件和样式（即功能性模式和感知性模式）。 >> 只有当元素被复用时，才会被添加到模式库里。有的团队只有在第二次甚至第三次使用某个模块的时候，才会将其添加到模式库里。这样做的逻辑是，在把元素添加到设计体系里之前，必须证明该元素确实是一种模式。这有助于保持模式库精简。 ◆ 结语 >> 亚历山大在1996年OOPSLA会议[插图]上做的主题演讲中强调，关于建筑模式语言有一个根本性的问题：这些模式进入体系之后，会让人类的生活更美好吗？即使并非所有模式都能拥有这种能力，我们至少也要不断努力实现这一目标。

极具指导和参考意义的设计方法论

特别实用，特别干货的好书，翻译的也好。

本书主要讲述了设计系统相关的设计理论和实践两大部分，其中关于组件落地方面还是比较有启发价值的。根据个人思路梳理了下书中内容，可能存在一些误解，欢迎各位同行批评指正。 设计系统应该是有态度的，可以给使用它的人提供一些创意的思路，否则直接拿个现成的组件库不就行了。这个态度如何体现，个人觉得主要在于设计原则，而设计原则又根据产品的目的来定，和产品息息相关。 好的设计原则不是停留在表面的，而是可执行的参考建议。比如“简化”这个词作为设计原则，是有些模糊的不明确的。因为并没有指出什么是简化如何简化。而换成另一种说法，“消除无用元素”，则是可执行的，任何元素都有目的，也就是它所属的目的，如果你不清楚一个元素为什么存在于此，那么可能它就不应该放在这。页面如此，产品在增加新功能时也是如此。 设计原则指导着功能性模式和感知性模式，功能性模式可以类比成动名词，是具体的可操作的部分，感知性模式则类似形容词，是描述的部分。比如按钮是有明确功能的模块，是用户能提交某项操作，而按钮本身的颜色、状态、上面的文字等则是描述按钮是什么样的，属于样式。在前端看来，模块建立在html上，感知性模式则是典型的css属性。 可以转换成容易理解的组件，需要考虑组件的可落地性，比如： 1.共享命名。命名要和组件本身紧密联系，名字起的好，则容易被记住，也就容易被应用。每次应用又会强化记忆，属于正循环。否则，一个记不住名字的组件很大几率不会想到被使用，可能连知道都不知道，不如新创建一个。 理想情况下，参与产品创建的每一个人都应该知道这个元素是什么：它的名称和目的是什么，为什么会被设计成这样，应该如何使用它，以及何时应该使用它。 2.动态维护。组件库是动态的，随着时间不断丰富，是需要维护的。前端和设计保持一致，能很大程度上提高协作效率，保证品牌统一和界面一致性。 关于维护方法，主要有两种，一种是较为严格的，每次创建新元素则设置成组件。这是有要求的，否则会不断累积，产生很多功能相似的、重复的组件。需要先看现有组件是否满足，如果不满足，看能否改动后满足，如果还不满足，则创建新的。 另一种则相对宽松，每次创建新元素不设置成组件，但做好记录。当再次使用的时候再搞成组件，这种理念也是很好理解的。再次使用说明存在复用性，做成组件也是理所当然的。 3.关注操作，将组件和行为联系起来，并兼容不同用例，这样可以扩展组件的使用范围，比如上传模型，上传图片，都是上传，则可以用一个组件，强化了用户认知。 4.关于迭代。过于一致，则可能归于普通；赋予设计师打破常规的权力，则存在更多可能性，也更容易做出品牌差异来。 5.“应该与不应该”（dos and don'ts）很有用，特别是有可能产生误用的时候。很多大厂规范中就采用了这种方法，确实很直观。 一些妥协。一些少量不同步总是会有的，不可能那么完美，我们要接受这个事实。 有了设计系统，可以有更多的精力去解决更重要、更有价值的事情，比如更好地了解用户、让产品体验更顺畅等。

看了大家评价还是很中肯的，我谈下我的观点。 首先这本书不存在过时，我觉得任何能被人推荐且有一定基础的书籍都不存在过时。相反我们看书的人正是因为避免过时才会看书。 若果你把书理解为一位很久不见或想聊一直没聊到的朋友就会发现，即使很简单的道理你也会吸取能量。 关于设计体系我也不认为不适合现在的职场，职场首先是公司第二是自己，没有一家公司不需要这些，而是成本不允许。那么你作为第二主体就必须学的很扎实，对自己的组建和梳理并不会因为这些而变得陈旧和臃肿，反而会让你在纷乱的思绪里发现你很久没复盘了，且复盘的规则该扩展了。 以我的经验这本书又提供了思考，我们的框架和体系需要再次迭代，这个感觉就好像最近的那个教人坐火车的博主。你明知道这些是不需要再次迭代的，但出现后你会发现边界不同了，可能是参与的人不同也可能是参与的市场不同了

书中关于体系化的解决问题的理念是将设计价值尽可能最大化才是核心，引导用户操作和传达品牌达到商业目的。设计体系的建立和维护是为提高设计师效率，以便做出更规范好用的页面，可将更多的时间放在研究和探索上。 具体实施需要结合所在公司的实际情况，1-3的设计团队建设和维护时间成本太高，在一直追求快速迭代现在执行起来确实有难度。反而是成规模设计团队的优势，能尽可能保证设计输出质量和稳定性。

很好的一本书，是研究产品技术和语言理论的不错选择。“创新、优雅、人性化”是产品设计的无上真理，作者很好地把这个原则融入到了书中。体系一直是重要的框架，而在产品设计领域很少有人提及，这算是一部集大成之作，填补了产品设计框架的空白。值得推荐。

随手挑选的一本，被书名“体系”“系统化”两个词吸引，而选作我入门UI UX设计的第一本书。 本以为是关于UX设计基础理论的书籍，结果看第一部分的时候发现完全不是这么一回事，说的是具体的模式库的构建，类似设计指导手册（白皮书）的构建与编写，导致我一度读不下去。 不过从“过程”这一章开始，作者开始介绍一些具体内容，结合过往建筑设计的经历，倒是很有代入感。我一直非常痛恨重复的手工活，如何聪明地构建可复用模块，减少重复性劳动，是永远伴随设计工业化流程的议题，很难一劳永逸。

什么才是有效的：只有当设计体系围绕产品目的，综合了设计过程中的成本效益及用户体验的效率和满意度时，它才是有效的。

产品目标、组织文化共同作用导出设计体系的价值和应用程度。将模式库区分为功能性模式（组件）和感知性模式（品牌、行为、认知等感知元素）。视觉设计师对模式库引发的“自我价值恐惧”，常未能从产品目标和设计初衷上去思考。设计体系和模式库的应用，受团队文化、资源限制，最终应以特定的程度和形式满足需要，建立过程中管理和维护共享方式也决定其后期的落地实际价值。