设计系统 on Hi, I'm 5key

Google DESIGN.md 实践：把设计系统写成 AI 能读的 Markdown

Sun, 19 Apr 2026 00:00:00 +0000

TL;DR

用 AI Coding 做产品时最大的问题不是「AI 不会用组件」，而是「AI 不知道什么时候不该用」。

Google 的 DESIGN.md 给出了一个轻量方案：把设计系统写成 Markdown 放进代码仓库，让 AI 每次 Coding 都能读到设计约束。

篇首语

最近这段时间，我一直在用 Claude Code 做一个数据分析系统。

最开始启动的时候，整体的体验还是非常不错的。我只需要写好需求描述文档，准备好各种 API，Claude 很快就能交付一个质量相当不错的结果。

指定好 React + Tailwind + Shadcn 的技术栈，再配合上 Shadcn 提供的 Skill，Claude 在 Coding 上的确非常顶。整个过程中最大的瓶颈其实是自己，写需求的速度赶不上 AI 写代码的速度，最后还是搞得自己非常累 😅

不过这也算不上是问题，真正的问题其实发生在一段时间之后。随着功能不断推进，界面设计的质量开始有些不太可控了。组件错用，样式不统一，交互流程前后不一致，这些问题开始频繁冒出来。

我用的已经是 Shadcn 了，组件库的文档也给了 AI，为什么还是管不住？

DESIGN.md 是什么？

DESIGN.md 是 Google 提出的一种设计系统文档约定：把产品的视觉风格、组件规则、交互约束用 Markdown 写入代码仓库，供 AI 编码助手（如 Claude Code、Cursor、Codex）在每次 Coding 前读取。它相当于写给 AI 的「设计决策指南」，解决传统组件库文档只回答「怎么用」、不回答「什么时候用、什么时候不该用」的问题。

简单说，DESIGN.md 把设计约束变成了 AI 的上下文。配合 CLAUDE.md 等启动加载规则，AI 每次生成界面前都会先读一遍这份设计规范，按其中的 Do’s and Don’ts 来生成代码，这是设计系统在 AI Agent 时代的一个轻量落地方案。

从概念到落地，产品界面的 AI 生成究竟卡在哪儿了？

Mon, 31 Mar 2025 00:00:00 +0000

TL;DR

AI 生成产品界面的 Demo 看起来很惊艳，但真正进入企业业务流程时几乎都「跑不动」。

原因不在 AI 能力本身，而在三道坎：生成质量（结果不稳定）、生成认知（不理解业务逻辑）、生成结构（输出不具确定性）。

设计系统的 AI 化，可能是跨过这条鸿沟的真正路径。

前两天，一位朋友兴奋地告诉我，TA 的机会来了，终于可以在公司的产品设计流程中，尝试用 AI 来进行界面设计的生成了。

说实话，看到这个事儿能有进展我也挺开心的。

几个月前 TA 约了次咖啡，说自己正负责团队里的设计系统，想听听我怎么看，有没有什么方向可以尝试。当时我跟 TA 聊到一个思路：可以尝试着把 AI 与设计系统进行结合，让它来自动完成一些重复性的界面生成。TA 听得挺认真，觉得这个方向挺有意思，回去之后也开始做了不少的功课。

虽然主管当时觉得时机未到，这项工作后来被搁置了，但 TA 并没有放弃。正好最近公司内部架构调整，AI 被提到了战略层面，就顺势把自己平时的研究，做了个演示 Demo 找主管做了一次汇报。

这个 Demo 本质上和现在市面上常见的界面生成方式差不多，都是通过输入一段需求描述，让 AI 自动生成对应的界面。

上图为文章配图案例，与真实业务无关

但不同的是，它生成的结果从布局结构到视觉风格，再到字段内容的业务贴合度，都与他们的产品高度一致。看上去不是那种“拼凑感”很强的概念稿，反倒更像是我们在日常项目评审里会看到、可以直接拿来走流程的设计方案。主管和业务团队看完之后也觉得眼前一亮，如果这个 AI 能力能做到这样的程度，那还是非常值得投入的。

AI 生成产品界面的 Demo 看似可行，真正落地有多难？

从 Demo 来看，效果的确不错。但我们其实都清楚，这只是一个演示 Demo，从“能演示”到“能实现”之间，还有很多的问题需要一个个解决。

大家看到的是一个界面，但它其实是由数十个组件、数个 Pattern 的组合，再叠加上层层的业务逻辑，才拼出来的这个看起来“顺理成章”的结果。要把这么多复杂的因子结合起来交给 AI 来“操作”，并不容易。

“前台”的简单，其实是“后台”的复杂。AI 让界面生成这一步看上去变得轻松了，但真正难的部分，那些规则、逻辑依旧存在，只是被藏在了后面。客观来说，这个 Demo 只是用了更贴合业务的“包装方式”来让公司接受，而其背后需要解决的问题依旧存在，一直都没有变过。

从 Ant Design X 探索 AI 产品领域设计系统

Mon, 09 Dec 2024 00:00:00 +0000

写在开头

在之前的文章中曾和大家提到过，ChatGPT 的这种会话式交互模式可能会成为未来 AI 产品最为主流的设计范式。这两年来，我们也看到越来越多的产品开始采用这种模式，来构建自己的 AI 产品。

但会话式交互真的会是 AI 产品的最终形态吗？这个问题在目前可能并没有答案。不过可以确定的是，至少在未来很长一段时间里，AI 产品都会以这种形态出现在我们面前。因此，基于会话的设计系统的出现也就成为了必然。

上周 Ant Design 推出了一个名为 Ant Design X 的全新设计系统。这是一个专注于会话式交互的解决方案，为 AI 产品的构建提供基础能力。

在这个领域中我们基本还没看到类似的能力出现，所以 Ant Design X 应该说是目前业内第一个真正意义上的服务于 AI 产品的会话式设计系统。

一直以来，我们聊设计系统，往往集中在中后台的 B 端产品上。因为它们的复杂度相对较低、可标准化的程度高，非常适合构建设计系统。

但也正是因为我们聊 B 端产品聊得太多了，而像电商、社交、金融等领域，迄今为止都很难看到能真正称之为领域级的标准出现。以至于我们对领域级设计系统的讨论终归显得有些单薄。

相较于 Ant Design X 所提供的内容，其实我更感兴趣的设计系统终于出现在一个新的领域了。这一期的文章，我不想聊太多 Ant Design X 文档中的设计细节，而是希望借助这个案例和大家一起聊聊领域级设计系统是如何构建的。

领域级设计系统是什么？

