设计模式 on Hi, I'm 5key

从概念到落地，产品界面的 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端设计的首要任务是让用户能够以最低的认知负担完成复杂的工作任务，从而提升整个业务系统的工作效率和生产力。

设计系统学习指南 - 国内外 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。

成为架构型设计师

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 案例解析

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