开始之前，我们还是要再回顾一下领域级设计系统。在之前的定义中，我们将设计系统分成了：系统级、领域（行业）级、业务（产品）级三个等级（关于三级分类的详细论述，可以参考设计系统学习指南 - 国内外 Design System 案例解析和深度解析 AWS CloudScape 这两篇）。

如何规划 B端设计系统？深度解析 AWS CloudScape Design System 最佳实践

Fri, 08 Nov 2024 00:00:00 +0000

TL;DR

AWS CloudScape 是 AWS 开源的 B端设计系统，在 Pattern 密度、约束清晰度、实操性上做到了极致。相比 Ant Design、Fusion 这类通用领域级系统，它把"业务级"设计系统的应有形态展示得非常完整。

本文用一篇文章的篇幅，从它的 4 层结构（Foundation / Component / Pattern / Demo）出发，拆解一套优秀 B端设计系统应该长什么样，以及我们能从中学到什么。

如果你正在规划自己团队的 B端设计系统，CloudScape 是当下最值得对标和借鉴的开源案例。

什么是 B端设计系统

在进入 AWS CloudScape 设计系统的深入分析之前，我们先来谈一谈什么是 B端设计系统，以及它与 C 端设计系统的不同之处。

B端设计系统的主要用户和场景

与 C 端（面向消费者）的设计系统不同的是，B端设计系统通常需要面对的是企业内部用户或特定领域的专业用户，例如企业的操作人员、管理人员或合作伙伴。这些用户的操作任务往往涉及到复杂的多步骤流程、大量的数据交互，以及多个角色之间的协同。

B端设计系统的核心目标是通过系统化的设计语言和标准化的交互模式来降低用户学习成本，提高效率，并确保不同模块之间的体验一致性。

B端设计系统面临的核心挑战

B端设计系统的设计挑战在于需要考虑用户的专业性和业务复杂度，而且必须兼顾高效性和稳定性。

例如，在企业级应用中，用户可能需要同时查看多项数据指标，处理多个任务并行的复杂场景。这就要求 B端设计系统具备强大的信息展示和组织能力，并且可以灵活应对不同的业务需求。同时，B端设计系统也必须考虑到用户角色的多样性：一套系统往往需要为不同层级的用户（如数据分析师、业务经理、IT 管理员等）提供可定制的体验。

B端设计系统往往更注重模块的可复用性和设计的拓展性。因为企业级系统通常会不断发展和变化，设计系统需要能够适应新的业务需求和变化，因此，模块化和组件化的设计思维至关重要。

通过标准化的组件库和模式库，设计系统可以在多个产品线或不同的项目中复用，确保设计的一致性和开发的高效性。

B端 vs C 端设计系统的本质差异

这与 C 端设计系统强调情感化体验和用户粘性的目标有所不同。C 端设计更多关注视觉吸引力、用户体验的愉悦性和情感联结，而 B端设计的首要任务是让用户能够以最低的认知负担完成复杂的工作任务，从而提升整个业务系统的工作效率和生产力。

Salesforce 的生成式画布，证明了 AI 在产品界面设计中的可行性？

Mon, 04 Nov 2024 10:34:56 +0000

TL;DR

Salesforce 的 Generative Canvas 给生成式 AI 在产品界面设计中找到了一条可行路径：它不是凭空生成 UI，而是基于成熟的 Lightning Design System 做约束式生成。

这恰好回答了过去两年 AI UI 工具失败的核心原因：缺乏可依赖的设计标准、缺乏对业务逻辑的理解。

设计系统才是 AI 生成 UI 的真正前提。

在上一期的专栏文章中，我们讨论了生成式 AI 在产品界面设计中遇到的问题（详见产品界面的 AI 生成式设计，为什么没人关注了？），以及为什么还无法运用到日常的设计工作中。

生成式 AI 在界面设计中遇到的问题

总的来说，主要体现在两个方面：

01.缺乏可依赖的设计标准

界面设计不仅仅是视觉上的创意，它更需要强有力的逻辑支持。

我们可以明确地定义一只猫或一辆汽车的外观，但对于购物车界面或下单支付流程，缺乏具体而明确的定义标准。在缺少这些明确规则的情况下，生成的 UI 可能只是各种组件的简单堆砌，缺乏逻辑性和良好的用户体验。

相比人类设计师的成果，生成式 AI 产出的界面往往不够稳定，难以达到企业级的需求标准。

02.缺乏对业务逻辑的理解

我们日常的设计工作都是围绕着具体的业务开展的。而如今现有的设计模型都只是通用模型，无法理解具体某个业务的特性和复杂度。这就导致 AI 的生成结果难以满足设计要求，无法直接应用到具体业务生产环节中去。

这两个问题是当前生成式 AI 在界面 UI 设计方面发展的最大挑战。然而，我们也注意到，生成式 AI 在一些特定的业务场景中已经取得了显著的进展。比如，Salesforce 的生成式画布就是一个很好的例子，展示了生成式 AI 在企业环境中应用的潜力。

本期的文章，我们将从 Salesforce 的生成式画布开始，与大家来一起看看当生成式 AI 与业务进行融合后，会给我们的设计带来哪些变化，给用户又带来哪些帮助。

Salesforce Generative Canvas

Generative Canvas（生成式画布）是 Salesforce 今年 10 月发布的一个新功能。它能够在 CRM 系统中基于用户的提示词，结合系统内实时业务数据来动态生成 Dashboard 的界面 UI。

设计系统究竟应该由谁来负责？

Wed, 25 Sep 2024 00:00:00 +0000

TL;DR

设计系统的卡点很多时候不在工作本身，而在「谁来负责」。

把它当成谁有空谁做的附加任务、或者交给新人练手，都会让推行变得困难。

设计系统不是一套文档，而是一套需要持续运转的机制：必须有清晰的所有权和稳定的资源投入，才能真正在产品研发流程中发挥价值。

设计系统所有权问题：为什么这么难？

在聊到设计系统这个话题时，很多人都有一个困惑。那就是在团队中，设计系统的工作究竟应该由谁来负责？这个问题表面上看似简单，但在实际操作中却远比想象中的复杂。

有些设计团队会认为，设计系统只是一套需要偶尔更新的文档，它只是在做项目时随手查找参考的工具。因此大家会认为，设计系统的工作并没有特别的重要，谁的资源相对空一些就安排谁来做。

我曾经也见过一些团队，会将设计系统的工作交给新入职的设计师。让新人熟悉团队和业务的同时也可以顺便梳理一下文档，分担一些工作。这种“谁做都行”的心态，最终的结果就是权责不清，导致设计系统的推进和落地变得异常艰难。

设计系统不是文档，而是一套需要运转的机制

在过往讨论设计系统的文章里，很多次和大家说设计系统绝对不能仅仅停留在一套文档的层面上。它必须在产品的研发过程中运转起来才能发挥出它真正的价值。这种运作的要求使得设计系统不可避免地与团队内以及上下游的协作关联起来。从这个角度来说，设计系统也不再是单一团队的责任，而是涉及到整个组织的流程和协作方式。

在设计中台的那个阶段里，我的团队非常重要的职责之一就是协作各个业务设计团队推进设计系统的落地。在这个过程中，我们看到了各式各样的问题。有的希望能快速迭代，有的希望极度收敛，还有的希望高度定制…

而这些看上去非常专业向的工作，很多时候出现的卡点并不是工作本身，而是其背后的机制和保障问题。直白点来说就是，这个事情究竟应该由谁来负责？

不同团队模式下的负责机制对比

在有的团队里，设计系统是设计师的“附加任务”，大家需要在完成日常设计工作的同时，负责系统的更新和管理，而在另一些团队，设计系统则由专人或者是团队负责。无论哪种，多多少少都会存在一些劣势，这些工作投入很多时候也不被业务所认可。

因此，在今天的文章中，我想从「谁来负责」这个问题切入，和探讨在设计团队中，设计系统究竟应该通过什么样的机制来推动。需要强调的是，每个团队的业务背景和工作模式不同，所以这里并不存在标准答案。这篇文章只是希望分享我的一些思路，能够为大家提供参考，帮助大家在各自的业务中找到合适的推进方式。

阅读全文

以上内容节选自OFF DESIGN 专栏 47 期文章「设计系统究竟应该由谁来负责？」。

💡 延伸阅读：

📚 主题枢纽：设计系统完整指南｜涵盖三层架构、案例、AI 时代的完整路径

入门基础：设计系统 · 我们为什么要做 Design System

角色演变：成为架构型设计师

推行话术：如何向你的主管和团队介绍 Design System 的重要性

欢迎加入我的知识星球，阅读本期文章全文内容以及过往所有文章。

设计系统中的决策树：让设计决策更简单

Tue, 18 Jun 2024 16:34:56 +0000

TL;DR

决策树是让设计系统"真正能用"的关键机制，它把分散的组件规范变成可执行的选择路径，既帮设计师做对选择，也为 AI 大模型在界面生成时提供稳定逻辑。

结合 AI 的发展趋势，决策树正在成为设计系统 AI 化的重要基础。

AI 设计近一年来的发展

过去的这一年里，AI 在界面设计方面的发展似乎很平淡，无论是国内还是国外都少有新的突破性产品发布。这种“沉寂”其实也并不意外，从大家惊叹于 AI 的可能性到真正认识到它的可行性，无论是资本还是用户都会逐步的回归理性。这其实也是给了 AI 设计类产品一个理性的发展空间。

在这段时间里，无论是海外还是国内的产品，大家都开始考虑将大模型和设计系统进行结合，为 AI 在界面设计领域的发展寻找一个有效的支撑。

其实在过去的好几篇文章里，我们都讨论过这个问题。一个强大的设计系统可以为AI 界面生成提供强有力的帮助，但这个演进的过程并非是直线前进的。

设计系统的复杂性和多样性需要大模型具备理解和运用这些系统的能力，但这其中的难点在于，虽然大多数设计系统都具备完备的文档系统，文档中也详尽地陈述了所有的指引和规则，但它却缺乏一种直观的方式来帮助用户或（模型）来快速理解和运用。

设计系统中的决策树

最近在网络上查阅资料时发现一个很有意思的文档。与其他的设计系统不一样的是，它引入了一个新的能力（或概念） – 决策树。目的是帮助用户，特别是非专业设计人员，能够更清晰地理解实际项目设计中应该如何选择合适的组件来完成业务的表达。

通过设计决策树，复杂的设计系统可以被拆解成一个个易于理解和判断的节点和路径，将设计系统中潜藏的逻辑和规则，以一种更具结构性和导向性的方式呈现出来。这种方法不仅能能降低用户的学习曲线，还使得设计过程更为准确和高效。

同时，在AI领域决策树的可以成为大模型学习的一个非常重要的补充。让 AI 更好的理解需求，在复杂的设计场景中做出智能决策。

本期的文章，我想和大家聊聊决策树在设计系统中的应用。我们将深入探讨如何利用决策树来简化和优化设计过程，尤其是在面对复杂的设计选择时，它如何帮助用户（包括非专业设计人员）做出准确的决策。

我们还会尝试按照这种方法，自己创建一个用户通知的决策树，看看如何在实际操作中将决策树应用于界面设计，并讨论决策树在AI界面生成中的潜力和可能性，探讨它如何为大模型的智能化设计提供强有力的支持。

设计系统核心理论篇 – 布局框架

Fri, 29 Mar 2024 16:34:56 +0000

TL;DR

设计系统的核心不是组件库，而是底层的布局框架。本文拆解一个完整的布局框架应该包含什么：WWTF 原则（Who / What / Targets / Facts）、顶部导航、侧边导航、Z 轴层级。

读完本文，你应该能动手为自己的业务构建一套可用的布局骨架。之前在 OFF DESIGN 专栏中，用了好几篇文章来和大家探讨设计系统的定义、价值，以及我们该如何去规划、使用它。相信现在大家已经对设计系统这个命题有了清晰的理解，接下来我们就开始分板块聊一聊各个重要的组成部分，帮助大家搞清楚设计系统的核心逻辑。

设计系统核心理论篇的思路

关于设计系统，目前能找到的教程或书籍并不太多。大家通常学习它的方法就是找一些设计系统的案例去分析。但这里有一个问题，所有这些设计系统对外开放的都是文档站点，它们都是按照工具书的逻辑来进行“平铺”呈现，重点在于方便大家查询使用，而不是教会大家如何自己动手创建。

所以，这一部分的内容我想换一个思路，将设计系统的各核心模块重新分类，拆解开。从一个用户的视角来进行讲解，尽可能让大家在读完这一整个板块的内容后，能够真正开始动手尝试构建自己的设计系统。

设计系统的 WWTF 原则

我们先暂时把设计系统这个概念放一边，想一想实际场景中用户是如何使用产品的。

绝大多数场景，特别是 toB 端，用户都是在不同的功能模块下与系统进行交互，完成一个个的任务。

一个好的产品需要时刻让用户清晰的了解自己在哪儿、需要干什么，并且高效的完成工作。所以这里先和大家介绍一个概念 – WWTF 原则：

Where am I？ / 我在哪儿？
What should I do？ / 我应该做什么？
Task / 我需要处理的任务。
Feedback / 处理的结果和反馈。

WWTF 是我们在构建 Fusion Design System 的时候定义的一个基本理论原则，目的是方便我们的业务设计团队在构建设计系统的过程中能够更好的理解产品设计过程中的核心要素。

在和业务设计团队合作的过程中我们发现，大家很容易一开始就将关注点放在样式、组件这些基础模块，不断的再揪着组件、规范，大家的关注点发生了偏移忽略了我们要解决的问题的本质。

基于 WWFT 原则，我们看待设计系统的角度就会发生变化。看似“平铺”堆砌在一起的这些资产就有了层次、重点，构建设计系统的思路也会变得清晰起来。

设计系统核心理论

整个设计系统理论的部分，我会将大家日常在文档站点中看到的那些内容整合成布局框架、系统组件、Pattern 模式、产品风格、页面模板五大部分来给大家进行讲解。这部分也是整个设计系统专题中最为重要的部分，我也会花比较多的篇幅来讲解。

设计系统学习指南 - 国内外 Design System 案例解析

Thu, 28 Mar 2024 16:34:56 +0000

TL;DR

国内外那么多 Design System（Ant Design、Material、CloudScape…），用同一套标准评价它们往往会得出"A 好 B 差"的偏颇结论。

真正的差异在层级定位：系统级、领域级、业务级各有各的使命。

本文提供一个分层视角，帮你看清不同设计系统的逻辑，少走"拿错标尺比较"的弯路。

设计系统这个话题近几年越来越受到大家的关注，国内有阿里集团的 Ant Design、Fusion Design，以及字节系的 Semi、Arco、腾讯的 TDesign；国外也有大家比较熟悉的 IBM Carbon Design、Salesforce Lightning Design，以及前段时间给大家介绍的 AWS CloudScape。

对于这些不同的设计系统，大家时常会有一些不一样的观点。比如有的同学认为 A 做得好，B 太过于简单，全是底层能力没啥用。

如何理解它们之间的差异，是我们学习过程中非常重要的一环。我们不能简单的从内容上去做比较，而是需要先从它们的定位出发。

设计系统的三个等级

从我个人的视角来看，我会倾向于将所有的设计系统分为是哪个不同等级系统级→领域级→业务级，大家可以用下面这张图看清楚它们的逻辑。从系统级到业务级，是对设计标准的抽象到具象，同时我们对设计的指引也是从基础认知转为更加具体的约束。

等级 1：系统级设计系统

系统级，顾名思义，就是操作系统级别的设计系统。当下的数字产品大部分是基于操作系统和浏览器所构建的，所以我们首先需要基于 OS 或浏览器级来开始工作。这里最常见的是 Google 的 Material Design、Apple 的 Human Interface Guideline 以及各种 Web 前端框架，比如 BootStrap。

配合硬件和软件技术的发展，系统级的设计系统为我们提供丰富的交互形式以及设计指引。同时它们也对用户的基础认知和使用习惯做出了定义和引导，确保了一个产品在基础交互层面的体验基准线。

其实我们也可以将它“简化”一下，将它们比作支付宝或微信的小程序就更容易理解了。支付宝和微信经过多年的运作累积了海量的用户和流量，于是很多的企业（或开发者）希望能够进驻到平台，为用户提供服务并获取响应的收益。

为了给用户带来一致、优质的服务和使用体验，支付宝和微信向企业（或开发者）提供一整套完整的设计指导原则和开发框架，也借此来帮助提升小程序的开发效率，降低产品的实现成本。而企业（或开发者）也会尽可能的去遵守它们的规则，以获得更好的业务上的合作扶持。

等级 2：领域级（行业级）设计系统

相较于系统级，领域级会更加聚焦于某一个领域或行业。比如 IBM 的 Carbon Design，阿里的 Fusion Design，蚂蚁的 Ant Design 以及字节的 Semi Design、Arco Design、腾讯的 TDesign。

如何向你的主管和团队介绍 Design System 的重要性

Thu, 07 Mar 2024 16:34:56 +0000

TL;DR

这是一份完整的「向主管和团队推行 Design System」的 PPT 分享内容，覆盖：为什么要做（外部环境变化）、阿里的真实实践案例、设计系统的三种层级、构建思路与三个阶段、以及设计师角色演变。

可以直接拿去给你的老板、团队同学讲清楚 Design System 的价值。

这是节前应邀进行了一次关于 Design System （设计系统）的“布道”分享。我将 PPT 内容进行了一些细化和调整，在这里分享给大家。大家在对内进行宣导的时候可以以此 PPT 为基础，给你的老板、团队同学讲解为什么要做设计系统。

这次分享也是对过往前面几期文章的一个不同视角的“串联”，从这个视角再来回顾这几篇文章相信大家会有更多不同的理解。欢迎大家有时间读完后来群里进一步一起探讨。

本次 Design System 分享 PPT 的内容定位

设计系统的理论和案例，相信大家在日常工作中已经看过不少，也不是本次的分享的重点。因此这份 PPT 不聊细节，而是基于这些年在设计系统、协同过程中的一些感受来给大家聊聊我是如何看待设计系统的。

为什么要做 Design System：价值与外部环境变化

Design System 的价值及重要性

外部环境的变化

互联网早已不是新鲜产物，我们生活的方方面面都已经逐步的互联网化。也正式因此，互联网公司也越来越受到国家政策、经济环境的影响，而身处互联网行业的设计师，我们工作也与之息息相关。

就近一年的观察，我觉得这三块变化和我们还是有很大的关联的，所以先拿出来和大家分享一下：

就像我们每个公司都有自己的目标，政府这个最大的平台也对近 5 年整个国家的数字经济发展有一个明确的目标。这四五十亿的预期增长目标的背后有大量的需求增加，显然依靠现有的生产模式是无法解决的；
今年大形势不太好，所有的企业都在做降本提效。降本很多团队都在做，但光降本还不够，提效同样也需要抓。我还在阿里的时候，你和人聊设计系统，人家没那么感冒。哦一下。你说这个东西可以提效，减少开发周期。那么大家眼前一亮，可以聊聊。
软件开源，也是十四五规划中非常重要的一点。如今的中美关系、国际形势使得大家的意识上越发的明确，国内企业、公司、政府不能长期依赖外部的产品和工具。开源是促进整体发展中非常重要的一环，互联网头部企业比如腾讯、字节、阿里都在其中承担着非常重要的带头作用。

一次关于 Design System 的调研

19 年的 Ucan，我做了一次关于设计系统的工作坊。大家都是带着好奇来参加的，真正在开展设计系统工作的团队并不多。而到了今年我做了一次调研，虽然有效样本只有 100 多个，但还是具备一些代表性的。大家可以看到无论是公司对设计系统的认知，还是投入的程度都有了非常大的变化。

表单设计的基础设计逻辑

Fri, 01 Mar 2024 16:34:56 +0000

TL;DR

表单看起来简单，但好的表单设计需要同时考虑三层：基础体验（组件/交互/反馈）、行业特性（金融严谨 vs 电商快捷）、业务特性（转化率/字段必要性）。

本系列提供一个由下至上的"通关"思考模型，帮你设计出真正好用的表单。

这篇表单设计的文章出自于4 年前 PinDesign 期刊中的文章。前段时间整理了一下旧文档，虽然时间有点久，但还是有不少内容的思路放到当前依旧有用，所以我会陆续修改一些过去的文章，重新更新在这里，希望对大家有帮助。

关于表单设计

如果从功能角度来划分，表单一定是互联网产品中最为重要的能力之一，它也是用户与产品之间进行交互的一个重要渠道。如果没有表单产品的体验将变得非常的被动，用户只能消费平台所提供的内容。

作为用户我们在日常会遇到各式不同的表单，我们会发自内心的喜欢某个产品的设计，也会因为一些糟糕的设计而吐槽。每一个组件都没有问题，但合在一起就是不好用。如果仔细分析，你会发现其实它并不是一个简单的设计问题，除了表单基础体验它还和所处行业、业务特性有着较大的关联。

如果从 Design System 的角度来看，这似乎又是一个很成熟的工作。输入框、单选、复选、日期、按钮…… 每一个组件都是用户所熟知的，它们是产品设计最底层、基础的元素，也完全有可以系统化的去沉淀。

为什么表单设计值得专门拆解

作为设计系统中讨论最多的部分之一，网络上有很多关于表单的设计资讯，但它们都有比较强的指向性。有一些更关注表单的交互，有一些则更关注表单的逻辑，但真正将它们融合在一起结合产品设计一起来讲述的并不太多（特别是针对移动端产品）。回过头来看自己这十几年的工作经历，互联网产品的方向和载体不断的在发生变化，但表单依旧还在那里，基础的交互形式也依旧是那些。

从表现上来看表单似乎很简单，即使是新入行的设计师也能很快的掌握基础的元素来搭建一个表单界面。但结合上业务的复杂度再来看待一个表单，它就变得不那么简单了。想要设计一个用户愿意填写且使用体验上还不赖的表单，除了设计本身，还需要我们结合产品、技术一起来思考。

此前已经写过几篇相关的文章，但出发点也是某个具象的角度，也不够系统化。在工作上近段时间里的一部分中心又开始回到到了表单的设计上，但在要求上需要更加的全面和系统化，这也让自己需要去重新梳理对它的思考。借这个机会也正好强迫自己将对思考系统的总结下来，也希望能在这个“课题”上带给大家实质性的帮助。

表单设计系列的完整内容框架

正如前面所言，表单复杂度在于除了设计自身，还与产品、技术有着较强的关联。所以这个系列会将这些因素整合在一起来进行讲解，大体上它会分成以下几大部分：

01. 理解设计表单的意义

如果将表单比作一个工具，那么我们将它比作 sketch。这个工具自身内置了很多基础元素的能力，每个人都可以用它做出不同的设计，但脱离业务场景单独去评价这个设计的好坏其实是没有意义的。一个明确的设计目标（产品目标）才是从设计上可以去尝试的方向，也是衡量它的一个直接标准。

在这部分内容中我们将站在一个商业产品设计的角度去将表单进行剥离，去分析在每一个层级中设计需要关注的核心本质是什么。也只有先将这个部分搞清楚，才能确保我们设计的表单是在当前情景下真正有效、易于使用的。

02. 表单基础设计规范

我们前面提到，表单是一个在产品设计中被大量使用的能力。正因为如此，它也非常有必要被“约束”起来。一套完整、有效的设计规范能够让我们在具体的界面设计中将关注点更多的放在业务诉求上，避免表单字段的规范带来对设计的干扰。

当然，表单的设计规范并不是只能一种。根据你的业务领域，它可以有更多不同的角度和形式去体现。这部分的核心是基于一个整体性的框架，以一个具象的领域为代表做一次案例的示范。希望大家最后得到不是这套表单的规范，而是如何去创建一套属于自己业务的表单规范。

03. 表单的设计实例

虽然我们可以通过基础元素随意的“组装”不同的表单，但在互联网产品的发展中它们已经形成了很多特定的使用场景，这也是我们在很多站点上能看到的实际案例。

如果只是简答的从表现层面来看，我们可能并不能去评判它的优劣，也不知道我们该如何去借鉴他们的思路。所以在这部分我们将以这些常用的场景（如注册登录、发布评论、搜索筛选等…）为案例从设计思路上来进行逐个的分析。这些可能也将是大家在日常工作中最为有用的部分，所以我们会用更多的篇幅来讲解这部分内容。

在产品设计中，表单是用来干什么的？

我们先来关注一个更宏观一些的问题。在一个产品中，表单是为了收集用户的信息（需求），再由系统做出一系列的处理返回展示给用户来满足用户的诉求。从表现上来看，它大多由一系列的输入框、选择框以及一组按钮所组成。

沿着这个思路往下走，作为设计师我们则会在一堆表单组件中打转，通过各种不同的组合来应对业务所提出的诉求。但这可能会让我们渐渐的忽略了这件事情的本质，我们究竟为什么要提供表单？

如果我们转化一下思路，将目光从做表单转移到用户身上，那么我们需要思考的问题则会转变成在当前场景下用户的需求是什么？

注册成为用户 – 想要获取会员才能查看的信息；
搜索关键词 & 筛选 – 想要快速获得所关注的信息；
填写地址信息 – 将货物准确的送到我需要的地方；
….

以上的几个案例，通常情况下我们都会用一个表单来处理，让用户自行录入。但大家仔细分析一下就会发现，注册、搜索、填地址这些操作并不是用户真正的目的，只是在产品设计上比较“粗暴”的解决方法之一。

如果我们接入更为通用的第三方登录，用户只需要几次点击就可以他所感兴趣的信息；
如果我们允许用户保存自定义搜索条件（请参看 ebay），用户只需要一次设置，后续再无烦扰；
如果我们提供当前位置定位和识别，用户将大幅减少信息输入，快速完成信息的录入。

如果我们更多的去关心用户填写表单的目的，那么可能有很多的表单都不应该出现在用户的面前，因为表单也只不过是解决问题的方法之一。

我们曾经在 109 期的文章中曾提到过，用户放弃完成某个页面有很大的比例是由于复杂、冗长的表单。对于用户来说，表单其实是一种“麻烦”，特别是对于移动设备来说，输入信息是一件极大影响用户使用心情的事情。

所以站在整个产品的角度来看，原则上我们尽可能减少向用户提供表单。每当出现一个表单，我们都需要问问自己这是不是一定需要通过表单来处理。如果可以从产品角度来进行规避，那么我们应该更多的去思考如何通过产品功能规划来解决；如果实在不行，我们在来考虑如何设计一个表单，并在这个过程中不断的思考其必要性（字段）、易用性及设计的表现力。

表单遇到了哪些问题？

之前我们讨论这个话题更多是站在使用者（用户）的视角，但如果换到一个表单系统的角度，表单最终的使用者和设计它的设计师都是我们的用户。所以这里我们也将从这两个不同的视角来看看我们会遇到哪些问题。

对于使用者（用户）：

对于最终使用表单的用户而言，表单最重要的问题就是具有较大的心理成本和操作成本，影响的是最终的完成率。本质上来说，在目前的环境下我们还无法消灭表单，只能说站在整个产品的角度来思考如何让用户更容易的获得 Ta 所需要的资讯。

设计系统在 PPT 领域的应用

Fri, 16 Dec 2022 16:34:56 +0000

TL;DR

设计系统不只是 toB/中后台的专利。

iA Presenter、Paste 等新一代 PPT 工具正在用"设计系统"的理念改造这个领域：用结构化约束代替自由画布，让用户专注于信息组织而不是视觉细节。

本文拆解这些工具的设计思路，以及设计系统理念在非 toB 领域的更多可能。

设计系统一直以来应用最多的领域还是在 toB 端，让很多人误认为设计系统 = 中后台设计。我们之前聊到过，设计系统实际上是对设计的抽象和约束，toB 端只是因为其场景在当下更容易达成一致，但不代表只有它可以做到。其他的领域只要能对规则进行抽象和定义，设计系统同样是成立的。

最近一直在关注 PPT 工具领域，试用了一些新理念的产品，比如 iA Presenter 、Paste。相较于“古典”的 PowerPoint 和 Keynote，这些工具都在试图用新的思路和能力来改变这个“万年不变”的工具领域，这其中就涉及到设计系统以及在线设计。所以这一期的文章，我想结合这些案例从产品和设计的角度和大家聊一聊在其他领域设计系统的实际应用。

PPT 工具市场分析

自从进入电脑办公时代，做 PPT 的工具几乎都选择微软的 PowerPoint，加上近十年苹果电脑普及后所引入的 Keynote，PPT 工具市场基本上已被这两家所垄断。想要在这个领域做一些商业探索，只有付费模板和付费制作两条路。

先来说说 PPT 模板，这也已经是一个非常古老的模式了。从国内到国外，大家可以在网络上找到非常多各式各样的免费模板。如果你愿意付点钱，那你还可以买到很多更加精美的内容。

比如下面这套来自 Creativemarket 的模板，花费 19 美元你可以获得 100 张不同样的模板，并且包含 Light & Drak 两种模式，2,000 多个 icon。

看上去似乎不错，拿来改改也能获得一个还不错的 PPT。但事实并非如此，它依旧有着不低的操作成本，普通用户难以驾驭。

自己不会做，但又想要一个好看的 PPT，那就只能“求助于人”了。低至 10 元淘宝上的低端设计服务，高至数万元的专业设计服务，PPT 制作市场一直有着不小的需求。整个市场我无法统计，但就之前在集团收口的制作需求这个切片来看，这个市场还是相当可观的。

几乎每个人都会需要做 PPT，在这个基数面前买模板和买设计的依旧只是很小一部分，绝大部分的人还是需要回归到工具，继续使用 PowerPoint、Keynote 磕磕绊绊的做 PPT。

PPT 工具有什么问题？

Figma 在去年的设计系统大会上曾提出过一个概念： Freefrom Design vs Structured Design，也就是自由式设计和结构化设计。

成为架构型设计师

Thu, 14 Jul 2022 16:34:56 +0000

设计师是我的第一份工作。从 2003 年毕业后的第一份工作在一家网络公司，从界面设计到 Flash 动画再到跑客户、贩卖 3721 网络实名，几乎和网络建站相关的工作全都得做，当然，那个时候对设计的要求并没有那么高，我们都被称之为美工。

一晃快 20 年过去了，伴随着中国互联网行业的高速发展越来越多优秀的人才进入到设计领域，设计已经成为一个非常有深度专业工种，设计师也已经成为互联网企业最为重要的专业力量之一。

上一期的文章里，我们在设计系统的话题中聊到通过「规范沉淀」「物料管理」「场景消费」三个方面来优化在产设研（产品、设计、研发）环节的工作模式，也提及了一个新的、也是非常重要的角色 – 架构型设计师。关于这个新的角色，上周分别与两位会员读者在设计团队能力建设的话题中也多次聊到。所以这一期我想正好顺着话题和大家聊聊什么是架构型设计师，以及如何成为架构型设计师。

TL;DR

架构型设计师不直接画界面，而是通过构建设计系统、管理设计资产、推动设计运营，让整个团队的设计产出标准化、规模化。这是设计系统时代设计师最重要的新职业方向。本文系统介绍架构型设计师的职责、素质要求、以及和「产品型设计师」的分工边界。

设计师 Job Title 的变迁

交互设计师 & 视觉设计师 ➔ 体验设计师 & 创意设计师

2008 年加入阿里时，设计团队内将设计师主要分为交互设计师和视觉设计师两类。交互设计师负责与产品一起实现承接商业需求、制作产品原型，再交由视觉设计师进行设计稿的最终输出并交付给开发工程师。

这样的分工一直延续到了 2015 年左右，阿里开始逐步对设计师的 Job Title 进行调整，由原来的交互设计师和视觉设计师调整为了体验设计师和创意设计师，并在 2017 年基本完成了全集团设计团队的调整。

相较于之前交互 & 视觉的定位，体验设计师在原有交互能力基础之上增加了对视觉、商业意识、用研等综合能力的要求，期望能够培养更加一专多能的设计师。这个变化在当年其实让很多设计师感觉到有些“难受”，特别是一些视觉、交互能力均较平的同学来说，对于未来的职业发展方向迎来了第一个较大的困惑和挑战。

不过在我看来这个调整是合理的，也是必然会发生的。互联网在发生着巨大且快速的变化，这也势必导致设计师的工作流程发生变化，以前的工作模式已经已经无法跟上业务的高速发展。到如今时间已经过去了 6、7 年，这种“不适感”在设计行业内已经慢慢消失了，两个新的岗位角色逐步进入正轨，找到了各自的发展方向也延展出了很多新的领域细分能力。

架构型设计师 & 产品型设计师

时间推移到 2018 年，我终于筹建了阿里集团的设计中台团队，为各业务设计团队提供设计过程中的工具及能力服务。在与大家的合作过程中，我发现一些自然而然在发生的变化，业务线的一些设计师已经开始逐步跳出原有岗位的定位，以更加综合、系统化的方式进行思考和工作推进，这个时候已经出现了一些“架构”的雏形了。

在思考并参与了一段时间后我向设计委员会做了一次汇报，尝试提出新增架构型设计师这个新的岗位。可惜的是在当时无论是团队建设还是整体的环境还不够成熟，这个提议并未通过，所以只能暂时的放一放。

不过这倒是不影响我自己继续去尝试，在接下来的日子里我在负责的四个业务中进行了一番调整，为每个业务团队增加了一个架构型设计师的岗位，开始将我之前对设计系统的思考付诸于尝试。虽然这个新增的岗位也是在大家不断的摸索、试错中前行，但新的工作模式为大家打开了新的思路，也带来了非常多正向的结果产生。

什么是架构型设计师

一提到架构这个词，大家很容易就联想到软件开发领域，设计领域也会有吗？过去这个概念可能与设计无关，但现在乃至未来它一定是存在的。当然，我们大家目前在这个领域都还是在边摸索边做，还达不到架构师的程度，所以我会先称它为架构型设计师。

和大家聊起这个话题时，我发现有些设计师会将这个角色理解为专业型的 Leader，精于设计、懂用研、能做好项目管理，也能够在专业角度上带团队。这种从能力项的定义的视角我认为还是在过往的思维模式里，不太准确。

「设计」作为业务生产中的一个技术工种，它在保障专业能力不断精进的同时，还需要确保业务生产的有效性和确定性，从业务视角去看团队的整体作战能力及专业能力的先进性。

基于以上这些背景信息，我会这样定义架构型设计师：

架构型设计师是设计团队专业能力的推动者，基于公司业务发展规划并构建精深的专业能力及高效的协作模式，协助设计团队为业务生产提供高质高效的设计专业能力。

架构型设计师不一定是团队管理者，Ta 会将更多的精力放在专业能力建设而不是人事工作；架构型设计师也不一定是一个人，Ta 可能是一个独立团队或是几位设计师组成的虚拟小组。

架构型设计师的职责

之前的专栏文中中我给大家画了这么一张图。我将它 zoom out 一下放到整个业务的生产流程中，架构型设计师的工作就围绕在这设计的前、中、后环节来开展。

在整个业务生产流程中，架构型设计师的核心工作主要会围绕以下三层来进行：

设计模式库与设计组件库到底有什么区别？

Thu, 14 Jul 2022 16:34:56 +0000

TL;DR

设计组件库（Components）像做菜的单个步骤（切菜、焯水、炒制），是解决单点操作的工具；设计模式库（Patterns）则是把这些步骤组合起来完成"做一道小龙虾"的完整方案。

组件提供基础能力，模式提供业务解法，两者缺一不可。

设计系统（Design System）中有两个重要的概念，设计系统和设计模式。对于这两者之间的区别，很多人都比较困惑。其实用一个例子就能很好的解释，比如大家都喜爱的小龙虾 🦞。

用一个例子来解释

小龙虾好吃，但真做起来并不是所有人都会。不过你可以在各类美食应用上看到它的「制作 SOP」，大致会有以下这些步骤

制作小龙虾 SOP：

去虾线
清洗小龙虾
准备小料
下龙虾过油
加入小龙虾调料翻炒
加入啤酒闷煮
.…

你不一定懂小龙虾的制作方法，但刷个小龙虾一听就能明白，把这些步骤组合在一起，你也能做出一盘色香味俱全的小龙虾了。

设计系统中的 SOP：

在设计系统中，每个组件就像 SOP 中的某个步骤，是解决某一个具体操作的方法，而将这些组件组合起来处理一件事情或任务，就是我们所理解的 Pattern 模式库。

所以，洗小龙虾、过油它们都是“组件”，做小龙虾是“模式”。

如果十三香小龙虾已经成为一个行业标准，大家做得基本完全一个样，那么小龙虾也可以被进一步的收敛，成为你做晚餐的一个标准“组件”了。

当然，如果你家的小龙虾和别人有些差异，比如重甜、重辣、或者说是三分熟（😁），那它的做法就具备较强的特色，成为你的业务级设计模式了。

设计系统延展阅读

💡 延伸阅读：

推行话术：如何向你的主管和团队介绍 Design System 的重要性

深度案例：如何规划 B端设计系统？深度解析 AWS CloudScape

学习路径：设计系统学习指南 - 国内外 Design System 案例解析

决策机制：设计系统中的决策树：让设计决策更简单

设计系统 · Design System 应该做到什么程度才够？

Fri, 08 Jul 2022 16:34:56 +0000

在上一期的文章里，我们从「业务」和「经营」两个视角讲解了为什么要做设计系统。相信大家对于设计系统的意义已经非常清楚了，但在自己的团队里，设计系统究竟要做到什么程度才算 OK ？这是文章发出后大家会提到最多的一个问题。

每个团队规模、业务进展都不一样，都以同样的标准进行设计系统建设的确是不切实际的。设计系统是一个长期、持续性的工作，一次性到位肯定是不可能的，所以这次的文章我们就来聊一聊设计系统的三个不同阶段，以及我们应该在何时进入、如何定义阶段目标。

开始之前，我们先简单回顾一下上一期文章里的几个关键信息:

设计系统的三种类型：

系统级：操作系统级别的设计系统，提供最底层操作系统级的设计及研发指引；
领域级：聚焦于某一类通用场景的设计及研发指引，当前最为成熟的还是在企业级应用（B 端）场景；
业务级：基于系统级或领域级的二次加工定义，为具体的产品或业务提供设计及研发指引。

做设计系统的目的：

提升业务生产效率。当下互联网红利逐步消失，业务生产的模式需要发生改变，来帮助企业留着利润
回归业务本质问题。逐步抽象封装业务模块，让产品回归业务逻辑本身；
统一“业务语言”。建立包含业务、产品、设计、技术的共同业务语言，提升团队沟通效率；
提升体验一致性。让设计系统团队专注于系统本身，优化并统一用户使用体验，降低用户使用成本；
更先进的协作模式。通过设计系统的引入，优化业务生产环节中生产协作模式；
提升团队战斗力。帮助新加入成员或生态合作伙伴更快的融入，提升整体生产力。

延展阅读：

节选自专栏 OFF DESIGN #02: 设计系统应该做成什么样子

设计系统 · 我们为什么要做 Design System

Tue, 14 Jun 2022 16:34:56 +0000

TL;DR

设计系统不是"画规范"，而是用系统化方式解决业务效率、体验一致性、团队协作三大痛点。

它的本质是把设计从"手艺"升级为"可复用的资产"。

本文结合我在阿里搭建 Fusion Design 的经验，回答为什么每个认真做数字产品的团队，都应该拥有自己的设计系统。

为什么现在是讨论设计系统的最佳时机

2018 年的 10 月，我在专栏里发布了第一篇关于设计系统的文章。那是我在阿里建立设计中台部门的第一个季度，作为部门三大重要方向之一，我们已经用 Fusion Design 支撑了集团内（除蚂蚁）几乎所有的 B 端产品。

2019 年的夏天，我在 Alibaba UCAN（现更名 U Design Week）做了一次关于设计系统的工作坊，和来自不同公司的设计师朋友们一起聊了 3 个多小时。那个时候已经有不少的小伙伴开始思考如何借助设计系统的体系化思维来进行设计交付。

那个阶段大家大多都还处在理论和实践摸索期，更多的还是站在体验一致性的角度来思考如何构建设计系统。而当年专栏的差不多二十篇文章也更多是从工具书的视角，再带上一些公司里实践的经验给大家介绍设计系统。

时间一晃快 4 年，环境在发生变化，我们对于设计的理解也在发生变化，这本“工具书”也是时候该进行升级了。前段时间在读者群里做了一次调研，发现很多公司对于设计系统的关注和投入都在明显的变化。

近 70% 的设计师所在团队都已经完成或正在建设设计系统，40% 团队由设计师和前端工程师共同参与；

90% 多的公司期望通过设计系统来提升整体的设计研发效能。

从阿里离职以后也不想再找一家公司继续两点一线的生活了，希望还是能够多一些闲暇时光体验不一样的生活。想了想继续码字还是最适合我当下的状态，同时也能将这些年在阿里工作的经验和思考分享给大家，而「设计系统的构建与应用」就是这其中的重要板块之一。

这个设计系统系列将覆盖的内容

在设计系统调研问卷的最后我留了一个开放问题给大家，想看看对于设计系统还有什么疑问。

设计系统的完整体系是怎样的？

如何面向行业、业务去定义设计系统？

设计系统需要做到什么程度？覆盖多少业务体量才算够？

什么样体量的团队需要设计系统？不同类型的公司做设计系统有没有什么差别？

如何看待设计系统的约束与创新诉求？

如果跨团队达成设计的共识？

如何衡量设计系统的价值？

市面上这么多开源设计系统，他们的差别是什么？

如何确保设计系统的落地？有没有具体的流程和方法？

设计系统启动之前有多的想法和思路，但在构建过程中出入又很多，有哪些道与术可以借鉴？

如何验证你所设计构建的系统就是当前最有效的方式？

通过以上内容你会发现大家不再是盯着规范如何制定、文档怎么写等相对具象的问题，而是更多的站在设计工程、业务价值、跨团队协作等更深入的角度进行思考。而这些，也是近几年我在集团内各业务做实施中感受最深的地方。

所以，这次设计系统专栏的重启我会先花一些篇幅和大家聊聊在阿里做设计系统的故事，聊聊背后的一些思考和决策逻辑。我们大家先在“基础土壤”上做到信息对齐，这样我们后面的讨论也会更加顺畅。

整个「设计系统的构建与应用」专栏我会主要围绕以下几个部分来写：

设计系统背后的思考
创建设计系统流程工具书
设计系统案例解析 & 应用案例解析
Design Pattern 案例解析
设计系统对协作模式的影响以及面向未来的思考

专栏的第一期，我们将先从 Why 开始，聊一聊为什么要建立设计系统。

设计系统 · 2022 Design System 调研总结

Sat, 21 May 2022 16:34:56 +0000

TL;DR

2022 年面向 80+ 设计师的 Design System 团队现状调研：近 70% 的团队已开始或正在建设设计系统，40% 团队由设计师和前端工程师共同参与；90% 多的公司期望通过设计系统提升设计研发效能。

但只有少数团队设有专职的设计系统架构设计师。

前段时间在群里针对设计系统 Design System 的建设和应用拉了个群并做了一个小调查。回收了 80 多份，不多但也足够反映大致的现状。理了理也给大家做一个分享。

本文出自专栏 OFF DESIGN 免费内容

2022 设计系统调研背景与样本

本次调研主要面向我个人专栏的设计师读者群体，通过微信群发起。共回收有效问卷 80+ 份，受访者主要为国内互联网行业的设计师、前端工程师及部分产品经理。

虽然样本量有限，但人群相对集中，对了解一线团队的设计系统建设现状仍有较强参考价值。下文将分 7 个维度展开数据。

关于 Design System 主要调研结论

01. 您所在团队是否已开始设计系统（Design System）相关工作

02. 您所在团队参与设计系统（Design System）建设的主要成员

03. 您所在团队设计系统（Design System）的使用情况是

04. 公司对设计系统（Design System）的期望是

05. 您所在团队是否有专职的设计系统架构设计师

06. 对于设计系统（Design System）的建设，您最希望了解的是

07. 设计系统（Design System）的开放性问题

总结了一下大概是以下这些方面：

设计系统的完整体系是怎样的？
如何面向行业、业务去定义设计系统？
设计系统需要做到什么程度？覆盖多少业务体量才算够？
什么样体量的团队需要设计系统？不同类型的公司做设计系统有没有什么差别？
如何看待设计系统的约束与创新诉求？
如果跨团队达成设计的共识？
如何衡量设计系统的价值？
市面上这么多开源设计系统，他们的差别是什么？
如何确保设计系统的落地？有没有具体的流程和方法？
设计系统启动之前有多的想法和思路，但在构建过程中出入又很多，有哪些道与术可以借鉴？
如何验证你所设计构建的系统就是当前最有效的方式？

总结：2022 调研反映的设计系统趋势

从这 80+ 份问卷中我们可以看到几个明显的趋势：