# Hi, I'm 5key · 全文档案
> 这是 Hi, I'm 5key 的**全文合集**（llms-full.txt），方便 LLM 一次性读取全部内容。
> 索引版本（带文章列表、无全文）：https://www.thefivekey.com/llms.txt
> 单篇 Markdown 原文：在任意文章 URL 末尾加 `.md` 或 `/index.md`
**作者**：5key
**网站**：https://www.thefivekey.com/
**简介**：深入探索设计系统、UX 设计与产品管理。二十多年互联网产品和设计经验，现在用商业视角重新理解设计。
**最后更新**：2026-08-10
**文章总数**：43 篇
---
================================================================
# Google DESIGN.md 实践：把设计系统写成 AI 能读的 Markdown
- **发布日期**：2026-04-19
- **原文链接**：https://www.thefivekey.com/design-system-as-markdown/
- **Markdown 原文**：https://www.thefivekey.com/design-system-as-markdown/index.md
- **标签**：设计系统, 设计 AI, AI Coding, DESIGN.md
> Google 提出的 DESIGN.md 让设计系统第一次以 AI 能读懂的形式进入代码仓库。本文从 Claude Code 做产品时的一致性失控问题出发，讲解如何把设计系统拆解为 Foundation / Component / Pattern 三层 Markdown 文档体系，让 AI 每次 Coding 都遵循你的设计约束。
> **TL;DR**
>
> 用 AI Coding 做产品时最大的问题不是「AI 不会用组件」，而是「AI 不知道什么时候不该用」。
>
> Google 的 DESIGN.md 给出了一个轻量方案：把设计系统写成 Markdown 放进代码仓库，让 AI 每次 Coding 都能读到设计约束。
## 篇首语
最近这段时间，我一直在用 Claude Code 做一个数据分析系统。
最开始启动的时候，整体的体验还是非常不错的。我只需要写好需求描述文档，准备好各种 API，Claude 很快就能交付一个质量相当不错的结果。
指定好 React + Tailwind + [Shadcn](https://ui.shadcn.com/) 的技术栈，再配合上 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](https://docs.claude.com/en/docs/claude-code/memory) 等启动加载规则，AI 每次生成界面前都会先读一遍这份设计规范，按其中的 Do's and Don'ts 来生成代码，这是设计系统在 AI Agent 时代的一个轻量落地方案。
> 📖 官方出处：DESIGN.md 由 Google 在 [Stitch 官方文档](https://stitch.withgoogle.com/docs/design-md/overview) 中提出，作为 Stitch 项目中定义设计系统的标准方式。
## AI Coding 的一致性为什么难以保证
拿下面这张图来举个例子。这是我在同一个项目下、不同阶段开发的两个功能界面。
菜单、Tab、输入框的样式，在两次 Coding 中出现了明显的不一致。照理说，在同一个项目、同一套技术栈下，不应该出现这种问题。但事实上它不仅出现了，而且随着页面越来越多，这类问题开始陷入了反复纠正，依旧出错的"死循环"。
为什么会这样？我总结了三个原因。
**第一，跨会话的记忆丢失。**
虽然现在 Claude Opus 可以用上 1M 的长上下文来工作，但它终归是有上限的。一个完整的项目则需要很多个 session 来接力，跨 session 势必会造成信息的丢失。
我们可以让 Claude 自己总结当前阶段的记忆并更新到约束文件里，但这种方式并不结构化，也不够确定性。它非常依赖我们对上下文约束的把控能力，同时还会搞得每次新对话要加载的内容不断膨胀。
**第二，AI 会自己假设。**
Claude 的幻觉控制算是做得不错的了，但它始终还是存在。虽然我们已经指定了使用 Shadcn 的组件库来构建页面，但它有些时候还是会跳过我们的约束，自己去写一些组件或修改一些布局排版等设定。
**第三，AI 无法理解设计意图。**
组件库的文档告诉了 AI「这个组件是什么」和「怎么用」，但没有告诉它「什么时候该用」和「为什么用这个而不是那个」。
说白了，Shadcn 的文档是写给开发者的 API 参考，不是写给 AI 的设计决策指南。但一到具体的业务场景里，该用哪个组件、不该用哪个、几个组件之间怎么配合，这些问题组件文档里都没有标准的答案，AI 只能自己猜，结果就是整个产品中存在大量的不一致。
在这里第三个问题其实才是根源的。即使 AI 有无限记忆、零幻觉，只要它不理解你的设计意图，做出来的界面就不会是你想要的。
这个问题的本质，其实和我们在 OpenClaw 中遇到的是一样的。如何用结构化的上下文来约束 AI 的行为。想要靠一套组件库文档就让 AI 按照我们的要求来构建产品，显然是不太够的。
按照配置 OpenClaw 的经验，我的第一反应就是自己来补一些文档做约束，把缺失的设计决策写进去，让 AI 按照这些规则来做。
也正是在这个过程中，突然发现 Google 提出了一个叫 DESIGN.md 的方案。用一个 markdown 文档来告诉 AI 在 Coding 界面的时候该遵循哪些设计约束。这正好是我想要的。
## 把设计规范变成 AI 的上下文
设计文档规范这件事本身不新鲜，每个设计师多少都在设计系统中做过相关的工作。但 Google 的 DESIGN.md，做的事情稍有不同。它不是给设计师看的设计规范，而是把设计规范写成 markdown，直接放进代码仓库，让 AI 在 Coding 的时候能读到。
说白了，就是把设计约束变成了 AI 的上下文。
来看看官方的基础案例：
```markdown
# Design System
## Overview
A focused, minimal dark interface for a developer productivity tool.
Clean lines, low visual noise, high information density.
## Colors
- **Primary** (#2665fd): CTAs, active states, key interactive elements
- **Secondary** (#475569): Supporting UI, chips, secondary actions
- **Surface** (#0b1326): Page backgrounds
- **On-surface** (#dae2fd): Primary text on dark backgrounds
- **Error** (#ffb4ab): Validation errors, destructive actions
## Typography
- **Headlines**: Inter, semi-bold
- **Body**: Inter, regular, 14–16px
- **Labels**: Inter, medium, 12px, uppercase for section headers
## Components
- **Buttons**: Rounded (8px), primary uses brand blue fill
- **Inputs**: 1px border, subtle surface-variant background
- **Cards**: No elevation, relies on border and background contrast
## Do's and Don'ts
- Do use the primary color sparingly, only for the most important action
- Don't mix rounded and sharp corners in the same view
- Do maintain 4:1 contrast ratio for all text
```
这个案例看上去很简单，但它其实做了几件关键的事情：风格定调、色彩定义、字体排版、组件基础设定，以及 Do's and Don'ts。
最后这一项对 AI Coding 来说尤为重要，而且 Don't 比 Do 更为重要。前面我们分析过，AI 最大的问题不是不会用组件，而是不知道什么时候不该用。Don't 就是在帮 AI 划出边界。
有了 DESIGN.md 之后，我们只需要在项目 CLAUDE.md 中进行强制加载。
> 启动加载（强制）
> 在执行任何任务之前，必须先确认已加载以下三个文件。如果当前对话中尚未读取，先读取再行动。
> - DOMAIN.md — 项目背景、内容地图、文件路由
> - CONSTRAINTS.md — 硬约束清单
> - DESIGN.md — Coding 中强制执行约束
这样 AI 每次执行 Coding 工作前，都会先读一遍这份设计规范，按照设定来进行生成工作。
这里也顺便澄清一下，DESIGN.md 和仓库里常见的几个 Markdown 文档有什么区别：
| 文件 | 面向对象 | 内容重点 | 读取时机 |
|---|---|---|---|
| README.md | 人类开发者 | 项目介绍、安装运行 | 新人上手时 |
| CLAUDE.md | AI 编码助手 | 指令、角色、加载规则 | 每次会话启动 |
| DESIGN.md | AI 编码助手 | 设计决策、组件规则、Do's and Don'ts | 每次 Coding 前 |
简单讲：README 告诉人怎么跑项目，CLAUDE.md 告诉 AI 该加载什么、怎么工作，DESIGN.md 告诉 AI 该按什么设计约束来生成界面。三者互补，不替代。
这个思路很快就火了，GitHub 上还有出现了一个开源项目，专门整理了各大知名产品平台的的 DESIGN.md 案例，可以直接复制到自己的项目中来使用。
内容很多很详细，这里我就不复述了，大家可以直接去看看。[https://github.com/VoltAgent/awesome-design-md](https://github.com/VoltAgent/awesome-design-md)
其实到这一步，DESIGN.md 已经让 AI Coding 进步很多了，至少界面风格上的一致性有了保障。但如果你真的拿它来做一个完整的产品，你会发现它其实还不够。
## 完整设计系统的 Markdown 化
从最早在 Yahoo 参与 DPL（Design Pattern Library），到后来在阿里主导 Fusion Design，我做设计系统已经十多年了。按照我自己一贯对设计系统的定义，DESIGN.md 其实只做了 Foundation 层的工作，关注色彩风格、字体排版等基础设置。但一个真正能用的设计系统，Component 层和 Pattern 层的定义是必不可少的。（关于设计系统的三个层级，可以参考 [设计系统学习指南 - 国内外 Design System 案例解析](/how-to-learn-from-other-design-systems/) 和 [如何规划 B端 设计系统？深度解析 AWS CloudScape](/b-end-design-system-deep-dive-aws-cloudscape/) 这两篇）
开始如果让我自己手动去对每个组件和 Pattern 写一份文档，这事儿我着实不太相干。于是我干脆直接把 Shadcn 的组件文档扔给了 Opus，想让它面向 AI 使用的视角先来帮我整理个基础版本，我再来逐条优化。
结果有点意思，效果比我预想的要好。
Shadcn 的官方文档详细解释了每个组件的参数配置，但缺少「什么时候用」的说明。所以每次调试的时候我都会把文档链接扔给 AI，让它读完再动手。浪费时间也浪费 token。
但由于我在项目的上下文初始化中写了很多的 Do 和 Don't，Claude 可能识别到了我的这个习惯，于是在扫描生成文档的过程中，也加上了对 Do 和 Don't 的定义，指定了什么场景该用这个组件，什么场景不该用。这其实正好补上了我们前面说的那个缺口。
摘取一下 Alert 组件的文档内容：
```markdown
# Alert
页面内静态提示信息，用于引起用户注意。
层级: Component | 来源: shadcn/ui
## 何时使用
- 展示重要的上下文提示（警告、错误、信息）
- 页面内持久显示的通知
## 何时不用
- 临时性通知 → 用 Sonner（Toast）
- 需要用户确认的阻断提示 → 用 Alert Dialog
## 常见组合
- 配合 lucide-react 图标增强视觉提示
- 表单顶部展示全局校验错误
```
我把 Claude 生成的 50 多个组件的文档都大致看了一下，质量都还不错，稍微修改一下基本就可以直接使用了。
有了这个说明文档之后，AI 在 Coding 时对组件的使用明显改善了不少。再配合上 Shadcn 自带的 Skill，基本上组件层面的问题就不大了。
既然组件的文档梳理工作做得还不错，那 Pattern 是不是也可以交给它试试？
这次 Claude 帮我整理了 30 多个 Pattern，分成了三个类别：交互流程（Flows）、功能区块（Blocks）、页面模板（Pages），基本能覆盖大部分常见的产品场景了。
再来摘取一个「删除确认流」的 Pattern 文档内容来看看：
```markdown
# 删除确认流
触发删除操作后，通过 AlertDialog 二次确认，执行后以 Toast 反馈结果。
## 适用场景
- 删除数据记录（用户、项目、文件等不可撤销的实体删除）
- 注销账户、清空数据等高风险破坏性操作
## 不适用场景
- 可撤销的软删除或归档操作（-> 直接执行 + undo toast）
- 非破坏性的普通确认（-> Dialog 即可）
## 交互规则
- 高危操作须二次输入确认
- 确认按钮文案必须明确为「删除」，不得使用「确认」「是」等模糊表述
- 确认按钮使用 destructive 变体
- 执行中禁用所有按钮并显示 Spinner
- 对话框关闭时重置输入状态
```
质量也还不错，使用/不使用场景以及对应的一些交互原则，文档里都考虑到了。
我们接下来就是按照实际的产品需求去调整。看看哪些 Pattern 要合并，哪些规则要加严，哪些场景要补充。
这里还有个有意思的做法。如果你觉得别人设计系统中的某个 Pattern 特别好，也想引用进来，可以直接发送给 AI 让它来帮你提炼沉淀到自己的体系中。
比如我觉得 [CloudScape Design System](https://cloudscape.design/) 中的 Announcing New Features 这个 Pattern 就很不错，把文档链接发给 Claude，它很快就按照我的逻辑完成了转化，同时还自动将 CloudScape 的组件映射到了 Shadcn：
| Cloudscape 组件 | shadcn/ui 映射 |
|---|---|
| Flashbar（全局横幅） | Alert |
| "New" label + Popover（导航） | Badge + Popover（在 Sidebar 中） |
| "-new" 后缀标签（页面内） | Badge |
最终完整的 DESIGN 目录长这样：
```
DESIGN/ # 设计系统根目录（90 个文件）
├── index.md # 组件系统总索引 + 选型速查
│
├── components/ # 基础组件文档（59 个）
│ ├── accordion.md # 可折叠内容面板组
│ ├── alert.md # 静态提示信息
│ ├── alert-dialog.md # 确认对话框（阻断式）
│ ├── aspect-ratio.md # 固定宽高比容器
│ ├── avatar.md # 用户头像
│ ├── badge.md # 状态标签/徽章
│ ├── breadcrumb.md # 面包屑路径导航
│ ├── button.md # 按钮
│ ├── button-group.md # 按钮组容器
│ ├── calendar.md # 日期选择日历
│ ├── card.md # 容器卡片
│ ├── carousel.md # 轮播
│ ├── chart.md # 图表（Recharts）
│ ├── checkbox.md # 复选框
│ ├── ...
│
└── patterns/ # 组件组合模式（30 个）
├── index.md # Pattern 总索引 + 场景速查
│
├── flows/ # 交互流程（12 个）
│ ├── add-info-full-page.md # 完整页面添加
│ ├── add-info-inline-dialog.md # 浮层简单添加
│ ├── announcing-new-features.md # 新功能公告（3 种变体）
│ ├── bulk-action.md # 批量操作
│ ├── delete-confirm.md # 删除确认流
│ ├── info-expansion-center-overlay.md # 中间浮层扩展
│ ├── info-expansion-side-panel.md # 右侧浮层扩展
│ ├── inline-edit.md # 行内编辑
│ ├── multi-step.md # 多步骤引导
│ ├── notification.md # 站内通知
│ ├── ...
│
├── blocks/ # 功能区块（10 个）
│ ├── command-palette.md # 全局命令面板（⌘K）
│ ├── data-table-block.md # CRUD 数据表格
│ ├── detail-header.md # 详情页头部
│ ├── empty-state.md # 空状态
│ ├── filter-bar.md # 筛选条件栏
│ ├── form-section.md # 表单分区
│ ├── loading-state.md # 加载状态
│ ├── ...
│
└── pages/ # 页面模板（7 个）
├── dashboard-page.md # 数据仪表盘
├── detail-page.md # 详情查看页
├── error-page.md # 错误页（404/500/403）
├── form-page.md # 独立表单页
├── list-page.md # 列表管理页
├── ...
```
到这里，整套体系就搭完了。在 CLAUDE.md 中设定好加载规则之后，AI 每次接到 Coding 任务都会自动读取 DESIGN/ 下的文档，根据需求场景找到对应的 Pattern 和组件定义，再结合 Shadcn 的 Skill 去构建页面。整个过程不需要我再额外解释该用什么组件、该怎么交互了。
从 Foundation 到 Component 再到 Pattern，三个层面补齐之后，我又根据自己数据分析系统的实际需求，补充了一些业务级的组件、Pattern 和页面模板，比如数据源配置流、指标卡片的交互规则、分析报告页的布局模板。这些是 Shadcn 和通用设计系统里不会有的，属于我自己产品的个性化定义。
有了这套东西之后，后续让 AI 帮我构建的新功能，在界面层面基本就没有太多问题了。如果有想调整的地方，也不用改代码，直接去 DESIGN/ 目录下修改对应的文档就能完成全局调整。
## 写在最后：设计系统 AI 化的轻量方案
之前聊设计系统 AI 化的时候，总觉得让 AI 真正消费设计系统是一件挺重的事情。
可能需要专门的工具链，可能需要复杂的接口对接。但如今再来看这个问题，一套 markdown 上下文文档体系，可能就是一个相当不错的轻量解决方案了。它不一定是最终的答案，但一定是当下一个值得尝试的方向。
而且现在开源的组件库生态已经非常成熟了。像 Shadcn 这类项目，对数字产品常见的基础组件穷举已经相当完善，给了我们一个很好的底子。
我们要做的其实不是从零开始造轮子，而是在这些已有的生态基础上，去做行业化、业务化的具体方案。把通用的组件库变成你自己产品的设计系统。这在以前可能是大团队才干得起来的事，但现在有了 AI 的协助，个人也可以来尝试尝试了。
上期文章聊到 AI 时代设计师的几个可能方向，设计系统是其中之一。
Google 的 DESIGN.md 其实已经给出了一个很好的起点。无论你现在是在用 AI Coding 做产品，还是在探索设计系统的新可能，都可以从一个 DESIGN.md 开始试试。把你的设计经验变成 AI 能读懂的上下文，也许你会发现，这件事值得去尝试尝试。
{{< callout type="cta" title="关于这篇文章" >}}
本文是我付费专栏 [OFF DESIGN](https://xiaobot.net/p/offdesign) 第 45 篇的节选。原文还涵盖：DESIGN.md 在 CLAUDE.md 中的组织方式、完整的 Project Template，以及常见踩坑排查。
如果你对设计系统 Markdown 化的实践感兴趣，可以看我在 [OFF DESIGN](https://xiaobot.net/p/offdesign) 的最近一篇，以一个具体的 Pattern 为案例，聊了聊具体怎么做。
{{< /callout >}}
---
## 常见问题（FAQ）
**Q1：DESIGN.md 和 README.md、CLAUDE.md 有什么区别？**
三者面向的读者和用途不同。README.md 面向人类开发者，讲项目怎么跑；CLAUDE.md 面向 AI 编码助手，定义加载规则和工作方式；DESIGN.md 也面向 AI，但专门用来表达「设计决策」：用什么组件、什么时候不该用、Do's and Don'ts 是什么。三者互补而不是替代。
**Q2：DESIGN.md 只能给 Claude Code 用吗？Cursor、Codex 能用吗？**
不限于 Claude Code。DESIGN.md 本质是一份放在代码仓库里的 Markdown 上下文文档，任何支持读取仓库文件的 AI 编码助手（Cursor、Codex、GitHub Copilot、Windsurf 等）都可以通过 rules / 启动指令让它读取。差别只在于每家怎么配置「强制加载」。
**Q3：已经用了 Shadcn 这样的组件库，还需要 DESIGN.md 吗？**
需要。Shadcn 文档告诉 AI「组件是什么、怎么用」，但没告诉它「什么时候该用哪个、什么时候不该用」。一到具体业务场景，AI 只能猜。DESIGN.md 正是补上了这层设计决策，它是 Shadcn 的上游约束，而不是替代品。
**Q4：DESIGN.md 要写多详细？一份够吗？**
一份简单的 DESIGN.md（色彩、字体、组件基调、Do's and Don'ts）能解决 Foundation 层的一致性。如果做完整产品，建议进一步拆成三层：Foundation（风格基调）+ Component（组件规则）+ Pattern（场景组合），参考本文的目录结构。组件和 Pattern 可以让 AI 基于 Shadcn 文档自动生成初版，再人工修订。
**Q5：DESIGN.md 该放在哪？由谁来维护？**
一般直接放在项目仓库根目录（如 `DESIGN.md`）或拆分成 `DESIGN/` 目录。维护人最合适的是「懂设计又懂代码的人」。在 AI 时代，设计师直接维护 Markdown 文档，比通过设计稿交付给工程师再二次翻译，要高效得多。
---
## 💡 延伸阅读
- 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
- [半年过去了，AI 设计的进展如何?](/progress-of-ai-design-in-ui-interface/)
- [一年过去了，AI design 的进展如何？](/current-trends-ai-design-in-interface-design/)
- [产品界面的 AI 生成式设计，为什么没人关注了？](/why-generated-ai-ui-design-is-losing-interest/)
- [Salesforce 的生成式画布，证明了 AI 在产品界面设计中的可行性？](/salesforce-generative-canvas-proves-ai-ui-design-feasibility/)
- [从概念到落地，产品界面的 AI 生成究竟卡在哪儿了？](/ai-generated-ui-not-work/)
- [设计系统中的决策树：让设计决策更简单](/design-system-decision-tree/)
- [设计系统 · 我们为什么要做 Design System](/why-we-need-design-system/)
- [如何规划 B端 设计系统？深度解析 AWS CloudScape](/b-end-design-system-deep-dive-aws-cloudscape/)
- [设计师的下一站，成为架构师，还是走向业务？](/designer-architect-or-business/)
================================================================
# Heptabase VS Tana，两种不同的知识管理逻辑
- **发布日期**：2025-11-05
- **原文链接**：https://www.thefivekey.com/difference-between-heptabase-tana/
- **Markdown 原文**：https://www.thefivekey.com/difference-between-heptabase-tana/index.md
- **标签**：知识管理, 工具产品, 产品视角, Tana, Heptabase
> 很多人做知识管理时，都困在 All in One 的幻觉里：希望一个工具解决所有问题，却发现越用越乱。我在这篇文章里直接拆开 Heptabase 的空间思考、Tana 的结构思考，讨论它们为什么天生互补，而不是彼此替代，并给出如何用“两套系统”构建长期知识体系的答案。
Heptabase: My Vision Project Meta
而 Tana 的重心则完全不同。它关注的不是「全貌」，而是「结构」以及结构化之后组织信息的方式。
我一直很喜欢节点式、大纲型的工具，因为它足够简单、快速，最适合即时记录想法。
还在公司的时候，我用过很长一段时间 Logseq 和 OmniOutliner，它们都很好用，但问题也很明显。内容容易变得零散、粗放，彼此之间缺乏联系。每条笔记都像是一个孤岛，你知道它们存在，但很难串联成体系。
Tana 出现后，演示视频立马就吸引了我。它在大纲的基础上引入了 Supertag，让每个节点都可以带上语义结构。从「记录信息」变成了「组织知识」。
这种方式极大地弥补了 Logseq、OmniOutliner 在信息管理上的不足，也让我真正感受到笔记其实可以是「有逻辑的网络」，而不是一堆堆分散的文本。
当然，Tana 也是我接触过学习门槛最高的一款工具。
它不像 Heptabase 那样容易理解，而是要求你具备相当强的结构化思维能力。你得自己去定义、去构建、去设计那套逻辑关系。这个过程很难，也注定需要反复的尝试。坦白讲，我中途放弃过好几次，直到最近一年后才真正用顺手。
为了让差异更直观，我整理了一张对比表：
| 维度 | Heptabase | Tana |
| --- | --- | --- |
| 核心理念 | 空间化思考（看见思考） | 结构化思考（组织思考） |
| 最小单位 | 卡片（Card） | 节点（Node） |
| 主要视图 | 白板（Whiteboard） | 大纲（Outliner） |
| 核心能力 | 视觉化关联、发散 | Supertag 语义建模 |
| 学习门槛 | 低，容易上手 | 高，需要建模能力 |
| 最适合场景 | 深度研究、问题梳理、发散思考 | 日常记录、信息结构化、分析建模 |
| 弱项 | 快速记录、结构化输出 | 全局视觉思考、发散联想 |
| 适合人群 | 研究者、视觉化思考者 | 分析师、结构化思维者 |
但表格只能呈现表层差异，真正的区别还要回到两款工具背后的思考方式本身。
## Heptabase 和 Tana 的核心差异：空间化 vs 结构化
工具类产品有很多，但真正有生命力的，从来都不是因为功能的堆砌，而是因为它背后都会承载着一套独特的思考方式。
每一个好的工具产品，其实都是创始团队对某个领域的理解外化。他们看问题的方式，决定了产品的形态，也决定了使用者被引导去思考的路径。换句话说，工具不只是一个被动的载体，它也是一种思维的表达。
Heptabase 和 Tana 正是这样两种典型的外化结果。一个是把「思考」空间化，一个把「知识」结构化。
从表面看，他们的差异是界面或交互层面的不同，但本质上其实是代表了两种对知识管理、信息处理的完全不同的认知。前者关注「看见关系」，后者关注「定义关系」。
### Heptabase 的思考空间化
Heptabase 是一款以视觉化思维为核心、支持空间化组织知识的工具。它让笔记这件事彻底脱离了线性文本的束缚。
在 Heptabase 里，每一条信息都是一张卡片，而卡片之间可以通过[白板](/start-design-work-with-whiteboard/)自由地摆放、分组、连接。随着白板上卡片的增加，你会发现自己不再只是记录，而是在构建一张可以看见思考路径的地图。那些原本零散的想法开始被重新排列、归类、连接，慢慢显出它们之间的关系。
比如下面我最近我一直在梳理的白板。是最近关注到 BOJ 考虑提升利率引发的我对日本历史上利率变化的一个研究。
Chip War
### Tana 的思考结构化
如果说 Heptabase 是帮助我们「看见思考」，那么 Tana 则是帮助我们「组织思考」,是一款以网状思维为核心、支持非线性结构化的知识工具。
在这里，每一条信息都是一个节点，而每个节点都可以通过 Super tag 拓展出自定义的语义结构。当这些节点彼此引用、关联、嵌套时，就会逐渐织出一张动态的知识网络。
所以，我们所有的笔记就不再只是被记录下来但最终会落灰的内容，而是可被组织、推理、甚至触发行动的结构化信息。
这里可以给大家举几个例子：
以下图中这个 Signal 标签为例，我会用它来记录每天的思考和摘要。我会在记录的同时也做好这条信息的领域划分，以及是在什么场景下记录这条信息的。方便后续进一步的整理和使用。（更轻量的日常灵感捕捉场景，我之前也分享过 [用 Notion + 语音做日常记录](/daily-drafts-journal-with-voice-ai-notion-template/) 的模板）
小报童专栏 ，解锁本期文章全文内容。
================================================================
# 设计师的下一站，成为架构师，还是走向业务？
- **发布日期**：2025-03-31
- **原文链接**：https://www.thefivekey.com/designer-architect-or-business/
- **Markdown 原文**：https://www.thefivekey.com/designer-architect-or-business/index.md
- **标签**：设计思考, 产品设计
> 设计系统逐步完善后，体验设计师的角色正在悄然变化。本文探讨设计师未来可能的两种路径：构建秩序的架构型设计师，或深度嵌入业务的业务型设计师，并讨论如何根据自己的能力倾向选择方向。
当这些重复性的工作被系统接手之后，设计师的角色会走向哪里？
今天这篇文章，我就想接着这个问题往下讲讲。
## 当设计不再从零开始，设计师应该往哪儿走？
设计系统完成某个阶段后，设计师的日常开始变得熟悉甚至有些重复。你会发现，很多事情都已经被提前定义好了，你要做的，仅仅是 "照着来"。看起来轻松了不少，但也开始让人感到焦虑：
> 如果我的工作变成使用既定的方案，那么我还能创造什么价值？
这是一个很现实的问题，也是在设计系统逐步成熟之后，许多设计师共同的焦虑。
但大家要知道，设计系统的建设从来不是一劳永逸的事。它更像是一个持续演进的过程。随着业务的拓展、产品形态的变化，系统也需要不断被更新和迭代。
它没有“最终版”，也不存在“完成时”。
也正因为它变成了一项长期存在的基础设施，也就不可避免地，带来了设计协作方式的变化。设计逐步走向一定的中心化，秩序逐步显性化。
设计系统构建团队负责制定通用规范，其余设计师则深入到业务，以这些规则为基础推动产品演进。大家在各自“既定边界”内创造更大的价值 。
有些人会继续深入到行业和业务中，提炼共识、持续地构建确定性；而其他更多的设计师则走向业务，将 Pattern 和组件当作“标准件”拼装调度，用设计去解决实际问题，推动产品落地。
如果没意识到这种转变，那么依旧会停留在执行细节里原地打转。今天改布局，明天调动效，每天都在赶交付、救火、填坑，忙得身心俱疲，却不知道这些工作是否真的还有价值。
这些看似必不可少的工作，其实设计系统早就在一点点接管。你还在一块块堆砖头，人家已经在起楼了。
但如果你能看清这个变化，意识到设计早就不是把需求一个个画出来。它不是在手动复刻业务流程，而是用系统化的方式，把重复劳动压缩到最小，让真正重要的部分浮出来。比如业务逻辑、产品流程、信息结构等等。
当你开始把这些问题当成你需要解决的设计问题来看，那么就会发现你的设计空间，不是变小了，而是被重新打开了。
## 设计师未来的两条路径：架构型 vs 业务型
其实早在 2020 年，我在负责集团设计中台团队时，就隐约意识到一个趋势：未来的体验设计师，会逐步分化为两类角色 。一类负责构建设计系统、制定规则的架构型设计师，另一类则深入业务一线，推动产品落地与业务增长，是更偏执行与协同的业务型设计师。
当时只是作为一个内部判断提出，并不确定是否成立。但几年过去，越来越多的团队和公司，正在沿着这个方向演进。
这不是因为谁预判得准，而是因为这本就是行业走向成熟、协作方式系统化之后的自然结果。
但这两个方向，真的有清晰的边界吗？我们又该如何判断自己适合哪一条路？这些角色背后，又分别隐藏着哪些挑战和机会？
在这篇文章的下半部分，我想带你一起聊聊我对这两类设计师的理解和观察。
如果你正面临选择，或者正在寻找突破瓶颈的新方向，希望这些内容能为你提供一些思路。
> 💡 延伸阅读：
> - 架构方向深度展开：[成为架构型设计师](/become-an-architectural-designer/)
> - 业务方向：[业务思考力，设计师跳出执行的起点](/business-thinking-for-designers/)
> - 体验设计师未来三年：[体验设计师 未来三年应该如何发展？](/ux-designers-in-the-next-three-years/)
> - AI 时代的新抓手：[把设计系统变成 Markdown：让 AI Coding 真正读懂你的设计约束](/design-system-as-markdown/)
欢迎订阅我的小报童专栏，解锁本期文章全文内容。
================================================================
# 从做设计，到构建秩序
- **发布日期**：2025-03-31
- **原文链接**：https://www.thefivekey.com/from-chaos-to-order-in-design/
- **Markdown 原文**：https://www.thefivekey.com/from-chaos-to-order-in-design/index.md
- **标签**：设计思考, 产品设计
> 设计体验不是靠细节打磨堆出来的，而是建立在清晰流程和稳定结构之上的。本文探讨设计中「确定性」的重要性：好的体验来自规则的稳定，而不是个体努力的极致；设计系统通过 Pattern 提供确定性，是从「做设计」走向「构建秩序」的关键路径。
体验从来就不仅仅是设计的事情 。你看到是界面设计，但用户真正感受到的，是整个业务逻辑、产品流程以及界面设计的综合表达。
而业务逻辑和产品流程，大多数早在设计师接手之前，就已经决定了。于是就出现了一个常见的悖论：越想体现设计的价值，越容易深陷在细节里死磕。结果忙活了半天，却忽略了真正影响体验的地方。
说白了，这种状态，就是为了设计而设计。
听上去挺专业的，其实很多时候，不过是我们对自我价值的一种焦虑回应。但企业看重的不是这些。他们关注的是整个产品是否高效可控，是团队能否稳定产出，是设计投入能不能带来实际的商业价值。
他们要的，不是设计的最大化，而是业务价值的最大化。
想要改变这一点，设计师就不能总窝在自己的世界里打转。我们得往前多走一些，去看业务逻辑、产品流程，甚至是整个产品的服务流程。
但问题是，我们想往前走，得先把眼下的事儿理清楚。一个设计方案落不落地，一套组件库是否通用，一个交互模式是不是每次都得争… 这些问题不解决，哪还有空去谈体验的本质？
所以，在我们想办法改善设计的价值之前，**先得想办法让设计这件事本身，变得更稳定、更高效、更少争议**。
而这背后的关键，就是确定性。
## 什么是确定性？
所谓的确定性，就是不用每次项目都得重新判断、重新选择、重新争论。流程清楚、形式明确、结果可预期。越稳定的系统，越容易复制，越能高效地产出。而设计这个环节，恰恰是最缺确定性的地方。
一个设计师换一套风格，每个项目抠自己的交互细节，左滑右滑各有各的说法…… 本来只是想要增加一个用户提示，最后还得为弹窗是否可以关闭争论个半天。
所以我们需要的是一个工具，来把混乱收敛成秩序。而设计系统，正是用来解决它们的一套有效机制。
## 设计系统中的确定性
在一款产品的诞生过程中，通常有三个关键角色。
产品经理决定做什么，工程师负责怎么实现，而设计师，通常负责的是怎么呈现。也就是把业务逻辑、业务的意图，用一种清晰、易懂的方式传达给用户。
但现在的问题是，大部分互联网产品的形态早已稳定下来，能重新发明的地方越来越少。大多数时候，设计并不需要创造一个新界面，而是用最小的代价，给出一个稳定的解法。
而在这种背景下，设计系统的重要性就体现出来了。
说到设计系统，时至今天，依旧有很多人对它有着错误的认知。认为它只是一套样式手册，或者一堆组件拼起来的 UI 组件库。这些当然都是它很重要的一部分，**但如果只停留在这个层面，其实是极度低估了它的价值。**
设计系统不是样式手册，更不是一个 UI 仓库。它的本质，是一套帮助企业构建秩序的工具。目标很明确：用结构化的方式抽象最佳实践，压缩设计成本、减少沟通代价、降低出错概率。
不同设计师有不同的习惯，不同团队有不同的理解，结果是就是一个业务模块，看起来像三个人分别做了三套界面。更麻烦的是，这些差异背后往往还要伴随着大量的时间消耗。光是到底怎么做这件事，团队就要反复争论、推翻、重来。设计资源被反复浪费，方向也在拉扯中开始跑偏。
**这些混乱堆在一起，带来的就是企业层面的设计磨损。**
而设计系统，就是试图用结构、规则和共识，把这些磨损控制在可预期的范围内。它不是限制你的发挥，而是减少那些不必要的浪费。已经验证过的方式，不需要每次都重来一遍；早就清晰的交互，也没必要每次都开会讨论一遍。
它提供的，是一种可复用的稳定方案。把那些可以标准化的部分，抽离出来，封装成可直接使用的 Pattern，让每个设计师在面对同类问题时，不用再从头来过，也不用在细节上反复纠结。
说到底，设计系统真正想做的，是把你从反复判断中解放出来，把你真正的脑力，留给更重要的地方。
所以它强调的是一种有界的自由，解决设计过程里的不确定性。
## Pattern，设计系统中的秩序单元
你可能也意识到了。要解决“为了设计而设计”的困境，光靠经验和努力是不够的。
真正能帮你跳出细节死角、建立稳定机制的，是一套结构化的认知方式。
而 Pattern，正是这套结构的关键思考模式。它不是样式手册，不是组件集合，而是一种让设计思维从“界面设计”走向“秩序构建”的方法和思考模式。
在接下来这篇文章的付费部分，我想继续和大家深入聊聊：
- Pattern 如何构建“团队共识”？
- 为什么说它才是设计系统中最核心的秩序单元？
- 当 Pattern 成为基础能力，设计师又该如何改变自己的角色？
如果你也正在面临开头提到的那些困扰。那么也许，是时候换一个更结构化的方式来看待设计这件事了。
> 💡 延伸阅读：
> - 设计师的下一站：[设计师的下一站，成为架构师，还是走向业务？](/designer-architect-or-business/)
> - 系统化思维深度：[设计系统 · 我们为什么要做 Design System](/why-we-need-design-system/)
> - 业务视角思考：[业务思考力，设计师跳出执行的起点](/business-thinking-for-designers/)
欢迎订阅我的小报童专栏，解锁后续全文。
================================================================
# 从概念到落地，产品界面的 AI 生成究竟卡在哪儿了？
- **发布日期**：2025-03-31
- **原文链接**：https://www.thefivekey.com/ai-generated-ui-not-work/
- **Markdown 原文**：https://www.thefivekey.com/ai-generated-ui-not-work/index.md
- **标签**：设计 AI, 设计工具, 设计模式, 设计系统
> 产品界面的 AI 生成在 Demo 演示阶段令人惊艳，但从「能演示」到「能在业务中使用」之间隔着三道坎：生成质量、生成认知、生成结构。本文拆解为什么 AI UI 生成始终无法真正进入企业业务流程，以及设计系统在其中扮演的关键角色。
小报童专栏 ，解锁本期文章全文内容。
---
## 💡 延伸阅读
- 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
- 2023-09 [半年过去了，AI 设计的进展如何?](/progress-of-ai-design-in-ui-interface/)
- 2024-06 [一年过去了，AI design 的进展如何？](/current-trends-ai-design-in-interface-design/)
- 2024-10 [产品界面的 AI 生成式设计，为什么没人关注了？](/why-generated-ai-ui-design-is-losing-interest/)
- 2024-11 [Salesforce 的生成式画布，证明了 AI 在产品界面设计中的可行性？](/salesforce-generative-canvas-proves-ai-ui-design-feasibility/)
- **2025-03 从概念到落地，产品界面的 AI 生成究竟卡在哪儿了？ ← 你在这里**
- 2026-04 [把设计系统变成 Markdown：让 AI Coding 真正读懂你的设计约束](/design-system-as-markdown/)
================================================================
# 当用户喝多了，需要找代驾
- **发布日期**：2025-03-21
- **原文链接**：https://www.thefivekey.com/the-user-is-drunk/
- **Markdown 原文**：https://www.thefivekey.com/the-user-is-drunk/index.md
- **标签**：设计思考, 产品设计
> 如何优化代驾 App，让醉酒用户也能顺利下单？借用"The User Is Drunk"这个设计观察方法，从一次真实的代驾叫车经历出发，探讨那些常被忽略的「情境性障碍」设计：产品不仅要服务正常状态的用户，也要能服务被酒精、疲惫、情绪等状态降级的用户。
此时你才明白，不问问题，比问问题的“蠢”更可怕。
没有人指望你刚加入就了解一切。真正让团队失望的，是你在面对疑问时选择沉默，不敢开口。当你不敢提问，怎么能够融入团队，如何去了解业务的脉络，进而做出有效的设计呢？
## 为什么问问题如此重要？
作为设计师，你的工作远不止是做做设计稿。设计的核心，是在真正理解业务需求的基础上，提出有价值的解决方案，推动产品的前进。可是，如果连业务的基本情况都还没弄清楚，交出的设计方案怎么可能靠谱呢？
想象一下，你满怀信心，花了几天时间精心完成了设计方案，终于准备好召集团队进行评审。结果，当方案一摆上桌，大家的反馈让你有点懵。那些你精心雕琢的设计细节，可能与真实需求严重脱节，功能安排也显得不合逻辑。
更糟糕的是，你意识到这些问题其实应该在前期通过沟通来避免。你明明可以在设计初期问清楚这些背景信息，却因为纠结于要不要问问题，最后把自己搞进了死胡同。
如果在开始前没能把核心需求和目标搞清楚，那么设计就可能完全跑偏。结果不仅浪费了团队的时间，还可能让你成为“误事”的源头。大家虽然嘴上不说，但眼神里的意思已经溢于言表：“下次，记得先问清楚。”
在团队里，大家希望设计师能解决问题，而不是增加麻烦。 一次失误，大家或许能理解，笑一笑就过去了。但如果你一直“盲目设计”，凭空猜测，缺乏沟通和反馈，信任就会悄悄溜走，像沙漏中的沙子一样，渐渐流失。
## 为什么新人总是害怕问问题？
新人不敢提问，大多不是因为问题太难，而是害怕“别人怎么看我”。其实，你真正应该害怕的，不是别人觉得你笨，而是你假装懂，却把事情搞砸了。无知不可怕，装懂才真正可怕。
### 三大提问阻力：
#### 01. 别人会觉得我很蠢吗？
每个新人都会有这样的担心。“我才刚进公司，怎么敢问这些基本问题，万一让别人觉得我不够聪明？”但你需要明白，没人指望你一进公司就什么都懂。
真正让人失望的，是那些不懂装懂，最后把事情搞得一团糟的人。如果你能坦诚地提问，反而能让人看到你对工作和团队的尊重。
### 02. 会不会打扰打扰别人？
团队里的每个人都很忙，特别是那些资深的“老同事”。他们看上去忙得像机器一样。但忙并不代表不能问，关键在于你提问的方式和时机。
如果你提前整理好问题，简洁明了地提出，没人会觉得你是在打扰他们，反而会觉得你在节省他们的时间。问得合适，大家反倒会觉得你是个“懂事”的新人。
### 03. 会不会显得自己没准备？
这种担心也挺正常的。尤其是当你发现，自己能通过文档或调研先找到答案时，再提问可能会觉得不够“专业”。但问题在于，如果你没有先做功课，或者做的功课不够深入，那提问其实是一种对自己工作的负责。
做功课是对问题的尊重，但如果真的无法解决，提问才是提升自己效率的关键。提问不是为了展示自己的“无知”，而是为了避免浪费时间和资源。
你付出的不是“问题的成本”，而是错过答案的代价。在团队里，最容易被浪费的资源就是沟通。你不问，别人不会主动告诉你，而你在盲目猜测和反复修改中耗费的时间和精力，才是最大的成本。
举个例子：
有个新人负责设计一个OMS（订单管理系统）页面，满怀信心地交付给团队进行评审。
结果，设计方案被推翻了：“这个页面的功能布局完全不符合我们流程的要求，我们的用户群体主要是大型企业客户，为什么要设计成这么简单的界面？”
产品经理的一句话让新人有些懵。
如果他在初期就主动提问，花几分钟确认需求和用户场景，这一切本可以避免。结果，不仅浪费了自己的时间，还浪费了团队的时间，甚至让自己成了“误事”的源头。
## 如何开始问一个好的问题？
问问题，远远不只是开口那么简单，它是一门技术活。什么时候问？怎么问？问到什么程度才算到位？哪些问题最好别问？是我们最需要关注的。这些细节决定了你在团队中的形象，是一个“能搞定事”的人，还是一个“搞不清事”的麻烦制造者。
在接下来的付费内容中，我会跟你聊聊更深入的话题，包括：
- 问问题过程中的常见坑：那些你一问出口，别人就开始翻白眼的问题，为什么总是让你踩到？
- 问问题前的准备工作：为什么有些问题问得精准、有深度，而有些问题让人觉得你毫无思考？秘诀全在开口之前的准备。
- 如何递进式地提问：问一个问题是起点，但问出连贯有逻辑的问题，才是真正解决问题的关键。
- 什么时候提问最合适：提问的时机，直接决定了回答的质量。问得聪明的人，总是能在恰好的时机获得恰好的答案。
> 💡 延伸阅读：
> - 跨行业入职时的直觉重建：[进入新行业，如何校正你的产品直觉](/calibrate-your-product-intuition/)
> - 长远的职业规划视角：[做了 5 年互动设计，我遇到了设计师职业发展天花板](/five-years-later-i-encountered-a-career-ceiling/)
加入 OFF DESIGN，你将解锁本期付费内容。以及全年更新的不低于 100 篇的专栏文章。
================================================================
# 好的简历作品集，需要有层次的表达
- **发布日期**：2025-01-14
- **原文链接**：https://www.thefivekey.com/how-to-structure-portfolio-expression/
- **Markdown 原文**：https://www.thefivekey.com/how-to-structure-portfolio-expression/index.md
- **标签**：求职面试, 职业发展
> 如何让你的作品集案例更具吸引力？本文拆解"分层表达"的实用方法：第一层讲项目主线（让面试官 3 分钟抓住核心），第二层讲实施细节（提供弹药支撑主线）。避免 0 到 1 项目被讲得冗长散乱，让面试官快速理解你的能力、思考和成果。
你的目标是什么，你的方法是什么，你的结果是什么。你是如何通过逻辑推导，逐步解决问题的。
### 第二层：实施细节，为主线提供弹药
这一部分是用来深入展开的。当面试官对某些结论产生兴趣时，你可以从容地打开“工具箱”，为主线提供更细节的支撑信息。
比如：
- 行业调研中，你用了哪些方法？得到了哪些关键发现？
- 竞品分析中，你关注了哪些维度？为什么这些维度很重要？
- 设计方案中，有哪些具体的创新点？它们如何与核心目标挂钩？
这里的关键是“可展开但不赘述”。细节只是你的支撑材料，而不是主线内容。
## 好的表达是需要有层次的
不管是面试还是作品集，缺乏层次感的表达往往会让人觉得枯燥乏味。很多失败的案例，问题并不是内容不够多，而是没有组织好内容的逻辑。
试想一下，你有一个非常绝妙的创意。但如果你把所有的细节从头到尾一股脑讲给面试官听，可能只会让人迷失在细枝末节里，不知道你的重点在哪里。
而如果你能先提炼出创意的核心价值，再用关键细节去充实和证明它，面试官会更容易被你的思考和成果打动。
## 如何让作品集“站住脚”
对于 0 到 1 的项目，作品集的陈述方式其实是可以学习“讲故事”的方法的。
**从结果反推整个流程：**
用一句话概括项目的最终成果，比如“通过优化流程，成功将操作效率提升了 30%”。再一步步拆解，你是如何达成这个结果的，形成一个清晰的故事链路。
**突出个人贡献：**
让面试官知道，这个项目中哪些部分是你主导的，哪些地方体现了你的思考和价值。
通过细节增强可信度：比如，在行业调研中，你是否发现了某个重要的用户痛点？在竞品分析时，你是否提出了某个有洞察的结论？
## 最后的建议
作品集的作用不只是展示你的能力，更是让面试官理解你的思考方式。
对于 0 到 1 的项目来说，最忌讳的是“从头到尾讲流程”，因为每个人的流程其实大差不差，难以突出亮点。对于 0 到 1 的项目，最好的方式是提炼主线、分层表达。
让面试官不仅知道你做了什么，还知道你为什么这么做、你的方法论是什么、你解决问题的能力又如何。记住，内容的“底料”可能大同小异，但如何组织和表达，才是拉开差距的关键。
你看，其实做好作品集，和做设计是一样的。
**你需要把它真正的当做一个项目来思考。**
方法已经摆在这里了，剩下的，就看你怎么用了。
---
面试官每天都在快速翻阅成百上千份简历，你的那一份不过是其中一张。你的简历在面试官眼中停留的时间是三分钟，可能是他们停留在你的简历上最长时间。
在这短短的三分钟里，你的简历要么成功敲开门，要么被悄悄归档。而这三分钟，决定了你的下一次机会能否到来。
在好莱坞，编剧们为了吸引投资人，会用一种叫“电梯推荐”的方式介绍自己的剧本。因为时间非常有限，这种自我推荐需要在 30 秒内完成，因为它相当于乘坐一次电梯的时间。
**30 秒后，电梯到达，你机会可能也就结束了。**
而设计师的简历，其实也是一样？在面试官有限的时间里，能否在短时间内展示你的能力。它的本质是讲一个简短而有力的故事，告诉面试官：我能做什么，我为什么值得你们的机会。
接下来，在本期付费文章「三分钟，你的简历能走多远？」中我会聊一聊如何用好这 3 分钟，让你的简历在面试官的眼中脱颖而出。
这三分钟不是走过场，它是你通往下一阶段的关键节点。如果你能抓住它，后面的 10 分钟，面试官愿意深入阅读你的简历，甚至未来 40 分钟的面试沟通，就会变成可能。
简历的本质，其实是一种需求。你想要一份机会，而面试官想找到一个合适的人。需求如何被满足？
**正如设计师做产品时需要去理解用户，简历也是需要被“设计”的，清晰、有逻辑、有吸引力。**
> 💡 延伸阅读：
> - 更基础的视角：[设计师的简历作品集应该关注什么？](/how-to-effectively-present-your-resume-portfolio/)
> - 为什么要升级作品集：[做了 5 年互动设计，我遇到了设计师职业发展天花板](/five-years-later-i-encountered-a-career-ceiling/)
加入 OFF DESIGN，你将解锁本期付费内容。以及全年更新的不低于 100 篇的专栏文章。
================================================================
# 设计的意义，得用业务语言讲明白
- **发布日期**：2025-01-08
- **原文链接**：https://www.thefivekey.com/design-business-value/
- **Markdown 原文**：https://www.thefivekey.com/design-business-value/index.md
- **标签**：设计思考, 产品视角
> 设计师如何用业务语言讲清楚设计的价值？本文从设计师与产品经理的常见冲突切入，介绍功能价值指数（FVI）框架，教你用数据量化设计的业务价值，让团队听得懂、决策者认可。
我们工作的环境，始终是一个商业环境。 **而这个环境中，每个角色的目标与视角有着天然的差异。**
**运营人员和产品经理，是企业对商业需求的具体化表达**，他们的目标非常明确：拉新、转化、留存、盈利。而设计师和工程师，尽管同样为这些目标服务，却更倾向于用自己的专业语言看世界。一个关注用户体验的美感与流畅，一个专注于技术实现的逻辑与效率。
这种视角的差异就像在用两种不同的语言互相喊话。设计师的“这交互更符合用户习惯”，和产品经理的“能不能提高点击转化率”，往往成了两种语言体系，彼此不理解，谁也无法完全说服谁。摩擦因此变得不可避免。
## 商业环境下，设计师的天然“劣势”
企业的核心始终是商业，而问题的本质最终也得用业务视角来解读。对于以专业视角为主的设计师来说，这是一个天然的劣势。我们精通设计的语言，但在商业这套逻辑中，却很难用专业的话语去表达设计的价值。
为什么设计师很难在业务的“牌桌”上拥有发言权？**因为我们习惯把设计结果当成目标。而产品经理甚至是管理者更关注的是设计对商业目标的推动。**
换句话说，设计师工作的重点不是“设计得好不好看”，而是“设计是否为商业提供价值”，最终是不是能解决业务问题。
产品经理关心的是最终的商业数字：这次改版能提升多少转化率？这个页面的点击量有没有提高？这条用户路径是否更高效？而设计师往往沉浸在自己的专业领域，视觉呈现、交互逻辑，甚至是一些设计师眼中的设计情怀。但如果设计无法转化成商业结果，那么在业务视角里，它可能就是“无效产出”。
这也是为什么，设计师可能在项目会上自信满满地展示了新设计，却被运营人员一句“这个流程复杂会不会降低转化率”击得无话可说。
设计师用体验的逻辑看待问题，但企业期待的是用增长和盈利的语言解答问题。
## 为什么设计师需要业务 Owner 精神？
我们常说，设计师需要具备“业务 Owner 精神”。这话听起来有点虚，很多人并不理解是什么意思？它不是让我们只用专业去解决业务问题，而是跳出专业视角，把自己当成业务 Owner，站在业务视角重新定义问题，看待设计。
业务 Owner 的视角是什么？
如果设计师在乎的是“这个界面好不好看”，**那业务 Owner 关心的则是“这个功能能不能帮我留住更多用户？”。**如果设计师想着“这个交互是否符合最佳实践”，**那业务 Owner 关注的则是“这个流程是否能让用户更快完成操作？”。**
简单来说，业务 Owner 精神就是要求你把业务的成败当成自己的责任，而不是单纯完成一张图、一套交互逻辑就算了。界面漂亮是一回事，但**业务跑不动，你也得真心地发愁。**
业务 Owner 精神不仅仅是调整视角的问题，还要求设计师在日常工作中主动去接触、理解业务的数据和问题。这就意味着，无论是设计方案的产出还是业务会议的讨论，我们的身份都应该是业务的 Owner。我们需要用业务发展的视角看待一切问题，设计只是我们最擅长的一项技能而已。
所有这些，都是在帮助你跳脱“专业”的局限，把设计的价值与业务目标紧密结合。
## 当设计师转为产品 Owner 时会发生什么变化？
在做了十多年的设计后，我开始转向了产品工作，一晃也五年了。当你真正开始为一个业务的生死负责时，思考方式针对会发生巨大的变化。每天我最关心的，不再是设计本身做得如何，而是更具体、更紧迫的问题：
- 用户量怎么样？
- 活跃度是否达标？
- 商业收入能不能支撑下个月的运营？
设计的确重要，但它只是这整个体系中的一环。每天琢磨如何让产品活下去时，你才会真正的体会到，**设计不仅要服务于用户，更重要的是还得为商业目标负责**。
于是，我会要求团队里的设计师要用业务的视角来看设计。如果一个设计对业务没有贡献，那它再精致也是失败的。
设计师需要从“设计好不好看”，走向“设计对业务有没有价值”。 这样的转变并不意味着抛弃专业，而是要求我们从专业的层面出发，为业务创造更大的价值。设计是帮助业务实现目标的工具，而不是业务的负担。
而首先，我们需要从真正的理解业务开始。
## 理解业务的第一步,数据和设计的语言转化
企业中，业务目标的语言是数据：转化率、收入、月活、日活... 这些指标是衡量成败的信号灯。
产品经理常说：“这个页面转化率太低了，能不能调整一下流程？”设计师回答：“调整流程会牺牲体验啊，用户可能觉得麻烦。”
表面看起来，这像是两个无解的问题，实际上，这恰恰是我们在职场工作中最大的劣势。我们需要学会用数据和专业语言对话。我们需要学会用商业语言和专业语言对话。
设计师只有从数据中找到设计的依据，把自己的专业思考转化为商业逻辑，才能更好的与产品经理和运营人员进行同频的沟通。
也才能够更加成熟的思考设计于商业的价值。
如何正确地理解数据，并让数据真正为设计所用？**关键在于为业务问题和设计方案之间建立清晰的关联。**
首先要做的是**切换到业务数据的视角，了解问题的本质**，而不仅仅停留在表层的体验数据上。接着，还需要借助一套强有力的观察指标，帮助我们**建立设计与商业目标之间的连接。**
这不仅能论证设计的价值，也能让我们反思设计的必要性，确保每一个方案都在为业务增长服务。
在做设计中台产品的那个阶段里，有大量的时间在做汇报。我需要有一个能够同时面向于老板们和团队内的指标，来让大家对产品的有一个共性的直观感知。
所以我创建了一个观察指标，我将它称之为**功能价值指数（FVI）**。
在对 FVI 指标不断优化的过程中，我开始逐渐找到了一个商业与设计之间理解数据的平衡点。同时帮助团队更好地建立商业目标与设计之间的链路。
接下来，我将在本期文章的后半部分（付费）内容中，通过具体案例详细解析如何用 FVI 将设计与商业目标挂钩。
在付费文章中，你将看到：
- 功能价值指数（FVI）详解，及其在数据中挖掘设计洞察的应用
- 以 Spotify AI DJ 为例，解析 FVI 如何量化设计的业务价值
> 💡 延伸阅读：
> - 业务思考的起点：[业务思考力，设计师跳出执行的起点](/business-thinking-for-designers/)
> - 设计系统的业务价值：[设计系统 · 我们为什么要做 Design System](/why-we-need-design-system/)
加入 OFF DESIGN，你将解锁本期文章的全文内容。 以及全年更新的不低于 100 篇的专栏文章。
================================================================
# HQ&A 笔记法：让你的思考更有效 (上)
- **发布日期**：2024-12-29
- **原文链接**：https://www.thefivekey.com/hqa-note-taking/
- **Markdown 原文**：https://www.thefivekey.com/hqa-note-taking/index.md
- **标签**：设计思考, 效率, 知识管理
> HQ&A 笔记法，教你从“记录”到“理解”，通过标记、提问、回答三步法，让碎片信息变成深度洞见，助力高效学习与工作。
这种“水与海”的逻辑不仅存在于学校里，在我们的日常工作中也很常见 。比如，项目需求会上你认真记录了一堆关键信息，觉得自己已经掌握了全局。可一到业务分析会议，大家讨论得热火朝天，你却发现，记了很多，但也聊不出啥。
**“复习点”与“考点”之间的鸿沟，是学习和工作的常态**。要跨越这道鸿沟，我们需要用方法，把“看似懂了”变成“真正明白” 。在这一类场景里，HQ&A 笔记法就是一个非常不错的选择。
## 什么是 HQ&A 笔记法？
HQ&A 是 Highlight（**标记重点**）、Question（**提出问题**）、Answer（**回答问题**）的缩写。它的核心在于，将复杂的知识点层层剥开，化整为零，再重新组合成逻辑清晰的体系。
**第一步：Highlight（标记重点）**
首先，将你在日常中认为有价值的信息记录下来，比如一句话、一个结论，甚至是一个关键词。这里要注意，不要贪多，不要把整段内容一股脑保存下来。重点是提取关键信息，而不是为笔记增加负担。
**第二步：Question（提出问题）**
接下来，对标记的重点提出问题。建议从自己的角度思考三个问题。比如：
1. 这个结论是怎么来的？
2. 它的前提是什么？
3. 它可能带来的影响有哪些？
提问的过程，其实就是将信息解构和挖深的过程。
**第三步. Answer（回答问题）**
最后，根据你的理解，尝试回答这些问题。回答时，尽量结合上下文或相关知识进行分析和拆解。这个环节不仅让你对问题有了更清晰的思路，还能帮助你把知识点转化为自己的洞见。
## 现在，我们用 HQ&A 方法再试试
> 汉武帝从政治、经济、军事三方面巩固了大一统
这句话看似言简意赅，但如果直接背诵，很可能只记住几个关键词，一旦考试题目展开可能就抓瞎了。为了真正吃透这个知识点，我们可以用 HQ&A 方法 来拆解，逐层深入挖掘背后的逻辑。
先从最基础的开始，我们可以对前面那条知识点提出三个问题：
> **问题 1：汉武帝在政治方面采取了哪些具体措施？**
>
> 汉武帝在政治上推行“推恩令”，通过让诸侯王分封子弟，逐步削弱了诸侯的权力，最终加强了中央集权。
>
> **问题 2：汉武帝在经济方面采取了哪些具体措施？**
>
> 汉武帝实行盐铁官营和均输平准政策，加强了国家对经济的控制，增加了财政收入，同时缓解了社会矛盾。
>
> 问题 3：汉武帝在军事方面采取了哪些具体措施？
>
> 汉武帝多次对匈奴发起大规模军事行动，打击了匈奴的威胁，扩大了汉朝疆域，加强了边疆地区的稳定，为国家统一与发展奠定了基础。
引导你把信息从“记录”升级为“理解”，再进一步成为有用的知识资产 。它让你从“看似懂了”走到“真正明白了”。就像徒手剥开一个榴莲，第一步虽然有点扎手，但当你吃到果肉的那一刻，就知道这一切值得了。
## 将 HQ&A 的思路用在工作中
在工作中，我们每天都会接收到大量的重要信息。
团队今年的整体设计策略、项目中的用户反馈、跨部门会上看似随口一提的观点……这些信息看起来都非常有用，值得记录，但如果不深入思考，它们最终只会停留在笔记里，难以真正产生价值 。
如果你只机械地记录，很快就会发现这并没有太大价值。再聪明的脑袋，面对如此多的碎片信息，也总有被填满的那一天。关键在于，**如何把“看起来懂了”变成“真正弄明白了”**。这不是记忆的问题，而是理解的问题。而理解的前提，是主动提问。
在公司的那些年，每天接触到的信息和观点实在太多了。于是，我逐渐形成了一个习惯：每当获得一个重要的观点或信息时，总要再 Google 一下，或者直接问问相关的人。哪怕只是随口一句“这个为什么是这样？”“它背后还有什么？”看上去好像是“多此一问”，但实际上，这个习惯让我对信息的理解多了一层，也逐步形成了自己的思考体系。
这个习惯延续了很多年，直到几年前，我偶然发现一位英国博主 Jamie Miles 分享的 HQ&A 笔记法。我才发现原来有人早就把这种“结构信息”的思路整理成了一套方法。
它看似简单，但逻辑精准，操作起来特别有效。
其实，所有的学习和工作，很多时候我们都是在做信息解构的游戏。 。提问，是这场游戏的起点。只要你掌握了提问的思路，就会发现信息的复杂程度并不是理解的障碍，只要你问对了问题，答案其实一直都在那里。
## HQ&A 的案例与实践
我以前经常和大家提，要用产品的思维去做设计。这个产品思维怎么来？HQ&A 就是一个简单直接、易于上手的方法，它能帮你把一条条看似孤立的信息变成深入的理解，真正的从业务视角来看问题。
方法本身之外，承载它的工具同样重要。我在 [Heptabase VS Tana，两种不同的知识管理逻辑](/difference-between-heptabase-tana/) 里聊过两款典型的知识管理工具：它们一个让你「看见思考」，一个让你「组织思考」，正好对应了 HQ&A 中"理解"和"结构化"两个环节。
以上就是关于 HQ&A 笔记法的上篇的内容。
在下篇（付费）中，我将重点为大家分享如何在我们的工作中的具体实践：
1. 如何用 HQ&A 笔记法来分析需求和数据，理清复杂问题的核心逻辑；
2. 如何结合 AI 来增强 HQ&A 的效率，让你的笔记和思考更进一步；
3. 以及如何选择合适的工具，将 HQ&A 方法无缝融入你的工作流程。
加入我的「OFF DESIGN」专栏，你将解锁 HQ&A 的下篇:
> HQ&A 笔记法：让你的思考更有效（下·案例与实践）
================================================================
# 设计师的 2024：边界在消失，2025 该怎么走？
- **发布日期**：2024-12-22
- **原文链接**：https://www.thefivekey.com/design-review-2024-and-outlook-2025/
- **Markdown 原文**：https://www.thefivekey.com/design-review-2024-and-outlook-2025/index.md
- **标签**：体验设计, 职业发展, 设计 AI
> 2024 年，设计行业的边界正在被重塑，AI 的崛起与角色的重构让设计师面临全新挑战。设计师们，该如何为 2025 年的变化做好准备？点击了解设计行业的转型与未来方向。
体验设计 」转向「业务设计」。
**Title 的变化只是表象，背后是公司对设计师期望的彻底重塑。** 过去，体验设计师讲究的是“以用户为中心”，可企业的视角可不一样，它更在意的是设计为企业带来的增长和利润。
企业需要的是一个「利润中心」，而不是一个只烧钱、不赚钱的「成本中心」。
设计师的角色也随之发生了根本性的转变。从「体验设计师」到「产品设计师」，意味着设计师不仅要画界面、做优化，还得能想清楚：**这个设计能不能提高转化率？能不能直接带来收入？**
这背后是企业策略的转变，用更直接的话说，设计师不仅要设计“看得见的好”，还得为“看不见的利润”负责。这不仅仅是一个岗位名称的变化，而是设计行业的一场结构性调整。
## 02. AI 在敲门，边界在消失
上个月，我开始用 Cursor 和 Windsurf 做一些小工具。刚开始是写写脚本练练手，后来干脆用它们解决工作中的一些琐碎问题。就这样，一不留神，做出了 20 多个工具，这效果实在有点不像话了。更别说更为强大的 Devin，对于设计师来说，**我们好像真的不需要工程师了。**
过去，设计师不懂代码，这是个绕不过去的槛。很多时候冒出一些好点子都卡在“实现不了”这一步。
但现在，AI 工具把这道门槛给直接拆了。只要你有想法，它就能帮你把想法变成产品。AI 不只是帮你提升效率，更是在改变你的工作边界：设计师可以写代码 ，工程师可以设计界面，产品经理甚至能用 AI 生成原型。
更关键的是，这种能力不再只是“少数高手的特权”。**AI 工具的门槛越来越低，工种之间的界限也越来越模糊。** 设计师、工程师、产品经理原本泾渭分明的角色，现在正在被重新定义。
这才是最让人不安的地方。当角色之间的护城河被填平，接下来会发生什么？答案可能比我们想象的要快得多。
看似毫不相关的两件事，实际上指向了同一个方向：**设计行业的角色边界正在消失。**
一方面，设计师的职责边界正在变化。过去，我们只需要关注用户体验和设计本身，但现在，企业希望我们把目光放得更远一些，思考设计对业务的直接价值。设计师不只是画图的，更是业务的推动者。
另一方面，AI 让我们的能力边界得到了无限扩展。不懂技术？没关系，AI 补上这块短板。曾经因为技术限制而束手束脚的事情，现在只需要一点想法，再交给工具去实现就行了。我们不再只是设计师，我们可以做更多。
不过，别高兴得太早，这件事对所有人都是公平的。设计可以跨界到研发，研发也可以跨界到设计，而产品经理甚至可以抛弃所有人，把问题直接转化为需求，再利用 AI 生成完整的解决方案。
边界的模糊化是双向的，大家都在同一个游戏里，彼此的护城河都正在迅速消失。
当能力边界走向无限拉平时，我们都得回归一个最本质的问题：**我们做这些事情，到底是为了什么？**
未来，用专业解决问题可能不再是难点，真正重要的，是发现问题、分析问题、定义问题的能力。至于后面那些实现环节，交给 Devin 这类产品不就行了吗？
AI 或许会取代技能，但它取代不了思考。**未来的职场最需要的，不是会做事的人，而是知道该做什么的人。**
## 2025 年新计划：从 OFF UX 到 OFF DESIGN 专栏升级
新的一年，既是延续，也是改变。回顾这些年的积累，我决定对自己做一些调整。
### 专栏品牌调整
首先，「设计有得聊」这个品牌会和大家 Say Goodbye 了。取而代之的，是我的新专栏「OFF DESIGN」。这个名字，我想了很久，在最终确定的时候，也已经想好了该如何向大家表达我的思考。
> 设计不止于设计，承载洞见，延展价值。
>
> 出离设计，立足其上，探索多维价值与可能。
这个变化背后的逻辑其实很简单：设计从来不是孤立的，它总是在与其他领域对话、交融，从用户到业务，从产品到世界，设计承载的意义远远超出界面本身。对我来说，**“OFF DESIGN”不仅是一种思维方式，更是一种新的探索。**
未来，我希望和大家一起，跳出设计的边界，站在更高的维度，去思考设计如何定义价值，又如何延展价值。设计的边界，不是终点，而是起点。
### 迁移与升级
从 2025 年开始，我的付费专栏将正式迁移到「小报童」，并更名为「**OFF DESIGN**」。这个决定，说起来其实很简单，过去几年，我输出的大部分内容以文字为主，而「小报童」在这一点上显然更加合适。
**新的「OFF DESIGN」，不只是一次平台的迁移，更是一次策略的升级。**
我会继续和大家分享对设计的思考，但不再局限于设计本身。正如今天这篇文章所表达的，设计从来不是孤立的，它与用户、业务、甚至技术和文化深度交织。我们需要用发展的眼光去看设计，才能发现它更大的潜力。
具体来说，新的「OFF DESIGN」会有以下两点变化：
1. **内容以中短篇为主，注重时效性和频次**
每次阅读不会占用太多时间，也减少心理负担，设计师忙碌的日常中，能随手来一篇、随手吸收一点。
2. **跳出设计，探索多维度的价值**
设计是一个基点，但不是终点。我们会一起思考设计如何与更多领域的结合，如何用更大的视角去定义和延展它的意义。
================================================================
# 从 Ant Design X 探索 AI 产品领域设计系统
- **发布日期**：2024-12-09
- **原文链接**：https://www.thefivekey.com/ant-design-x-ai-product-design-system/
- **Markdown 原文**：https://www.thefivekey.com/ant-design-x-ai-product-design-system/index.md
- **标签**：设计系统, 设计模式, AI
> Ant Design 推出了业内首个面向 AI 产品领域的会话式设计系统：Ant Design X。本文探讨了领域级设计系统的概念及其在 AI 交互中的应用，分析了 Ant Design X 背后的设计逻辑、应用场景及未来发展趋势。
「融资利率计算器」小工具 。
「百万计划」小工具 。
Cursor 帮我完成了它们。我只是作为产品经理和设计师，提出需求，规划功能，再通过 Cursor 帮我实现了我的想法。
在互联网行业工作了 20 多年，前面的十多年一直都是做设计，后面的几年开始做产品。多年来，我对编程一直抱有执念。
作为设计师和产品经理，我总会想到各种稀奇古怪的需求，但由于自己不会写代码，很多想法都无法尝试。虽然我尝试学过编程，但真正掌握编程的逻辑和语言始终需要投入大量时间，而这对于我来说，并不现实。
## 为什么我建议每个非工程师都试试 Cursor
有了 AI 工具，局面完全打开了。在过去，ChatGPT 让我能够改改代码，而如今 Cursor 则让我开始可以大胆的做一些更为复杂的工具了。
Cursor 对我来说最大的意义，是让我可以退回到产品经理的角色，只需要把握功能的需求和细节，把实现交给“它”来完成。
用 Cursor 完成我的第一个工具后，我毫不犹豫地决定付费订阅了。
一个月一百多块钱的成本，就像雇佣了一个“随叫随到的程序员”。对于我这种技术能力有限、却常有小想法的人来说，绝对是超值的投资。
## 接下来想用 Cursor 探索什么
接下来的日子里，我会继续用 Cursor 实现一些日常生活中“看到”的需求。它们不一定复杂，也不一定适合所有人，只是用来解决一些我自己感兴趣的问题，就像以前的 Notion 模板 一样。
我会将用 Cursor 创建的小工具聚合在一起，如果你也感兴趣，那自然也是很好的。
> https://www.toolsxyz.com
================================================================
# 如何规划 B端 设计系统？深度解析 AWS CloudScape Design System 最佳实践
- **发布日期**：2024-11-08
- **原文链接**：https://www.thefivekey.com/b-end-design-system-deep-dive-aws-cloudscape/
- **Markdown 原文**：https://www.thefivekey.com/b-end-design-system-deep-dive-aws-cloudscape/index.md
- **标签**：设计系统, 设计模式
> AWS CloudScape 是当下最被低估的 B端 设计系统之一。本文从 Foundation / Component / Pattern / Demo 四层结构出发，完整拆解 CloudScape 的 67 个组件、35 个 Pattern 和 27 个 Demo，并给出如何参考它构建自己 B端 设计系统的实操思路。
#### Foundation 亮点 3：Design Token 的可定制与强约束
CloudScape 的 Token 部分原理上和大多数设计系统没有太大差异，它可以帮助用户打造出不同风格的产品。
系统提供了颜色、文字排版、间距和动效。前面两部分用户可以自行定义，但间距和动效是不开放自定义的。
### Design Pattern · 设计模式
### 四层结构的关系：从基础到收敛
回顾完整个 CloudScape Design System，我想给大家画张图：
。
### B端 设计系统和 C 端设计系统的核心差异是什么？
B端 关注**效率、一致性、复杂任务处理**；C 端关注**情感体验、视觉吸引、用户粘性**。B端 设计系统需要更严的约束，C 端设计系统需要更多的情感化表达空间。
## 总结：从 CloudScape 学到的 B端 设计系统构建思路
CloudScape 作为一套服务于云产品业务的 B端设计系统，做得非常的完整和准确。
从组件到模式再到模板的一步步收敛非常清晰，对使用者而言实操性非常强，尤其是对于复杂业务场景下的高效性和一致性有着很好的保障。对于新入职的设计师而言，这样的 B端设计系统使得他们可以在一两天内快速上手并开始工作。
这一点对于云服务领域的设计师来说，尤其是在阿里云、字节跳动、腾讯等类似业务中的设计师，应该感触会非常深。
今天和大家聊这套 B端设计系统，并不是想告诉大家直接去用它就好。设计方案没有绝对好，但有相对的最合适。CloudScape 其实是给了我们一个非常好的思路去构建自己的设计系统，这篇文章也仅仅只是"总览"了一下这套设计系统。大家不妨花点时间去多读几遍官网文档，相信对你一定有更多的感悟。
{{< callout type="cta" title="继续深入" >}}
设计系统 (Design System) 是当前设计领域最热门话题的之一，但其价值并非所有人都清晰认识。如果你还没想清楚"为什么团队需要设计系统"这个根本问题，可以先看 [设计系统 · 我们为什么要做 Design System](/why-we-need-design-system/)，从业务效率、体验一致性、团队协作等角度系统回答了这个问题。
如果你感觉很难给你的主管或团队成员推行设计系统、讲解清楚设计系统的价值，可以参考 [如何向你的主管和团队介绍 Design System 的重要性](/how-to-prove-the-value-of-design-system-to-your-boss/)，里面有完整的分享 PPT 可以直接使用。
{{< /callout >}}
## 💡 延伸阅读
- 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
- [设计系统 · 我们为什么要做 Design System](/why-we-need-design-system/)
- [设计系统学习指南 - 国内外 Design System 案例解析](/how-to-learn-from-other-design-systems/)
- [如何向你的主管和团队介绍 Design System 的重要性](/how-to-prove-the-value-of-design-system-to-your-boss/)
- [设计系统中的决策树：让设计决策更简单](/design-system-decision-tree/)
- [设计模式库与设计组件库到底有什么区别？](/difference-between-design-pattern-and-design-component/)
- [把设计系统变成 Markdown：让 AI Coding 真正读懂你的设计约束](/design-system-as-markdown/)
- [成为架构型设计师](/become-an-architectural-designer/)
> 本文出自专栏 **[OFF DESIGN](https://xiaobot.net/p/offdesign)**，提供全文试读。
================================================================
# Salesforce 的生成式画布，证明了 AI 在产品界面设计中的可行性？
- **发布日期**：2024-11-04
- **原文链接**：https://www.thefivekey.com/salesforce-generative-canvas-proves-ai-ui-design-feasibility/
- **Markdown 原文**：https://www.thefivekey.com/salesforce-generative-canvas-proves-ai-ui-design-feasibility/index.md
- **标签**：设计系统, 设计 AI, 生成式 AI, 工具产品
> 前两年，生成式 AI 一度在界面设计领域备受瞩目，但随着实验效果不佳，这种热度逐渐消退，许多国内设计工具产品也减少了关注。然而，Salesforce 的生成式画布却让我们看到了新的可能性。那么，它究竟是如何做到的呢？
> **TL;DR**
>
> Salesforce 的 Generative Canvas 给生成式 AI 在产品界面设计中找到了一条可行路径：它不是凭空生成 UI，而是基于成熟的 Lightning Design System 做约束式生成。
>
> 这恰好回答了过去两年 AI UI 工具失败的核心原因：缺乏可依赖的设计标准、缺乏对业务逻辑的理解。
>
> 设计系统才是 AI 生成 UI 的真正前提。
在上一期的专栏文章中，我们讨论了生成式 AI 在产品界面设计中遇到的问题（详见 [产品界面的 AI 生成式设计，为什么没人关注了？](/why-generated-ai-ui-design-is-losing-interest/)），以及为什么还无法运用到日常的设计工作中。
## 生成式 AI 在界面设计中遇到的问题
总的来说，主要体现在两个方面：
### 01.缺乏可依赖的设计标准
界面设计不仅仅是视觉上的创意，它更需要强有力的逻辑支持。
我们可以明确地定义一只猫或一辆汽车的外观，但对于购物车界面或下单支付流程，缺乏具体而明确的定义标准。在缺少这些明确规则的情况下，生成的 UI 可能只是各种组件的简单堆砌，缺乏逻辑性和良好的用户体验。
相比人类设计师的成果，生成式 AI 产出的界面往往不够稳定，难以达到企业级的需求标准。
### 02.缺乏对业务逻辑的理解
我们日常的设计工作都是围绕着具体的业务开展的。而如今现有的设计模型都只是通用模型，无法理解具体某个业务的特性和复杂度。这就导致 AI 的生成结果难以满足设计要求，无法直接应用到具体业务生产环节中去。
这两个问题是当前生成式 AI 在界面 UI 设计方面发展的最大挑战。然而，我们也注意到，生成式 AI 在一些特定的业务场景中已经取得了显著的进展。比如，Salesforce 的生成式画布就是一个很好的例子，展示了生成式 AI 在企业环境中应用的潜力。
本期的文章，我们将从 Salesforce 的生成式画布开始，与大家来一起看看当生成式 AI 与业务进行融合后，会给我们的设计带来哪些变化，给用户又带来哪些帮助。
## Salesforce Generative Canvas
Generative Canvas（生成式画布）是 Salesforce 今年 10 月发布的一个新功能。它能够在 CRM 系统中基于用户的提示词，结合系统内实时业务数据来动态生成 Dashboard 的界面 UI。
它为用户提供了一种全新的工作方式，更灵活也更有效。只需要输入一个简单的指令，系统便会自动整合相关的数据，生成相应的画布界面。这极大地减少了用户在数据汇总、整理和设计界面时的时间和精力。
## 生成式画布解决了什么问题？
举个例子，一位售前支持人员准备与客户进行例行的月度沟通会议。
在过去他需要手动从不同的系统中提取销售数据、沟通记录、会议纪要，再整理好会议要讨论的议题，形成一个文档或 PPT。对于一个没有设计相关经验的人员来说，这需要花费大量的时间和精力。
而借助生成式画布，他只需要输入一个「生成与 X 公司的月度沟通会议的准备材料」，系统便会自动聚合相关数据，生成一个整洁、直观且实用的画布界面。
如果有需要，用户还可以进一步输入指令，让系统动态添加信息模块，比如某个地区的销售趋势或客户反馈数据。同时，生成式画布会基于信息重新进行界面的排版生成。
在过去，这种报表界面需要由平台来提供，或是由企业的管理员来进行手动配置。使用体验上很难照顾到所有人的不同需求。而生成式画布为用户提供了一种全新的工作方式，更灵活也更有效。
只需要输入一个简单的指令，系统便会自动整合相关的数据，生成相应的画布界面。这极大地减少了用户在数据汇总、整理和设计界面时的时间和精力。
Salesforce 的生成式画布给了我们一个很好的案例，让我们看到生成式 AI 在产品界面设计中是具有巨大潜力的。然而，生成式 AI 在界面设计领域的成功并非偶然，其背后有着深层的原因和逻辑。在我的付费专栏中，我将从以下几个方面更加深入地讨论这个话题：
01. 为什么 Salesforce 的生成式画布能够取得成功？有哪些独特的策略和技术支撑？
02. 用 Salesforce 的思路，我们的日常 B 端设计会有哪些改变？生成式 AI 是否能够带来设计效率的革命性提升？
03. 生成式画布成功落地的关键因素是什么？它和设计系统 又有哪些关联？
大家如果对生成式 AI 在界面设计方面的发展感兴趣
欢迎订阅我的付费专栏，来获得第 49 期的文章的付费部分内容，同时还将获取已更新的共 48 期付费专栏文章。
---
## 💡 延伸阅读
- 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
- 2023-09 [半年过去了，AI 设计的进展如何?](/progress-of-ai-design-in-ui-interface/)
- 2024-06 [一年过去了，AI design 的进展如何？](/current-trends-ai-design-in-interface-design/)
- 2024-10 [产品界面的 AI 生成式设计，为什么没人关注了？](/why-generated-ai-ui-design-is-losing-interest/)
- **2024-11 Salesforce 的生成式画布，证明了 AI 在产品界面设计中的可行性？ ← 你在这里**
- 2025-03 [从概念到落地，产品界面的 AI 生成究竟卡在哪儿了？](/ai-generated-ui-not-work/)
- 2026-04 [把设计系统变成 Markdown：让 AI Coding 真正读懂你的设计约束](/design-system-as-markdown/)
================================================================
# 产品界面的 AI 生成式设计，为什么没人关注了？
- **发布日期**：2024-10-21
- **原文链接**：https://www.thefivekey.com/why-generated-ai-ui-design-is-losing-interest/
- **Markdown 原文**：https://www.thefivekey.com/why-generated-ai-ui-design-is-losing-interest/index.md
- **标签**：设计 AI, 生成式 AI, 工具产品, 设计工具
> 生成式 AI 在界面设计领域，为什么渐渐失去关注？曾经热闹的行业风向为何突然“冷场”？企业纷纷出海寻找新机会，但现实真的如预期那般顺利吗？本文深入分析背后的原因和现状，解读生成式 AI 的挑战与潜在新方向。
> **TL;DR**
>
> 国内一年前还热闹的 AI 生成式 UI 设计工具，今年明显"冷场"了。
>
> 原因有四：AI 生成能力不足以应对真实业务复杂度、设计需求本身的业务深度、国内付费环境差、政策监管影响。
>
> 出海寻找新机会的公司，市场表现也并不乐观。
>
> 生成式 AI 在界面 UI 领域不是没机会，而是要重新定位场景。
不知大家是否有察觉到，曾经大受关注的界面 UI 的生成式设计，现在似乎有些“冷场”了。
一年多前，国内的几家设计工具平台纷纷砸钱入场搞生成式 AI，准备在 产品界面 UI 领域大展拳脚。而一年后的现在，大家都渐渐没了声响，产品界面 UI 貌似已不再是大家在 AI 方面的重点。
这个曾经的热点是被大家抛弃了吗？其实也并不是，只不过是大家都默默地调转方向，转向了海外市场。尝试去寻找商业化和技术发展更大的空间。有的平台选择专注于相对容易入手的“官网”型界面设计，以满足中小企业的基础设计需求；有的则退回到设计助理的定位，专注于通过 AI 来辅助设计师更高效地工作。
## 为什么会发生这样的变化？
我认为主要有以下几点原因：
### 01. AI 生成能力尚且不足
虽然每一款产品都给我们展示了一些看上去还很不错的生成界面，但这些“不错”还是仅限于 Demo 中。对于真实的复杂设计需求，如今的生成能力还是不太能达到预期。
如果大家仔细试用过这类工具，就会发现，除了官方展示的几个经过优化的案例外，用户在实际操作中无论如何调整提示词，生成的界面效果都不太好，甚至出现一些非常低级的设计错误。这使得生成式 AI 还是很难参与到真实的工作中。
### 02. 设计需求的业务复杂度
在真实的设计工作中，我们的设计需求通常会包含很多复杂的业务逻辑和用户流程，而这些都是当前的系统无法理解的。
于是，在真实的业务需求面前，这些通用的 AI 模型基本就派不上用场了。
### 03. 国内的付费环境不佳
国内的付费环境相较于早几年的确有很明显的改善，但也仅限于刚需类的工具产品。其他的产品在缺少真正核心竞争力的情况下，都经营得非常艰难。
但从企业的视角来看，它并没能直接替代设计师的工作，大家明显对于回报信心不足，因此企业很难愿意为其买单。
主要原因在于生成式 AI 的效果仍不够理想，无法满足真实场景的复杂设计需求。在付费环境不佳的情况下，企业难以看到明确的投资回报，自然很难愿意为之付费。
### 04. 政策监管影响
随着国家对生成式 AI 技术的监管力度的不断加强，大模型的开发和应用受到了诸多的限制。很多优秀的大模型能力很难被应用到产品中，这样使得产品的能力建设也受到不小的影响。
在这样的大背景下，大家纷纷选择了将产品出海，去探索更多的机会。海外市场尤其是欧美等发达国家，对于新兴设计工具和生成式 AI 的付费意愿显著更高，这为 AI 产品的商业化提供了更大的潜力。同时，海外的政策相对更加宽松，为产品的快速发展提供了更好的条件。
## 这些公司出海后的表现如何呢？
这些产品在上线初期，都在 ProductHunt 上获得了非常大的曝光，引起了不少用户的兴趣。通过 ProductHunt 的平台，它们迅速积累了一批早期用户和初步的市场关注。
这种曝光为产品后续的推广打下了一定的基础，但在初期的热度过后，大家目前的情况怎么样呢？目前来看，大家也都过得不太好。
在这些出海的工具产品中，我选了一家情况相对较好的产品（下面统称为产品 A），借助 Similarweb 做了一些对比分析。
虽然 Similarweb 的数据统计并不能绝对的准确，但在同一口径下还是能看到一些趋势情况的，具备一定的参考意义。
先抛一下分析的结果：
### 01. 市场占有率较低
产品 A 在设计类 SaaS 工具市场中的占有率较低，流量与头部企业如 Canva 和 Webflow 相差甚远，用户群主要集中在新兴市场（印度、巴基斯坦、尼尔尼亚等），占比达 45%。
### 02. 核心产品能力有限
产品 A 的在界面 UI 生成主要还是依赖于“模板库”，自身模型能力比较有限。因此在应对不同的真实设计需求时，能力还是比较单薄。
### 03. 盈利能力有限
用户主要分布在印度、巴基斯坦等新兴市场。与其可能预期的欧美市场相比，这些市场的用户付费意愿都比较低，即使活跃用户数大，但付费转化率难以形成有效的收入支撑。
设计类 SaaS 工具市场竞争是非常激烈的。在 Web Design 领域，排名前 100 的产品月活用户通常都在 300 万以上。在 Similarweb 排名第一的 Canva 有超过 7000 万月活（也有新闻报道已经超过了 1.9 亿）。
与产品 A 场景类似的 Webflow 有 700 万的月活，而在这个类目下排名前 100 的产品月活都超过 300 万。相比之下，产品 A 的月活跃用户只有 20 多万，与行业前列的竞争者存在明显差距。
在这种情况下，想要在海外市场的激烈竞争中分得一杯羹是相当有难度的。在能力方面，产品 A 是基于前端框架来提供的。本质上来说，这些生成结果是基于已存且成熟的模板来完成的。
对于产品官网这一类的界面设计，我们还是有不少已经比较确定的模式抽象，相对也比较成熟。但如果我们换到其它领域，比如让 AI 帮我们生成一个电商购物平台的界面，它的生成结果就不太行了。
这也是为什么我一直说，界面 UI 的生成式设计，在目前阶段还是非常依赖于行业标准化的建立。
另一方面，对于绝大多数的潜在用户而言，大家希望的是借助 AI 完成产品界面设计的工作，而不仅仅是一套皮肤。相较于 Webflow，它们所提供的 CMS 能力才更加贴近用户的真实需求。
最后再来聊聊付费市场的问题。对于 SaaS 类的产品，付费转化率行业基础水准大概在为 5% 到 10% 之间，而这还是在付费环境较好的欧美市场中。
产品 A 目前的流量主要来源于几个新兴市场，这其中印度（24.5%）、巴基斯坦（11%）、尼日利亚（9.37%）加起来占了 40% 多。
这些新兴市场的付费意愿度和价格敏感度则更进一步影响了其整体的盈利能力，使其商业模式的可持续性受到较大限制。
## 生成式 AI 在界面 UI 方面还有机会吗？
对于这个问题，我的答案是肯定的。但在这个过程中我们需要考虑的是，界面生成如何能解决企业在业务需求。生成式 AI 想要在界面 UI 方面有所进展，就必须与具体的业务需求紧密结合，与业务需求深度融合。
还记得早期介绍的 Salesforce 的 GPT 吗？它将生成式 AI 整合进业务工作流，帮助用户在推进业务的过程中生成所需的界面和功能。这类与业务流程融合在一起的生产能力，才可能为企业带来的实际价值，企业也才愿意为其的能力而买单。
前段时间一位做产品的朋友约咖啡。他原本来是想来了解一下生成式 AI 在设计领域目前的能力进展，结果大家聊着聊着变成了 AI 如何能够融入到企业的业务项目生产中，同时帮助企业降低内耗。
我们姑且称之为“去中心化”的产品研发设计吧。这是一个很有趣的话题，大家一个多小时聊下来，逻辑上还是具备可行性的。
它同时也需要时间，去等待技术能力的进步，等待产品、设计、研发等角色之间协作模式的演变。这可能是生成式 AI 真正能落地在企业中发挥其价值的一个重要方向。
回来后我花了些时间重新梳理了一下，从「去中心化产品研发设计」的逻辑，以及它给我们的工作方式变化以及调整等角度详细的分析了一下我的一些思考。
大家如果对生成式 AI 在界面设计方面的发展感兴趣，欢迎订阅我的付费专栏，来阅读第 48 期的付费文章「去中心化的产品研发设计模式」。
---
## 💡 延伸阅读
- 2023-09 [半年过去了，AI 设计的进展如何?](/progress-of-ai-design-in-ui-interface/)
- 2024-06 [一年过去了，AI design 的进展如何？](/current-trends-ai-design-in-interface-design/)
- **2024-10 产品界面的 AI 生成式设计，为什么没人关注了？ ← 你在这里**
- 2024-11 [Salesforce 的生成式画布，证明了 AI 在产品界面设计中的可行性？](/salesforce-generative-canvas-proves-ai-ui-design-feasibility/)
- 2025-03 [从概念到落地，产品界面的 AI 生成究竟卡在哪儿了？](/ai-generated-ui-not-work/)
- 2026-04 [把设计系统变成 Markdown：让 AI Coding 真正读懂你的设计约束](/design-system-as-markdown/)
================================================================
# 设计系统究竟应该由谁来负责？
- **发布日期**：2024-09-25
- **原文链接**：https://www.thefivekey.com/who-should-own-design-system/
- **Markdown 原文**：https://www.thefivekey.com/who-should-own-design-system/index.md
- **标签**：设计思考, 设计系统
> 团队中谁应该负责设计系统？是设计师的附加任务、新人的练手项目，还是专门的团队？这个看似简单的问题在实际操作中往往是设计系统推进失败的关键卡点。本文从设计中台的实战经验出发，分析不同模式的优劣，以及如何为你的团队找到合适的推进机制。
> **TL;DR**
>
> 设计系统的卡点很多时候不在工作本身，而在「谁来负责」。
>
> 把它当成谁有空谁做的附加任务、或者交给新人练手，都会让推行变得困难。
>
> 设计系统不是一套文档，而是一套需要持续运转的机制：必须有清晰的所有权和稳定的资源投入，才能真正在产品研发流程中发挥价值。
## 设计系统所有权问题：为什么这么难？
在聊到设计系统这个话题时，很多人都有一个困惑。那就是在团队中，设计系统的工作究竟应该由谁来负责？这个问题表面上看似简单，但在实际操作中却远比想象中的复杂。
有些设计团队会认为，设计系统只是一套需要偶尔更新的文档，它只是在做项目时随手查找参考的工具。因此大家会认为，设计系统的工作并没有特别的重要，谁的资源相对空一些就安排谁来做。
我曾经也见过一些团队，会将设计系统的工作交给新入职的设计师。让新人熟悉团队和业务的同时也可以顺便梳理一下文档，分担一些工作。这种“谁做都行”的心态，最终的结果就是权责不清，导致设计系统的推进和落地变得异常艰难。
## 设计系统不是文档，而是一套需要运转的机制
在过往讨论设计系统的文章里，很多次和大家说设计系统绝对不能仅仅停留在一套文档的层面上。它必须在产品的研发过程中运转起来才能发挥出它真正的价值。这种运作的要求使得设计系统不可避免地与团队内以及上下游的协作关联起来。从这个角度来说，设计系统也不再是单一团队的责任，而是涉及到整个组织的流程和协作方式。
在设计中台的那个阶段里，我的团队非常重要的职责之一就是协作各个业务设计团队推进设计系统的落地。在这个过程中，我们看到了各式各样的问题。有的希望能快速迭代，有的希望极度收敛，还有的希望高度定制...
而这些看上去非常专业向的工作，很多时候出现的卡点并不是工作本身，而是其背后的机制和保障问题。直白点来说就是，这个事情究竟应该由谁来负责？
## 不同团队模式下的负责机制对比
在有的团队里，设计系统是设计师的“附加任务”，大家需要在完成日常设计工作的同时，负责系统的更新和管理，而在另一些团队，设计系统则由专人或者是团队负责。无论哪种，多多少少都会存在一些劣势，这些工作投入很多时候也不被业务所认可。
因此，在今天的文章中，我想从「谁来负责」这个问题切入，和探讨在设计团队中，设计系统究竟应该通过什么样的机制来推动。需要强调的是，每个团队的业务背景和工作模式不同，所以这里并不存在标准答案。这篇文章只是希望分享我的一些思路，能够为大家提供参考，帮助大家在各自的业务中找到合适的推进方式。
## 阅读全文
以上内容节选自OFF DESIGN 专栏 47 期文章「设计系统究竟应该由谁来负责？」。
> 💡 延伸阅读：
> - 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
> - 入门基础：[设计系统 · 我们为什么要做 Design System](/why-we-need-design-system/)
> - 角色演变：[成为架构型设计师](/become-an-architectural-designer/)
> - 推行话术：[如何向你的主管和团队介绍 Design System 的重要性](/how-to-prove-the-value-of-design-system-to-your-boss/)
欢迎加入我的知识星球，阅读本期文章全文内容以及过往所有文章。
================================================================
# 从 PRD 到设计稿，如何避免设计遗漏带来的坑？
- **发布日期**：2024-09-08
- **原文链接**：https://www.thefivekey.com/from-prd-to-design-draft/
- **Markdown 原文**：https://www.thefivekey.com/from-prd-to-design-draft/index.md
- **标签**：设计思考, 体验设计
> 设计师常被诟病"丢三落四"：界面流程有遗漏、特殊状态没考虑清楚。本文从一位设计师的真实绩效反馈切入，介绍 DRD（设计需求文档）的概念与方法，通过将 PRD 翻译成结构化的 DRD，系统避免设计交付的常见坑。
> **TL;DR**
>
> "丢三落四"几乎是设计师绩效中最常被吐槽的问题，但很多时候不是设计师不细心，而是缺少把 PRD 系统转化为设计的工作方法。
>
> 引入 DRD（设计需求文档）这一中间层，把 PRD 中的业务需求拆解为完整的设计任务清单（含状态、流程、异常分支），可以系统性减少设计遗漏。
## 篇首语
本期文章的这个话题源于与一位设计师的咨询。前段时间她刚刚经历了一次与主管的阶段性绩效 review，结果却让她有些失落。
她的主管给了她一个不太理想的评价，这其中有一点是日常做设计的过程中，总是会出现一些丢三落四的问题。要么是界面流程有遗漏，要么就是某些特殊状态没考虑清楚。无论是对接的业务方还是直接主管，都提到了这个问题，认为这个问题对项目的整体质量和速度都带来了一些影响。
对于这个问题，这位设计师她自己其实也有意识到，但还是会觉得有些委屈。在日常工作中，新需求一个接一个，很多时候产品需求文档也都还只是个初稿就提给设计了。加上项目的时间都十分的紧张，的确会出现一些考虑不全面的问题。
设计的前期其实都还好，但一旦进入到设计评审环节，研发团队加入进来后很多问题就都暴露出来了。而作为设计师提案者，自然也受到了大家的很多质疑。这些问题更多是由于PRD的不完善引起的，但最后却落在了设计身上，似乎一切问题都成了设计的责任。
这种情况我相信应该很多设计师都曾遇到过。当我们从 PD 手上接过产品需求文档开始进入设计时，方案的合理性和逻辑问题就不可避免的转移到了设计师身上。如果我们在设计的过程中没能发现问题，那么一旦设计稿输出了，无论是产品的功能还是使用的体验，作为设计师我们都会有不可推卸的责任。
如今的产品，复杂度越来越高，特别是哪些涉及到特定的业务逻辑的产品设计，难免会在设计的过程中遇到一些考虑不周或有所遗漏的情况。面对这样的情形，想要完全避免错误的确是件很难的事情。但我们还是可以借助一些流程和方法来尽可能的帮助自己减少这些问题的发生。
在本期的文章中，我想从产品需求文档（PRD）和设计需求文档（DRD）这两份文档出发，来和大家聊一聊在设计过程中的一些思路和方法，帮助我们能够更好地把控设计过程，在设计交付的时候更好地应对来自各方的挑战。
## PRD vs DRD
在我们日常的设计工作中，很多设计师会遇到“设计遗漏”的问题，实际上，这种问题与两个非常重要的文档密切相关：PRD（产品需求文档）和 DRD（设计需求文档）。
对于设计师而言，理解这两类文档并做好 PRD 向 DRD 的转化非常重要，它将直接影响到我们的设计能否完整且准确地满足产品需求，避免设计遗漏的发生。
## PRD 和 DRD 有什么区别
PRD 是我们在设计工作中最常接触的一类文档，产品经理会从业务和市场的角度描述产品的需求，在PRD 中详细列举产品的目标、功能、用户场景和技术约束。有些产品经理还会附上一些自己线框图，来表达自己对产品设计的一些想法。
在 PRD 文档中，虽然产品经理详细的描述了需求，为设计师的工作提供基础方向，但它始终不是专门面向设计师的交付。大家可以想一想，对比我们在设计交付给研发环节时的设计说明文档，其实 PRD 对设计工作的“友好度”是很差的。
这就意味着，如果我们的整个设计过程是完全依赖 PRD 去完成，这个过程是并不顺畅的，因为它的“格式”与我们的设计工作并不兼容。
为什么会出现这种情况呢？这里有非常核心的一点，PRD 是从产品和市场的视角出发，描述的是业务层面的需求，它所关注的是产品要实现什么功能、满足什么样的用户群体以及如何推动业务目标的达成。
如果设计师完全按照 PRD 所描述的功能需求一步步执行，那么在设计过程中很可能会遗漏掉一些关键的设计细节，或者由于对需求的理解不够深入而产生考虑不周全的问题。这是因为 PRD 仅仅提供了业务层面的框架，忽视了设计中的需求，这就是为什么设计工作中经常会出现设计遗漏的原因之一。
而设计需求则是完全是从另一个视角出发，更多地关注用户体验、交互逻辑、视觉设计等细节问题。可以说，PRD 是宏观的方向，而设计需求则需要更微观和具体的落地。所以，如果我们只是单单对照着 PRD 去进行做设计，就会容易遗漏掉一些关键的设计细节或是思考不全的问题发生。
## 阅读全文
以上内容节选自OFF DESIGN 专栏 45 期文章「从 PRD 到设计稿，如何避免设计遗漏带来的坑？」。
> 💡 延伸阅读：
> - 设计的业务价值表达：[设计的意义，得用业务语言讲明白](/design-business-value/)
> - 业务思考的起点：[业务思考力，设计师跳出执行的起点](/business-thinking-for-designers/)
欢迎加入我的知识星球，阅读本期文章全文内容以及过往所有文章。
================================================================
# 进入新行业，如何校正你的产品直觉
- **发布日期**：2024-07-03
- **原文链接**：https://www.thefivekey.com/calibrate-your-product-intuition/
- **Markdown 原文**：https://www.thefivekey.com/calibrate-your-product-intuition/index.md
- **标签**：设计思考, 求职面试
> 当进入新领域时，行业特性和用户需求的差异可能使过去的产品直觉不再可靠。设计师需通过学习和研究来校正直觉，避免依赖过往经验。本文从一次真实的面试案例切入，拆解产品直觉是怎么形成的，以及跨行业时如何快速校正。
> **TL;DR**
>
> 设计师跨行业（比如从电商到医疗）时，过往的"产品直觉"可能会失效，因为直觉是在具体领域里慢慢建立的。
>
> 本文从一次面试案例切入，讲清楚产品直觉的两个来源（用户代入 + 领域深耕），以及如何主动校正直觉，让跨行业 landing 更顺滑。
上个月的一次模拟面试中，一位同学聊了一下她的上一次面试的经历。这是一次线下的面试 ，面试官和 HR 一起参加。前面的环节聊得都还不错，但在最后结尾时 HR 的一个问题让她有点卡壳了，感觉自己回答得不是很好。
这位同学之前的工作经历都是在电商领域，而这次面试的是一个 toB 的医疗领域，这与她过往的业务领域截然不同。HR 问，虽然你在之前的领域里经验很丰富，但如果来到这个全新的领域，你如何能确保自己的经验和对产品的嗅觉还是同样有效呢？因为之前没有考虑过这个问题，都是将重心放在案例上，以至于一时间没能很好的组织语言，回答得磕磕绊绊。
先撇开 HR 的这个问题。其实转换领域对我们所有人来说都是一个很常见的现象，我们的职业生涯有几十年，不可能一直都处于同一个行业中。面对不同业务、不同行业的用户需求，如何让我们的专业能力和经验能够“平移”到下一个领域中的确是一个需要思考的问题。
我们做设计的经验和感觉往往都是基于在某个特定领域中长期工作而慢慢形成的，无论主动或被动，它都会慢慢的累积，形成对某一领域的直觉，也就是我们的产品直觉。
当我们进入到一个全新领域的时候，这个行业的特性和用户的需求可能是不一样的，比如前面提到的电商 vs 医疗。这个时候我们过去的产品直觉就可能会变得不在可靠了，我们不能再依赖过去的经验和直觉来做设计，而是需要通过学习和研究来校正我们的产品直觉。
这是所有设计师在进入新领域时都需要面临的问题，有些人会在“犯错”中逐步修正，而有些人会主动借助方法来进行快速地校正，来帮助自己更快更好地 landing 到新的业务中。
## **产品直觉是如何形成的**
我们的产品直觉是如何形成的？这个问题我认为可以从两个方面来看，一方面是我们自己作为用户所代入的体验，另一方面则是我们对具体领域或产品的深入理解而形成的。
产品直觉的一个重要来源就是我们自己，作为一个真实用户的使用体验。以前面这位同学过去的电商领域为例，基本上我们大家都是这个领域中的用户。我们可能媒体都在发生在线购物的行为，因此我们对这个领域有着天然的理解和直觉。
以上是本期专栏文章的节选部分，这次我想和大家聊一聊产品直觉，看看如何借助方法来快速校正我们的产品直觉，帮助我们更快的进入到新的领域中。
> 💡 延伸阅读：
> - 新工作入职的提问艺术：[入职新公司，学会问问题才能少踩坑](/ask-questions-when-starting-new-job/)
> - 跨行业面试的作品集策略：[设计师的简历作品集应该关注什么？](/how-to-effectively-present-your-resume-portfolio/)
================================================================
# 用 AI 重命名截图 – Keep it shot
- **发布日期**：2024-06-19
- **原文链接**：https://www.thefivekey.com/use-ai-rename-screenshots-keep-it-shot/
- **Markdown 原文**：https://www.thefivekey.com/use-ai-rename-screenshots-keep-it-shot/index.md
- **标签**：工具产品
> Setapp 最近新上架了一款工具 - Keep it shot，功能很简单，用 AI 来进行图片的批量重命名。从结果上来说还是不错的，基本都能比较好的还原出图片的本意。虽然 Keep it shot 的介绍是对截图进行重命名，但事实上基本的 PDF、Word 文档之类的也可以使用，效果也还不错。
> **TL;DR**
>
> Keep it shot 是 Setapp 上的一款 macOS 小工具，用 AI 视觉能力把无意义的截图文件名（如 `Screenshot 2024-06-19.png`）批量重命名为内容描述。
>
> 除了截图，PDF/Word 也支持。
>
> 每月用量有限，但作为工作流"小补丁"非常实用。
Setapp 最近新上架了一款工具 – Keep it shot，功能很简单，用 AI 来进行图片的批量重命名。
## AI 重命名效果
先看结果，下图中上面四张是 Keep it shot 用 AI 能力重命名后的图片，下面是与之对应的原始截图文件。从结果上来说还是不错的，基本都能比较好的还原出图片的本意。当然，这个对目前的 AI 能力来说并不是什么难点。
另外，虽然 Keep it shot 的介绍是对截图进行重命名，但事实上基本的 PDF、Word 文档之类的也可以使用，效果也还不错。
## Keep it shot 功能介绍
Keep it shot 也支持批处理，我选择了 5 张图片一次性重命名。处理的时间基本就是我们现在和 ChatGPT 的响应时间，速度上可以接受。不过由于 Credits 有限，就没有做更大量的测试了。
我所使用的 Setapp Family 计划一月只有 50 个 Credits，简单使用问题不大。如果有大批量的需求，我们也可以使用自己的 API 来进行操作。Keep it shot 目前可以提供 OpenAI 和 Azure 两类 API 的接入。
## Keep it shot 的定价
Keep it shot 可以一次性买断，并提供 500 个 credits，更多的部分则需要接入自己的 API key。当然，你也可以选择他们的[订阅模式](https://keepitshot.com/pricing)，获得更多的使用次数。
就功能而言，这个价格并不便宜，如果没有对这个功能有特别强的需求，我觉得用用 Setapp 提供版本的也就行了。
================================================================
# 设计系统中的决策树：让设计决策更简单
- **发布日期**：2024-06-18
- **原文链接**：https://www.thefivekey.com/design-system-decision-tree/
- **Markdown 原文**：https://www.thefivekey.com/design-system-decision-tree/index.md
- **标签**：设计系统
> 决策树是把设计系统从"查手册"变成"可执行逻辑"的关键。本文从 AI 设计的发展现状切入，讲解决策树如何帮助设计师在多个组件之间做出准确选择，同时为 AI 大模型在界面设计场景中提供稳定的输出逻辑。
> **TL;DR**
>
> 决策树是让设计系统"真正能用"的关键机制，它把分散的组件规范变成可执行的选择路径，既帮设计师做对选择，也为 AI 大模型在界面生成时提供稳定逻辑。
>
> 结合 AI 的发展趋势，决策树正在成为设计系统 AI 化的重要基础。
## AI 设计近一年来的发展
过去的这一年里，AI 在界面设计方面的发展似乎很平淡，无论是国内还是国外都少有新的突破性产品发布。这种“沉寂”其实也并不意外，从大家惊叹于 AI 的可能性到真正认识到它的可行性，无论是资本还是用户都会逐步的回归理性。这其实也是给了 AI 设计类产品一个理性的发展空间。
在这段时间里，无论是海外还是国内的产品，大家都开始考虑将大模型和设计系统 进行结合，为 AI 在界面设计领域的发展寻找一个有效的支撑。
其实在过去的好几篇文章里，我们都讨论过这个问题。一个强大的设计系统 可以为AI 界面生成提供强有力的帮助，但这个演进的过程并非是直线前进的。
设计系统的复杂性和多样性需要大模型具备理解和运用这些系统的能力，但这其中的难点在于，虽然大多数设计系统都具备完备的文档系统，文档中也详尽地陈述了所有的指引和规则，但它却缺乏一种直观的方式来帮助用户或（模型）来快速理解和运用。
## 设计系统 中的决策树
最近在网络上查阅资料时发现一个很有意思的文档。与其他的设计系统不一样的是，它引入了一个新的能力（或概念） – 决策树。目的是帮助用户，特别是非专业设计人员，能够更清晰地理解实际项目设计中应该如何选择合适的组件来完成业务的表达。
通过设计决策树，复杂的 设计系统 可以被拆解成一个个易于理解和判断的节点和路径，将设计系统中潜藏的逻辑和规则，以一种更具结构性和导向性的方式呈现出来。这种方法不仅能能降低用户的学习曲线，还使得设计过程更为准确和高效。
同时，在AI领域决策树的可以成为大模型学习的一个非常重要的补充。让 AI 更好的理解需求，在复杂的设计场景中做出智能决策。
本期的文章，我想和大家聊聊决策树在设计系统中的应用。我们将深入探讨如何利用决策树来简化和优化设计过程，尤其是在面对复杂的设计选择时，它如何帮助用户（包括非专业设计人员）做出准确的决策。
我们还会尝试按照这种方法，自己创建一个用户通知的决策树，看看如何在实际操作中将决策树应用于界面设计，并讨论决策树在AI界面生成中的潜力和可能性，探讨它如何为大模型的智能化设计提供强有力的支持。
## 更多全文内容
以上内容节选自「OFF DESIGN」专栏第 41 篇专栏文章「#41 设计系统中的决策树：让设计决策更简单」。
> 💡 延伸阅读：
> - 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
> - AI 与设计系统结合：[从概念到落地，产品界面的 AI 生成究竟卡在哪儿了？](/ai-generated-ui-not-work/)
> - Salesforce 案例：[Salesforce 的生成式画布，证明了 AI 在产品界面设计中的可行性？](/salesforce-generative-canvas-proves-ai-ui-design-feasibility/)
> - 模式 vs 组件：[设计模式库与设计组件库到底有什么区别？](/difference-between-design-pattern-and-design-component/)
成为会员您将获得本文全文内容，以及已更新的 40 篇专栏文章。
================================================================
# 一年过去了，AI design 的进展如何？
- **发布日期**：2024-06-07
- **原文链接**：https://www.thefivekey.com/current-trends-ai-design-in-interface-design/
- **Markdown 原文**：https://www.thefivekey.com/current-trends-ai-design-in-interface-design/index.md
- **标签**：设计协同, 设计 AI
> 一年时间，AI 在 UI 界面设计的浪潮经历了从狂热到沉寂的转折。本文从设计的复杂性、产品设计的难度层级、企业与设计师的真实期望，到 AI 设计能力的双向发展路径，系统梳理 AI Design 在界面设计领域的真实进展，回答"为什么 AI 还没真正取代 UI 设计师"。
> **TL;DR**
>
> 一年过去了，AI 在 UI 界面设计上的进展并不如最初想象的快。
>
> 原因不在于 AI 不够强，而在于"界面设计"这件事本身的复杂度（业务导向、设计目的性、通用与特定标准、持续迭代）远超模型能直接处理的范围。
>
> 未来的发展不是单一替代，而是「平台型」和「定制型」两条路径同时演进。
去年年初 AI 浪潮席卷了整个科技互联网领域，从海外的 UIZard 到国内的即时设计、MasterGo，大家都在不断尝试探索新的模式将 AI Design 与 UI 界面进行结合。我也一直都在密切关注着它对设计行业所带来的变化，特别是在界面设计领域。
时间一转眼已经到了 9 月，尽管前面提到的这几家公司在文生 UI 领域都投入了大量的资源和精力，也获得了一些初步的成果，但就目前的结果来看 AI 在界面设计方面依旧处于一个比较初级的阶段。与此同时大家可能也会发现，这几家公司对这方面的发声也在慢慢变少，整个领域似乎进入了一个相对沉寂的时期，这股热潮似乎在默默的消退。
上周与一位老同事喝咖啡，一起深入探讨了一下当前 AI 设计的能力进展、现实中客户的真实需求以及未来的发展趋势。回来后我又重新整理了一下思路，想在这篇文章中，与大家分享一些我对当前AI 界面设计的思考和想法。
## AI Design 在 UI 界面设计的复杂性
与创意设计领域中 Stable Diffusion、MidJourney 飞速进化相比，AI 在 UI 界面设计上的能力进展显然是缓慢的。
创意设计侧重于高概念的构思发散，而界面设计则是深入到具象的业务实现。这也就意味着从产品逻辑到交互模式，都是需要基于深入的用户洞察和对业务逻辑的细致理解。
这种差异化和复杂性为 AI 在界面设计方面的发展带来了巨大的挑战，迫使我们需要做更多深入的研究和基础建设才有可能获得实质性的进步。这里我们可以展开细说一下：
### **01. 业务导向的多维度设计**
UI 界面不仅仅是产品功能的呈现，它还更需要综合用户需求、数据反馈来进行设计从而向达成业务目标前进。
这也就意味着在设计的过程中我们不仅需要关注产品的界面美观和使用体验，还需要考虑如何结合这些背景信息来进行产品的设计。这就让设计变得不那么“纯粹”，也没有足够明确的规律可遵循，更多的依赖于人的判断。
### **02. 复杂的设计目的性**
相较于创意设计，UI 界面设计的目的性会复杂得多。每一个界面都可能需要满足用户不同场景下的多个诉求。
例如，一个电商平台的商品列表页不仅要向用户直观地展示具有吸引力的商品，还需要向用户提供商品的筛选 & 比价、加购 & 凑单以及平台的功能导航等不同场景下的用户使用路径，而这些功能在不同的状态下可能还会存在不同的逻辑。
这些需求的层层叠加会让产品的界面设计变得异常复杂，这就要求设计师在界面的布局和功能分配上进行精细的权衡，确保用户在不同的场景下都能快速找到自己需要的功能模块并完成后续的操作。
### **03. 通用与特定的设计标准**
就像之前在设计系统 的话题中我们一直讨论的，不同的行业和具体的业务中，都会存在其特有的设计需求和习惯。比如金融类产品中需要强调正式感和安全性，而社交娱乐型产品则更关注轻松、互动性的交互氛围。
系统级的设计系统为我们提供了普适性的界面设计原则和交互标准，但它无法为特定的业务提供具象的设计指引，更别说体现产品的品牌特性和“人设”了。这也就要求设计师针对于特定的行业、用户进行深入的研究，定义出符合业务的品牌特性。
### **04. 持续迭代的设计过程**
产品的界面设计并不是一次性任务。它需要随着技术的进步、用户需求的变化以及市场环境的演变，来进行界面设计的不断优化和更新。这不仅仅是为了提供更好的产品使用体验，也是为了适应业务的发展和变化，确保产品始终保持竞争力。
由此可见，UI 界面设计是一个复杂且多维度的设计过程，涉及范围大、业务耦合度高，AI 想要在这个领域中真正的占有一席之地是还是非常难的。
过去的时间里，我们对 UI 界面设计的 AI 能力聊得还比较“宏观”，围绕着 AI 的潜在能力和可能性上。这其中的能力层次以及具体的困难，实际上大家探讨得都不多。今天借这个机会，正好也和大家聊聊我自己的理解。
## 产品设计的难度层级
如果将一个产品从设计工作的视角进行“解构”，我们大概可以将其拆解成组件、模块、页面、流程、功能及应用六个难度层级。
- 应用：代表整个产品或软件，涵盖了一个业务单元中所有的功能和特性，也是产品体验的总体框架；
- 功能：产品的核心功能，它是产品为用户提供的主要价值点，影响了产品的主要用途和目标用户群体；
- 流程：用户为完成某项特定任务时的产品互动路径，流程设计的优劣很大程度上影响了用户的操作体验，决定了用户完成任务的效率和对产品的满意度；
- 页面：产品功能的具体界面或视图，是用户号与产品互动的主要场景，它的设计将直接影响到用户的具体感知和体验；
- 模块：页面中的特定区块或组合组件，在设计过程中会被大量的重复使用；
- 组件：页面构成的基础元素，如输入框、按钮、文本、富媒体等，是构件页面体验的最小基础单元。
在现实的工作场景中，它们的设计难度是由左至右依次递增的。即便是不考虑业务属性叠加的情况下，想要很好地完成这些层级的设计，对 AI 来说也依旧有很大的挑战。
在「应用」这一层级上，当前 AI 的能力显然并不具备可行性，所以在接下来的讨论中，我们会暂时忽略它，将重点关注从组件到功能的这五个层级中。
### 功能 vs 组件，两个极端
撇开应用不聊，功能和组件是整个难度层级中的两个“极端”。
功能的设计需要将用户需求、业务目标进行整体思考。它不仅仅页面、流程的组合，还需要关注它们的可用性、逻辑性，确保产品的使用体验能够满足用户的实际需求。
相比之下，组件的设计更加具体和微观。它关注的是单一的组件或部分，比如一个具体动作的交互形式、风格色彩、甚至是一个 icon、一句文案。这些元素虽然在设计中起到了基础的作用，但它们本身并不涉及过多复杂的逻辑，并且在互联网的长期发展中已经形成了基础标准。
这也是为什么在基于组件的模块和简单界面设计上 AI 的应用效果尚可的原因。通过对大量物料的学习和专家经验的植入，AI 可以快速的生成大量各种风格的模块和界面。
但一旦涉及到具体的产品功能或流程，AI 则需要更多的上下文背景、行业知识以及更为深入的用户和业务洞察。以当前的情况来看，想要很好的实现这部分需求，在能力上还是有一定差距的。
### 流程和页面：AI 设计的“中间层”
在功能和组件之间，我们还有非常“硬核”的两个部分，即流程和页面。页面是用户与产品进行交互的主要界面，而流程则是用户完成某个任务所需要的界面的集合，并且还具有更为复杂的业务逻辑。
流程设计关注的是用户如何通过不同的步骤或操作来完成特定的任务。这需要对用户的需求、行为模式以及可能遇到的障碍有深入的了解。
例如，一个购物网站的购买链路会包含选择商品、添加购物车、选择地址、选择支付方式等一系列的步骤。这其中的每一个环节都需要尽可能的考虑到用户操作的易用性和对促进购买的引导，已达成提升购买转化率的目的。
页面设计则更加具体，它关注的是如何将各种元素和组件组合在一起，形成一个统一且和谐的界面。这包括了页面的布局、模块和交互形式的选择以及色彩的搭配、文字的排版等工作，为用户提供一个预约的使用体验。
在现实工作中，流程和页面的设计是绝大部分设计师都具备的能力，它需要设计师对于业务、数据、用户的理解。但对于目前的 AI 能力而言，即没有这些信息的输入，也没有足够的理解能力，这些依旧属于难以达成的“极端”。
## AI 的当前能力与用户的真实需求
随着技术的进步和市场的不断“炒作”，AI 被快速地推向了实践、落地。然而这种现象并没有给这个行业带来太多积极、正向的影响，反而进一步加剧设计师工作环境的变坏，同时也让很多人对 AI 的能力开始产生质疑。
### 企业对 AI 设计的期望
在当下的经济环境中，大多数企业都在想方设法尽可能的降本提效。而 AI 作为当前最大的热点和风口，势必会被很多的企业的管理者所关注，将它看作是解决设计成本投入的一个很好方法。
但是在目前，最让人担忧的其实并不是 AI 本身对设计师所带来的冲击，反而是很多管理者对 AI 能力的认知偏差从而导致对团队带来的一系列负面影响。事情没弄成，反而把团队、业务搅得一团糟。
最近的这段时间里与一些企业的管理者有过一些交流，他们大多数来自产品、市场或技术领域，对设计其实都并不太了解。
大家似乎都有着一个共同的观点，认为 AI 设计可以帮助他们至少在部分场景中直接替代掉设计师，有的甚至已经开始用一些 AI 产品来替代设计师，但最终发现事实和他们所预想的并不太一样。他们并不了解的是，AI 在设计领域的应用和发展，其实还处在一个比较初级的阶段。
顺带聊两句，虽然这些企业都有自己的设计团队，但他们几乎都没有从自己团队中获取到对设计行业及其发展的了解，所以也只能按照自己的理解和工具平台的介绍来自己做决定了。设计师们则被自然而然的当做了“工具人”，当更合适的工具出现时，他们就可能成为牺牲品被淘汰掉了。
在国内的环境中设计一直都是一个相对位置边缘一些的岗位角色，设计的价值很容易被公司和管理者所忽略，这个问题其实无论是在小公司还是大厂都一样。所以，如果不想自己不明不白的轻易地被取代，就需要设计团队 Leader 或设计师自己多一些给公司管理者的“布道”。不要有过多的顾虑，机会还是只能得靠自己争取来。
再回到我们的话题里来。对于企业而言，他们的期望的是通过 AI 能够帮助完成大部分的设计工作，可以将更多的资源投入到产品的研发和市场推广中。但事实上以 AI 现有的能力，它最多只能覆盖组件、模块和部分页面的工作，如果再考虑到叠加上业务自有的特性，这个效果可能难以满足要求。
真实的业务场景，设计师的工作与业务信息和数据高度关联，而几乎现有所有的平台型 AI 设计产品在这方面都还是“孤岛”。现有的平台型 AI 能力只能基于自有的数据进行训练和生成。这也是为什么我们现在能得到的生成结果如此“飞机稿”的原因，而飞机稿显然是无法直接参与到业务生产中的。
### 设计师对 AI 设计的期望
相较于企业对 AI 的期望，作为设计师大家还是会务实得多。和很多设计师探讨过这个问题，大家并不期望 AI替代自己的工作，而是希望 AI 能够成为他们的得力助手，在设计的过程中打辅助，帮助他们更高效地完成设计工作。
例如，设计师们希望 AI 能够帮助快速填充内容，这样他们就不必花时间来找寻文案或图片进行手动输入；希望 AI 能够自动生成界面的基本框架和模块，这样他们可以更专注于业务逻辑的还原和体验的优化，不必像我们在前面文章中聊到的那样面对「空白页综合症」。
还有在具体功能设计过程中提供可参考的Check list， 以及类似 MasterGo 已经在内测中的组件检查功能，以此来确保设计的完整性和一致性，减少设计过程中的错误发生。
总的来说，设计师对 AI 设计的期望更多地体现在如何提高工作效率上，而不是完全依赖 AI 来直接生成。同时大家也期望在设计的过程中 AI 能够提供一些辅助功能，为设计的交付提供一些有效的基础保障。
## **AI 设计的双向发展路径**
虽然前面我们说了这么多 AI 设计当前的问题，以及 AI 在设计辅助上的价值。但在我仍然相信在生成式的这条路上依旧充满了非常多的可能性。但如何选择其路径，还需要我们更为细致的探索和分析。
我们还是回到前面的产品设计中的难度层级，如果以「页面」作为中心点，我们会有两条完全不同的发展方向：
### **向右走 → 平台型 AI 能力**
第一条路径是“向右走”，以「组件」、「模块」为基础，「页面」为核心的平台型 AI 能力。这一类能力的特点是业务的耦合度相对较低，但对于设计的通用性和效率有着较高的要求，同时需求体量也相对较大。
比较典型的场景就是营销类的 Banner、主题页、官方站点以及偏后台的管理型界面。前段时间比较热门的 Dora AI 、特赞的 DAM 就属于这一类型。
VIDEO
在这条路径上 AI 设计的目标是帮助设计师或设计者（产品、运营、技术）快速搭建、优化UI 界面或模块。由于它们没有太多过于复杂的业务逻辑，从生产到使用的路径也相对较短，会更容易产出明确的价值。同时它也是设计师以外的群体最容易接触并理解的能力，会更容易获得市场的认可。
对于平台而言除了 AI 能力本身，最重要的是需要具备特定行业领域中的专业性，以确保 AI 生成的界面能够满足用户的需求。
如果你正好是平台型 AI 产品的设计师，那么就需要你对所服务的行业有深入的研究，了解它们的特性和核心诉求，将它们抽象成为平台 AI 的基础能力。同时还需要针对高频的需求进行“模板”的研究，以此来不断对模型进行训练和优化，覆盖到更多的需求场景。
### **向左走 → 定制型 AI 能力**
另一条路则是“向左走”，以「流程」为核心的定制型 AI 能力。这部分场景需要 AI 生成的界面能够直接参与到业务生产中，所以它需要对企业的业务及数据理解、确定性的设计规则有着非常高的要求。
相较于平台型 AI 能力，它更适合那些业务复杂度较高，需要高度定制化设计的场景，例如我们曾经提到的 Salesforce Einstein GPT 就是属于这一类型。
这条路径不仅仅是简单地生成界面，更多的还需要将业务的核心逻辑和思路准确的还原出来。所以，小到一个业务组件，大到一系列的交互模式在这里都需要能足够的明确。
由于涉及到企业的信息和数据，这类 AI 能力通常需要进行私有化部署，以达成与业务生产环节的真正融合。当然，以现在的平台能力而言，具备私有化部署的能力还为时过早，大概率还是企业内部自建会更早的出现。
在这条路径下，企业中的设计师将会成为这个 AI 能力最为重要的产品设计者。参与其中的设计师的定位和职责也会发生一些变化。
首先，设计师需要参与到策略的制定中，确定哪些部分应该由 AI 进行完成，哪些需要人工的介入。确保 AI 的应用能够真正为企业带来价值，而不是简单的替代人工投入。
其次，设计师需要成为训练师参与到 AI 的模型建设中。对业务规则和行业特性进行抽象，为业务 AI 能力的训练提供基础的数据支撑。与此同时，设计师还需要进一步将业务级的设计系统进行 AI 化，为界面的 AI 生成提供明确的设计约束。
在这个场景中，AI 设计的能力是不会孤立存在的，大概率会类似于 Salesforce 一样融入到业务生产的环境中。所以，设计师还需要兼顾一定的产品经理的工作，从产品的视角将 AI 设计工具融入到企业内部的工作流中。
## 写在最后
随着技术的发展与进步，AI 能力一定会逐步达成我们所期望的样子。无论是平台型 AI 设计还是定制型 AI 设计，它们都将成为领域中不可获取的一部分。如今我们所面临的大环境，只不过是加速了这一变化。
但同时我们也需要坚信的是，AI 并不能简单的取代设计师，而是在提高设计师门槛的同时成为我们的伙伴，协助我们更高效的完成设计工作。而设计师的角色和定位也会在这个过程中随之发生变化，从过往的设计实现转变为真正的产品设计者、AI 训练师、策略制定者。
在这个快速变化的时代，变化本身并不可怕。可怕的是在变化的过程中还在原地不动，错失了与时俱进的机会。
---
## 💡 延伸阅读
- 2023-09 [半年过去了，AI 设计的进展如何?](/progress-of-ai-design-in-ui-interface/)
- **2024-06 一年过去了，AI design 的进展如何？ ← 你在这里**
- 2024-10 [产品界面的 AI 生成式设计，为什么没人关注了？](/why-generated-ai-ui-design-is-losing-interest/)
- 2024-11 [Salesforce 的生成式画布，证明了 AI 在产品界面设计中的可行性？](/salesforce-generative-canvas-proves-ai-ui-design-feasibility/)
- 2025-03 [从概念到落地，产品界面的 AI 生成究竟卡在哪儿了？](/ai-generated-ui-not-work/)
- 2026-04 [把设计系统变成 Markdown：让 AI Coding 真正读懂你的设计约束](/design-system-as-markdown/)
================================================================
# 要不要自己开发一个设计协作工具？
- **发布日期**：2024-05-21
- **原文链接**：https://www.thefivekey.com/design-collaboration-for-team/
- **Markdown 原文**：https://www.thefivekey.com/design-collaboration-for-team/index.md
- **标签**：设计协同
> 在决定自研设计协作工具前，先思考四个问题：识别真实问题而非工具幻想、评估已有工具再考虑自建、与上下游团队达成一致、给自己设定清晰目标。本文基于多年设计协同产品的实战经验，给团队一份避坑清单。
> **TL;DR**
>
> 自研设计协作工具前先问四个问题：这是真需求还是新功能幻想？已有工具能不能凑合？上下游团队认不认这个方向？自己给自己设没设清楚目标？这四关过了再动手，能省 80% 的返工。
昨晚和一位设计师朋友喝咖啡，聊聊[设计协作](/tags/design-collaboration/)的问题。想起之前在专栏里写过的一段话，算是这些年折腾设计协同产品的一些感受吧。
## **识别问题，远比捣腾工具有效**
有些时候我们会因为某一款新工具（或个功能）而产生想要一些对工具自研的“幻想”。但这些想法往往只是对新功能的价值的假想，而忽略了团队中真实需要解决的问题。 所以，不要急着有了新想法就往里扎。先好好思考一下它是不是一个真需求。
## **工具不一定要自己造，选择一个合适的先开始**
我们经常会陷入到个性化需求的“陷阱”中，总想着针对性的为自己争取资源定制开发。这样往往会陷入大量的时间和资源的消耗，而且未必能达到预期的效果，最终可能给自己埋下一个又一个坑。 所以，不妨先挑选一个合适的工具先进行尝试，等到摸索出一段时间，验证后再考虑自己研发。
## **与上下游达成一致，不要自嗨**
协同不仅仅局限在团队内，更重要的还有上下游的相关人员。在探索协同效率的时候一定不要沉浸在自己的世界里，先将想法和上下游相关的同学聊一聊。 相信我，没有上下游的支持，自己搞设计协同是玩不转的。
## **不要盲目改进，给自己制定一个目标**
协同的目的是为了提升效率，这就意味着我们需要有一个明确的可衡量的目标，否则我们很容易陷入盲目的改进和迷失方向。
一定要先给这件事情定义一个清晰且有意义的目标（无论是定量还是定性），通过设定目标来持续监测改进的效果，并根据实际的情况进行调整和优化。
> 💡 延伸阅读：
> - 设计协同的宏观视角：[从 Adobe 收购 Figma 的背后看设计协同](/adobe-acquisition-of-figma/)
> - 设计系统作为协同基础：[设计系统 · 我们为什么要做 Design System](/why-we-need-design-system/)
================================================================
# 设计系统核心理论篇 – 布局框架
- **发布日期**：2024-03-29
- **原文链接**：https://www.thefivekey.com/design-system-layout-framework/
- **Markdown 原文**：https://www.thefivekey.com/design-system-layout-framework/index.md
- **标签**：设计系统
> 设计系统的布局框架是所有界面设计的骨架：顶部导航、侧边导航、内容容器、Z 轴层级。本文从 WWTF 原则出发，系统讲解设计系统布局框架的构建逻辑，帮你真正动手创建自己的设计系统。
> **TL;DR**
>
> 设计系统的核心不是组件库，而是底层的布局框架。本文拆解一个完整的布局框架应该包含什么：WWTF 原则（Who / What / Targets / Facts）、顶部导航、侧边导航、Z 轴层级。
>
> 读完本文，你应该能动手为自己的业务构建一套可用的布局骨架。
之前在 [OFF DESIGN 专栏](https://www.thefivekey.com/premium-design-subscription/) 中，用了好几篇文章来和大家探讨 设计系统 的定义、价值，以及我们该如何去规划、使用它。相信现在大家已经对设计系统这个命题有了清晰的理解，接下来我们就开始分板块聊一聊各个重要的组成部分，帮助大家搞清楚设计系统的核心逻辑。
## 设计系统 核心理论篇的思路
关于设计系统，目前能找到的教程或书籍并不太多。大家通常学习它的方法就是找一些设计系统的案例去分析。但这里有一个问题，所有这些设计系统对外开放的都是文档站点，它们都是按照工具书的逻辑来进行“平铺”呈现，重点在于方便大家查询使用，而不是教会大家如何自己动手创建。
所以，这一部分的内容我想换一个思路，将设计系统的各核心模块重新分类，拆解开。从一个用户的视角来进行讲解，尽可能让大家在读完这一整个板块的内容后，能够真正开始动手尝试构建自己的设计系统。
## 设计系统 的 WWTF 原则
我们先暂时把设计系统这个概念放一边，想一想实际场景中用户是如何使用产品的。
绝大多数场景，特别是 toB 端，用户都是在不同的功能模块下与系统进行交互，完成一个个的任务。
一个好的产品需要时刻让用户清晰的了解自己在哪儿、需要干什么，并且高效的完成工作。所以这里先和大家介绍一个概念 – **WWTF 原则**：
- Where am I？ / 我在哪儿？
- What should I do？ / 我应该做什么？
- Task / 我需要处理的任务。
- Feedback / 处理的结果和反馈。
**WWTF** 是我们在构建 [Fusion Design System](https://fusion.design/) 的时候定义的一个基本理论原则，目的是方便我们的业务设计团队在构建设计系统的过程中能够更好的理解产品设计过程中的核心要素。
在和业务设计团队合作的过程中我们发现，大家很容易一开始就将关注点放在样式、组件这些基础模块，不断的再揪着组件、规范，大家的关注点发生了偏移忽略了我们要解决的问题的本质。
基于 WWFT 原则，我们看待设计系统的角度就会发生变化。看似“平铺”堆砌在一起的这些资产就有了层次、重点，构建设计系统的思路也会变得清晰起来。
## 设计系统 核心理论
整个设计系统理论的部分，我会将大家日常在文档站点中看到的那些内容整合成布局框架、系统组件、Pattern 模式、产品风格、页面模板五大部分来给大家进行讲解。这部分也是整个设计系统专题中最为重要的部分，我也会花比较多的篇幅来讲解。
- **布局框架：**对屏幕空间进行规划和划分，定义各板块的具体用途；
- **系统组件：**基于基础组件库抽象并定义业务组件，解决用户人机操作效率问题；
- **Pattern 模式：**基于行业和业务特性进行模式的抽象，为解决通用问题提供可复用的设计方案；
- **产品风格：**基于色彩、动效、文案等“系统设定”构建产品风格体系，定义产品的风格和气质；
- **页面模板：**构建行业和业务可复用、可配置模板库，提升业务实现的效率。
以上这些内容大致需要十几期的篇幅来讲解，这一期的内容，我们先从布局框架开始。
## 设计系统 布局框架
之前我们做过一次调研，在 toB 端场景中用户对功能跳转逻辑、任务流程逻辑有着非常多的抱怨，这些问题导致用户产生极高的系统操作成本、效率降低。这也是导致很多产品体验评价差的重要原因。而这两个问题，都和布局框架有着非常密切的关系。
相较于 toC 端的产品，toB 端会更加的“严肃”。用户需要借助它来与系统进行交互，高效的完成所有工作。一个好的产品布局框架需要对空间进行合理有效的规划和应用，让用户能够更好更高效的完成工作。时刻都能够清晰自己在哪儿，需要做什么；快速的处理每一个任务，并且获取系统的有效反馈。
按照 toB 端产品最通用的模式，我们可以先将屏幕空间进行一个划分，将其分为顶部导航、侧边导航和内容容器三大部分。
### 顶部导航
顶部导航是一个产品的全局功能。通常情况下它会由产品的品牌名称、功能导航、站内搜索、系统设置以及用过个人信息等组成，用来指引用户去到系统的各核心功能板块。
大家可以试着找一些产品案例来仔细对比一下，你会发现无论它们使用怎样的组合模式和排列形式，大体上它们都是一致的。
注：上图为概念示意稿，后续图片同上。
### 侧边导航
侧边导航一般用作对顶部导航功能模块的扩展补充，引导用户进入该功能模块下的不同业务模块。侧边导航的交互比较简单，主要是以级联菜单为主。
关于侧边导航有一个点需要展开一下，侧边导航通常采用向下展开和向右展开两种模式，同时也支持收缩与展开，为内容区域留出更多的空间便于用户完成工作。今天的主题在框架和容器层面，所以组件的部分我们今天不聊，后面会再讲解。
整个导航体系（顶部 + 侧边）组成了产品的“壳”，通过对它们的操作来改变内容容器中的信息呈现，为用户提供与系统的交互，完成具体的每一项工作任务。
在产品设计的过程中我们经常会对所用的功能进行盘点梳理，它的目的就是合理的向用户呈现系统中的能力。导航体系中的体验核心其实是在对业务模块的定义和分类，大家需要基于业务的具体特性来进一步展开。
### 布局框架的 “Z 轴”
前面我们聊到的导航体系，它核心解决的是功能页面分类及跳转。在浏览器屏幕中通过操作进行页面的跳转操作，比如从 Dashboard 进入到某个 List 列表，再到某个 Detail 详情。
大家可以将这些页面间的跳转想象成一个平面上的运动，有了它们就可以将产品的基础操作串联起来。
但在 toB 端的实际场景中业务逻辑远比这些要复杂，仅仅靠这一层能力是不够的，我们还需要更多的能力来辅助实现业务需求，这就需要引入一个新的概念 – 布局空间的 Z 轴。
在空间布局引入 Z 轴的概念后，系统与用户的交互能力就得到进一步的提升。我们可以通过对 Z 轴空间的利用来减少页面间频繁跳转，提升用户完成任务的效率。
在这部分的设计中大家经常会听到一些名词，比如对话框、半浮层、全浮层、底部浮层、右侧浮层… 听起来很复杂、而且大家各自的用法还不一样，时间一久产品界面必然五花八门，用户也跟着开始迷糊起来。
其实看似这么多的展现形式，但究其根本也并不复杂。大家不要从展现形式上去看待它们，而是要从解决问题的角度来去理解。
**01. Z：页面内容**
Z 层是整个系统中最基底的一层， 通过导航体系和内容容器组合成页面内容，通过页面间的跳转为引导用户完成每一项工作任务。
**02. Z + 1：模态页面**
模态页面在 Z 轴上处于页面内容的上方，以浮层页面的形式为页面内容提供页面层级的补充。我们前面提到的底部浮层、侧边浮层、全浮层就属于这一类型，只是表现形式上有所差异。
**03. Z + 2：模态对话框**
模态对话框处于这个框架结构的最上方，主要表现形式为对话框。用于简单的信息交互和系统中断操作。
基于这三层结构，我们基本上可以把系统中的页面跳转和信息呈现的逻辑确定下来，绝大部分的产品通用场景都可以被满足。比如下图中从用户进入工作台到完成具体工作任务的完整流程。
以上这一套布局框架，基本上可以满足绝大多数的 toB 端业务场景。大家可以尝试着套用一些业务上的真实场景，针对实际情况做一些局部调整。
有了这一层“壳”的定义，我们设计系统的第一步就基本完成了。下一期我们将开始进入「内容容器」的部分，聊一聊页面上信息呈现的思考逻辑。
> 💡 延伸阅读：
> - 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
> - 学习路径：[设计系统学习指南 - 国内外 Design System 案例解析](/how-to-learn-from-other-design-systems/)
> - 深度案例：[如何规划 B端 设计系统？深度解析 AWS CloudScape](/b-end-design-system-deep-dive-aws-cloudscape/)
> - 基础视角：[设计系统 · 我们为什么要做 Design System](/why-we-need-design-system/)
> - 推行话术：[如何向你的主管和团队介绍 Design System 的重要性](/how-to-prove-the-value-of-design-system-to-your-boss/)
================================================================
# Notion Template · Daily Drafts with Voice and AI
- **发布日期**：2024-03-29
- **原文链接**：https://www.thefivekey.com/daily-drafts-journal-with-voice-ai-notion-template/
- **Markdown 原文**：https://www.thefivekey.com/daily-drafts-journal-with-voice-ai-notion-template/index.md
- **标签**：Notion, Notion 模板
> Daily Drafts Journal 是一个非常轻量的 Notion Template ，它可以通过语音输入和 AI 能力帮助你实现日常灵感的快速记录和总结，让你不会再在开车时、走路时想到的好想法被不小心丢失。你需要的只是打开 Notion，用语音说出它们即可，Notion AI 将帮助你完成记录和分析总结。
Daily Drafts Journal 是一个非常轻量的 Notion Template ，它可以通过语音输入和 AI 能力帮助你实现日常灵感的快速记录和总结，让你不会再在开车时、走路时想到的好想法被不小心丢失。你需要的只是打开 Notion，用语音说出它们即可，Notion AI 将帮助你完成记录和分析总结。你可以到晚上回家之后再对它们进行整理，归档到你的日记或知识库中。
## 我的日常应用场景
平常开车或走在路上，会突然有一些灵感和想法想要记录。一般情况下我会用 iOS 端的 Drafts 用语音来输入记录，晚上回家再整理归档。这次的模板就是它的 Notion 版。相较于 Drafts（应用），它的好处是可以借助 Notion 的 AI 来帮我们进行总结，提取任务。
## Notion Template : Daily Drafts Journal 介绍
### 用语音输入记录所有的灵感闪现
模板使用了一个数据库来记录每日的纪要，按时间排序。每天点击「**新增今日纪要** 」新增一条，将临时想到的事情用输入法键盘的语音识别功能说出来即可。
### **用 Notion AI 进行每日汇总，提取待办任务**
今日纪要页面中主要包含两个部分：
1. 记录今天发生的事情（下半部分）
这里是语音输入的每一条信息，当我在开车或是行走的时候我就会用它快速记录下我的一些临时的想法。
2. AI 汇总和任务提取（上半部分）
这里预制了一个 Notion AI 命令，主要用于对下方输入的内容进行信息的汇总和任务提取。当有新的信息录入后，我们只需要对这个 Notion AI 命令 update 一下即可。
## 每日汇总
去年开始，我的日常工作学习主要会借助以下三款工具：
- [HeptaBase](https://join.heptabase.com?invite-acc-id=113d3775-eb63-4166-8ecd-1c9d2c534894/)，用于日常知识的整理会归档
- OmniFocus，用于日常待办工作和任务的管理
- Craft，用于日常文档的撰写和管理
最后，每天晚上我会将 Daily Drafts Journal 中通过 AI 整理的信息归档到 HeptaBase 的画布中。（如下图）
顺便说下，HeptaBase 目前已经成为我日常使用频率使用最高的 Top3 应用。从去年内测开始使用一年多，它的确能够帮助我更好的管理自己的知识库。
关于 HeptaBase 的使用思路以及它和 Tana 在知识管理逻辑上的差异，我后来专门写了一篇 [Heptabase VS Tana，两种不同的知识管理逻辑](/difference-between-heptabase-tana/)，聊清楚了为什么我现在用「两套系统」来分别承载日常记录和深度研究。
## Daily Drafts Journal Notion Template 下载地址:
https://5key.gumroad.com/l/daily-drafts-journal-with-voice-ai-notion-template
模板完全免费。Enjoy！如果觉得还不错，还请到 Gumroad 上给我一个五星好评🫰
了解更多我制作的 Notion 模板：
[我制作的几款 Notion Template 模板](https://www.thefivekey.com/notion-template/)
================================================================
# 设计系统学习指南 - 国内外 Design System 案例解析
- **发布日期**：2024-03-28
- **原文链接**：https://www.thefivekey.com/how-to-learn-from-other-design-systems/
- **Markdown 原文**：https://www.thefivekey.com/how-to-learn-from-other-design-systems/index.md
- **标签**：设计系统, 设计模式
> 深入解析设计系统的核心概念与应用方法。通过 Ant Design、Fusion Design 等国内外经典案例，分解设计系统的系统级、领域级、业务级三大层级，并提供清晰的学习路径与实用指南，帮助你高效掌握设计系统的思维逻辑。
设计系统 分为是哪个不同等级**系统级→领域级→业务级**，大家可以用下面这张图看清楚它们的逻辑。从系统级到业务级，是对设计标准的抽象到具象，同时我们对设计的指引也是从基础认知转为更加具体的约束。
### 等级 1：系统级设计系统
系统级，顾名思义，就是操作系统级别的设计系统。当下的数字产品大部分是基于操作系统和浏览器所构建的，所以我们首先需要基于 OS 或浏览器级来开始工作。这里最常见的是 Google 的 Material Design、Apple 的 Human Interface Guideline 以及各种 Web 前端框架，比如 BootStrap。
配合硬件和软件技术的发展，系统级的设计系统为我们提供丰富的交互形式以及设计指引。同时它们也对用户的基础认知和使用习惯做出了定义和引导，确保了一个产品在基础交互层面的体验基准线。
其实我们也可以将它“简化”一下，将它们比作支付宝或微信的小程序就更容易理解了。支付宝和微信经过多年的运作累积了海量的用户和流量，于是很多的企业（或开发者）希望能够进驻到平台，为用户提供服务并获取响应的收益。
为了给用户带来一致、优质的服务和使用体验，支付宝和微信向企业（或开发者）提供一整套完整的设计指导原则和开发框架，也借此来帮助提升小程序的开发效率，降低产品的实现成本。而企业（或开发者）也会尽可能的去遵守它们的规则，以获得更好的业务上的合作扶持。
### 等级 2：领域级（行业级）设计系统
相较于系统级，领域级会更加聚焦于某一个领域或行业。比如 IBM 的 Carbon Design，阿里的 Fusion Design，蚂蚁的 Ant Design 以及字节的 Semi Design、Arco Design、腾讯的 TDesign。
如果对以上这些名字有过一定的了解，你应该发现它们基本面向的都是企业级应用场景，或者是我们常说的 B 端场景。为什么会是这样呢？其实还是在于 B 端产品相对来说更看重实用性和效率，比较适合对设计进行抽象。C 端的业务能做吗？逻辑上当然是可以的，只不过在目前来看，大家并没有能够达成一致。
这里的共识并不是说它简单、对设计的要求不高。而是在企业级的场景下，高效、一致、简洁等关键词是大家最为核心的设计原则，目的是让用户能够更为有效、轻松的完成当下的任务。再加上如今蓬勃发展的 B 端业务，设计系统的价值在这里可以得到很好的验证和体现。
领域级最重要的目的是能够帮助在这个行业中的产品能够快速完成 0 到 1 的产品建设。减少在前期工作中的浪费，让大家能够更加快速的进行对产品的迭代和市场的验证上。
领域级的产品比较多了，我们这里可以简单列举一些：
### 等级 3：业务级（产品级）设计系统：
我们前面说过，设计系统的等级从下至上是从抽象到具象的过程，而这个具象就是我们对业务中设计标准的明确指引。同时，业务级的设计系统往往也是我们设计师参与得最多的一类。它的定位很明确，就是基于行业和业务的特性来构建，一切都是为业务而服务。
**业务级设计系统的目的是提供明确的约束和指引，能够帮助业务快速的实现产品业务逻辑，避免不必要的浪费**。
同时它也需要具备良好的业务抽象和扩展性，有非常好的运作机制，能够提升整体业务生产链路的效率。在网络上我们能看到的业务级设计系统其实并不太多，AWS 的 CloudScape 是一个还不错的案例，大家有兴趣可以读一下下面这篇文章进一步了解。
### 业务级设计系统案例 - AWS CloudScape Design System
CloudScape Design System 是今年的 7 月底，AWS 正式对外发布的设计系统 。这是一套开源解决方案，可用于大规模构建云服务业务的的复杂 Web 应用。
这套解决方案其实早在 2016 年就已经在开始内部启动了，如果大家有用过 AWS 的产品，可能你已经默默的见过它了。
用户的核心工作是完成任务，所以尽可能保持沟通内容的简洁，减少用户认知的负担
给予用户控制权，减少对用户工作的打扰
控制好对 Flashbar 这类组件的使用，降低对用的视觉干扰
如何规划 B 端设计系统？深度解析 AWS CloudScape Design System的最佳实践
### 业务级设计系统案例 - 阿里巴巴 Fusion Design 和 蚂蚁 Ant Design
一种是基于领域级来构建，适合偏 Web 端的产品，有很好的 0 到 1 基础。重点关注行业领域的特性，去抽象业务组件、业务 pattern
另一种是基于系统级去构建，适合偏移动端的场景，直接业务级往上去做
这里在领域级，我推荐大家可以去使用阿里、字节、腾讯这几家的产品，因为迭代速度和维护有更好的保障。
## 我们做设计系统是要解决什么问题？
**这里我们再简单回顾一下这三类设计系统**
- 系统级：操作系统级别，提供最底层操作系统级的设计及研发指引；
- 领域级：聚焦于某一类通用场景的设计及研发指引，当前最为成熟的还是在企业级应用（B 端）场景；
- 业务级：基于系统级或领域级的二次加工定义，为具体的产品或业务提供设计及研发指引。
### 对于设计系统的思考变化
这里我们聊的思考变化不仅仅是指在设计师角度，更多的是公司的角度来看待设计系统以及它所提供的价值。
以前我们聊设计系统，很多都是设计师和前端从认知、从兴趣的角度出发来尝试更为先进的业务生产模式。而很多公司的管理者对它的理解是设计的一致性、设计体验的提升，而对于降本提效至少在工程上我们也并没有特别明显的价值产出。
#### 从企业经营的视角看待设计系统
这两年随着互联网红利的逐步消失、疫情的影响，成本、收益都都面临的巨大的考验，连各大互联网公司也不再放任大家去不断的“试错”。阿里在一年多前也逐步的开始对每个团队实行经营责任制，让大家必须认真思考每一次的资源投入。
虽然大家诸多抱怨，但宏观上来说我认可这是一件正确的事情。它也倒闭着团队管理者们通过更科学、高效的工作模式来运作团队，杜绝浪费。同时也就在这个时刻，因为业务的特性，一些企业级产品从相关方到管理者都开始重新审视它所能带来的价值，有些想清楚的也早早的开始并已经获得了相当明显的收益。
这里面的逻辑其实也并不复杂，给大家举个例子：某事业部 CTO 线的核心交付就是各类中台系统，宏观角度可以拿页面数进行计算。
> **单页面成本 = 平均工时工资 x 单页面交付时长**
这里提供了两个影响成本的变量，要么降低工时工资，要么降低单页面交付时长，但对于企业来说非常时期往往两手都得抓。平均工时工资不在我们的把控范围内，但单页面交付时长对于设计师和研发来说就有很多事情可做了。设计系统的投入和产出价值可以很清晰的算笔账，只要方案制定得合理，大概率这个 ROI 是满足预期的。
#### 从业务的视角看待设计系统
还是说回前面那次调研，你会发现产品经理的出现了，设计系统不再只是一个设计和研发的工作，产品经理也需要参与其中一起制定规则。
> 受访者中有 16% 表示团队中的参与者为设计师、前端工程师、产品经理。
产品经理为什么要参与？因为在设计系统的角度，设计师和前端工程师定义的是解决某一类问题的界面交互模式。而产品经理的日常工作是创建实例，解决某个具体业务流程问题。
想象一下产品经理在写 PRD 的时候如果是这样的场景：
> **这是一个新品报名系统**
> - 模块 1：注册登录
> - 模块 2：报名表单
> - 子模块 1：用户身份认证
> - 子模块 2：商家资质认证
> - 子模块 3：…
> - 模块 3：报名管理
> - 模块 4：商品管理
这背后每一个模块、子模块，除了交互模式上的定义，还需要从产品上进行业务逻辑的定义。好的业务级设计系统应该让产品经理将重心放在业务流程本身，而不必去关心某一个具体按钮、弹框。而作制定者也不用再整天纠缠在业务细节中，将工作的重心放在对业务 Pattern的抽象、制定中。
当然，这类模式并不是一件容易的事情。它首先需要设计师、前端工程师、产品经理达成共识：
- 我们需要的不仅仅是规范，还需要更多的确定性的“约束”，将达成的共识封装成模块供使用；
- 非必要情况下，我们要做无畏的“设计创新”，一切以切实解决问题为优先；
- 如果需要对制定好的规则进行改变，不要修改实例。去给已封装的模块提需求。
进入 AI Coding 时代后，这些"约束"还多了一种新的承载形式：把设计系统写成 Markdown，直接放进代码仓库让 AI Agent 读取。如果你希望自己团队的设计系统也能被 AI 真正消费，可以看看 [把设计系统变成 Markdown：让 AI Coding 真正读懂你的设计约束](/design-system-as-markdown/)。
> 延展阅读 👉 我们为什么要做设计系统
## 如何向公司、团队、主管介绍设计系统的价值
以上的这些思考不能仅停留在设计师群体里。在企业里工作，讲清楚一件事情的价值很重要，我们不仅需要自己先想清楚，还需要我们的合作伙伴、管理者也能理解，这样才能给我们推行设计系统给予更多的理解和支持。
产品型设计师和架构型设计师 。
当然，除了对我们的价值层面，我们还需要从更多的方面向公司去介绍它的价值。如果大家不太清楚应该如何去组织、表达，可以阅读下面这篇文章进一步了解。
> 延展阅读 👉 如何向你的主管和团队介绍 Design System 的重要性
> 💡 延伸阅读：
> - 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
================================================================
# 如何向你的主管和团队介绍 Design System 的重要性
- **发布日期**：2024-03-07
- **原文链接**：https://www.thefivekey.com/how-to-prove-the-value-of-design-system-to-your-boss/
- **Markdown 原文**：https://www.thefivekey.com/how-to-prove-the-value-of-design-system-to-your-boss/index.md
- **标签**：设计系统, 求职面试, 职业发展
> 设计系统 (Design System) 是当前设计领域最热门话题之一，但其价值并非所有人都清晰认识。本文以一份完整 PPT 为基础，从外部环境变化、阿里实战案例、设计系统的层级与构建思路、设计师角色演变等维度，提供一套向主管和团队推行 Design System 的完整话术框架。
> **TL;DR**
>
> 这是一份完整的「向主管和团队推行 Design System」的 PPT 分享内容，覆盖：为什么要做（外部环境变化）、阿里的真实实践案例、设计系统的三种层级、构建思路与三个阶段、以及设计师角色演变。
>
> 可以直接拿去给你的老板、团队同学讲清楚 Design System 的价值。
> 这是节前应邀进行了一次关于 [Design System](/tags/design-system/) （设计系统）的“布道”分享。我将 PPT 内容进行了一些细化和调整，在这里分享给大家。大家在对内进行宣导的时候可以以此 PPT 为基础，给你的老板、团队同学讲解为什么要做设计系统。
> 这次分享也是对过往前面几期文章的一个不同视角的“串联”，从这个视角再来回顾这几篇文章相信大家会有更多不同的理解。欢迎大家有时间读完后来群里进一步一起探讨。
## 本次 Design System 分享 PPT 的内容定位
设计系统的理论和案例，相信大家在日常工作中已经看过不少，也不是本次的分享的重点。因此这份 PPT 不聊细节，而是基于这些年在设计系统、协同过程中的一些感受来给大家聊聊我是如何看待设计系统的。
## 为什么要做 Design System：价值与外部环境变化
### Design System 的价值及重要性
### 外部环境的变化
互联网早已不是新鲜产物，我们生活的方方面面都已经逐步的互联网化。也正式因此，互联网公司也越来越受到国家政策、经济环境的影响，而身处互联网行业的设计师，我们工作也与之息息相关。
就近一年的观察，我觉得这三块变化和我们还是有很大的关联的，所以先拿出来和大家分享一下：
- 就像我们每个公司都有自己的目标，政府这个最大的平台也对近 5 年整个国家的数字经济发展有一个明确的目标。这四五十亿的预期增长目标的背后有大量的需求增加，显然依靠现有的生产模式是无法解决的；
- 今年大形势不太好，所有的企业都在做降本提效。降本很多团队都在做，但光降本还不够，提效同样也需要抓。我还在阿里的时候，你和人聊设计系统，人家没那么感冒。哦一下。你说这个东西可以提效，减少开发周期。那么大家眼前一亮，可以聊聊。
- 软件开源，也是十四五规划中非常重要的一点。如今的中美关系、国际形势使得大家的意识上越发的明确，国内企业、公司、政府不能长期依赖外部的产品和工具。开源是促进整体发展中非常重要的一环，互联网头部企业比如腾讯、字节、阿里都在其中承担着非常重要的带头作用。
### 一次关于 Design System 的调研
19 年的 Ucan，我做了一次关于设计系统的工作坊。大家都是带着好奇来参加的，真正在开展设计系统工作的团队并不多。而到了今年我做了一次调研，虽然有效样本只有 100 多个，但还是具备一些代表性的。大家可以看到无论是公司对设计系统的认知，还是投入的程度都有了非常大的变化。
关于这次的调研分析，大家可以进一步阅读设计系统 2022 调研总结
## 阿里 Design System 实践：真实案例与业务价值
### 在阿里 Design System 的真实案例
在阿里有两套主流的设计系统，分别是我们设计中台的 Fusion Design 和蚂蚁的 Ant Design。
两套设计系统都是差不多在 16 年左右启动的，发展至今它俩支撑了三大集团（阿里、菜鸟、蚂蚁）的全部数百条业务线。在一些我们重点合作的业务里，已经可以达成帮助设计师提效 50%，研发提效 30%的成果。当然，这些成果不只是源于设计系统，还需要有一系列的配套流程和工具。
### 设计系统的价值
在企业里工作，讲清楚一件事情的价值很重要，比如做设计系统就经常会面临很多人的疑问。19 年 Ucan 工作坊上我也收到过同样的问题，但我觉得当时回答的不太好，更多还是偏向于强调对设计、对设计师的价值。
但随着接下来这些年在阿里很多业务中的摸索，有成功也有失败，我认为从以上三个方面来回答这个问题会更容易获得大家的认同。
## Design System 的三种层级与案例解析
### 设计系统的三种类型
这些年业内出现了很多的设计系统，国内、国外有很多。大家在聊起设计系统时候经常会说起这家怎么怎么好，那家怎么怎么不好。为什么会有这些不同的开发？是因为大家所面临的问题以及对它们的定位有所不同。
比如字节的 Arco、Semi、腾讯的 TDesign，有很多人说他们过于简单，也缺少差异性。如果你带着对解决业务实际问题的角度看待它们，那确实很难满足大家的要求。因为他们的定位都是企业中后台的领域级系统，它的目的就是尽可能的减少同质化的基础工作，业务的部分并不在这套系统的目标范畴内。
有了这个定位的概念，我们就可以再来将我们曾经看过的这些[设计系统](https://www.thefivekey.com/tag/design-system/)做一下分类。（如上图）。从系统级→领域级→业务级，他们本质上是一个从抽象到具象的过程，大家可以关注一下这里，不同类型的设计系统在定义和要求上是有差异的。
对于我们绝大多数设计师而言，主要的工作都发生在业务级，基于一套底层的系统去构建符合业务述求的设计系统。比如阿里云的 BDesign，就是在 Fusion Design 的基础上“生长”出来的。
### 领域级设计系统案例 AWS CloudScape
AWS 的 [CloudScape](https://cloudscape.design/) 是近期我看到完成度最高，最值得大家学习的设计系统。总体来说我会将它的优点总结为以下三点：
**01. 内容简练务实，指导准确有效果**
相较于很多设计系统的站点，CloudScape 提供的内容非常简练，没有太多对这套设计系统设计理念、价值观的讲解，更多还是落在实际应用指导。它更像是一本面向实操的指导手册，每一个 Component 和 Pattern 都提供了清晰准确的定义、场景以及使用说明。而且大部分都提供了在线配置调试功能，帮助使用者更好的理解和使用。
**02. 定位明确，领域性强**
从 2016 年启动到现在已经有了 6 年时间， 经过了 AWS 这么多年业务中的打磨后 CloudScape 给我的一个感觉就是清晰和明确。特别是在 Pattern 的部分，35 个虽然不算多，但基本都是这个领域的内的一些标准场景的抽象。基本上云产品业务需要的场景它提供了指引，相信做过相关产品的同学会有更强的体感。
**03. 强约束性 & 可控自由度**
设计系统就是要对场景进行抽象、封装并逐步进行合理有效的约束，达成体验上的和谐和统一。CloudScape 坚定的给出了很多强约束来保障产品的基础体验一致性和有效性，同时它也在可行的范围内提供了一些自定义空间，来确保产品设计过程中的差异性。
详细内容大家可以参考过往文章 「[设计系统案例分析 – CloudScape Design System](https://www.thefivekey.com/aws-cloudscape-design-system/)」
### 领域级设计系统案例 AWS CloudScape – 新功能发布
业务级的设计系统，很多时候面向的是业务中的具体问题。这些问题不是指下拉操作怎么做、填写表单报错怎么弄，这些都太过于“底层”，本就应该封装起来。
这里给大家举个例子「新功能发布」应该怎么做？
CloudScape 对新功能发布给出了一个明确的解决方案，通过三种设计来解决不同颗粒度的功能发布通知诉求。
**01. 服务级的功能发布 – 图中 ①**
如果新发布功能会影响到该服务中的所有页面，可以使用系统中视觉最强的组件 FlashBar 来进行提示引导
**02. 页面级功能发布 – 图中②**
页面级功能发布是针对新增页面或服务中有新功能增加所提供的通知方式，在侧边栏中使用弹出气泡提供提示引导。
**03. 页面内功能发布 – 图中③**
页面内功能发布是针对某个具体功能页中新模块增加所提供的通知方式，在页面模块中使用类似 Flashbar（视觉强度较低）的通知模块提示引导。
## 如何构建 Design System：思路与三个阶段
### 设计系统的构建思路
前面我们讲了设计系统的三种类型，但到自己做的时候该怎么入手呢？我给大家推荐两种思路。
- 一种是基于领域级设计系统，适合偏 Web 端的产品，有很好的 0 到 1 基础。重点关注行业领域的特性，去抽象业务组件、业务 pattern
- 另一种是基于系统级去构建，适合偏移动端的场景，直接业务级往上去做
这里在领域级，我推荐大家可以去使用阿里、字节、腾讯这几家的产品，因为迭代速度和维护有更好的保障。
### 设计系统的三个阶段
## Design System 时代设计师角色的演变
### 设计师岗位的变迁
03 年毕业工作至今，有幸经历了从“美工”到设计师的整个历程。时至今天设计师这个职能已经被行业、被公司所认可，职能和领域也在不断演变。设计系统的不断发展让设计的“架构”逐步成型。
19 年左右第一次在委员会和大家提出了架构型设计师和产品设计师的构想，不过当年的时机确实还不够成熟。随着这些年在团队内部的试验，我相信架构型设计师是未来设计师职能中非常重要的一种类型。
关于这个话题，我在 [📬 成为架构型设计师](https://www.thefivekey.com/become-an-architectural-designer/) 的文章中有更详细的讨论。
### 设计师岗位的变迁
有人说，和 DesignOps 很像。对，但我觉得在国内还需要些时间，但架构型设计师是可以先尝试的，它更偏向于具体的工作，为业务为团队发展所服务。
架构型设计师核心工作是设计系统构建，但不能只做这个，还需要能建立流程、方法来促使它们真的落地。
## Take Away：向主管推行 Design System 的核心要点
> 💡 延伸阅读：
> - 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
> - 入门基础：[设计系统 · 我们为什么要做 Design System](/why-we-need-design-system/)
> - 学习路径：[设计系统学习指南 - 国内外 Design System 案例解析](/how-to-learn-from-other-design-systems/)
> - 深度案例：[如何规划 B端 设计系统？深度解析 AWS CloudScape](/b-end-design-system-deep-dive-aws-cloudscape/)
> - 角色演变：[成为架构型设计师](/become-an-architectural-designer/)
================================================================
# 设计师的简历作品集应该关注什么？
- **发布日期**：2024-03-03
- **原文链接**：https://www.thefivekey.com/how-to-effectively-present-your-resume-portfolio/
- **Markdown 原文**：https://www.thefivekey.com/how-to-effectively-present-your-resume-portfolio/index.md
- **标签**：求职面试
> 阿里做面试官看过上千份简历作品集后，我发现大部分作品集最容易出现的三个问题：流水账记录、缺少「解决问题能力」的体现、忽略了对「用户需求」的关注。本文从面试官视角拆解作品集的真正评估标准：不是看你做了什么，而是看你解决了什么问题。
> **TL;DR**
>
> 面试官看作品集，不是看你"做了什么"，而是看你"解决了什么问题"。
>
> 作品集最常见的三个坑：流水账记录、缺少解决问题能力的体现、忽略用户需求。
>
> 好的作品集要从"用户需求"切入，展示你看问题、拆问题、解问题的完整思路。
作品集 的制作是每个设计师都会经历的工作，也是大家最难做的设计之一。最近两周帮几位会员同学看了不少 ，我发现大家的文档基本都是至少 30 页打底，有的甚至到了 60 多页，信息量很大。看得出都在想尽可能全方位的向面试官展示自己的能力，但这些冗长的文档里也都出现了一个明显的共性问题，那就是缺少对自己能力优势的有效表达。
这里主要会体现在以下几个方面：
- 流水账记录。通篇按照时间线将自己做过的项目罗列了一遍；
- 缺少「解决问题能力」的体现；
- 忽略了对「用户需求」的关注。
这些问题不仅仅会出现在求职简历作品集里，所有基于文档的“沟通”场景，比如晋升答辩、汇报分享等场景也都会遇到。所以，这一期的文章我想和大家聊聊自己关于作品集、项目的汇报的一套写作方法。
## 作品集 ，从你的「用户需求」开始
作为设计师，我们时刻都在思考用户遇到了什么问题，我的这个设计方案是不是能解决他们的问题。可是到了写 PPT、作品集的时候往往却忽略掉了这一点，更多的去想“我”要表达什么，忽略了“用户”想要看到什么。
在阿里这些年做面试官也看了上千篇简历，面试了几百人。从“人肉数据分析”的角度来看，除去定向挖人之外，简历作品集水准较高的候选人确实更容易走到最后。
当然，这不是说作品集水准高就代表能力一定强，而是它能够在一定程度上反映出设计师的思考深度。所以我一直说找人帮忙改简其实并不靠谱，简历虽然改了但你的思维模式并没有发生变化，进入到正式[面试环节](https://www.thefivekey.com/tag/求职面试/)还是容易出问题。
## 从用户需求的视角来看作品集
回到「用户需求」，在不同场景下我们的「用户」和「用户需求」都有会存在一些差异。
- 投递简历时，我们的「用户」是专业面试官、HR，他们会关注候选人的业务背景、专业能力及团队匹配度等；
- 晋升面试时，我们的「用户」是专业评委，他们会关注候选人挖掘问题的能力、设计过程及发展潜力；
- 专业分享时，我们的「用户」是设计师，他们会关注你的解题思路以及背后的思考。
如果你也是设计师，正在需要寻求面试过程中的帮助，可以预约我的模拟面试服务。
> 💡 延伸阅读：
> - 进阶实操方法：[好的简历作品集，需要有层次的表达](/how-to-structure-portfolio-expression/)
> - 跨行业面试时的直觉校正：[进入新行业，如何校正你的产品直觉](/calibrate-your-product-intuition/)
================================================================
# 表单设计的基础设计逻辑
- **发布日期**：2024-03-01
- **原文链接**：https://www.thefivekey.com/design-strategies-for-form-design/
- **Markdown 原文**：https://www.thefivekey.com/design-strategies-for-form-design/index.md
- **标签**：设计系统, 表单设计
> 表单是互联网产品中最重要的交互能力之一，但好的表单设计不仅是组件堆砌。本文提供一个三层思考模型（基础体验、行业特性、业务特性）帮你系统思考表单设计。
> **TL;DR**
>
> 表单看起来简单，但好的表单设计需要同时考虑三层：基础体验（组件/交互/反馈）、行业特性（金融严谨 vs 电商快捷）、业务特性（转化率/字段必要性）。
>
> 本系列提供一个由下至上的"通关"思考模型，帮你设计出真正好用的表单。
这篇表单设计的文章出自于4 年前 PinDesign 期刊中的文章。前段时间整理了一下旧文档，虽然时间有点久，但还是有不少内容的思路放到当前依旧有用，所以我会陆续修改一些过去的文章，重新更新在这里，希望对大家有帮助。
## 关于 表单设计
如果从功能角度来划分，表单一定是互联网产品中最为重要的能力之一，它也是用户与产品之间进行交互的一个重要渠道。如果没有表单产品的体验将变得非常的被动，用户只能消费平台所提供的内容。
作为用户我们在日常会遇到各式不同的表单，我们会发自内心的喜欢某个产品的设计，也会因为一些糟糕的设计而吐槽。每一个组件都没有问题，但合在一起就是不好用。如果仔细分析，你会发现其实它并不是一个简单的设计问题，除了表单基础体验它还和所处行业、业务特性有着较大的关联。
如果从 Design System 的角度来看，这似乎又是一个很成熟的工作。输入框、单选、复选、日期、按钮…… 每一个组件都是用户所熟知的，它们是产品设计最底层、基础的元素，也完全有可以系统化的去沉淀。
## 为什么表单设计值得专门拆解
作为[设计系统](https://www.thefivekey.com/tag/design-system/)中讨论最多的部分之一，网络上有很多关于表单的设计资讯，但它们都有比较强的指向性。有一些更关注表单的交互，有一些则更关注表单的逻辑，但真正将它们融合在一起结合产品设计一起来讲述的并不太多（特别是针对移动端产品）。回过头来看自己这十几年的工作经历，互联网产品的方向和载体不断的在发生变化，但表单依旧还在那里，基础的交互形式也依旧是那些。
从表现上来看表单似乎很简单，即使是新入行的设计师也能很快的掌握基础的元素来搭建一个表单界面。但结合上业务的复杂度再来看待一个表单，它就变得不那么简单了。想要设计一个用户愿意填写且使用体验上还不赖的表单，除了设计本身，还需要我们结合产品、技术一起来思考。
此前已经写过几篇相关的文章，但出发点也是某个具象的角度，也不够系统化。在工作上近段时间里的一部分中心又开始回到到了表单的设计上，但在要求上需要更加的全面和系统化，这也让自己需要去重新梳理对它的思考。借这个机会也正好强迫自己将对思考系统的总结下来，也希望能在这个“课题”上带给大家实质性的帮助。
## 表单设计系列的完整内容框架
正如前面所言，表单复杂度在于除了设计自身，还与产品、技术有着较强的关联。所以这个系列会将这些因素整合在一起来进行讲解，大体上它会分成以下几大部分：
### 01. 理解设计表单的意义
如果将表单比作一个工具，那么我们将它比作 sketch。 这个工具自身内置了很多基础元素的能力，每个人都可以用它做出不同的设计，但脱离业务场景单独去评价这个设计的好坏其实是没有意义的。一个明确的设计目标（产品目标）才是从设计上可以去尝试的方向，也是衡量它的一个直接标准。
在这部分内容中我们将站在一个商业产品设计的角度去将表单进行剥离，去分析在每一个层级中设计需要关注的核心本质是什么。也只有先将这个部分搞清楚，才能确保我们设计的表单是在当前情景下真正有效、易于使用的。
### 02. 表单基础设计规范
我们前面提到，表单是一个在产品设计中被大量使用的能力。正因为如此，它也非常有必要被“约束”起来。一套完整、有效的设计规范能够让我们在具体的界面设计中将关注点更多的放在业务诉求上，避免表单字段的规范带来对设计的干扰。
当然，表单的设计规范并不是只能一种。根据你的业务领域，它可以有更多不同的角度和形式去体现。这部分的核心是基于一个整体性的框架，以一个具象的领域为代表做一次案例的示范。希望大家最后得到不是这套表单的规范，而是如何去创建一套属于自己业务的表单规范。
### 03. 表单的设计实例
虽然我们可以通过基础元素随意的“组装”不同的表单，但在互联网产品的发展中它们已经形成了很多特定的使用场景，这也是我们在很多站点上能看到的实际案例。
如果只是简答的从表现层面来看，我们可能并不能去评判它的优劣，也不知道我们该如何去借鉴他们的思路。所以在这部分我们将以这些常用的场景（如注册登录、发布评论、搜索筛选等…）为案例从设计思路上来进行逐个的分析。这些可能也将是大家在日常工作中最为有用的部分，所以我们会用更多的篇幅来讲解这部分内容。
## 在产品设计中，表单是用来干什么的？
我们先来关注一个更宏观一些的问题。在一个产品中，表单是为了收集用户的信息（需求），再由系统做出一系列的处理返回展示给用户来满足用户的诉求。从表现上来看，它大多由一系列的输入框、选择框以及一组按钮所组成。
沿着这个思路往下走，作为设计师我们则会在一堆表单组件中打转，通过各种不同的组合来应对业务所提出的诉求。但这可能会让我们渐渐的忽略了这件事情的本质，我们究竟为什么要提供表单？
如果我们转化一下思路，将目光从做表单转移到用户身上，那么我们需要思考的问题则会转变成在当前场景下用户的需求是什么？
- 注册成为用户 – 想要获取会员才能查看的信息；
- 搜索关键词 & 筛选 – 想要快速获得所关注的信息；
- 填写地址信息 – 将货物准确的送到我需要的地方；
- ….
以上的几个案例，通常情况下我们都会用一个表单来处理，让用户自行录入。但大家仔细分析一下就会发现，注册、搜索、填地址这些操作并不是用户真正的目的，只是在产品设计上比较“粗暴”的解决方法之一。
- 如果我们接入更为通用的第三方登录，用户只需要几次点击就可以他所感兴趣的信息；
- 如果我们允许用户保存自定义搜索条件（请参看 ebay），用户只需要一次设置，后续再无烦扰；
- 如果我们提供当前位置定位和识别，用户将大幅减少信息输入，快速完成信息的录入。
如果我们更多的去关心用户填写表单的目的，那么可能有很多的表单都不应该出现在用户的面前，因为表单也只不过是解决问题的方法之一。
我们曾经在 109 期的文章中曾提到过，用户放弃完成某个页面有很大的比例是由于复杂、冗长的表单。对于用户来说，表单其实是一种“麻烦”，特别是对于移动设备来说，输入信息是一件极大影响用户使用心情的事情。
所以站在整个产品的角度来看，原则上我们尽可能减少向用户提供表单。每当出现一个表单，我们都需要问问自己这是不是一定需要通过表单来处理。如果可以从产品角度来进行规避，那么我们应该更多的去思考如何通过产品功能规划来解决；如果实在不行，我们在来考虑如何设计一个表单，并在这个过程中不断的思考其必要性（字段）、易用性及设计的表现力。
## 表单遇到了哪些问题？
之前我们讨论这个话题更多是站在使用者（用户）的视角，但如果换到一个表单系统的角度，表单最终的使用者和设计它的设计师都是我们的用户。所以这里我们也将从这两个不同的视角来看看我们会遇到哪些问题。
### 对于使用者（用户）：
对于最终使用表单的用户而言，表单最重要的问题就是具有较大的心理成本和操作成本，影响的是最终的完成率。本质上来说，在目前的环境下我们还无法消灭表单，只能说站在整个产品的角度来思考如何让用户更容易的获得 Ta 所需要的资讯。
**01. 心理成本**
心理成本是一个容易被忽略的因素，很多人认为我把表单交互做的简单一些，那么用户填写起来也会轻松一些。但其实有研究曾提到过，对于表单用户看到的第一时间是先扫读一下，看看需要填写的内容有多少，估算一下自己需要多久完成。所以为了不吓到用户，很多长表单会选择进行分拆，降低用户的心理压力。
除此之外，用户也会看一看表单中的字段有没有特别难填写的。比如在很多支付流程中的信用卡信息，需要用户从钱包里找出卡再对应着一步步的填写进去。
这是一个麻烦且容易出错的流程，很多用户会卡在这一步。所以在产品设计上会加入扫描信用卡识别来降低用户首次输入的成本，同时还可以记录信用卡信息来方便下次的支付操作。
用户对于一个表单的心理成本在填写过程中起到了至关重要的作用，表单的字段也多，用户内心的抗拒则越大。
**02. 操作成本**
至于操作成本这个因素，大家相对都还比较理解。比如下方的这个案例，很明显就是在交互设计上有些欠考虑，用户完成表单的实际点击、输入的操作步骤非常多、繁琐。
### **对于设计师：**
设计师日常都会去看很多的案例，希望将它们设计好的地方借鉴到自己的工作中，但到了具体的设计中却发现并不一定适用。这背后的关键其实是如何去分析别人的案例，如何将设计的思路带入到自己的设计中，而这也才是学习借鉴的真正意义。
我们所看到的每一个具体案例它背后面向的其实也是一个具体的问题，只不过由于我们忽略了它背后的用户述求以及设计的“解题”的模式，关注点更多的放到了设计的“表象”上。
这个并没有捷径，只有结合其产品的背景进行分析才能真正搞清楚其设计意图。而对于设计师而言，想要更深入理解某一类功能的设计还需要找到更多的同类但不同设计形式的案例放在一起来进行思考。最终得到的才能会是更为全面、科学的结论。这也是为什么接下来我们会花大量篇幅来讨论具体 Pattern 的原因。
## 如何来看待表单设计？
基于以上的分析，我们可以发现在具体的项目设计中，它其实是一个结合了基础体验、行业特性及自有业务的工作，这也是为什么我们说它并不简单的原因。
在期刊的第 101 期中，曾经给大家提出了一个思考的模型。由上至下我们将一个表单的设计分为基础体验、行业特性和业务特性三个维度。我们要做的则是由下至上一层层的“通关”，也只有想清楚了每一层，我们才能让表单具备更好的使用体验。
在这整个过程中，一套完备的表单基础规范定义了每一个组件、Pattern 的使用规则以及所有可预见的交互。在系统的解决了这个问题之后，我们在之后的工作中则不再需要关注这个基础问题，将更多的精力放在对业务诉求的体现和用户需求的满足上。
> 💡 延伸阅读：
> - 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
> - 设计系统入门：[设计系统 · 我们为什么要做 Design System](/why-we-need-design-system/)
> - 布局框架理论：[设计系统核心理论篇 – 布局框架](/design-system-layout-framework/)
> - 模式 vs 组件：[设计模式库与设计组件库到底有什么区别？](/difference-between-design-pattern-and-design-component/)
================================================================
# 半年过去了，AI 设计的进展如何?
- **发布日期**：2023-09-04
- **原文链接**：https://www.thefivekey.com/progress-of-ai-design-in-ui-interface/
- **Markdown 原文**：https://www.thefivekey.com/progress-of-ai-design-in-ui-interface/index.md
- **标签**：AI, 设计工具, 体验设计
> AI Design 在过去一年多时间里引起了广泛关注，国内外众多产品纷纷投入探索。然而，随着冷静期的到来，越来越多的人意识到让AI真正融入日常设计工作远比预期复杂。本文将从业务视角切入，深入分析了AI在UI界面设计中的发展潜力和挑战，揭示了真实业务的复杂性对AI设计的影响和未来可能性。
> ⚠️ **本文已有更新版本**
>
> 这篇文章发布于 2023 年 9 月，是我对 AI 设计的早期观察。我在 2024 年 6 月写了一篇更深入、更全面的更新版：[一年过去了，AI design 的进展如何？](/current-trends-ai-design-in-interface-design/)，建议优先阅读新版。
# 篇首语
今年年初 AI 浪潮席卷了整个科技互联网领域，从海外的 UIZard 到国内的即时设计、MasterGo，大家都在不断尝试探索新的模式将 AI 与 UI 界面进行结合。我也一直都在密切关注着它对设计行业所带来的变化，特别是在界面设计领域。
时间一转眼已经到了 9 月，尽管前面提到的这几家公司在文生 UI 领域都投入了大量的资源和精力，也获得了一些初步的成果，但就目前的结果来看AI 在界面设计方面依旧处于一个比较初级的阶段。与此同时大家可能也会发现，这几家公司对这方面的发声也在慢慢变少，整个领域似乎进入了一个相对沉寂的时期，这股热潮似乎在默默的消退。
上周与一位老同事喝咖啡，一起深入探讨了一下当前 AI 设计的能力进展、现实中客户的真实需求以及未来的发展趋势。回来后我又重新整理了一下思路，想在这篇文章中，与大家分享一些我对当前AI 界面设计的思考和想法。
# UI 界面设计的复杂性
与创意设计领域中Stable Diffusion、MidJourney 飞速进化相比，AI 在 UI 界面设计上的能力进展显然是缓慢的。
创意设计侧重于高概念的构思发散，而界面设计则是深入到具象的业务实现。这也就意味着从产品逻辑到交互模式，都是需要基于深入的用户洞察和对业务逻辑的细致理解。
这种差异化和复杂性为 AI 在界面设计方面的发展带来了巨大的挑战，迫使我们需要做更多深入的研究和基础建设才有可能获得实质性的进步。这里我们可以展开细说一下：
**01. 业务导向的多维度设计**
UI 界面不仅仅是产品功能的呈现，它还更需要综合用户需求、数据反馈来进行设计从而向达成业务目标前进。
这也就意味着在设计的过程中我们不仅需要关注产品的界面美观和使用体验，还需要考虑如何结合这些背景信息来进行产品的设计。这就让设计变得不那么“纯粹”，也没有足够明确的规律可遵循，更多的依赖于人的判断。
**02. 复杂的设计目的性**
相较于创意设计，UI 界面设计的目的性会复杂得多。每一个界面都可能需要满足用户不同场景下的多个诉求。
例如，一个电商平台的商品列表页不仅要向用户直观地展示具有吸引力的商品，还需要向用户提供商品的筛选 & 比价、加购 & 凑单以及平台的功能导航等不同场景下的用户使用路径，而这些功能在不同的状态下可能还会存在不同的逻辑。
这些需求的层层叠加会让产品的界面设计变得异常复杂，这就要求设计师在界面的布局和功能分配上进行精细的权衡，确保用户在不同的场景下都能快速找到自己需要的功能模块并完成后续的操作。
**03. 通用与特定的设计标准**
就像之前在设计系统的话题中我们一直讨论的，不同的行业和具体的业务中，都会存在其特有的设计需求和习惯。比如金融类产品中需要强调正式感和安全性，而社交娱乐型产品则更关注轻松、互动性的交互氛围。
系统级的设计系统为我们提供了普适性的界面设计原则和交互标准，但它无法为特定的业务提供具象的设计指引，更别说体现产品的品牌特性和“人设”了。这也就要求设计师针对于特定的行业、用户进行深入的研究，定义出符合业务的品牌特性。
**04. 持续迭代的设计过程**
产品的界面设计并不是一次性任务。它需要随着技术的进步、用户需求的变化以及市场环境的演变，来进行界面设计的不断优化和更新。这不仅仅是为了提供更好的产品使用体验，也是为了适应业务的发展和变化，确保产品始终保持竞争力。
由此可见，UI 界面设计是一个复杂且多维度的设计过程，涉及范围大、业务耦合度高，AI 想要在这个领域中真正的占有一席之地是还是非常难的。
过去的时间里，我们对 UI 界面设计的 AI 能力聊得还比较“宏观”，围绕着 AI 的潜在能力和可能性上。这其中的能力层次以及具体的困难，实际上大家探讨得都不多。今天借这个机会，正好也和大家聊聊我自己的理解。
## 产品设计的难度层级
如果将一个产品从设计工作的视角进行“解构”，我们大概可以将其拆解成组件、模块、页面、流程、功能及应用六个难度层级。
> **TL;DR**
>
> Heptabase 让你「看见思考」，Tana 让你「组织思考」，它们不是彼此替代，而是天然互补。
>
> 如果你想同时拥有快速记录的效率和全局思考的深度，不妨让两者并行使用。
## 为什么我要重新思考知识管理工具
2022 年，我离开了公司。十多年陆陆续续做的记录，随着电脑一起交还了回去。那一刻其实挺好，终于不用再去维护那些零散、混乱的信息了。
对我来说，这是一次从零开始的机会。没有历史包袱，也不用考虑数据迁移。我可以重新搭建一套属于自己的知识体系，围绕我接下来真正关心的领域和命题，重新构建思考的框架。
后来我陆续接触了 Heptabase 和 Tana。
这两款工具的思路完全不同，一个强调空间，一个强调结构。这几年里我也在它们之间来回切换，想找到一个最合适的方式，但却又始终没能真正解决我的问题。总觉得哪里不太对，却又说不清。
直到今年，我才慢慢意识到，问题并不在工具本身，而是我把自己困在了「All in One」的执念里。总想着在一个工具里解决所有场景的需求，结果什么都顾不上，也什么都没做好。
所以，这一期的文章，我想重新聊聊知识管理这件事。聊聊我这几年在工具之间的反复和困惑，以及我现在怎么看「如何选择一款知识管理工具」。
> 💡 如果你对知识管理方法论本身感兴趣，可以先看我之前写的 [HQ&A 笔记法：让你的思考更有效](/hqa-note-taking/)，讲的是从「记录」到「理解」的三步思考框架，和本文聊的工具选择互为补充。
## Heptabase vs Tana
这两款产品的特点其实非常鲜明，差异也很大。
从表面来看，Heptabase 更像是一个帮助你看清全局、发散思考的工具。它把笔记这件事彻底空间化，让你能像警察办案那样，在一块白板上把所有线索思路连接起来。
那些原本散落在各个角落的想法，突然被放在同一个平面里，变得可以移动、组合、连接。你能清楚地看到思考的路径，也能在重新排列的过程中，发现新的关系与洞见。
当然，让我真正决定付费的并不是当时的产品形态，而是它背后的理念。Heptabase 的核心并不是「记录」，而是「理解」。它让思考变成一个空间事件，而不是文字的堆叠结果。
创始人 Alan 对如何思考知识这件事的理解，远比市面上大多数笔记产品要深。大家感兴趣的可以去阅读一下他这篇文章。
Heptabase: My Vision Project Meta
而 Tana 的重心则完全不同。它关注的不是「全貌」，而是「结构」以及结构化之后组织信息的方式。
我一直很喜欢节点式、大纲型的工具，因为它足够简单、快速，最适合即时记录想法。
还在公司的时候，我用过很长一段时间 Logseq 和 OmniOutliner，它们都很好用，但问题也很明显。内容容易变得零散、粗放，彼此之间缺乏联系。每条笔记都像是一个孤岛，你知道它们存在，但很难串联成体系。
Tana 出现后，演示视频立马就吸引了我。它在大纲的基础上引入了 Supertag，让每个节点都可以带上语义结构。从「记录信息」变成了「组织知识」。
这种方式极大地弥补了 Logseq、OmniOutliner 在信息管理上的不足，也让我真正感受到笔记其实可以是「有逻辑的网络」，而不是一堆堆分散的文本。
当然，Tana 也是我接触过学习门槛最高的一款工具。
它不像 Heptabase 那样容易理解，而是要求你具备相当强的结构化思维能力。你得自己去定义、去构建、去设计那套逻辑关系。这个过程很难，也注定需要反复的尝试。坦白讲，我中途放弃过好几次，直到最近一年后才真正用顺手。
为了让差异更直观，我整理了一张对比表：
| 维度 | Heptabase | Tana |
| --- | --- | --- |
| 核心理念 | 空间化思考（看见思考） | 结构化思考（组织思考） |
| 最小单位 | 卡片（Card） | 节点（Node） |
| 主要视图 | 白板（Whiteboard） | 大纲（Outliner） |
| 核心能力 | 视觉化关联、发散 | Supertag 语义建模 |
| 学习门槛 | 低，容易上手 | 高，需要建模能力 |
| 最适合场景 | 深度研究、问题梳理、发散思考 | 日常记录、信息结构化、分析建模 |
| 弱项 | 快速记录、结构化输出 | 全局视觉思考、发散联想 |
| 适合人群 | 研究者、视觉化思考者 | 分析师、结构化思维者 |
但表格只能呈现表层差异，真正的区别还要回到两款工具背后的思考方式本身。
## Heptabase 和 Tana 的核心差异：空间化 vs 结构化
工具类产品有很多，但真正有生命力的，从来都不是因为功能的堆砌，而是因为它背后都会承载着一套独特的思考方式。
每一个好的工具产品，其实都是创始团队对某个领域的理解外化。他们看问题的方式，决定了产品的形态，也决定了使用者被引导去思考的路径。换句话说，工具不只是一个被动的载体，它也是一种思维的表达。
Heptabase 和 Tana 正是这样两种典型的外化结果。一个是把「思考」空间化，一个把「知识」结构化。
从表面看，他们的差异是界面或交互层面的不同，但本质上其实是代表了两种对知识管理、信息处理的完全不同的认知。前者关注「看见关系」，后者关注「定义关系」。
### Heptabase 的思考空间化
Heptabase 是一款以视觉化思维为核心、支持空间化组织知识的工具。它让笔记这件事彻底脱离了线性文本的束缚。
在 Heptabase 里，每一条信息都是一张卡片，而卡片之间可以通过[白板](/start-design-work-with-whiteboard/)自由地摆放、分组、连接。随着白板上卡片的增加，你会发现自己不再只是记录，而是在构建一张可以看见思考路径的地图。那些原本零散的想法开始被重新排列、归类、连接，慢慢显出它们之间的关系。
比如下面我最近我一直在梳理的白板。是最近关注到 BOJ 考虑提升利率引发的我对日本历史上利率变化的一个研究。
从一开始这次利率上调的事件，到触发的原因，到日元升值对国际金融市场带来的影响，再到日本历史上利率政策的几个阶段，不断的引出新的问题、新的理解。让我对过去读过的「失去的三十年」和「十年轮回」有了另一个视角的理解，也帮我理清了很多逻辑。
Heptabase 的核心，并不是笔记本身，而是思考的过程。当我们把碎片化的信息拆成原子化的卡片，再在白板上不断移动、聚合、连线时，其实就是在让思维变得可视化、可操作。
这种形式，是传统的笔记工具无法给予的。卡片的整理和连线，是我们对某个具体问题的逻辑梳理，也能引发我们更多的思考，真正做到对一个问题的深度思考。思考不再停留在脑海里，而是变成可以「被看见」的结构。
所以，Heptabase 的入门门槛不高，但上限则在于你是否愿意把思考变成一个主动搭建的过程。通过不断拆解、重组、反思，去寻找不同信息之间的联系。这个过程虽然慢，但最终会生成属于你自己的知识结构与洞见网络。
我上面的这个白板，才开始不久。大家可以看看官方提供的这个「Chip War」的线上案例感受一下。
Chip War
### Tana 的思考结构化
如果说 Heptabase 是帮助我们「看见思考」，那么 Tana 则是帮助我们「组织思考」,是一款以网状思维为核心、支持非线性结构化的知识工具。
在这里，每一条信息都是一个节点，而每个节点都可以通过 Super tag 拓展出自定义的语义结构。当这些节点彼此引用、关联、嵌套时，就会逐渐织出一张动态的知识网络。
所以，我们所有的笔记就不再只是被记录下来但最终会落灰的内容，而是可被组织、推理、甚至触发行动的结构化信息。
这里可以给大家举几个例子：
以下图中这个 Signal 标签为例，我会用它来记录每天的思考和摘要。我会在记录的同时也做好这条信息的领域划分，以及是在什么场景下记录这条信息的。方便后续进一步的整理和使用。（更轻量的日常灵感捕捉场景，我之前也分享过 [用 Notion + 语音做日常记录](/daily-drafts-journal-with-voice-ai-notion-template/) 的模板）
写作场景则更典型，我专门为写作建立了一个 Function 的标签，把文章写作“打散”成若干问题来组织。
每篇文章都保留了几组基础问题，比如：
- 这篇文章核心要表达什么？
- 为什么写这篇文章，它的背景与场景是什么？
- 我有哪些洞察？核心观点是什么？
除此之外，我还设计了一些“可选功能”，比如：
- 观点支撑：是否有已有的观点或材料可以佐证我的看法？
- 类比映射：是否能用类比帮助表达？
- 切换视角：是否能换个角度讲，让读者更容易理解？
- 认知递进：这篇文章是否能带来进一步的思考？
这些问题其实构成了我自己的写作「思维框架」，它让写作过程更像一次系统化推理，而不是临场发挥。
同样的逻辑，我还用 Tana 构建了一个公司分析模型。
这是一个针对公司基本面分析的本体论（Ontology）结构：包括业务模式、收入来源、客户群体、成长路径等。它代表的是我理解一家公司的方式，当这套逻辑模型搭建完成后，我就能以此为模板，快速分析任何一家新的公司。
在这些场景里，Tana 其实已经远超出了笔记工具的范畴。
它的核心价值，不在于帮助你记录信息，而在于让你把自己的思考方式显性化、结构化。让思考变成可以被构建、被复用的对象，让工具真正成为你思维的一部分。
## Heptabase 和 Tana 分别适合谁用
两款产品代表的是不同的思考方式，所以「谁更适合用哪个」其实可以从你日常的使用场景反推。
### 适合 Heptabase 的人
如果你的笔记是为「深度研究」服务的（比如围绕一个话题做长期探索、梳理因果、建立自己的理解框架），那 Heptabase 的白板会非常契合。它也适合那些更偏好视觉思考、习惯用画图来理清逻辑的人。
典型场景：做选题研究、写长文前的素材梳理、读一本难啃的书时做主题式整理、对某个领域的长期追踪与沉淀。
### 适合 Tana 的人
如果你的日常是大量信息的吸收和分类（比如每天记录想法、整理资料、建立公司或产品的分析模型），那 Tana 的节点和 Supertag 会很得心应手。它更适合有结构化思维、愿意为自己的知识库「建模」的人。
典型场景：每日速记与回顾、写作框架管理、公司/产品分析模板、项目任务流转、复用型知识资产的沉淀。
## 选择知识管理工具之前，先想清楚你的逻辑
聊完这两个产品，其实我们还是得回到自己去思考一个根本问题。我们究竟是如何理解「知识」这件事的？我认为自己在管理的到底是什么？该如何管理？
我们无法决定工具的形态，却可以决定自己的理念。一个具备独立思考能力的人，应该拥有属于自己的知识观与世界观。而这套理解，才是我们选择某个工具的真正逻辑。
很多时候，我们看到别人去推荐一个工具，说特别好用，但自己试了却怎么都别扭。其实问题有时候并不在工具本身，而在于它并不契合我们的思考方式。有或者说，我们当下还没有形成足够清晰的方法论去驾驭它。
其实这并不是问题。相反，它其实可以让我们停一停，不必去追没有给新的工具，去反复的试错，而要先想清楚自己是怎么想的。
在我看来，无论是做知识管理还是建立对世界的理解，第一步都不是去找一个更好的工具，而是先找到一套属于自己的逻辑与理念。只有这样，你才能真正选择、甚至塑造出与你思维方式匹配的工具。
## 为什么 All in One 是一个陷阱：Heptabase 和 Tana 如何互补
知识管理其实是一个很大的命题。它会由很多不同的场景组合而成，而每个人的使用侧重点也都不同，所以叠加起来它的逻辑是很复杂的。
而对我来说，核心的关注只有两个：
一个是如何快速记录，并对信息进行结构化处理形成基础物料；另一个则是如何基于某一个问题或领域出发，把这些信息整合成一个完整的知识框架。
过去很长一段时间里，困扰我的问题是总是想要尝试过在 Heptabase 或 Tana 中实现 All in One 的方案。结果很快就发现，都不太行。
Heptabase 的白板在信息的组织、发散上非常好用，但在快速记录和信息的结构化上却不好用；而 Tana 虽然在记录和结构话上很强，但由于它以节点为核心的结构模式，天然又不擅长做全局的思考。
想要在一个工具里同时做到既要聚焦细节，又要能俯瞰全貌，至少在当下是不现实的。
所以今年开始，我重新启用了 Heptabase，让它和 Tana 并行使用。Tana 负责前期的快速记录、结构化信息，作为基础资料库；Heptabase 则作负责后期用白板来沉淀内容、面向问题和领域构建全局思考。
有意思的是，当真这样运行了一段时候后，我发现两个工具之间的复制粘贴并没有增加多少工作量。因为当 Tana 中的每一条信息都被结构化的梳理之后，它的完成度是很高的，进入到 Heptabase 中不需要做太多的调整。
所以，这里依旧回到了我们前面提到的核心问题：我们是如何去理解知识，如何去构建自己的思考逻辑的，工具只是用来承载我们逻辑的方法。这个时候Tana 和 Heptabase 就不再是一个竞争关系，而是我不同场景下的能力互补。
对于知识管理这件事，至少目前，我的个人观点是尽量不要执着于 All in One。
相较于在多个工具之间交换信息所带来的少量成本，All in One 的代价往往更大。它不仅让效率下降，还容易让你的思考被工具的边界限制。
## 常见疑问
在聊这两款产品时，我经常被问到下面几个问题，一并在这里回答。
### Heptabase 和 Tana 哪个更好？
没有绝对答案。它们服务的是不同的思考场景，选「更好」不如选「更契合」。如果你要做的是发散和深度研究，Heptabase 更合适；如果你要做的是结构化记录和知识建模，Tana 更合适。
### Heptabase 能替代 Tana 吗？
很难。Heptabase 在快速记录和结构化输出上有明显短板，强行拿它做日常笔记会让流程变得低效。反过来 Tana 替代 Heptabase 也一样不顺，因为 Tana 做不了真正意义上的视觉化发散。
### Tana 的学习门槛真的很高吗？
是的，但回报也高。一旦理解了 Supertag 的本体建模思路，你可以把它迁移到写作、研究、公司分析、项目管理等几乎所有场景。它的复杂度来自灵活度，这是一个一次性成本。
### 一定要两个都用吗？
不必。如果你只需要深度研究，Heptabase 足够；只需要结构化记录，Tana 足够。两者并用只在你同时需要「发散」和「收敛」两种能力时才有必要，也就是既想快速记录结构化信息，又想围绕问题做深度思考的人。
### 和 Logseq、OmniOutliner 这类工具比呢？
Logseq 和 OmniOutliner 都是优秀的大纲工具，但它们偏向「记录」，缺少 Tana 那种基于 Supertag 的语义建模能力，也没有 Heptabase 的空间化白板。如果你对知识的组织方式已经有明确结构，它们足够用；如果你希望工具本身帮你塑造思考方式，那 Heptabase 或 Tana 会更进一步。
## 总结：如何选择适合自己的知识管理工具
从产品层面来看，所有的笔记工具归根到底无非就是「增删改查」和「视图呈现」。功能上的差异并不会太大。
但工具，始终是思维方式的外化。很多时候，我们选择一款工具，其实是在选择这个产品背后的团队，对「知识」和「思考」这一领域的理解。
所以，面对任何一个产品，我们真正需要判断的，是它的理念是否与你的思考逻辑一致，是否能契合你的使用场景，而不是它能不能 All in One。
知识管理这件事，始终是高度个人化的。好的思路和方法可以借鉴，就像我今天分享的这些方式。它们可能非常适合我，但未必适合其他人。所以，重要的还是先找到属于自己的逻辑与方法。
================================================================
# 业务思考力，设计师跳出执行的起点
- **发布日期**：2025-03-31
- **原文链接**：https://www.thefivekey.com/business-thinking-for-designers/
- **Markdown 原文**：https://www.thefivekey.com/business-thinking-for-designers/index.md
- **标签**：设计思考, 产品设计, 职业发展, 产品视角
> 设计师如何跳出被动响应的执行思维，从业务视角出发？本文拆解两个常见误区：把 KPI 当作终点而非线索；把用户反馈当成业务问题本身。学会区分症状和根源，是设计师从「执行者」到「决策者」的关键起点。
> **TL;DR**
>
> 设计师跳出执行的关键，是建立自己的业务思考力。
>
> 两个最常见的认知错位：把 KPI 当成终点而不是线索（围着 KPI 做设计，但偏离了真正的业务目标）；把用户反馈直接等同于业务问题（响应症状而非根源）。
>
> 学会用业务视角反推设计决策，是从执行者走向决策者的起点。
我们一直强调，设计是要服务于业务目标的。但在实际工作中，这句话往往会变了味。
大多数时候，业务目标是由一系列数字呈现的。数字看起来明确、量化、可追踪，所以也就理所当然地变成了决策依据、优先级判定标准。但问题也就出在这里，我们每天面对的是 KPI，而不是目标本身，这就让设计工作很容易变得看起来合理，实际上却偏离了核心。
## KPI 是起点，但并不是答案
KPI 本意是为了帮助我们从目标回推行动，但在实际工作中，它往往变成了另一种“任务指令”。指标一旦被拆解到每个人头上，就很容易变成一个明确的执行目标，而不再是一个值得分析的问题。
我们会习惯性地围着 KPI 做设计：DAU 要上涨，那就提升 Push 的频次；GMV 要提升，就改按钮、调样式；点击率要提升，那就多加俩弹层。
这些操作不一定错，但很多时候，它们只是“指标驱动”下的机械响应，而并未真正回到目标本身的去理解它的目的，从而反过来思考我们究竟应该选择什么样的路径和方法来达成？
事实上，很多的需求在流转过程中逐步失焦，并不是因为老板瞎定目标，也不一定是 KPI 本身出了问题，而是大家在拆解 KPI 时，把它当成了终点，而不是线索、问题。这也是最常见、也最隐蔽的认知错位。
KPI 是我们实现业务目标推理链路上的线索节点。你需要做的，是搞清楚它和目标之间的逻辑关系，以及它和当前设计工作之间的传导逻辑。
如果你发现这之间没有可验证的连接，那你就要停下来问一句：我现在做的，是为了实现目标，还是只是为了完成一个动作？
## 用户反馈不等于业务问题
如果说 KPI 让我们在执行上会失焦，那用户反馈的问题则往往会让我们在方向上跑偏。
很多设计师在面对用户的声音时，会本能地站在「同理心」的一边。我们习惯说，“要为用户而设计”，于是只要用户说“这个地方不好用”或者说“我希望能有某个功能”，我们就会将它们一通整理，然后写一个 PPT 告诉需求方，产品需要改进、体验需要优化。
这看起来很负责任，也很为用户着想，但同时也可能会出现跑偏的问题。
用户说的，真的是他的本质问题吗？他描述的是需求，还是他自己想象出来的解决方案？
大多数情况下，用户反馈的是某个体验层的卡顿感。比如“流程不合理”“步骤太多”“结构不清晰”。但这些感受并不等于问题本身，它们往往还存在着更深层次的问题。
你得顺着这些反馈往下挖。你要问的不是“他说了什么”，而是“为什么他说这个”。更重要的，是判断这个问题是否真的和我们的目标相关，是否值得投入资源去解决。
而判断的标准，不是谁的声音大、谁抱怨多谁就对（对于产品经理的沟通同理）。而是这个问题，是否来自我们真正要服务的那一类人、那一类场景？
不是所有用户的问题都需要被解决。一个产品的核心竞争力，**恰恰来自于它知道该为谁解决问题，也知道不为谁解决问题。**
所以下当一次我们面对用户的问题，不妨思考一下：这是症状，还是根源？是个体，还是代表？是“我们要服务的用户”，还是“我们暂时不解决的场景”？
看到这里，相信你对「设计师如何理解业务目标、判断需求价值」已经有了一些新的思考。
那么，后面的内容将更值得你深入了解。
在这篇文章剩下的付费部分，我将继续展开三个关键问题：
**01. 如何判断一个需求值不值得做？**
> **TL;DR**
>
> 设计系统逐步完善之后，体验设计师的角色正在分化为两类：一类继续深入构建系统、制定规则（架构型设计师）；另一类深入业务一线，把 Pattern 和组件当成"标准件"拼装，推动产品落地（业务型设计师）。
>
> 继续做通用 UX 是最危险的位置，识别自己的倾向并主动选择，是设计师当下最需要做的事。
在上一篇文章「[从做设计，到构建秩序](/from-chaos-to-order-in-design/)」里我们提到，设计系统的真正价值不在于样式和组件的统一，而在于提供确定性。
尤其是通过 Pattern 这种面向问题的抽象思路，把常见问题的解法沉淀下来，帮助设计师跳出细节，专注更高阶的业务思考。
当这套机制建立起来，设计师不再需要花精力来每一次都从头开始。那么问题来了，当这些重复性的工作被系统接手之后，设计师的角色会走向哪里？
今天这篇文章，我就想接着这个问题往下讲讲。
## 当设计不再从零开始，设计师应该往哪儿走？
设计系统完成某个阶段后，设计师的日常开始变得熟悉甚至有些重复。你会发现，很多事情都已经被提前定义好了，你要做的，仅仅是 "照着来"。看起来轻松了不少，但也开始让人感到焦虑：
> 如果我的工作变成使用既定的方案，那么我还能创造什么价值？
这是一个很现实的问题，也是在设计系统逐步成熟之后，许多设计师共同的焦虑。
但大家要知道，设计系统的建设从来不是一劳永逸的事。它更像是一个持续演进的过程。随着业务的拓展、产品形态的变化，系统也需要不断被更新和迭代。
它没有“最终版”，也不存在“完成时”。
也正因为它变成了一项长期存在的基础设施，也就不可避免地，带来了设计协作方式的变化。设计逐步走向一定的中心化，秩序逐步显性化。
设计系统构建团队负责制定通用规范，其余设计师则深入到业务，以这些规则为基础推动产品演进。大家在各自“既定边界”内创造更大的价值。
有些人会继续深入到行业和业务中，提炼共识、持续地构建确定性；而其他更多的设计师则走向业务，将 Pattern 和组件当作“标准件”拼装调度，用设计去解决实际问题，推动产品落地。
如果没意识到这种转变，那么依旧会停留在执行细节里原地打转。今天改布局，明天调动效，每天都在赶交付、救火、填坑，忙得身心俱疲，却不知道这些工作是否真的还有价值。
这些看似必不可少的工作，其实设计系统早就在一点点接管。你还在一块块堆砖头，人家已经在起楼了。
但如果你能看清这个变化，意识到设计早就不是把需求一个个画出来。它不是在手动复刻业务流程，而是用系统化的方式，把重复劳动压缩到最小，让真正重要的部分浮出来。比如业务逻辑、产品流程、信息结构等等。
当你开始把这些问题当成你需要解决的设计问题来看，那么就会发现你的设计空间，不是变小了，而是被重新打开了。
## 设计师未来的两条路径：架构型 vs 业务型
其实早在 2020 年，我在负责集团设计中台团队时，就隐约意识到一个趋势：未来的体验设计师，会逐步分化为两类角色 。一类负责构建设计系统、制定规则的架构型设计师，另一类则深入业务一线，推动产品落地与业务增长，是更偏执行与协同的业务型设计师。
当时只是作为一个内部判断提出，并不确定是否成立。但几年过去，越来越多的团队和公司，正在沿着这个方向演进。
这不是因为谁预判得准，而是因为这本就是行业走向成熟、协作方式系统化之后的自然结果。
但这两个方向，真的有清晰的边界吗？我们又该如何判断自己适合哪一条路？这些角色背后，又分别隐藏着哪些挑战和机会？
在这篇文章的下半部分，我想带你一起聊聊我对这两类设计师的理解和观察。
如果你正面临选择，或者正在寻找突破瓶颈的新方向，希望这些内容能为你提供一些思路。
> 💡 延伸阅读：
> - 架构方向深度展开：[成为架构型设计师](/become-an-architectural-designer/)
> - 业务方向：[业务思考力，设计师跳出执行的起点](/business-thinking-for-designers/)
> - 体验设计师未来三年：[体验设计师 未来三年应该如何发展？](/ux-designers-in-the-next-three-years/)
> - AI 时代的新抓手：[把设计系统变成 Markdown：让 AI Coding 真正读懂你的设计约束](/design-system-as-markdown/)
欢迎订阅我的小报童专栏，解锁本期文章全文内容。
================================================================
# 从做设计，到构建秩序
- **发布日期**：2025-03-31
- **原文链接**：https://www.thefivekey.com/from-chaos-to-order-in-design/
- **Markdown 原文**：https://www.thefivekey.com/from-chaos-to-order-in-design/index.md
- **标签**：设计思考, 产品设计
> 设计体验不是靠细节打磨堆出来的，而是建立在清晰流程和稳定结构之上的。本文探讨设计中「确定性」的重要性：好的体验来自规则的稳定，而不是个体努力的极致；设计系统通过 Pattern 提供确定性，是从「做设计」走向「构建秩序」的关键路径。
> **TL;DR**
>
> 一个产品的好体验，从来不是靠界面细节"卷"出来的，而是来自清晰的流程和稳定的结构。
>
> 设计师追求"细节极致"会陷入越走越窄的死胡同。
>
> 真正的破局点是从"做设计"升级到"构建秩序"：通过设计系统提供确定性，让团队从重复的样式决策中解放，专注于真正影响业务的问题。
很多设计师在工作中，常常会陷入一个熟悉又尴尬的状态。想着怎么把界面做得更漂亮一点，交互更高级一点，细节更精致一点。希望用这些工作，来提供更好的用户体验。
这事儿听上去没毛病，说到底是想把用户体验这事儿做到极致。但慢慢你会发现，这条路会越走越窄。
你推敲界面布局、打磨交互模式、调整风格样式，几乎把所有能做的细节都做到了。可产品体验还是没太多变化。用户依旧困惑，流程依旧卡顿，业务数据还是一样没有变化。
这其实是因为，体验从来就不仅仅是设计的事情。你看到是界面设计，但用户真正感受到的，是整个业务逻辑、产品流程以及界面设计的综合表达。
而业务逻辑和产品流程，大多数早在设计师接手之前，就已经决定了。于是就出现了一个常见的悖论：越想体现设计的价值，越容易深陷在细节里死磕。结果忙活了半天，却忽略了真正影响体验的地方。
说白了，这种状态，就是为了设计而设计。
听上去挺专业的，其实很多时候，不过是我们对自我价值的一种焦虑回应。但企业看重的不是这些。他们关注的是整个产品是否高效可控，是团队能否稳定产出，是设计投入能不能带来实际的商业价值。
他们要的，不是设计的最大化，而是业务价值的最大化。
想要改变这一点，设计师就不能总窝在自己的世界里打转。我们得往前多走一些，去看业务逻辑、产品流程，甚至是整个产品的服务流程。
但问题是，我们想往前走，得先把眼下的事儿理清楚。一个设计方案落不落地，一套组件库是否通用，一个交互模式是不是每次都得争… 这些问题不解决，哪还有空去谈体验的本质？
所以，在我们想办法改善设计的价值之前，**先得想办法让设计这件事本身，变得更稳定、更高效、更少争议**。
而这背后的关键，就是确定性。
## 什么是确定性？
所谓的确定性，就是不用每次项目都得重新判断、重新选择、重新争论。流程清楚、形式明确、结果可预期。越稳定的系统，越容易复制，越能高效地产出。而设计这个环节，恰恰是最缺确定性的地方。
一个设计师换一套风格，每个项目抠自己的交互细节，左滑右滑各有各的说法…… 本来只是想要增加一个用户提示，最后还得为弹窗是否可以关闭争论个半天。
所以我们需要的是一个工具，来把混乱收敛成秩序。而设计系统，正是用来解决它们的一套有效机制。
## 设计系统中的确定性
在一款产品的诞生过程中，通常有三个关键角色。
产品经理决定做什么，工程师负责怎么实现，而设计师，通常负责的是怎么呈现。也就是把业务逻辑、业务的意图，用一种清晰、易懂的方式传达给用户。
但现在的问题是，大部分互联网产品的形态早已稳定下来，能重新发明的地方越来越少。大多数时候，设计并不需要创造一个新界面，而是用最小的代价，给出一个稳定的解法。
而在这种背景下，设计系统的重要性就体现出来了。
说到设计系统，时至今天，依旧有很多人对它有着错误的认知。认为它只是一套样式手册，或者一堆组件拼起来的 UI 组件库。这些当然都是它很重要的一部分，**但如果只停留在这个层面，其实是极度低估了它的价值。**
设计系统不是样式手册，更不是一个 UI 仓库。它的本质，是一套帮助企业构建秩序的工具。目标很明确：用结构化的方式抽象最佳实践，压缩设计成本、减少沟通代价、降低出错概率。
不同设计师有不同的习惯，不同团队有不同的理解，结果是就是一个业务模块，看起来像三个人分别做了三套界面。更麻烦的是，这些差异背后往往还要伴随着大量的时间消耗。光是到底怎么做这件事，团队就要反复争论、推翻、重来。设计资源被反复浪费，方向也在拉扯中开始跑偏。
**这些混乱堆在一起，带来的就是企业层面的设计磨损。**
而设计系统，就是试图用结构、规则和共识，把这些磨损控制在可预期的范围内。它不是限制你的发挥，而是减少那些不必要的浪费。已经验证过的方式，不需要每次都重来一遍；早就清晰的交互，也没必要每次都开会讨论一遍。
它提供的，是一种可复用的稳定方案。把那些可以标准化的部分，抽离出来，封装成可直接使用的 Pattern，让每个设计师在面对同类问题时，不用再从头来过，也不用在细节上反复纠结。
说到底，设计系统真正想做的，是把你从反复判断中解放出来，把你真正的脑力，留给更重要的地方。
所以它强调的是一种有界的自由，解决设计过程里的不确定性。
## Pattern，设计系统中的秩序单元
你可能也意识到了。要解决“为了设计而设计”的困境，光靠经验和努力是不够的。
真正能帮你跳出细节死角、建立稳定机制的，是一套结构化的认知方式。
而 Pattern，正是这套结构的关键思考模式。它不是样式手册，不是组件集合，而是一种让设计思维从“界面设计”走向“秩序构建”的方法和思考模式。
在接下来这篇文章的付费部分，我想继续和大家深入聊聊：
- Pattern 如何构建“团队共识”？
- 为什么说它才是设计系统中最核心的秩序单元？
- 当 Pattern 成为基础能力，设计师又该如何改变自己的角色？
如果你也正在面临开头提到的那些困扰。那么也许，是时候换一个更结构化的方式来看待设计这件事了。
> 💡 延伸阅读：
> - 设计师的下一站：[设计师的下一站，成为架构师，还是走向业务？](/designer-architect-or-business/)
> - 系统化思维深度：[设计系统 · 我们为什么要做 Design System](/why-we-need-design-system/)
> - 业务视角思考：[业务思考力，设计师跳出执行的起点](/business-thinking-for-designers/)
欢迎订阅我的小报童专栏，解锁后续全文。
================================================================
# 从概念到落地，产品界面的 AI 生成究竟卡在哪儿了？
- **发布日期**：2025-03-31
- **原文链接**：https://www.thefivekey.com/ai-generated-ui-not-work/
- **Markdown 原文**：https://www.thefivekey.com/ai-generated-ui-not-work/index.md
- **标签**：设计 AI, 设计工具, 设计模式, 设计系统
> 产品界面的 AI 生成在 Demo 演示阶段令人惊艳，但从「能演示」到「能在业务中使用」之间隔着三道坎：生成质量、生成认知、生成结构。本文拆解为什么 AI UI 生成始终无法真正进入企业业务流程，以及设计系统在其中扮演的关键角色。
> **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 只是用了更贴合业务的“包装方式”来让公司接受，而其背后需要解决的问题依旧存在，一直都没有变过。
产品界面的 AI 生成，不是一个新鲜话题了，每隔一段时间我们都会拿出来讨论一下。过去两年我陆续就写过一些相关的文章。那个时候，这个方向正热，无论是海外的 Uizard，还是国内的各大设计协同平台，大家都在推“用一句 Prompt 来生成界面设计”，似乎接下来这些界面设计的工作都可以交给 AI 来完成了。
看上去方向已经跑通了，行业共识几乎已经形成。但热闹了一阵子后，这些平台却都渐渐地没了声音。这有是什么原因呢？在我看来，核心在于在经过了初期的探索、兴奋之后，大家逐步意识到，**从“能够生成”到“能够在业务中使用”之间，存在一条看不见的鸿沟，而这条鸿沟我们暂时还无法跨越过去。**
如果把这个问题拆开来分析，你会发现其实背后卡住我们的，核心并不是某些技术上的难题，而是存在着三个不同层次的问题叠在了一起，导致了现在的“停滞”局面。
## AI 生成 UI 的三道坎：生成质量、生成认知、生成结构
在这里，「能用」这个词其实有两层含义。
第一层含义是 AI 生成**能跑通**，大模型能够将界面生成出来，完成用户提出的一个需求。
第二层含义则是让生成能力能**真正能在业务中发挥作用**，能够嵌入到实际的工作流中，像一个设计师一样按照业务的要求，理解需求、交付设计。
在我们当前的技术实现中，AI 在生成界面时，虽然能够使用相应的 UI元素来构建界面，但由于缺乏对行业、业务的理解，生成的结果往往并不如人意。界面可能看上去有模有样，但逻辑不对、交互不合理、业务信息缺失，从而导致它无法真正服务于真实的业务场景。
简单点来说，第一种“能用”意味着界面能“生成”，第二种“能用”则是指生成的界面可以“被用”。这两个层面看起来很相似，但本质上差距巨大。事实上如果只是做到第一个“能用”，那么 AI 设计对于企业来说其实是没用的。
那么，AI 究竟要具备什么样的内容里才能真正“能用”呢？
在我看来核心在于生成质量、生成认知和生成结构三个核心要素，想要让界面设计的 AI 生成能力能真正跑起来，这三者缺一不可。
首先，是**生成质量**的问题。
AI 交出来的这份“作业”，在完整性、专业度和可用性上到底合不合格？但事实上，很多情况下，AI 生成的界面基本结构都不完整，生成的能力极度不稳定。
其次，是**生成认知**的问题。
通过 NLP，它可以理解我们需要的是什么，但是通用大模型，并不了解具体的业务逻辑。结果就是，生成的界面看上去形式对了，但语义和业务意图却完全对不上。
最后，是**生成结构**的问题。
这里讨论的不是界面生成质量好不好的问题，而是它是否具备稳定的输出。会不会同一个类型的需求，今天生成的结果是一个样，明天又是一个样？这就涉及到我们一直提到的「确定性」问题，但往往现在的大模型给我们的结果并不具备很好的确定性。
三个层级，卡在任何一层，最后生成的界面看上去都像那么回事，但实际上就是用不了。
如果真想让它前面的 Demo 得以实现，让 AI 能力能真正进入到业务流程，我们该从哪里下手？设计系统的 AI 化，到底该怎么做？什么样的抽象、封装与规则建立，才是真正可行的路径？
下半部分，我将尝试从这些问题出发，结合实际案例，聊聊一套“能落地”的界面生成能力，需要具备哪些条件。以及我们有哪些方法可以逐步推动它实现。
以上是本期专栏文章的免费部分内容。欢迎订阅我的小报童专栏，解锁本期文章全文内容。
---
## 💡 延伸阅读
- 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
- 2023-09 [半年过去了，AI 设计的进展如何?](/progress-of-ai-design-in-ui-interface/)
- 2024-06 [一年过去了，AI design 的进展如何？](/current-trends-ai-design-in-interface-design/)
- 2024-10 [产品界面的 AI 生成式设计，为什么没人关注了？](/why-generated-ai-ui-design-is-losing-interest/)
- 2024-11 [Salesforce 的生成式画布，证明了 AI 在产品界面设计中的可行性？](/salesforce-generative-canvas-proves-ai-ui-design-feasibility/)
- **2025-03 从概念到落地，产品界面的 AI 生成究竟卡在哪儿了？ ← 你在这里**
- 2026-04 [把设计系统变成 Markdown：让 AI Coding 真正读懂你的设计约束](/design-system-as-markdown/)
================================================================
# 当用户喝多了，需要找代驾
- **发布日期**：2025-03-21
- **原文链接**：https://www.thefivekey.com/the-user-is-drunk/
- **Markdown 原文**：https://www.thefivekey.com/the-user-is-drunk/index.md
- **标签**：设计思考, 产品设计
> 如何优化代驾 App，让醉酒用户也能顺利下单？借用"The User Is Drunk"这个设计观察方法，从一次真实的代驾叫车经历出发，探讨那些常被忽略的「情境性障碍」设计：产品不仅要服务正常状态的用户，也要能服务被酒精、疲惫、情绪等状态降级的用户。
> **TL;DR**
>
> 产品设计不能只服务"正常状态"的用户。
>
> 借用"The User Is Drunk"这个设计观察方法：把自己想象成一个醉酒的用户来重新走一遍流程，你会发现大量平时合理的设计会瞬间崩溃。
>
> 情境性障碍（醉酒、疲惫、紧张、分心等）才是真实世界里最常被忽略的设计盲区。
## 一个找代驾的故事
前两天晚上有个饭局，朋友喝得有点多，准备叫个代驾回酒店。他低头打开手机，目光呆滞地盯着屏幕，手指在屏幕上划来划去，捣鼓了半天。几分钟后，一脸不爽的把手机扔到了桌上，嘟嚷了一句，什么破玩意，太难用了。
最后，他女朋友接过手机，把代驾叫好。无奈地笑笑说：“确实有点复杂，喝多了还真不好操作。”
这时我在想一个问题：是不是所有喝多了需要代驾的人，都会遇到同样的麻烦？头昏脑胀、眼神飘忽、手指不听使唤，这种状态下，掏出手机还能顺利下单吗？
我不喝酒，所以也从来没有经历过醉酒后叫代驾的场景，因此我没法靠亲身体验来判断。但作为一名设计师，我对这个问题有点兴趣。
回到家，我打开某出行 App 仔细研究了一下，想看看朋友刚才遇到的麻烦到底出在哪里。
我的第一感受是，打车和代驾服务的界面几乎是一模一样，布局、功能及交互方式都没有太大区别。
虽然我自己没用过代驾，但打车服务还是偶尔会用的。对比了一下流程，选出发地、选目的地、选车型、确认订单，再加上各种营销广告、弹窗，整个界面信息量不小。
清醒的时候可能还好，但如果是一个喝醉的人面对这些信息，想要顺利的下个单的确不是那么顺畅。这么一想，朋友刚才的不爽，好像也不是没道理。
接着我开始在网络上搜索，想看看是否有人分享过类似的经历，或者有没有什么研究可以参考。案例是没找到，但我倒是发现了一个有趣的东西 - The User Is Drunk。
## The User Is Drunk
The User is Drunk（用户喝醉了），是产品设计中的一个理念，也是一项有趣的服务。
这个想法是设计师 Richard Littauer 在 2015 年提出。他在工作之余还提供了一项独特的体验测试服务，在醉酒的情况下测试客户网站（或产品）的可用性。
图片来源：https://theuserisdrunk.com/
Richard 会先灌醉自己，再打开客户的网站（或产品）进行浏览、操作。同时他还录制整个过程，一边使用一边“吐槽”，指出那些让自己用起来很难受的操作和体验。第二天，他会再将录制的视频整理后发给客户。
YouTube 上现在还能找到 Richard 录制的部分测试视频，推荐大家可以随便找一个看看，感受一下。
> https://www.youtube.com/@richlitt/search?query=drunk
这个服务在当时引起了不小的关注。
不过，说实话，这些视频严格来说算不上真正的用户体验测试。它并不像我们前面提到的叫代驾那样，有明确的任务要完成，而是随意地浏览一些页面，一边看一边发表即兴的使用体验点评。
但有意思的是，「The User Is Drunk」 这个概念引发了很多公司在产品设计上新的思考：如果用户在醉酒状态下使用我们的产品，会发生什么？
于是，「The User Is Drunk」从一个测试服务，逐渐演变成了一种产品设计理念。
它的核心观点是：产品的设计应该足够直观、直接，即便用户喝醉了，也能顺利使用。 换句话说，如果一个醉酒的人都能毫无障碍地完成操作，那对普通用户来说，它的体验一定是简单、顺畅的。
如果我们把「The User Is Drunk」 这个理念再进一步延展，会发现它其实适用于更广泛的情境。我们是否应该在产品设计时考虑用户处于某种认知受限、操作受阻的状态和场景？
这些场景可能不同于“醉酒状态”，但它们有一个共同点，那就是用户的操作能力、认知能力或感知能力因为特定环境受到了限制，导致他们无法像平时一样轻松使用产品。
而这其实就进入了另一个话题 - 情境性障碍设计（Situational Disability Design）。
以上内容，是本期文章的免费部分。在接下来的付费部分中，我将详细讨论一下情境性障碍。以及在前面的那个案例中，我们如何思考代驾功能的界面设计。
> 💡 延伸阅读：
> - 设计观转变：[从做设计，到构建秩序](/from-chaos-to-order-in-design/)
> - 设计与业务连接：[设计的意义，得用业务语言讲明白](/design-business-value/)
加入 OFF DESIGN，获取本期文章的付费部分内容。
================================================================
# 多邻国 Handbook 中文版
- **发布日期**：2025-02-22
- **原文链接**：https://www.thefivekey.com/duolingo-handbook-zh/
- **Markdown 原文**：https://www.thefivekey.com/duolingo-handbook-zh/index.md
- **标签**：设计思考, 产品设计
> 前段时间多邻国在官方 Blog 上发布一份 Handbook，给大家分享了公司成立以来的一些成功经验、产品思路和一些有趣的文化理念。
本文档由 5key 借助 DeepL、Perplexity 进行翻译，并结合个人理解完成校正，旨在为网友提供学习参考。如有翻译不当之处，敬请谅解。
原文 PDF 文档见底部链接 。
转载请注明出处：https://xiaobot.net/post/a615ae51-416a-40c4-92a9-9412eb644202
我们的使命是发展世界上最好的教育，并普及到全世界。
## CEO 路易斯的来信
> Duolingo 是一个古怪的地方。
> 如果某件事对短期有利，但从长远来看会损害 Duolingo 的利益，那它就不是正确的选择。
### 多邻国从来不是一场短跑
这并不是一个快速的实验，也不是一个周末的副业。
我们知道，打造全球最好的教育应用将是一项需要数十年的努力，并且需要耐心。但耐心，也就是放眼长远，这的确是很难做到的。
以广告为例。我们可以通过在应用中展示更多广告来立即增加收入。但我们也知道，过多的广告会惹恼用户，阻碍长期增长，甚至可能影响我们实现“让最好的教育普及化”这一目标。
这确实是一个权衡。但一次又一次，我们选择了放眼长远。我们必须这样做，因为我们的目标太宏大，无法以其他方式思考。
### 起初
并不是每家公司都能以这种方式运作。但我们拥有一些早期的优势，使得“放眼长远”成为可能。首先，路易斯（Luis）在2009年已经成功出售了他的第一家公司 reCAPTCHA。正如他所说：
> 这让我有了更多的灵活性和视角，能够将我们的使命放在首位。
因此，我们开始致力于打造一款具有突破性的产品。一种即使是我们的孩子和孙辈也可能继续使用的教育工具。这一愿景的清晰性，加上早期投资者的信任，让我们在探索多邻国未来可能性时拥有了更多的自由。
同样重要的是：我们招聘了一群对我们的使命同样充满热情的人。在当时，他们中的许多人如果选择去更大的科技公司工作，薪资可能会翻倍。但他们来这里并不是为了快速赚钱，他们是为了打造地球上最好的学习工具。
### 不要做愚蠢的事
短期收益的诱惑可能非常强大。在早期，我们有一个简单的信条：
> 不要做愚蠢的事。
回头看，这其实是“放眼长远”的第一个版本。我们知道，如果想要实现有意义的成功，就必须避免那些看似有助于短期发展的噱头和技巧，因为它们最终会在未来伤害到我们。
### 投注于技术
放眼长远不仅仅是避免某些事情，还涉及你选择拥抱的事物。
我们是技术乐观主义者。从一开始，我们就相信技术的进步会让我们最具雄心的想法成为可能。而押注技术的进步对我们的运营方式至关重要。
例如，我们在早期选择投资于文本转语音系统，而不是录制真人语音。尽管一开始我们的音频听起来像机器人，但我们知道技术会随着时间的推移而改进。
### 长远视角的招聘
招聘决策是我们所做的最重要决策之一。
这就是为什么我们花时间找到合适的人，即使这意味着等待。每一位新员工都需要达到我们的标准。这人是否优秀卓越？他们是否愿意亲力亲为？他们是否是清晰的沟通者？他们是否会将公司利益置于个人目标之上？
我们不会为了填补组织中的空缺而妥协招聘标准，尤其是在团队合作方面。正如我们在多邻国所说：
> 宁可有一个空缺，也不要一个麻烦。
### 留住优秀的人才
好消息是，当你雇佣了合适的人，他们往往会留下来。
而我们的经验验证了这一点：平均而言，多邻国员工的任职时间远长于大多数科技公司的员工。许多人从大学毕业后加入我们，在这里发展技能，并随着时间的推移迎接新的挑战。不论你的经验水平如何，我们希望你能长期与我们同行。
### 打造一款“永恒的产品”
多邻国应用的设计目标是短期内具备吸引力，长期内实现变革性影响。多年来，我们专注于构建一款既实用又令人愉悦的产品，使其成为用户生活中不可或缺的一部分。
学习，尤其是语言学习，需要长期的规律练习。这就是为什么我们优先考虑用户留存，并花费数年时间完善“连击”（Streak）功能。我们能让学习者长期坚持得越久，他们从多邻国中获得的价值就越大。
我们也在提升教学质量上进行投资。尽管这不会立即带来收入，但我们知道，如果产品无法兑现其承诺，用户最终会停止使用它。
### 通知
每天 Duolingo 都会向学习者发送数百万条消息。这些通知反映了短期目标和长期思维之间的根本张力。
更多的通知可以在短期内增加每日活跃用户（DAU）。但如果用户感到被轰炸，他们不会长期留下来。最终会关闭通知，甚至完全放弃使用应用。这就是为什么我们对通知数量设置了严格限制，无论短期指标如何表现。
用户信任比即时收益更重要。
### Juicy 设计语言
多邻国并不总是像今天这样看起来生动有趣。多年来，它的界面以浅灰色背景、柔和的按钮颜色以及一个更“机器人化”的 Duo 为特色。
但在2018年，我们的一些设计师和插画师开始为一款儿童应用构思设计方案。通过更明亮的配色、更圆润的边角以及一个更可爱、更友好的 Duo，这种新设计让学习感觉更像是一场游戏。这正是我们希望为主应用提供的那种有趣体验。
因此，即使我们并不指望它能在短期内提升指标，我们仍然大胆尝试，并将这种新的设计语言，称为“Juicy”，并应用到整个多邻国平台中。
这次重新设计不仅仅是关于美学，它是一项面向未来的投资。
尽管风险高且资源密集，但它为如今定义我们品牌的有趣世界奠定了基础：富有表现力的角色、生动的动画以及一种像游戏一样的学习体验。
通过“放眼长远”，我们创造了一种设计语言，可以随着产品的成长而扩展，并持续多年。
### 成为被认可的标准
当被问到某人英语水平如何时，我们希望他们回答：“我的多邻国分数是70。”
多邻国分数是用户在学习语言中的熟练度估算，而多邻国英语测试（DET）则是一种认证方式，可以将这一分数用于高风险场景，例如大学入学申请。两者结合，形成了我们成为语言熟练度标准的双管齐下策略。
将分数显示在应用中为我们带来了巨大的曝光量，数亿人都会看到它。而通过 DET 进行认证则赋予了我们可信度。这一分数甚至可以帮助你进入世界上最负盛名的大学。
当然，成为一个被认可的标准并不容易，可能需要几十年的时间。但这正是为什么多邻国分数和 DET 是“放眼长远”的绝佳例子。
### 通过工程构建未来
在工程领域，“放眼长远”需要采用略微不同的方法。
即使是现在，我们仍会在未来几年不断改进我们的产品。因此，我们不会构建“永远有效”的系统，而是快速测试想法，仅在成功时才投入大量工程资源。如果某些事情不起作用，我们会迅速放弃，保持代码库的整洁并尽量减少浪费。
视频通话就是一个很好的例子。只有当它显示出长期用户粘性的潜力时，我们才投资于其扩展和稳定化。
另一个例子是通知功能。当我们意识到未来几年都会测试通知文案时，我们开发了一个定制工具，让产品经理可以在无需工程支持的情况下测试文案。
这种平衡，专注于速度，同时为真正有效的长期投资保留资源，引导了我们的成功。
### 成为一家企业
多年来，多邻国并不盈利。我们专注于扩大用户基础并保持学习者的参与度。同时，我们中的一些人担商业化可能会妨碍我们的使命。
这一视角在 2015 年 D 轮融资后开始转变。我们开始探索收入模式，包括应用内购买、广告以及付费订阅，但有一个关键前提：这些模式绝不能妨碍我们的使命。我们也不会把学习锁在付费墙后面。
### 构建商业化引擎
我们从应用内购买开始，但除了 Streak Freeze 外，几乎没有什么可供“购买”的内容。广告的展示也受到了限制。我们发现每节课后展示一条广告不会影响用户留存，但如果广告过多，就会让用户流失。
> 注：Streak Freeze 是多邻国商店中的一个道具，可以防止用户在未能达到每日目标时失去中断。
很快我们便意识到，引入一种免费增值订阅产品是扩展业务的最佳机会。困难之处在于，如何在提供订阅服务的同时，依然为无法付费的用户提供优质的产品。
最终，我们推出了一种订阅套餐，该套餐移除了广告，并为学习者提供了无限生命值。这两个功能都减少了应用中的使用障碍。
多年来，我们不断优化这一模式，但核心逻辑始终未变：付费产品为我们提供了资源，以最大规模追求我们的使命，而免费产品则是实现这一使命的主要途径。
许多投资者，甚至包括我们多邻国的一些成员曾质疑，提供如此优质的免费产品是否会让学习者缺乏订阅的动力。这种“可及性”与“收入”之间的张力可能永远存在。然而，随着时间推移，我们的商业化方式证明了我们可以找到平衡，在建立大型业务的同时，实现长期用户忠诚度。
### 百年品牌
通过稳步增长和巧妙的营销，我们让多邻国成为了家喻户晓的名字。即使从未使用过这款应用的人，也熟悉我们的吉祥物，那个令人愉快但偶尔有些“脱线”的 Duo。我们在 Duo 的发展历程中投入了大量资源，同时也投入到其他角色及其所处的世界中。这些努力充分体现了我们的雄心壮志。
我们不仅仅是想帮助人们提高法语水平。我们的目标是打造一个品牌及一组角色，使它们成为人们生活的一部分，将全世界的人转变为日常学习者。
### 角色的重要性
我们的角色让学习变得有趣。通过简单的几何形状构建，每个角色都有独特的个性和故事。它们共同反映了学习者的多样性，为应用注入了幽默感和趣味性。
但这些角色，与其说是受传统学习公司启发，不如说更像任天堂等品牌的风格，还具有重要的战略意义。
我们将这些知识产权（IP）视为业务的关键支柱，尤其是在人工智能学习工具兴起的时代。这种情感连接不仅让学习更愉快，还使我们的产品随着时间推移变得更具粘性。即使有人完全复制了我们的应用，学习者仍会因为这些角色而回到多邻国。
### 投资于营销
在多邻国我们通过创造人们真正喜欢并乐于分享的产品实现了增长。但我们也学会了如何利用其他杠杆，比如效果营销，以补充这种自然增长。
我们的付费广告旨在放大口碑传播的势头，而不是取而代之，因此我们对支出保持谨慎。这让我们能够投资于那些突出的营销活动和反应迅速的社交时刻，从而使我们脱颖而出。
我们的营销团队擅长以低成本创造高影响力的内容。多亏了他们，Duo 已经走上了《芭比》电影首映礼的红毯，在流媒体服务 Peacock 上主持了一档（虚构的）恋爱真人秀节目，并成为了一位国际社交媒体明星。这些时刻体现了品牌那种充满活力、略带叛逆的能量，同时表明有机增长与精心策划之间的平衡可以创造有意义的影响力。
### 学习路径
最初，学习者通过“知识树”（Tree）在多邻国中导航，这种结构由技能组成（例如“去餐馆”）。
每项技能从基本的单词含义开始，逐步进阶到更难的内容，但学习者只需完成第一层级即可继续前进。尽管这种灵活性让他们能够快速进展，但当遇到更难的概念时，往往会暴露出基础知识的不足，从而导致挫败感。
2022 年，我们迈出了大胆的一步：用“学习路径” 取代了“知识树”。这种新的线性结构要求学习者按顺序完成每一课，从而确保每个人都能建立一致且扎实的基础。
“学习路径”是一个涉及工程和设计的大型项目。我们预料到学习者可能会对这种日常学习方式的剧烈变化产生抵触情绪。尽管数据并未立即显示核心指标（如每日活跃用户或收入）的改善，但这一改变是正确的决策。
它优先考虑了真正的掌握，而非快速完成简单课程以保持“连击”。它还为我们提供了更清晰的学习者进度洞察，并让我们对学习体验有了更大的掌控力。
有时候，“放眼长远”意味着做出一些看似短期内无益的大胆决策。“学习路径”正是如此。它从根本上改变了人们在多邻国上的学习方式，并成为我们成功的重要基石。
## 原则 2：提高标准
卓越不是一个遥不可及的目标，它是我们的基本标准。
我们的期望是，在这里我们能够完成职业生涯中最出色的工作，不断提升技能和创意，达到我们的标准，并超越它。
当然，我们也是人，难免会犯错。当错误发生时，我们不会追究责任，而是深入分析，找出问题所在。这就是我们如何持续提升标准的方法，不是追求完美，而是每天变得比昨天更好一点点。
### 卓越文化
我们的质量标准从一开始就被设定在最高水平。路易斯（Luis）、塞维林（Severin）和早期团队对细节的关注几乎到了“荒谬”的程度。（路易斯是一位罕见的 CEO，他至今仍会报告自己在应用中发现的每一个 bug。）
但如今，这不仅仅是关于领导层或某个个人的努力。随着公司的成长，我们携手定义了卓越的明确标准，并将其扩展到整个组织。
### 承担责任
保持高标准的关键之一是明确责任归属。这意味着某项任务都会指定一个具体的负责人或团队，并清楚地告诉他们：“你负责。” 我们一次又一次地看到，只有明确了责任的事情才能达到卓越。
随着公司的发展，不明确的责任归属可能成为一个挑战。一项任务可能涉及四个职能部门和七个团队，但却不清楚谁负责什么。总会有一些项目难以明确责任，甚至无法指定负责人。但公司最重要的项目必须有一个明确的负责人。
### 对工作严格，对人宽容
我们的文化以温暖和友好著称，这很好！但过于“温暖模糊”的文化有时会让人难以进行艰难的对话。在设计和产品反馈方面，我们一直直言不讳，但我们希望在其他领域也能更加坦率。
我们的标准是：“对工作严格，对人宽容。”
这意味着要提供建设性且清晰的反馈，以帮助完善想法，而不会破坏人际关系。
我们关注的是“问题是什么”，而不是“谁的问题”。
这也意味着要乐于接受反馈，并且不将其视为对个人的攻击。这种坦诚且建设性的方式让我们能够彼此保持高标准，同时促进信任与协作。
### 内部试用，吃自己的狗粮
我们保持卓越的另一个关键方式是每天使用自己的应用。这确保了我们自己也热爱这款产品，并能够快速发现和解决问题。为了让这一流程更高效，我们开发了“摇一摇提 Bug”工具。这是一种简单的功能，任何公司成员都可以通过摇动设备立即截图并报告问题。
多年来，“摇一摇提 Bug”已成为我们开发流程中不可或缺的一部分，使应用中的卓越表现成为每个人共同的责任。
### 设定标准
那么，这个卓越的标准到底是什么？我们如何确保达标？让我们看看在公司的一些领域中，这个标准是如何体现的。
产品和设计的标准
在产品和设计领域，我们遵循以下四个核心要素：
01. 实用性（Useful）
学习者需要从我们构建的内容中获得实际用途。否则，我们只是增加了应用的复杂性，分散了学习者的注意力，使他们无法专注于学习。
02. 直观性（Intuitive）
学习者应该专注于学习，而不是花时间搞明白如何使用应用。每个功能都必须对所有人来说易于使用。无论是 75 岁的印度用户用安卓设备，还是 16 岁的纽约用户用 iPhone。每一个功能或界面都不应该需要额外的解释或背景信息，否则它就不够直观。
03. 愉悦性（Delightful）
每个新功能都需要带来一定程度的乐趣和愉悦感。即使在功能的第一个版本中，我们可能不需要复杂的动画，但也应该有一丝魔力，让学习者感受到乐趣。
04. 精致性（Polished）
这是让功能显得完整的关键。紧凑的视觉设计、精准的文案以及流畅的交互是基本要求。一切都不应该显得笨拙或不一致。例如，我们不应该同时有“返回”按钮和“关闭”按钮来完成相同的操作。
### 招聘标准
我们的团队为我们所做的一切设定了基准。
因此，我们坚持只招聘卓越的人才，不仅在技能上出类拔萃，还要在人品上表现突出。这可能意味着某人是班级中的佼佼者，或者是家族中第一个大学毕业的人。但更重要的是，他们必须真诚且友善。为了保持这一标准，路易斯（Luis）和塞维林（Severin）至今仍会亲自审批每一位新员工的录用。
我们不会为任何人降低这个标准。
例如，有一次，我们放弃了一位高级管理职位的候选人，即使这个职位已经空缺了一年多。原因是他们不够友善。尽管他们在面试中表现出色，简历也很强，但他们对从机场接他们的司机表现出了不尊重。这一个瞬间就让我们知道了所需的信息。
> 卓越不仅仅是你做了什么，更在于你如何对待他人。
### V1s 而非 MVPs
在科技领域，发布未完成的功能或最小可行产品（MVP, Minimum Viable Product）是一种常见做法。然而，MVP 通常伴随着一套特定的预期，以及局限性。
因此，在多邻国我们不做 MVP，只做 V1。
两者的区别至关重要：
MVP 通常质量标准较低，甚至可能被用作发布次品的借口。
而 V1 则不同，它是经过打磨的。尽管它可能没有所有的附加功能和细节，但它达到了我们的质量标准。有时，这种方法可能需要花费更多时间，但我们拒绝通过展示“半成品”来妥协用户体验。
## 原则 3：快速交付
> 为了将一个美好的想法变为现实，我们需要带着紧迫感行动起来。所以，加油，加油，加油！
### 创立初期，我们所有人都在一起共同协作
我们没有正式的产品评审、OKR 或任何今天的结构化流程。因为没有其他学习应用尝试过我们正在做的事情，所以也没有蓝图可供参考。无论好坏，我们都是一边摸索一边前进。
我们也快得惊人。我们实验的速度让我们能够迅速判断什么有效，什么无效，并果断舍弃那些行不通的东西。这种方式适用于所有领域：产品、招聘、工程以及整个业务。我们以极快的速度进行测试和学习。
即使到了今天，我们仍然保持这种工作方式。我们每周都会发布新版的 iOS 和 Android 应用，同时公司任何时间点都在运行数百个实验。没有“快速交付”这一原则，多邻国就无法取得如今的成就。
- “快速交付”让我们始终领先于竞争对手；
- “快速交付”让多邻国成为一个有趣的工作场所；
- “快速交付”确保我们的产品始终在不断进步。
### 全速前进
多邻国是数千个实验的累积成果。我们运行实验的速度越快，无论这些实验是否成功。我们就能越快改进应用并推动使命的实现。随着时间推移，这些变化会相互叠加，形成一种复利效应。
快速发布还让我们避免了关于“我们应该做什么”的冗长讨论和猜测。这是因为在真实世界中进行测试比任何内部讨论都能提供更有价值的信息。因此，我们以快速行动为原则，启动反馈循环，让真实数据引导我们的工作。
### 时钟速度
“时钟速度” 是一种驱动我们工作的思维方式。这个概念来源于微处理器技术，指的是系统处理指令的速度。在多邻国，我们借用这个术语来讨论如何最小化行动之间的间隙：从决策到实施，以及从收到反馈到完成更改的时间。
通过这种方法，我们专注于减少每个环节之间的延迟，以保持高效和敏捷的工作节奏。
提高“时钟速度”帮助我们减少空闲时间，并确保最重要的项目能够真正完成。我们几乎不应该需要等待一个月才能看到某个项目的下一次迭代。缩短这些间隙的时间，意味着我们可以更快地交付、更快地学习和改进。
这并不是在追求“赶工”，而是确保链条中的任何环节都不会拖慢我们的进度。
### 无情的优先级排序
尽管我们希望快速行动并提高时钟速度，但我们始终需要确保自己专注于正确的事情。在多邻国，优先级排序有时被形容为“无情的”：我们果断地决定公司应该专注于什么，基于哪些事情对学习者会产生最大的影响。
这一理念也延伸到我们的产品中。我们会砍掉那些无法创造价值的功能，移除不必要的复杂性，并始终专注于我们的使命。放弃无效的事物往往与创造新事物一样有力。
### 实验文化
“快速交付”不仅仅是追求速度；它还关乎创造尽可能多的机会来学习和改进。我们喜欢尝试，甚至有时会有些疯狂。虽然偶尔会失败，但每次实验都让我们更接近找到有效的方法。
### 99 个糟糕的想法
我们的一些最佳功能和营销活动都源于那些看似荒谬、不太可能的问题。
在领导层的外部研讨会中，我们有一个传统，称为“99 个糟糕的想法”。在这个环节中，我们会集思广益，提出一些离谱的创意，比如 Duo 的最新恶作剧，或者将我们的股票代码改为 LILY。
但这种精神不仅限于领导层，而是贯穿整个公司。我们为挑战假设和提出大胆问题留出了空间。例如：
如果用户可以与多邻国的角色对话，会怎么样？
如果 Duo 有 5 秒钟的超级碗广告时间，它会做什么？
如果语言认证测试可以在家里完成，会怎样？
多年来，这些类型的问题帮助我们不断发现新的机会，让学习者感到惊喜，并推动我们的使命向前发展。
### 适量的流程
随着多邻国的成长，保持敏捷性变得更加困难。我们需要设置一些规则和流程来防止事情失控，但同时也要避免不必要的繁琐程序。那么问题来了：如何在不拖慢效率的情况下引入适当的流程？
好的流程应该能够减少工作量、提升质量，并帮助做出更好的决策。例如，“产品评审”就是一个很好的案例。
在早期，路易斯（Luis）经常在非正式会议中做出产品决策，这有时会变得混乱。并不是所有相关方都被包括或知情，更糟的是，有时甚至不清楚这些决策是否具有约束力，还是路易斯的一时想法。
我们需要一个更好的方法。
### 从工程实践中汲取灵感
借鉴工程领域的代码评审流程，我们为“产品评审”引入了一种正式结构。
如今，“产品评审确保每个人都清楚已经做出的决策，并且所有相关利益方都被通知到位。这些会议还包括来自产品和设计团队的轮值领导者，他们提供意见，确保多样化视角。
“产品评审”的成功为其他团队树立了榜样。
例如，市场团队也引入了类似的“营销评审”，为他们的活动带来了相同的清晰度和一致性。这些流程帮助我们保持高质量标准，同时让整个公司能够更快、更透明地做出决策。
## 原则 4：用结果说话，而不是解释过程
> 我们使用清晰、简洁的沟通方式，以数据和实际影响为基础。
### Show Don’t Tell
“Show Don’t Tell”的意思是：我们以工作的成果为主导，而不是讲述努力的过程。
这种方法与我们大多数人所受的教育不同。在学校或之前的工作中，我们经常学习如何通过沟通来说服他人，用推销和故事来展示自己。尽管这些技能有其用武之地，但它们并不是发现真相、解决问题或创造伟大事物的方式。
### 数字就是故事
当指标可用时，它们应该成为我们所有工作和沟通的核心。决策必须基于证据，而不是抽象的叙述。
通过专注于实际结果（例如，新功能对每日预订量的影响），我们可以快速评估某件事是否适合应用。但这种精神远远超出了应用本身。例如，我们会衡量办公室的使用情况（包括哪些空间未被使用），以便让每一个新空间比之前更好。
### TL;DR
我们“用结果说话”的一个关键方式是通过 TL;D。在任何重要沟通的顶部，我们都会提供一个执行层级的摘要。我们在许多地方使用它，比如功能性能分析、会议前的阅读材料，以及新政策公告。
撰写强有力的 TL;DR 可以提高你的工作被看到和记住的几率。它让复杂的信息更易于理解，并且最重要的是，鼓励更清晰的思考。要写好一份 TL;DR，你需要将信息提炼到最核心的要点上。
### 少说多做
原型，而非提案
讨论想法往往不如实际动手来构建它们来得有效。原型让我们能够将概念变为现实，统一团队的愿景，并快速推进项目。
在处理复杂挑战时（例如将 AI 集成到现有功能中），原型尤其重要。
### 优秀的产品无需解释
我们的应用设计以直观为核心。与其通过弹出消息或冗长的新手引导流程来告诉学习者如何使用多邻国，我们更倾向于通过设计、动画和简单提示来“展示”功能。
无论用户是第一次还是第百次打开多邻国，学习体验都不应该需要任何说明。这样一来，用户就可以真正专注于学习本身。
这一原则同样塑造了实际的学习过程。研究表明，最有效的学习来自于实践体验，而不是一长串指令。例如，与其解释语法规则，我们更倾向于通过互动练习和引人入胜的视觉效果来展示语言模式。
### 想法优先于自我
伟大的想法不需要销售推销，它们需要机会来证明自己。在多邻国我们优先考虑结果而非个人观点。通过赋能团队探索大胆的概念，并让数据指标指引方向，我们确保最好的想法能够脱颖而出。
### 分歧与承诺
分歧在所难免，但在这里，我们通过采取行动而不是陷入僵局来应对它们。当双方意见不一致时，双方都会承诺推进一个决策，并让结果自己说明问题。
例如，即使像路易斯（Luis）这样的人对某个想法有所怀疑，他们通常会说：
去试试看吧，看看会发生什么。
这正是排行榜功能的诞生过程，如今它已成为应用中的一个关键功能。
这种心态不仅限于产品开发。例如，在我们的社交媒体团队中，初级团队成员也被信任去尝试大胆的想法，并衡量其影响。通过为实验创造空间，我们确保结果而非个人意见，以此来引导前进的方向。
### 信任电池
建立信任是这一方法的重要组成部分。在多邻国，信任不是理所当然的，而是通过努力赢得的。通过有影响力的工作，每个人都为自己的“信任电池”充电。
无论你是实习生还是新入职的高管，你都需要从有意义的贡献开始，展示自己的价值。每一次贡献都会为“信任电池”充电，逐渐积累信任储备，从而加强协作、决策能力和责任感，并随着时间推移不断巩固。
## 原则 5：让一切变得有趣
> 我们为所做的一切带来幽默、快乐和想象力。
### 学习不必枯燥，工作也一样。
当你进入多邻国的世界时，会感受到一种鲜明的幽默感。这不是一个充满扑克脸和形式化的文化，而是一个充满创意和趣味的世界。巨大的毛绒猫头鹰在冰上出演虚构的百老汇音乐剧；任何疯狂的想法都可以被提出来，比如愚人节推出“语言学习厕纸”的营销活动。
在这里，没有人能逃过玩笑的洗礼，甚至连 CEO 也不例外。
### 一款以“玩乐”为核心的产品
教授语言的方法有很多，但如果学习者无法保持参与感，这些方法都不会奏效。
从一开始，我们就决定将多邻国设计为一款游戏化的应用。随着时间推移，我们通过引入越来越多的互动机制，吸引学习者不断回到平台上继续学习并取得进步。但这些策略并不是让我们与众不同的唯一原因。
多邻国感觉像是一个完全不同于传统教育工具的世界。
在这里，会发生一些奇怪而意想不到的事情。课程被设计成类似脱口秀或电子游戏的形式。
例如，“你的熊正在喝啤酒”这样的句子接近荒诞，而角色 Lily 会用讽刺的语气通过一个缓慢的鼓掌来支持你的进步。
这些令人愉悦的时刻，角色、动画以及荒诞的惊喜。这不仅仅是为了娱乐，它们还在保持学习者参与方面发挥了关键作用。
### 你可以不止是一种身份
多邻国并不完全符合某一个单一类别。
我们不是一款游戏，但我们也不仅仅是一个教育产品。在这个模糊的界限中，蕴藏着我们的魔力。事实是，我们正在与 TikTok、Instagram 和在线游戏等平台争夺用户的注意力，因此我们必须让学习变得和它们一样有趣。
这些平台旨在让用户无休止地滚动和观看，而多邻国与之不同的是：我们的用户带着一个明确的目标而来，那就是学习。这不是无意义的娱乐，而是一种富有成效且有目的性的时间利用。而正是这种乐趣、意外时刻以及别具一格的设计，让用户愿意留下来。
### 独特文化 开放的环境
在一些公司，真正的决策可能发生在走廊尽头的一个摆放着巨大红木桌的房间里。而在这里，并不是这样。事实上，路易斯常用的会议室是一个全透明的“玻璃房”。
我们对公司最重要的问题保持开放，即使是那些其他地方可能会选择隐瞒的问题。
在“与路易斯问答”（Q&A with Luis）中，这种透明性尤为明显。但更广泛地说，在整个多邻国，我们努力做到随时可接触。
即使是最高级别的领导者，也只需发一条私信就能联系到。公司里的任何人都可以参加产品评审。这种开放性和透明性为冒险和创新提供了条件，甚至鼓励我们去尝试一些“奇怪”的想法。
### 设计中的乐趣
我们的产品之所以有趣，是因为它背后的人让它变得有趣。任何走进办公室的人都能感受到这一点：
在某一天，你可能会看到一个真人大小的 Duo 在中庭练习体操，或者偶然发现一个由 100 多个俱乐部组成的社区，这些俱乐部分布于从填字游戏到牡蛎爱好等各种主题。也许你会在十月赶上年度匹兹堡小狗游行（Pittsburgh Puppy Parade）。
这些都不是偶然发生的。一种伟大的文化很难建立，却很容易失去，但它对我们的成功至关重要。
这种文化在我们每年的冬季团建活动中达到高潮。整个公司会前往坎昆，没有议程、没有讨论会，也没有培训课程。目标很简单，为团队成员提供一个低压力的空间，用来放松和建立联系。
我们相信，当我们真正享受工作环境和彼此的陪伴时，工作会变得更好，从各个层面来说都是如此。
### 纯真与疯狂
多年来，我们尝试了不同的形式、语调和设计语言，最终确立了我们独特的品牌风格：既纯真又疯狂。
### 坚持到底
找到我们的品牌声音，尤其是在外部营销中，并非一蹴而就。起初，我们试图迎合尽可能广泛的受众，但结果却是毫无特色。在营销中，没有什么比平淡无奇更糟糕。因此，我们调整了方向，让我们的营销风格变得古怪、出人意料且常常充满幽默感。
幽默并不总是能被所有人接受，它是主观的，有时甚至会引发争议。
为了充分释放 Duo 幽默的力量，我们必须接受一个事实，并不是每个人都能理解这些笑点。但真正重要的是，那些理解并喜欢它的人会非常热爱它，而我们会尽一切努力去培养这种热情。
### Duo 的双重性
我们的吉祥物最初是为了鼓励用户坚持规律练习而设计的。然而，当互联网开始“接管”他时，他逐渐演变成一个更复杂甚至有些令人“畏惧”的角色，并拥有了自己的传说。
他依然可爱又毛绒绒，但他也愿意为了确保你完成课程而“暂时搬走你的家人”。
通过充分利用玩笑，Duo 已经成为真正的病毒式传播现象。他的身影出现在《周六夜现场》（Saturday Night Live）、热门电子游戏以及名人 Instagram 中。互联网上充满了各种疯狂的表情包，从健美版 Duo 到动漫版 Duo，应有尽有。
### 愚人节
愚人节是多邻国的完美节日。任何事情都可以成为玩笑的素材，而且越大胆越好。在公司成立的早期，我们意识到愚人节恶作剧是一个绝佳方式，可以引发热议并展现我们古怪的幽默感。
我们最早的一些尝试，比如“多邻国枕头”（多邻国Pillow），后来发展成了全规模的营销活动，例如 2024 年的“冰上多邻国”（多邻国on Ice），这一活动在社交媒体上获得了 1 亿次曝光。
### 与 Duo 共度的五秒钟
超级碗第 58 届比赛，全球 2 亿观众正在观看。突然间，一只明亮的绿色猫头鹰从它的屁股上“发射”出另一只猫头鹰，并提醒你“完成你的多邻国学习”。
这不是一则典型的超级碗广告，但它再多邻国不过了。
2024 年 2 月 11 日播出的这五秒广告，是历经数月、跨越六个团队合作的成果。我们不想为 30 秒的广告位支付高昂费用，于是给自己提出了一个挑战：如何在短短五秒内引起轰动？
我们知道每一个像素都至关重要。没有时间炫技或填充内容，因此我们拥抱了 Duo 那种古怪、疯狂且出人意料的特质。当团队为“展示多少屁股才合适”而争论不休时，我们意识到，这就是一个成功的创意。
这个赌注得到了回报。用极少的成本，我们的广告引发了与当年任何其他超级碗广告一样多的话题，并登上了多个“最佳广告”榜单。它充满趣味、意外且不拘一格正是这种公式推动了我们作为品牌取得成功。
> 注：这个梗源于广告中多邻国的吉祥物猫头鹰 Duo 用夸张的方式展示“屁股”的画面：它的屁股会像气球一样膨胀，最后爆裂并“生出”另一个 Duo。这种荒诞的表现不仅吸引了观众注意，还成为社交媒体上的热点。
## The Green Machine
我们的原则提供了理论框架，而“绿色机器”（The Green Machine）将这些理论付诸实践。
> 注：The Green Machine 是多邻国用来描述其内部运作模式的一个比喻性术语，代表了一种高效、快速、以实验驱动的工作文化。它强调通过明确目标、快速迭代和数据驱动的决策来推动产品和业务的发展。
### 我们的流程
到这里为止，我们已经讲了很多关于多邻国原则的内容。它们的历史、存在的原因以及它们的意义。而“绿色机器”（The Green Machine）则是将这些原则付诸实践的框架。
这种方法最早在我们作为一家初创公司时自然形成，并在此后的每一年都不断完善。（在这个过程中，它也促成了一些我们最有价值的创新和最大的成功。）
你可以将“绿色机器”视为一个通过小幅改进实现持续提升的过程。当一个小变化能改善指标时，我们就会做更多类似的改变。
在最基本的形式中，“绿色机器”的运作方式如下：聚集优秀的人才，给予他们实验的空间，然后加倍投入到有效的方法上。
如果你正在处理某个项目，但遇到了瓶颈，可以将其与以下六个步骤进行对比。也许问题出在你没有仔细考虑团队构成，或者缺乏适当的反馈循环。“绿色机器”模型几乎可以帮助任何项目重新步入正轨。
### 绿色机器的六个步骤
**01. 配备优秀的人才**
伟大的实验需要卓越的团队，他们能够快速头脑风暴、执行并灵活调整方向。这就是为什么我们在招聘时设定了如此高的标准，并对团队成员进行大量投资。
我们喜欢从精干的小团队开始，只有在看到成功时才会增加更多人手。
**02. 定义成功**
我们始终希望设定清晰、可衡量的目标，无论是每日活跃用户（DAU）、预订量还是社交媒体影响力。
但对于早期项目来说，可能无法获得明确的量化指标。在这种情况下，我们会定义最合适的定性目标，通过迭代逐渐明确目标，同时关注任何有用的信号。
**03. 设置边界并考虑长期**
我们通过设置边界条件来确保我们的工作在长期内既能为多邻国，也能为学习者带来益处。这与我们的核心原则“放眼长远”）一致。
深思熟虑的边界条件帮助我们专注于可持续、有意义的增长，确保每个实验都服务于更大的目标。
**04. 构建产品并建立反馈循环**
创造卓越产品的最快方式不是通过抽象讨论，而是直接开始构建，并设置适当的反馈循环。这些反馈既包括定量数据（如 A/B 测试结果、社交媒体反响、效果研究），也包括定性来源（如广泛的内部试用）。
早期项目通常更依赖定性反馈，然后逐步转向数据驱动的指标。
**05. 以紧迫感和卓越执行**
由于小幅改进会随着时间获得复利，而缓慢行动会付出巨大代价。但过快推进也可能导致粗糙的结果。在第 5 步中，我们努力持续（且紧迫地）交付符合我们高标准的成果。
**06. 加倍投入有效的方法，停止无效尝试**
当某件事情奏效时，我们会分配更多资源并持续改进它（有时会持续数年）。但我们也需要有勇气淘汰那些未能证明成功的项目，甚至是整个产品。
> 💡 延伸阅读（设计与产品思考）：
> - [业务思考力，设计师跳出执行的起点](/business-thinking-for-designers/)
> - [设计的意义，得用业务语言讲明白](/design-business-value/)
> - [从做设计，到构建秩序](/from-chaos-to-order-in-design/)
================================================================
# 从「白板」开始你的设计工作
- **发布日期**：2025-02-13
- **原文链接**：https://www.thefivekey.com/start-design-work-with-whiteboard/
- **Markdown 原文**：https://www.thefivekey.com/start-design-work-with-whiteboard/index.md
- **标签**：设计思考, 工具产品, 产品视角
> 学习如何通过“白板模式”优化设计流程，从理解需求、分析问题到制定设计策略，让每一项设计决策都有坚实的基础。在这篇文章中，我们将带你走出设计细节的陷阱，探索如何从全局思考，确保设计真正解决业务问题，帮助企业获得增长。
## 你会如何开启设计工作
很多设计师拿到一个新需求时，第一反应往往是习惯性的打开设计工具，比如 Figma 或 Sketch 开始设计。
为什么会这样？
其实这不仅仅是工作习惯的问题。更重要的是这些设计工具已经成为我们的“主场”，是我们的舒适区。就像工程师需要记录点信息时，第一反应是打开自己的代码编辑器。我们都在各自的安全领域中“安营扎寨”，在工具中舒适地“解决问题”。
这其实也并不是什么坏事，毕竟趁手的工具干起活来效率高。但问题就在于这种依赖性，其实会把我们“圈”得死死的，导致我们很多时候不自觉地陷入细节，而忽略了更重要的思考。
想象一下，当你打开设计工具，面对那些熟悉的界面和准备好的模板、组件库，会让我们不自觉地进入到设计的实现中，开始沉迷于界面设计的细节。一会改一个布局，一会调整一下组件的位置。于是，我们就掉进了细节的陷阱里，开始在“小问题”上耗费大量时间，最终不自觉地忽略了背后的更重要的业务需求、用户痛点，甚至我们本该考虑的设计策略，也是在最后评审时“反向推理”出来的。
设计得虽然好看，但可能并没有能真正的解决问题。
而事实上，一个真正好的设计方案的核心，并不是能画出多少炫酷的界面，而是是否能理解业务需求、分析用户问题、找到合适的设计策略。这些前期的思考环节做得足够扎实，最后的设计实现才能真正的站得住脚。
总的来说，一个好的设计方案，其实应该是：七分思考分析，三分设计实现。可是，现实往往是我们花了七成时间搞设计实现，剩下的时间都用来在思考上“打酱油”。
## 企业如何看待设计师的专业能力？
曾经，企业可能更关心设计师的技能树。你能掌握哪些设计工具？擅长哪些设计方法？能不能做出一些酷炫的交互原型？但现在，企业更在乎的是你能不能用设计帮助公司获得增长，帮助公司营利。
设计不光是为了好看，它最重要的任务是好用。能让用户更舒服地使用，进而带来商业价值。如果设计最后还是不能解决问题，再精致再华丽也不过是“空中楼阁”，根本不能为公司创造实际价值。所以，设计师的角色已经不再是做个漂亮的界面那么简单了，再好看的设计也不能忽视「生意」的本质。我们还得成为「问题的解决专家」。
## AI vs 设计师，应该选哪个？
当我们还在死守专业的时候，不要忘记了在另一边还有一股“力量”在试图替代我们。随着这两年 AI 能力的突飞猛进，我们的传统技能，比如设计流程、画界面之类的活儿，已经越来越容易被机器取代。
以为对专业工具的操作和界面设计的能力就足够形成牢固的壁垒了吗？不好意思，AI 也能干，而且比我们更快，还没有情绪、不需要休息。虽然它们现在可能只具备一个实习生的能力，但它的“晋升”速度可能会比我们想象的快得多。
去年年底兴起的 Cursor、Windsurf，能够帮助我们直接完成需求文档到产品实现的路径。甚至更进一步的 Devin ，我们已经可以把它当成团队里的一位新成员，它们能做的事，可能比我们想象的还多。
虽然 AI 在设计实现方面的能会越来越强大，但这里依旧在某些方面暂时还无法替代我们。那就是对业务的理解、问题的分析、策略的制定，总的来说，就是我们对业务思考的能力。而这些，也正好是企业对不仅仅是设计师的每一个角色在当下最核心的期望。
## 从白板开始你的设计工作吧
我们前面提到，设计师的工作应该是“七分在分析，三分在设计实现”。也就是说，设计师应该花更多时间思考和分析，而不是直接进入设计工具进行细节的实现。
理解我们需要进行思路的转变不难，难的是如何实施。在我看来，工具是一个具备可行性的切入点。白板就是这种思维方式的具体体现。
白板不仅仅是一个工具，它是一个思考的空间，是设计师跳出工具局限，全面分析问题、构建解决方案的地方。
我在 [Heptabase VS Tana，两种不同的知识管理逻辑](/difference-between-heptabase-tana/) 里也聊过类似的思考：Heptabase 这类空间化白板工具的核心价值，恰恰就是把「思考」从线性文档解放出来，变成可以被看见、被移动、被组合的过程。设计的前期工作其实和它是一回事。
接下来的付费内容中，我将通过一个实际的案例，向大家展示如何利用「白板模式」进行设计的前期工作。确保我们的设计思路清晰，决策有依据。
================================================================
# 入职新公司，学会问问题才能少踩坑
- **发布日期**：2025-01-22
- **原文链接**：https://www.thefivekey.com/ask-questions-when-starting-new-job/
- **Markdown 原文**：https://www.thefivekey.com/ask-questions-when-starting-new-job/index.md
- **标签**：职业发展
> 刚入职新公司，设计师总有一肚子疑问，却又不敢开口：怕问得太多显得蠢，怕打扰同事惹人烦。可真正让你掉坑的，往往不是问题太难，而是你选择沉默。本文从"为什么问问题重要"、"新人为什么害怕问"、"怎么开始问一个好问题"三个维度，拆解入职前 90 天最关键的沟通姿态。
> **TL;DR**
>
> 入职新公司，新人最容易犯的错不是问得太多，而是问得太少。
>
> 不问问题比问"蠢"问题更致命，你错过的是理解业务、对齐预期、建立信任的窗口期。
>
> 本文讲清楚怎么克服提问阻力、怎么问出高质量问题，让新人 landing 期少踩坑。
刚入职新公司时，如何问问题对设计师来说常常是一件让人头疼的事情。满脑子的疑问，却又害怕问多了显得蠢，被同事觉得自己不够专业。于是，问题被默默地藏在心底，想着自己慢慢摸索吧。
最后，当你满怀激情、疯狂熬夜加班，准备打响自己的第一炮时，方案却在讨论的那一刻暴露出了不少偏差。虽然大家并没有责怪你，但从同事们的礼貌微笑里，你仿佛能看到一层不易察觉的尴尬。他们的眼神似乎告诉你：“这位新同学，可能并没有大家期待的那么好。”
你会开始意识到，搞清楚公司的业务背景和现状，才是当下最重要的事情。此时你才明白，不问问题，比问问题的“蠢”更可怕。
没有人指望你刚加入就了解一切。真正让团队失望的，是你在面对疑问时选择沉默，不敢开口。当你不敢提问，怎么能够融入团队，如何去了解业务的脉络，进而做出有效的设计呢？
## 为什么问问题如此重要？
作为设计师，你的工作远不止是做做设计稿。设计的核心，是在真正理解业务需求的基础上，提出有价值的解决方案，推动产品的前进。可是，如果连业务的基本情况都还没弄清楚，交出的设计方案怎么可能靠谱呢？
想象一下，你满怀信心，花了几天时间精心完成了设计方案，终于准备好召集团队进行评审。结果，当方案一摆上桌，大家的反馈让你有点懵。那些你精心雕琢的设计细节，可能与真实需求严重脱节，功能安排也显得不合逻辑。
更糟糕的是，你意识到这些问题其实应该在前期通过沟通来避免。你明明可以在设计初期问清楚这些背景信息，却因为纠结于要不要问问题，最后把自己搞进了死胡同。
如果在开始前没能把核心需求和目标搞清楚，那么设计就可能完全跑偏。结果不仅浪费了团队的时间，还可能让你成为“误事”的源头。大家虽然嘴上不说，但眼神里的意思已经溢于言表：“下次，记得先问清楚。”
在团队里，大家希望设计师能解决问题，而不是增加麻烦。一次失误，大家或许能理解，笑一笑就过去了。但如果你一直“盲目设计”，凭空猜测，缺乏沟通和反馈，信任就会悄悄溜走，像沙漏中的沙子一样，渐渐流失。
## 为什么新人总是害怕问问题？
新人不敢提问，大多不是因为问题太难，而是害怕“别人怎么看我”。其实，你真正应该害怕的，不是别人觉得你笨，而是你假装懂，却把事情搞砸了。无知不可怕，装懂才真正可怕。
### 三大提问阻力：
#### 01. 别人会觉得我很蠢吗？
每个新人都会有这样的担心。“我才刚进公司，怎么敢问这些基本问题，万一让别人觉得我不够聪明？”但你需要明白，没人指望你一进公司就什么都懂。
真正让人失望的，是那些不懂装懂，最后把事情搞得一团糟的人。如果你能坦诚地提问，反而能让人看到你对工作和团队的尊重。
### 02. 会不会打扰打扰别人？
团队里的每个人都很忙，特别是那些资深的“老同事”。他们看上去忙得像机器一样。但忙并不代表不能问，关键在于你提问的方式和时机。
如果你提前整理好问题，简洁明了地提出，没人会觉得你是在打扰他们，反而会觉得你在节省他们的时间。问得合适，大家反倒会觉得你是个“懂事”的新人。
### 03. 会不会显得自己没准备？
这种担心也挺正常的。尤其是当你发现，自己能通过文档或调研先找到答案时，再提问可能会觉得不够“专业”。但问题在于，如果你没有先做功课，或者做的功课不够深入，那提问其实是一种对自己工作的负责。
做功课是对问题的尊重，但如果真的无法解决，提问才是提升自己效率的关键。提问不是为了展示自己的“无知”，而是为了避免浪费时间和资源。
你付出的不是“问题的成本”，而是错过答案的代价。在团队里，最容易被浪费的资源就是沟通。你不问，别人不会主动告诉你，而你在盲目猜测和反复修改中耗费的时间和精力，才是最大的成本。
举个例子：
有个新人负责设计一个OMS（订单管理系统）页面，满怀信心地交付给团队进行评审。
结果，设计方案被推翻了：“这个页面的功能布局完全不符合我们流程的要求，我们的用户群体主要是大型企业客户，为什么要设计成这么简单的界面？”
产品经理的一句话让新人有些懵。
如果他在初期就主动提问，花几分钟确认需求和用户场景，这一切本可以避免。结果，不仅浪费了自己的时间，还浪费了团队的时间，甚至让自己成了“误事”的源头。
## 如何开始问一个好的问题？
问问题，远远不只是开口那么简单，它是一门技术活。什么时候问？怎么问？问到什么程度才算到位？哪些问题最好别问？是我们最需要关注的。这些细节决定了你在团队中的形象，是一个“能搞定事”的人，还是一个“搞不清事”的麻烦制造者。
在接下来的付费内容中，我会跟你聊聊更深入的话题，包括：
- 问问题过程中的常见坑：那些你一问出口，别人就开始翻白眼的问题，为什么总是让你踩到？
- 问问题前的准备工作：为什么有些问题问得精准、有深度，而有些问题让人觉得你毫无思考？秘诀全在开口之前的准备。
- 如何递进式地提问：问一个问题是起点，但问出连贯有逻辑的问题，才是真正解决问题的关键。
- 什么时候提问最合适：提问的时机，直接决定了回答的质量。问得聪明的人，总是能在恰好的时机获得恰好的答案。
> 💡 延伸阅读：
> - 跨行业入职时的直觉重建：[进入新行业，如何校正你的产品直觉](/calibrate-your-product-intuition/)
> - 长远的职业规划视角：[做了 5 年互动设计，我遇到了设计师职业发展天花板](/five-years-later-i-encountered-a-career-ceiling/)
加入 OFF DESIGN，你将解锁本期付费内容。以及全年更新的不低于 100 篇的专栏文章。
================================================================
# 好的简历作品集，需要有层次的表达
- **发布日期**：2025-01-14
- **原文链接**：https://www.thefivekey.com/how-to-structure-portfolio-expression/
- **Markdown 原文**：https://www.thefivekey.com/how-to-structure-portfolio-expression/index.md
- **标签**：求职面试, 职业发展
> 如何让你的作品集案例更具吸引力？本文拆解"分层表达"的实用方法：第一层讲项目主线（让面试官 3 分钟抓住核心），第二层讲实施细节（提供弹药支撑主线）。避免 0 到 1 项目被讲得冗长散乱，让面试官快速理解你的能力、思考和成果。
> **TL;DR**
>
> 0 到 1 项目内容多、链条长，作品集容易写成流水账或全是细节的"论文"。
>
> 破局关键是**分层表达**：第一层讲"项目主线"（面试官能 3 分钟抓到核心），第二层讲"实施细节"（为主线提供弹药，按面试官提问按需展开）。
>
> 这不是压缩内容，而是给内容一个可以被快速理解的结构。
在设计师的职业生涯中，能遇到一个真正从 0 到 1 的项目无疑是一种幸运。它的复杂性和系统性让人抓狂，但同样，它也给了你在面试中大放异彩的机会。
当你终于完成了产品背景、行业调研、实际案例、竞品体验分析和设计方案，并把这些成果整理到作品集中的时候，一个疑问突然冒出来：**我这些内容该怎么讲？面试官会不会根本就不会看？**
## 0 到 1 项目的优势和困惑
0 到 1 项目的优势显而易见。它能讲的内容非常多，从业务背景到设计落地。
你可以用一个系统化的链路去展现自己的专业能力，也可以从细节中体现你如何深度参与每个环节。但问题也随之而来。很多人在面试的时候，开始心生顾虑：
- 讲太细：面试官可能对前置研究没兴趣，会觉得你在浪费时间。
- 讲太少：又担心自己表现不够全面，面试官无法理解你到底干了什么。
于是，有的人选择按部就班，把所有流程从头到尾摊开来讲。还有人干脆一头扎进细节中，试图用竞品分析的表格和数据直接“砸晕”面试官。结果呢？对方可能微微一笑，轻轻地打了个哈欠。
## 如何破局？分层表达是关键
对于 0 到 1 的项目，最重要的不是“讲多少”，而是“怎么讲”。我的建议是：对内容进行分层，把流程和细节拆开，用不同的方式呈现。
### 第一层：项目流程，提炼出方案主线
这部分是向面试官展示你思路清晰、能抓住关键问题的能力。
你的表达逻辑可以是这样的：
- 业务问题：为什么会有这个项目？你要解决什么问题？
- 核心指标：业务方的关注点是什么？你们设定了什么衡量成功的标准？
- 产品能力：从业务问题到产品方案，中间的链路是什么？
- 设计策略：在确定方向后，你具体采取了哪些设计策略来支持目标？
- 设计方案：最终呈现的产品是什么样的？它解决了哪些问题？
- 数据验证：结果如何？通过什么数据说明你成功了？
这一层的重点不是细节，而是做了什么、得到什么结论、推动了什么进展。
面试官不需要了解业务的所有背景，但需要知道你的目标是什么，你的方法是什么，你的结果是什么。你是如何通过逻辑推导，逐步解决问题的。
### 第二层：实施细节，为主线提供弹药
这一部分是用来深入展开的。当面试官对某些结论产生兴趣时，你可以从容地打开“工具箱”，为主线提供更细节的支撑信息。
比如：
- 行业调研中，你用了哪些方法？得到了哪些关键发现？
- 竞品分析中，你关注了哪些维度？为什么这些维度很重要？
- 设计方案中，有哪些具体的创新点？它们如何与核心目标挂钩？
这里的关键是“可展开但不赘述”。细节只是你的支撑材料，而不是主线内容。
## 好的表达是需要有层次的
不管是面试还是作品集，缺乏层次感的表达往往会让人觉得枯燥乏味。很多失败的案例，问题并不是内容不够多，而是没有组织好内容的逻辑。
试想一下，你有一个非常绝妙的创意。但如果你把所有的细节从头到尾一股脑讲给面试官听，可能只会让人迷失在细枝末节里，不知道你的重点在哪里。
而如果你能先提炼出创意的核心价值，再用关键细节去充实和证明它，面试官会更容易被你的思考和成果打动。
## 如何让作品集“站住脚”
对于 0 到 1 的项目，作品集的陈述方式其实是可以学习“讲故事”的方法的。
**从结果反推整个流程：**
用一句话概括项目的最终成果，比如“通过优化流程，成功将操作效率提升了 30%”。再一步步拆解，你是如何达成这个结果的，形成一个清晰的故事链路。
**突出个人贡献：**
让面试官知道，这个项目中哪些部分是你主导的，哪些地方体现了你的思考和价值。
通过细节增强可信度：比如，在行业调研中，你是否发现了某个重要的用户痛点？在竞品分析时，你是否提出了某个有洞察的结论？
## 最后的建议
作品集的作用不只是展示你的能力，更是让面试官理解你的思考方式。
对于 0 到 1 的项目来说，最忌讳的是“从头到尾讲流程”，因为每个人的流程其实大差不差，难以突出亮点。对于 0 到 1 的项目，最好的方式是提炼主线、分层表达。
让面试官不仅知道你做了什么，还知道你为什么这么做、你的方法论是什么、你解决问题的能力又如何。记住，内容的“底料”可能大同小异，但如何组织和表达，才是拉开差距的关键。
你看，其实做好作品集，和做设计是一样的。
**你需要把它真正的当做一个项目来思考。**
方法已经摆在这里了，剩下的，就看你怎么用了。
---
面试官每天都在快速翻阅成百上千份简历，你的那一份不过是其中一张。你的简历在面试官眼中停留的时间是三分钟，可能是他们停留在你的简历上最长时间。
在这短短的三分钟里，你的简历要么成功敲开门，要么被悄悄归档。而这三分钟，决定了你的下一次机会能否到来。
在好莱坞，编剧们为了吸引投资人，会用一种叫“电梯推荐”的方式介绍自己的剧本。因为时间非常有限，这种自我推荐需要在 30 秒内完成，因为它相当于乘坐一次电梯的时间。
**30 秒后，电梯到达，你机会可能也就结束了。**
而设计师的简历，其实也是一样？在面试官有限的时间里，能否在短时间内展示你的能力。它的本质是讲一个简短而有力的故事，告诉面试官：我能做什么，我为什么值得你们的机会。
接下来，在本期付费文章「三分钟，你的简历能走多远？」中我会聊一聊如何用好这 3 分钟，让你的简历在面试官的眼中脱颖而出。
这三分钟不是走过场，它是你通往下一阶段的关键节点。如果你能抓住它，后面的 10 分钟，面试官愿意深入阅读你的简历，甚至未来 40 分钟的面试沟通，就会变成可能。
简历的本质，其实是一种需求。你想要一份机会，而面试官想找到一个合适的人。需求如何被满足？
**正如设计师做产品时需要去理解用户，简历也是需要被“设计”的，清晰、有逻辑、有吸引力。**
> 💡 延伸阅读：
> - 更基础的视角：[设计师的简历作品集应该关注什么？](/how-to-effectively-present-your-resume-portfolio/)
> - 为什么要升级作品集：[做了 5 年互动设计，我遇到了设计师职业发展天花板](/five-years-later-i-encountered-a-career-ceiling/)
加入 OFF DESIGN，你将解锁本期付费内容。以及全年更新的不低于 100 篇的专栏文章。
================================================================
# 设计的意义，得用业务语言讲明白
- **发布日期**：2025-01-08
- **原文链接**：https://www.thefivekey.com/design-business-value/
- **Markdown 原文**：https://www.thefivekey.com/design-business-value/index.md
- **标签**：设计思考, 产品视角
> 设计师如何用业务语言讲清楚设计的价值？本文从设计师与产品经理的常见冲突切入，介绍功能价值指数（FVI）框架，教你用数据量化设计的业务价值，让团队听得懂、决策者认可。
> **TL;DR**
>
> 设计师和产品经理之间的争执，根本不是"你觉得不行、我觉得可以"的口味之争，而是双方在用不同语言系统沟通。
>
> 设计要被业务认可，需要用业务语言（数据、价值、KPI 关联）来重新表达。
>
> 本文介绍一个实用框架：功能价值指数（FVI），帮你把"我觉得这个体验更好"翻译成"这个改动能带来 X% 的业务收益"。
每一个重要的项目里，设计师和工程师都不会缺席。设计师负责将业务的想法界面化，工程师负责将这些界面和功能工程化。但几乎每一次项目中，设计师多少都会与产品经理、运营人员之间出现一些不同意见。有时候甚至会发展成争执，最终演变成“你觉得不行、我觉得可以”的局面，弄得大家都不太愉快。
问题出在哪？设计师和产品经理的逻辑难道就永远对不上吗？答案其实并不复杂。
我们工作的环境，始终是一个商业环境。**而这个环境中，每个角色的目标与视角有着天然的差异。**
**运营人员和产品经理，是企业对商业需求的具体化表达**，他们的目标非常明确：拉新、转化、留存、盈利。而设计师和工程师，尽管同样为这些目标服务，却更倾向于用自己的专业语言看世界。一个关注用户体验的美感与流畅，一个专注于技术实现的逻辑与效率。
这种视角的差异就像在用两种不同的语言互相喊话。设计师的“这交互更符合用户习惯”，和产品经理的“能不能提高点击转化率”，往往成了两种语言体系，彼此不理解，谁也无法完全说服谁。摩擦因此变得不可避免。
## 商业环境下，设计师的天然“劣势”
企业的核心始终是商业，而问题的本质最终也得用业务视角来解读。对于以专业视角为主的设计师来说，这是一个天然的劣势。我们精通设计的语言，但在商业这套逻辑中，却很难用专业的话语去表达设计的价值。
为什么设计师很难在业务的“牌桌”上拥有发言权？**因为我们习惯把设计结果当成目标。而产品经理甚至是管理者更关注的是设计对商业目标的推动。**
换句话说，设计师工作的重点不是“设计得好不好看”，而是“设计是否为商业提供价值”，最终是不是能解决业务问题。
产品经理关心的是最终的商业数字：这次改版能提升多少转化率？这个页面的点击量有没有提高？这条用户路径是否更高效？而设计师往往沉浸在自己的专业领域，视觉呈现、交互逻辑，甚至是一些设计师眼中的设计情怀。但如果设计无法转化成商业结果，那么在业务视角里，它可能就是“无效产出”。
这也是为什么，设计师可能在项目会上自信满满地展示了新设计，却被运营人员一句“这个流程复杂会不会降低转化率”击得无话可说。
设计师用体验的逻辑看待问题，但企业期待的是用增长和盈利的语言解答问题。
## 为什么设计师需要业务 Owner 精神？
我们常说，设计师需要具备“业务 Owner 精神”。这话听起来有点虚，很多人并不理解是什么意思？它不是让我们只用专业去解决业务问题，而是跳出专业视角，把自己当成业务 Owner，站在业务视角重新定义问题，看待设计。
业务 Owner 的视角是什么？
如果设计师在乎的是“这个界面好不好看”，**那业务 Owner 关心的则是“这个功能能不能帮我留住更多用户？”。**如果设计师想着“这个交互是否符合最佳实践”，**那业务 Owner 关注的则是“这个流程是否能让用户更快完成操作？”。**
简单来说，业务 Owner 精神就是要求你把业务的成败当成自己的责任，而不是单纯完成一张图、一套交互逻辑就算了。界面漂亮是一回事，但**业务跑不动，你也得真心地发愁。**
业务 Owner 精神不仅仅是调整视角的问题，还要求设计师在日常工作中主动去接触、理解业务的数据和问题。这就意味着，无论是设计方案的产出还是业务会议的讨论，我们的身份都应该是业务的 Owner。我们需要用业务发展的视角看待一切问题，设计只是我们最擅长的一项技能而已。
所有这些，都是在帮助你跳脱“专业”的局限，把设计的价值与业务目标紧密结合。
## 当设计师转为产品 Owner 时会发生什么变化？
在做了十多年的设计后，我开始转向了产品工作，一晃也五年了。当你真正开始为一个业务的生死负责时，思考方式针对会发生巨大的变化。每天我最关心的，不再是设计本身做得如何，而是更具体、更紧迫的问题：
- 用户量怎么样？
- 活跃度是否达标？
- 商业收入能不能支撑下个月的运营？
设计的确重要，但它只是这整个体系中的一环。每天琢磨如何让产品活下去时，你才会真正的体会到，**设计不仅要服务于用户，更重要的是还得为商业目标负责**。
于是，我会要求团队里的设计师要用业务的视角来看设计。如果一个设计对业务没有贡献，那它再精致也是失败的。
设计师需要从“设计好不好看”，走向“设计对业务有没有价值”。这样的转变并不意味着抛弃专业，而是要求我们从专业的层面出发，为业务创造更大的价值。设计是帮助业务实现目标的工具，而不是业务的负担。
而首先，我们需要从真正的理解业务开始。
## 理解业务的第一步,数据和设计的语言转化
企业中，业务目标的语言是数据：转化率、收入、月活、日活... 这些指标是衡量成败的信号灯。
产品经理常说：“这个页面转化率太低了，能不能调整一下流程？”设计师回答：“调整流程会牺牲体验啊，用户可能觉得麻烦。”
表面看起来，这像是两个无解的问题，实际上，这恰恰是我们在职场工作中最大的劣势。我们需要学会用数据和专业语言对话。我们需要学会用商业语言和专业语言对话。
设计师只有从数据中找到设计的依据，把自己的专业思考转化为商业逻辑，才能更好的与产品经理和运营人员进行同频的沟通。
也才能够更加成熟的思考设计于商业的价值。
如何正确地理解数据，并让数据真正为设计所用？**关键在于为业务问题和设计方案之间建立清晰的关联。**
首先要做的是**切换到业务数据的视角，了解问题的本质**，而不仅仅停留在表层的体验数据上。接着，还需要借助一套强有力的观察指标，帮助我们**建立设计与商业目标之间的连接。**
这不仅能论证设计的价值，也能让我们反思设计的必要性，确保每一个方案都在为业务增长服务。
在做设计中台产品的那个阶段里，有大量的时间在做汇报。我需要有一个能够同时面向于老板们和团队内的指标，来让大家对产品的有一个共性的直观感知。
所以我创建了一个观察指标，我将它称之为**功能价值指数（FVI）**。
在对 FVI 指标不断优化的过程中，我开始逐渐找到了一个商业与设计之间理解数据的平衡点。同时帮助团队更好地建立商业目标与设计之间的链路。
接下来，我将在本期文章的后半部分（付费）内容中，通过具体案例详细解析如何用 FVI 将设计与商业目标挂钩。
在付费文章中，你将看到：
- 功能价值指数（FVI）详解，及其在数据中挖掘设计洞察的应用
- 以 Spotify AI DJ 为例，解析 FVI 如何量化设计的业务价值
> 💡 延伸阅读：
> - 业务思考的起点：[业务思考力，设计师跳出执行的起点](/business-thinking-for-designers/)
> - 设计系统的业务价值：[设计系统 · 我们为什么要做 Design System](/why-we-need-design-system/)
加入 OFF DESIGN，你将解锁本期文章的全文内容。以及全年更新的不低于 100 篇的专栏文章。
================================================================
# HQ&A 笔记法：让你的思考更有效 (上)
- **发布日期**：2024-12-29
- **原文链接**：https://www.thefivekey.com/hqa-note-taking/
- **Markdown 原文**：https://www.thefivekey.com/hqa-note-taking/index.md
- **标签**：设计思考, 效率, 知识管理
> HQ&A 笔记法，教你从“记录”到“理解”，通过标记、提问、回答三步法，让碎片信息变成深度洞见，助力高效学习与工作。
女儿的历史复习资料中有这么一段 Highlight 的知识点。
> 汉武帝从政治、经济、军事等方面巩固了大一统的局面，使西汉王朝开始进入鼎盛时期。
到期中测验的时候，考题却问的是：汉武帝在政治、经济、军事等方面采取了哪些具体举措？考完试女儿就怒了，抱怨历史老师太不地道了。我只能笑笑安慰，恭喜她正式地感受到了「**教你一滴水，考你一片海**」的精髓。
其实，这种“水与海”的逻辑不仅存在于学校里，在我们的日常工作中也很常见。比如，项目需求会上你认真记录了一堆关键信息，觉得自己已经掌握了全局。可一到业务分析会议，大家讨论得热火朝天，你却发现，记了很多，但也聊不出啥。
**“复习点”与“考点”之间的鸿沟，是学习和工作的常态**。要跨越这道鸿沟，我们需要用方法，把“看似懂了”变成“真正明白”。在这一类场景里，HQ&A 笔记法就是一个非常不错的选择。
## 什么是 HQ&A 笔记法？
HQ&A 是 Highlight（**标记重点**）、Question（**提出问题**）、Answer（**回答问题**）的缩写。它的核心在于，将复杂的知识点层层剥开，化整为零，再重新组合成逻辑清晰的体系。
**第一步：Highlight（标记重点）**
首先，将你在日常中认为有价值的信息记录下来，比如一句话、一个结论，甚至是一个关键词。这里要注意，不要贪多，不要把整段内容一股脑保存下来。重点是提取关键信息，而不是为笔记增加负担。
**第二步：Question（提出问题）**
接下来，对标记的重点提出问题。建议从自己的角度思考三个问题。比如：
1. 这个结论是怎么来的？
2. 它的前提是什么？
3. 它可能带来的影响有哪些？
提问的过程，其实就是将信息解构和挖深的过程。
**第三步. Answer（回答问题）**
最后，根据你的理解，尝试回答这些问题。回答时，尽量结合上下文或相关知识进行分析和拆解。这个环节不仅让你对问题有了更清晰的思路，还能帮助你把知识点转化为自己的洞见。
## 现在，我们用 HQ&A 方法再试试
> 汉武帝从政治、经济、军事三方面巩固了大一统
这句话看似言简意赅，但如果直接背诵，很可能只记住几个关键词，一旦考试题目展开可能就抓瞎了。为了真正吃透这个知识点，我们可以用 HQ&A 方法 来拆解，逐层深入挖掘背后的逻辑。
先从最基础的开始，我们可以对前面那条知识点提出三个问题：
> **问题 1：汉武帝在政治方面采取了哪些具体措施？**
>
> 汉武帝在政治上推行“推恩令”，通过让诸侯王分封子弟，逐步削弱了诸侯的权力，最终加强了中央集权。
>
> **问题 2：汉武帝在经济方面采取了哪些具体措施？**
>
> 汉武帝实行盐铁官营和均输平准政策，加强了国家对经济的控制，增加了财政收入，同时缓解了社会矛盾。
>
> 问题 3：汉武帝在军事方面采取了哪些具体措施？
>
> 汉武帝多次对匈奴发起大规模军事行动，打击了匈奴的威胁，扩大了汉朝疆域，加强了边疆地区的稳定，为国家统一与发展奠定了基础。
在此基础之上，我们还可以进一步挖掘更深入的问题：
> 问题 4：汉武帝是如何削弱诸侯权力，加强中央集权的？
>
> 问题 5：“罢黜百家，独尊儒术”的背景是什么？这项政策对西汉社会产生了什么影响？
>
> 问题 6：张骞出使西域的意义是什么？这对汉武帝的军事和经济策略有何帮助？
通过这种层层递进的方式，原本单薄的知识点被扩展成了一个清晰、立体的知识网络。老师划的重点、可能涉及到的考点，基本上就都可以抓住了。
HQ&A 方法看似简单，但它的每一步都能引导你把信息从“记录”升级为“理解”，再进一步成为有用的知识资产。它让你从“看似懂了”走到“真正明白了”。就像徒手剥开一个榴莲，第一步虽然有点扎手，但当你吃到果肉的那一刻，就知道这一切值得了。
## 将 HQ&A 的思路用在工作中
在工作中，我们每天都会接收到大量的重要信息。
团队今年的整体设计策略、项目中的用户反馈、跨部门会上看似随口一提的观点……这些信息看起来都非常有用，值得记录，但如果不深入思考，它们最终只会停留在笔记里，难以真正产生价值。
如果你只机械地记录，很快就会发现这并没有太大价值。再聪明的脑袋，面对如此多的碎片信息，也总有被填满的那一天。关键在于，**如何把“看起来懂了”变成“真正弄明白了”**。这不是记忆的问题，而是理解的问题。而理解的前提，是主动提问。
在公司的那些年，每天接触到的信息和观点实在太多了。于是，我逐渐形成了一个习惯：每当获得一个重要的观点或信息时，总要再 Google 一下，或者直接问问相关的人。哪怕只是随口一句“这个为什么是这样？”“它背后还有什么？”看上去好像是“多此一问”，但实际上，这个习惯让我对信息的理解多了一层，也逐步形成了自己的思考体系。
这个习惯延续了很多年，直到几年前，我偶然发现一位英国博主 Jamie Miles 分享的 HQ&A 笔记法。我才发现原来有人早就把这种“结构信息”的思路整理成了一套方法。
它看似简单，但逻辑精准，操作起来特别有效。
其实，所有的学习和工作，很多时候我们都是在做信息解构的游戏。。提问，是这场游戏的起点。只要你掌握了提问的思路，就会发现信息的复杂程度并不是理解的障碍，只要你问对了问题，答案其实一直都在那里。
## HQ&A 的案例与实践
我以前经常和大家提，要用产品的思维去做设计。这个产品思维怎么来？HQ&A 就是一个简单直接、易于上手的方法，它能帮你把一条条看似孤立的信息变成深入的理解，真正的从业务视角来看问题。
方法本身之外，承载它的工具同样重要。我在 [Heptabase VS Tana，两种不同的知识管理逻辑](/difference-between-heptabase-tana/) 里聊过两款典型的知识管理工具：它们一个让你「看见思考」，一个让你「组织思考」，正好对应了 HQ&A 中"理解"和"结构化"两个环节。
以上就是关于 HQ&A 笔记法的上篇的内容。
在下篇（付费）中，我将重点为大家分享如何在我们的工作中的具体实践：
1. 如何用 HQ&A 笔记法来分析需求和数据，理清复杂问题的核心逻辑；
2. 如何结合 AI 来增强 HQ&A 的效率，让你的笔记和思考更进一步；
3. 以及如何选择合适的工具，将 HQ&A 方法无缝融入你的工作流程。
加入我的「OFF DESIGN」专栏，你将解锁 HQ&A 的下篇:
> HQ&A 笔记法：让你的思考更有效（下·案例与实践）
================================================================
# 设计师的 2024：边界在消失，2025 该怎么走？
- **发布日期**：2024-12-22
- **原文链接**：https://www.thefivekey.com/design-review-2024-and-outlook-2025/
- **Markdown 原文**：https://www.thefivekey.com/design-review-2024-and-outlook-2025/index.md
- **标签**：体验设计, 职业发展, 设计 AI
> 2024 年，设计行业的边界正在被重塑，AI 的崛起与角色的重构让设计师面临全新挑战。设计师们，该如何为 2025 年的变化做好准备？点击了解设计行业的转型与未来方向。
> **TL;DR**
>
> 2024 年设计行业经历了两个本质变化：体验设计师向产品设计师演化、AI 在敲打设计的边界。
>
> 本文是我对 2024 的复盘和对 2025 的判断，也宣布了我从「OFF UX」专栏到「OFF DESIGN」专栏的品牌升级：从聊体验设计走向跳出设计本身、从产品视角看设计。
## 2024 年设计行业的本质变化
每到年末，我都会写点东西，总结这一年的起伏。总结，不只是为了回顾，而是为了看清下一步的方向。今年也不例外。
但是，今年的总结似乎又有些不同。2024年的设计行业，已经不再是过去那种按部就班的延续，而是在经历一次显而易见的本质变化。
过去，我们总以为设计行业会一年一年地稳步发展：工具更高效了，流程更完善了，用户需求更复杂了…
然而，事实是，变革早已悄然发生。边界正在被打破，规则正在被改写，连角色的护城河也开始崩塌。
今年，这些变化变得尤为明显，甚至显得近在咫尺。设计行业的边界正在模糊，角色的护城河正在被削弱，连游戏规则本身也在被重新书写。
这种变化不像以往那样渐进，而更像是一次推倒重来的重建。那些曾经熟悉的技能优势、行业规范和职业分工，如今似乎都站在了不确定的边缘。对于设计师来说，这不仅仅是工具的升级，而是一次重新思考自身角色与价值的挑战。
最近，我特别想和大家分享两件事情。它们看起来没有太大关联性，但仔细想想，变化其实早就在我们身边发生了。
## 01. 体验设计师 → 产品设计师
LinkedIn 上，一位朋友的岗位从「体验设计师」改成了「产品设计师」。他发了一条动态，说这并不是他的个人行为，而是公司的一次整体的调整。
原因很简单，**公司希望大家别再沉迷于自己的一亩三分田了**，别再只盯着设计细节、搞专业，而是把目光更多地放在业务价值思考上。换句话说，设计师要从「体验设计」转向「业务设计」。
**Title 的变化只是表象，背后是公司对设计师期望的彻底重塑。** 过去，体验设计师讲究的是“以用户为中心”，可企业的视角可不一样，它更在意的是设计为企业带来的增长和利润。
企业需要的是一个「利润中心」，而不是一个只烧钱、不赚钱的「成本中心」。
设计师的角色也随之发生了根本性的转变。从「体验设计师」到「产品设计师」，意味着设计师不仅要画界面、做优化，还得能想清楚：**这个设计能不能提高转化率？能不能直接带来收入？**
这背后是企业策略的转变，用更直接的话说，设计师不仅要设计“看得见的好”，还得为“看不见的利润”负责。这不仅仅是一个岗位名称的变化，而是设计行业的一场结构性调整。
## 02. AI 在敲门，边界在消失
上个月，我开始用 Cursor 和 Windsurf 做一些小工具。刚开始是写写脚本练练手，后来干脆用它们解决工作中的一些琐碎问题。就这样，一不留神，做出了 20 多个工具，这效果实在有点不像话了。更别说更为强大的 Devin，对于设计师来说，**我们好像真的不需要工程师了。**
过去，设计师不懂代码，这是个绕不过去的槛。很多时候冒出一些好点子都卡在“实现不了”这一步。
但现在，AI 工具把这道门槛给直接拆了。只要你有想法，它就能帮你把想法变成产品。AI 不只是帮你提升效率，更是在改变你的工作边界：设计师可以写代码，工程师可以设计界面，产品经理甚至能用 AI 生成原型。
更关键的是，这种能力不再只是“少数高手的特权”。**AI 工具的门槛越来越低，工种之间的界限也越来越模糊。** 设计师、工程师、产品经理原本泾渭分明的角色，现在正在被重新定义。
这才是最让人不安的地方。当角色之间的护城河被填平，接下来会发生什么？答案可能比我们想象的要快得多。
看似毫不相关的两件事，实际上指向了同一个方向：**设计行业的角色边界正在消失。**
一方面，设计师的职责边界正在变化。过去，我们只需要关注用户体验和设计本身，但现在，企业希望我们把目光放得更远一些，思考设计对业务的直接价值。设计师不只是画图的，更是业务的推动者。
另一方面，AI 让我们的能力边界得到了无限扩展。不懂技术？没关系，AI 补上这块短板。曾经因为技术限制而束手束脚的事情，现在只需要一点想法，再交给工具去实现就行了。我们不再只是设计师，我们可以做更多。
不过，别高兴得太早，这件事对所有人都是公平的。设计可以跨界到研发，研发也可以跨界到设计，而产品经理甚至可以抛弃所有人，把问题直接转化为需求，再利用 AI 生成完整的解决方案。
边界的模糊化是双向的，大家都在同一个游戏里，彼此的护城河都正在迅速消失。
当能力边界走向无限拉平时，我们都得回归一个最本质的问题：**我们做这些事情，到底是为了什么？**
未来，用专业解决问题可能不再是难点，真正重要的，是发现问题、分析问题、定义问题的能力。至于后面那些实现环节，交给 Devin 这类产品不就行了吗？
AI 或许会取代技能，但它取代不了思考。**未来的职场最需要的，不是会做事的人，而是知道该做什么的人。**
## 2025 年新计划：从 OFF UX 到 OFF DESIGN 专栏升级
新的一年，既是延续，也是改变。回顾这些年的积累，我决定对自己做一些调整。
### 专栏品牌调整
首先，「设计有得聊」这个品牌会和大家 Say Goodbye 了。取而代之的，是我的新专栏「OFF DESIGN」。这个名字，我想了很久，在最终确定的时候，也已经想好了该如何向大家表达我的思考。
> 设计不止于设计，承载洞见，延展价值。
>
> 出离设计，立足其上，探索多维价值与可能。
这个变化背后的逻辑其实很简单：设计从来不是孤立的，它总是在与其他领域对话、交融，从用户到业务，从产品到世界，设计承载的意义远远超出界面本身。对我来说，**“OFF DESIGN”不仅是一种思维方式，更是一种新的探索。**
未来，我希望和大家一起，跳出设计的边界，站在更高的维度，去思考设计如何定义价值，又如何延展价值。设计的边界，不是终点，而是起点。
### 迁移与升级
从 2025 年开始，我的付费专栏将正式迁移到「小报童」，并更名为「**OFF DESIGN**」。这个决定，说起来其实很简单，过去几年，我输出的大部分内容以文字为主，而「小报童」在这一点上显然更加合适。
**新的「OFF DESIGN」，不只是一次平台的迁移，更是一次策略的升级。**
我会继续和大家分享对设计的思考，但不再局限于设计本身。正如今天这篇文章所表达的，设计从来不是孤立的，它与用户、业务、甚至技术和文化深度交织。我们需要用发展的眼光去看设计，才能发现它更大的潜力。
具体来说，新的「OFF DESIGN」会有以下两点变化：
1. **内容以中短篇为主，注重时效性和频次**
每次阅读不会占用太多时间，也减少心理负担，设计师忙碌的日常中，能随手来一篇、随手吸收一点。
2. **跳出设计，探索多维度的价值**
设计是一个基点，但不是终点。我们会一起思考设计如何与更多领域的结合，如何用更大的视角去定义和延展它的意义。
================================================================
# 从 Ant Design X 探索 AI 产品领域设计系统
- **发布日期**：2024-12-09
- **原文链接**：https://www.thefivekey.com/ant-design-x-ai-product-design-system/
- **Markdown 原文**：https://www.thefivekey.com/ant-design-x-ai-product-design-system/index.md
- **标签**：设计系统, 设计模式, AI
> Ant Design 推出了业内首个面向 AI 产品领域的会话式设计系统：Ant Design X。本文探讨了领域级设计系统的概念及其在 AI 交互中的应用，分析了 Ant Design X 背后的设计逻辑、应用场景及未来发展趋势。
## 写在开头
在之前的文章中曾和大家提到过，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 案例解析](/how-to-learn-from-other-design-systems/) 和 [深度解析 AWS CloudScape](/b-end-design-system-deep-dive-aws-cloudscape/) 这两篇）。
从系统级到业务级，是一个对设计从抽象到具象的过程。从最底层的基础交互模式到具象到一个业务逻辑的执行流程。
领域级设计系统，简单来说就是一种针对某一个领域中进行设计的抽象和定义。通过分析同类场景的共性，制定出一套符合该领域特性的解决方案。
最典型的例子就是中后台领域的设计系统，这也是我们目前最常见、最成熟的领域级设计系统类型。如前面所说，领域级设计系统绝不仅仅局限于中后台。
事实上，只要在某个领域内的产品有足够多的共性，无论是电商、社交，还是金融，理论个上都能抽象出一套领域级设计系统。
这里大家可能会有问题，既然有共性即可，那为什么现实中，我们很少能见到其他领域的设计系统呢？
这里就不得不再聊一聊领域级设计系统成立的几个前提条件。
> 01. 产品形态已基本形成共识
> 02. 产品复杂度可控
> 03. 构建设计系统的时机成熟
> 04. 设计系统的价值得到认可
关于这部分的细节，我们这里暂时不展开。详细的分析大家如果感兴趣，可以见全文内容中的讲解。
## 为什么 Ant Design X 会出现？
带着前面提到的几个前提条件，我们再来看 Ant Design X 这套面向 AI 产品领域的设计系统，我们就能理解它的出现也就成为了必然。
AI 产品的发展时间点非常合适。作为一个新兴领域，AI 产品的形态相对简单且高度一致。在交互上都体现出了一种共性。而且，过去两年的探索已经初步形成了一些行业内认可的设计模式，这些共识为领域级设计系统的构建打下了良好的基础。
Ant Design 作为国内开源设计系统最为重要的力量之一，它也的确有必要对设计系统的发展方向进行探索。
而领域级设计系统就是设计系统发展的一个必然趋势。
那 Ant Design X 的出现能为我们提供什么启发呢？作为一个面向会话式 AI 产品的领域级设计系统，它其实是为我们提供了一个值得参考的样板。
我们可以看到，在 B 端之外的领域中，也还有不少领域也能提炼出拥有通用特征的抽象体系。至于这套系统背后的思考逻辑、应用思路，以及如何从它的案例中发掘更多适用于其他更多领域的实施策略，我都会在本期的文章中进行详细的讲解。
加入我的星球后，你将不仅能阅读这篇文章的完整版本，也能探索以往更多与设计系统相关的专题内容。你的下一步思考，也许就从这里开始。
> 💡 延伸阅读：
> - 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
================================================================
# 从 0 到 1：用 Cursor 做了两个小工具
- **发布日期**：2024-11-30
- **原文链接**：https://www.thefivekey.com/build-mini-tools-with-cursor/
- **Markdown 原文**：https://www.thefivekey.com/build-mini-tools-with-cursor/index.md
- **标签**：AI, 工具产品
> 用 Cursor 两天内打造了两个简单实用的小工具，一个是帮助计算融资利率的「融资利率计算器」，另一个是帮助规划存款目标的「百万计划」。从产品经理到"程序员"，我分享了用 AI 辅助编程的心得与体验。
> **TL;DR**
>
> 不会写代码的设计师/产品经理，靠 Cursor 在两天内做出了两个真正可用的网页小工具：融资利率计算器和百万计划。
>
> 这篇是个人实践记录，讲我从「产品经理」到「程序员」的真实体验，以及 AI 辅助编程对非工程师角色的意义。
## 两个小工具：融资利率计算器与百万计划
在美股市场，偶尔会用到富途的融资。每次用融资之前，我总要在脑海中默算这笔钱会产生多少利息。这件事虽然不复杂，但计算的过程总让我有点烦躁。为什么不自己做一个呢？于是，就有了这个「融资利率计算器」小工具。
功能特点：
- 输入初始资金、月存金额、年化收益率，计算达成 100 万的所需时间。
- 支持不同利率和存入金额的调整，直观展示投资增值的概念。
## 从产品经理到"程序员"：用 Cursor 写代码的真实体验
其实，这两个工具都不是我写的。实际上，是 Cursor 帮我完成了它们。我只是作为产品经理和设计师，提出需求，规划功能，再通过 Cursor 帮我实现了我的想法。
在互联网行业工作了 20 多年，前面的十多年一直都是做设计，后面的几年开始做产品。多年来，我对编程一直抱有执念。
作为设计师和产品经理，我总会想到各种稀奇古怪的需求，但由于自己不会写代码，很多想法都无法尝试。虽然我尝试学过编程，但真正掌握编程的逻辑和语言始终需要投入大量时间，而这对于我来说，并不现实。
## 为什么我建议每个非工程师都试试 Cursor
有了 AI 工具，局面完全打开了。在过去，ChatGPT 让我能够改改代码，而如今 Cursor 则让我开始可以大胆的做一些更为复杂的工具了。
Cursor 对我来说最大的意义，是让我可以退回到产品经理的角色，只需要把握功能的需求和细节，把实现交给“它”来完成。
用 Cursor 完成我的第一个工具后，我毫不犹豫地决定付费订阅了。
一个月一百多块钱的成本，就像雇佣了一个“随叫随到的程序员”。对于我这种技术能力有限、却常有小想法的人来说，绝对是超值的投资。
## 接下来想用 Cursor 探索什么
接下来的日子里，我会继续用 Cursor 实现一些日常生活中“看到”的需求。它们不一定复杂，也不一定适合所有人，只是用来解决一些我自己感兴趣的问题，就像以前的 Notion 模板一样。
我会将用 Cursor 创建的小工具聚合在一起，如果你也感兴趣，那自然也是很好的。
> https://www.toolsxyz.com
================================================================
# 如何规划 B端 设计系统？深度解析 AWS CloudScape Design System 最佳实践
- **发布日期**：2024-11-08
- **原文链接**：https://www.thefivekey.com/b-end-design-system-deep-dive-aws-cloudscape/
- **Markdown 原文**：https://www.thefivekey.com/b-end-design-system-deep-dive-aws-cloudscape/index.md
- **标签**：设计系统, 设计模式
> AWS CloudScape 是当下最被低估的 B端 设计系统之一。本文从 Foundation / Component / Pattern / Demo 四层结构出发，完整拆解 CloudScape 的 67 个组件、35 个 Pattern 和 27 个 Demo，并给出如何参考它构建自己 B端 设计系统的实操思路。
> **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端设计的首要任务是让用户能够以最低的认知负担完成复杂的工作任务，从而提升整个业务系统的工作效率和生产力。
## CloudScape 属于哪种类型的设计系统
### 设计系统的三个等级：系统级、领域级、业务级
在之前的文章「[设计系统学习指南 - 国内外 Design System 案例解析](/how-to-learn-from-other-design-systems/)」里，我们曾介绍过设计系统的三个等级。
我会倾向于将所有的 [设计系统](/tags/design-system/) 分为不同等级：**系统级 → 领域级 → 业务级**，大家可以用下面这张图看清楚它们的逻辑。从系统级到业务级，是对设计标准的抽象到具象，同时我们对设计的指引也是从基础认知转为更加具体的约束。
### CloudScape 的领域级定位
而 B端设计，在这里的定义就是领域级设计系统。我们通常说的 B端设计就是一个非常明确的领域，它需要聚焦于某一个具体的领域而产生具体的解决方案，例如大家经常提到的 [Ant Design](https://ant.design/index-cn/)。
而我们今天要讨论的 [AWS CloudScape Design System](https://cloudscape.design/) 也是如此。虽然从严格意义上来说它应该是业务级设计系统，主要是为 AWS 的业务所服务。但在我看来，抛开业务属性本身，它还对 B端设计的很多通用场景做了大量的深入和研究，非常值得我们学习和借鉴。
因此，我想专门用一篇文章来详细的介绍一下 CloudScape 这套 B端设计系统的构建思路，希望能给大家在构建自己的设计系统时有所帮助。
## AWS CloudScape Design System 是什么
### CloudScape 的发布背景与规模
CloudScape Design System 是今年的 7 月底，AWS 正式对外发布的 [设计系统](/tags/design-system/)。这是一套开源设计系统解决方案，可用于大规模构建云服务业务的的复杂 Web 应用。
这套解决方案其实早在 2016 年就已经在开始内部启动了，如果大家有用过 AWS 的产品，可能你已经默默的见过它了。
相较于近段时间腾讯发布的 TDesign、字节的 Arco Design 和 Semi Design，CloudScape 显然更加的"丰满"也更加的"明确"。虽然发布已经有一个多月，但网络上关于它的讨论还很少，本期的文章就来和大家聊聊这套还挺新但非常优秀的 [设计系统](/tags/design-system/)。
### CloudScape 的核心数据：67 个组件 + 35 个 Pattern + 27 个 Demo
CloudScape 提供了多达 67 个组件，而且这里面大多数都是基于 toB 类业务特性制定的自定义组件。基于这些组件和云服务业务的特性，它还封装了 5 大类 35 个 Pattern 以及 27 种场景的演示 Demo。
> 官方站点：
Foundation 包含了上图中 10 多类基础设定。这部分内容和其他设计系统基本上大同小异（可能在命名会组织上有所差别），这里主要聊聊内容密度、数据可视化、Design Token 和布局这四个模块中的一些亮点设定。
#### Foundation 亮点 1：内容密度（舒适 vs 紧凑）
云服务以及大量的 toB 产品本质都是追求操作的高效性，这也就对信息内容的展示提出了更高的要求。以前在负责财资线的业务时，总会听到很多关于信息密度的讨论。
有的人说用户屏幕小工作时间长，希望信息内容不要太密集避免眼睛疲劳；有的人说也有很多大屏幕用户，希望页面能够展示更多的信息来帮助他们提升处理的效率。大家说得都没错，这一对问题看似矛盾但却又真实存在。
CloudScape 提供了两种模式（舒适 & 紧凑）供用户选择，舒适模式是系统的标准密度方案，它针对所有的场景以及跨端做了很多细节上的调试优化；而紧凑模式则精心调整优化，通过减少了页面元素之间的空间来提升页面信息的可见性。
系统通过 [Spacing（间距）组件](https://cloudscape.design/foundation/visual-foundation/spacing/) 来改变内容密度的变化，以 4px 为基础单位来控制组件内、外部的空间。
这里就要说到 CloudScape 的一些细节控制。虽然内容密度的设置会同步调整整个系统的内容展示，但为了保证良好的使用体验，有一些特定界面是不会受到密度调整的影响的。比如帮助信息页面、警告提升、验证信息的页面和模块，以及按钮、input 框、DataPicker 之类的交互组件。
同时它还对一些特定页面比如 Dashboard、列表、详情还会做一些细节上的优化来确保页面的操作体验和视觉感受。
#### Foundation 亮点 2：数据可视化色彩规范
云服务产品会大量使用到图表将数据进行可视化，辅助用户进行监控以及操作，这里对色彩的使用就需要相对更加严肃。除了在可读性上的一些基础要求之外，CloudScape 对标示状态和严重性时间的色彩选择上做了明确的定义。
上图中对于资源使用情况的色彩制定是非常重要的，它可以帮助用户快速感知系统运作的状态。这个设定其实非常重要，但不知出于什么考虑 CloudScape 允许使用者通过 token 进行自定义的。逻辑上虽然是合理，但我其实目前没想清楚开放它的必要性。
> 
怎么去理解这个不可自定义呢，这个就是我前面提到的「逐步约束」。当通过一系列验证（或强设定）后你发现在特定场景下某些设定是最为合理的，那么就可以考虑与各相关方沟通达成一致并将它封装起来，通过这个标准来保障当前场景下的最佳体验。
这里间距和动效的"强约束"应该是 AWS 产品体验的通用标准，也是 CloudScape 在多年业务实践中不断尝试找到的"最优解"。
> 
这个区域的划分和定义其实并不复杂，但很多时候大家并没有做。这个看似不太大的"问题"却会造成在应用的时候错误，长久以往造成页面的混乱。
> [查看 CloudScape 布局介绍](https://cloudscape.design/foundation/visual-foundation/layout/)
还是前面财资线的例子，我们在创建设计系统的初期最重要的事情之一就是定义系统的布局。明确每一个区域的作用，可以放哪些业务模块，以及它的交互行为如何都进行了明确的定义。
不过可惜由于业务实在过于复杂，导致当时我们布局的设定还是有些复杂。但它的效果是非常明显的，无论是在与业务方的沟通还是后期的设计研发过程，它都帮我们减少了很多不必要的沟通浪费。
### Component · 设计组件
CloudScape 提供以上 10 大类共 67 个组件，基本涵盖了 toB 产品的核心场景。这部分做得非常用心，基本上每个组件都提供了 **使用说明**、**配置调试**、**API**、**测试指南**，让用户清晰的理解和使用这个组件。
这里挑选 1 个有代表性的和大家聊聊，其他的 60 个多个组件就不一一介绍了，大家可以去官网查看。
#### 组件案例：Autosuggest 自动填充
Autosuggest 字面意思就是自动建议，在其他很多设计系统里也叫 Autocomplete （自动填充），是帮助用户快速完成信息输入非常有用的一个功能。
早些年很多人会把这个功能封装在具体的某个组件中。看起来似乎没毛病，但到了新的需求中你可能会发现某个自动填充的场景没有考虑到。于是就出现了新的组件继续往下走，遇到新问题，再出现一个…
如果换个角度来看，自动填充它确实本身也是一个组件，目的就是解决当需要系统向用户提供输入辅助时的帮助。这样一来，这个看似小小的自动填充模块深入挖掘下去还是非常复杂的。
下图是 CloudScape 的 Autosuggest 组件页面。从左到右以此是配置调试、API、测试指南和使用说明。
在当前配置调试界面的左侧红色区域，你可以查看它的一些实际案例。比如标注的输入建议、输入建议分组、带标签建议、报错模式等。这里你基本上能够感受到它可以如何去使用。
顺便说一句，CloudScape 提供了标准亮黑模式，每一个组件和 Pattern 都可以预览它的效果。
在构建设计系统的过程中，组件梳理和定义看似是一件很机械的工作，但实际上非常的重要和严肃。架构型设计师首先需要从海量的业务场景中找出它们进行归类、抽象、定义、封装，这其实非常考验设计师的能力。
> 
CloudScape 提供以上 5 大类共 35 组 Pattern。相较于之前和大家提供的 Carbon Design System 这里对 Pattern 的定义会更加的具象，也更贴合业务。大家一看就很清楚它能帮助我解决哪个业务需求。
这里也一样，挑选 1 个比较有代表性的和大家展开聊聊，其他更多大家还是去官网查看。
#### Pattern 案例：Announcing New Features 新功能发布
「新功能发布」可以说是 toB 产品中的老大难问题了。不是它本身有多复杂，而是绝大多数产品上都很乱。规则制定不清晰，设计师会错用，有了规则执行也难以到位，时间一长就会出现通知、浮窗、提示满天飞的情况。
当然，这本身是一个和产品、设计、运营多方以及"利益"都有关的问题，我们今天还是先回到设计本身，看看 CloudScape 是如何定义标准的。
首先对于「新功能发布」它给出了三条核心体验原则：
1. 用户的核心工作是完成任务，所以尽可能保持沟通内容的简洁，减少用户认知的负担
2. 给予用户控制权，减少对用户工作的打扰
3. 控制好对 Flashbar 这类组件的使用，降低对用的视觉干扰
CloudScape 提供了三种「新功能发布」的类型，提供不同场景下的视觉引导。
##### 服务级功能发布：FlashBar 全局通知
如果新发布功能会影响到该服务中的所有页面，可以使用系统中视觉最强的组件 FlashBar 来进行提示引导。
##### 页面级功能发布：侧边栏气泡提示
页面级功能发布是针对新增页面或服务中有新功能增加所提供的通知方式，在侧边栏中使用弹出气泡提供提示引导。
##### 页面内功能发布：模块级通知
页面内功能发布是针对某个具体功能页中新模块增加所提供的通知方式，在页面模块中使用类似 Flashbar（视觉强度较低）的通知模块提示引导。
CloudScape 对新功能发布的定义其实也并不复杂，但通过分类之后也已经非常清晰了。使用者需要的是在使用前先确定它是属于哪一个层级的新增功能，在选择与之对应的类型即可。
> 
纵观整套设计系统，它其实就是组件、模式、模板、基础四大部分的一步步收敛和包含。
- 基于领域和业务的特性先进行组件的盘点和定义，解决核心操作的交互问题
- 通过各组件的组合形成固定的设计模式，用来解决一些明确的场景任务
- 通过大量的实践和迭代，将组件和模式沉淀成模板，提升页面的生产效率
- 基础设定作为整套设计系统的"地基"，严格渗透执行在设计系统的每个环节中
## 主流设计系统对比：CloudScape / Ant Design / Fusion / Material
如果你还在犹豫应该参考哪套设计系统，下面这张对比可以帮你快速定位。
| 设计系统 | 层级 | 核心特点 | 组件数 | Pattern 丰富度 | 最适合场景 |
| --- | --- | --- | --- | --- | --- |
| **Material Design** | 系统级 | 基础交互规范、跨端一致 | 50+ | 低 | 通用 Web / Mobile 基础规范 |
| **Ant Design** | 领域级（B 端通用） | 组件丰富、社区成熟、中文友好 | 60+ | 中 | 中后台产品快速启动 |
| **Fusion Design** | 领域级（阿里生态） | 定制能力强、支持 Design Token | 70+ | 中 | 阿里内部、需要定制的 B 端 |
| **TDesign / Arco / Semi** | 领域级（大厂 B 端） | 各厂业务沉淀、组件完整 | 60+ | 中 | 对应厂内业务 / 同类场景 |
| **AWS CloudScape** | 业务级（云服务） | Pattern 密集、约束清晰、实操性极强 | 67 | 高（35 个） | 复杂 toB 业务、云产品 / 管控台 |
**一句话选型建议**：
- 想要一个能**直接用的通用 B 端组件库** → Ant Design
- 想要**深度定制和拓展** → Fusion Design
- 想要**学习如何把业务级设计系统做到极致** → AWS CloudScape
## 常见问题
在聊到 AWS CloudScape 时，我经常被问到下面几个问题，一并在这里回答。
### CloudScape Design System 是什么？
CloudScape 是 AWS 官方推出的开源 B端 设计系统，2024 年 7 月对外发布。它已经在 AWS 内部服务了多年（从 2016 年开始内部启动），被用于构建 AWS 云服务的复杂 Web 控制台和管理界面。
### AWS CloudScape 有多少个组件和 Pattern？
CloudScape 提供了 **67 个组件**、**35 个 Pattern**（覆盖 5 大类）和 **27 个 Demo** 演示模板。组件数量不算最多，但 Pattern 密度在主流设计系统中属于顶级。
### CloudScape 和 Ant Design 有什么区别？
Ant Design 是**领域级通用 B 端**设计系统，面向所有中后台场景；CloudScape 是**业务级（云服务领域）**设计系统，定位更专、Pattern 更具体。Ant Design 是一套"可以直接用的组件库"，CloudScape 是一套"可以对标学习的完整方法论"。
### 我的团队不做 AWS 产品，CloudScape 对我有什么参考价值？
**参考价值很大**。即使你的业务不是云服务，CloudScape 的分层结构（Foundation → Component → Pattern → Demo）、Pattern 的组织思路、Do's and Don'ts 的写法，都可以直接借鉴到自己的设计系统里。它提供的不是"模板"，而是"方法论"。
### 如何基于 CloudScape 构建自己的设计系统？
5 步落地思路：
1. 评估业务复杂度（是否真的需要业务级设计系统）
2. 先对齐 Foundation 层（色彩、字体、间距、布局）
3. 抽象组件层（优先做业务高频组件）
4. 沉淀 Pattern 层（围绕具体业务场景）
5. 持续迭代 Demo 模板，作为团队沟通语言
### CloudScape 是免费开源的吗？
是的，CloudScape 以 Apache 2.0 协议开源，可以自由查看、使用、参考。官方仓库：
CloudScape 提供了多达 66 个组件，而且这里面大多数都是基于 toB 类业务特性制定的自定义组件。基于这些组件和云服务业务的特性，它还封装了 5 大类 35 个 Pattern 以及 27 中场景的演示 Demo。
#### CloudScape Design System 的核心特点
**01. 内容简练务实，指导准确有效**
相较于很多设计系统的站点，CloudScape 提供的内容非常简练，没有太多设计理念、价值观的讲解，更多还是落在实际应用指导。它更像是一本面向实操的指导手册，每一个 Component 和 Pattern 都提供了清晰准确的定义、场景以及使用说明。而且大部分都提供了在线配置调试功能，帮助使用者更好的理解和使用。
**02. 定位明确，领域性强**
从 2016 年启动到现在已经有了 6 年时间， 经过了 AWS 这么多年业务中的打磨后 CloudScape 给我的一个感觉就是清晰和明确。特别是在 Pattern 的部分，35 个虽然不算多，但基本都是这个领域的内的一些标准场景的抽象。基本上云产品业务需要的场景它提供了指引，相信做过相关产品的同学会有更强的体感。
**03. 强约束性 & 可控自由度**
在之前的文章里有很大家提到过，设计系统就是要对场景进行抽象、封装并逐步进行合理有效的约束，达成体验上的和谐和统一。CloudScape 坚定的给出了很多强约束来保障产品的基础体验一致性和有效性，同时它也在可行的范围内提供了一些自定义空间，来确保产品设计过程中的差异性。
#### CloudScape Design System 中的设计模式
CloudScape Design System 的另一个亮点在于它对设计模式的抽象，能够很好的覆盖在此类业务场景中的一些共性场景，为同类型的设计需求提供了一个很好的标准解决方案。
### 设计系统对公司的价值
当我们投入资源做一件事情，需要关注到它所带来的价值。特别是在如今的大环境下，大家都更加的精打细算，讲不清价值的事情在任何公司都难以推动。
对于公司而言，设计系统就是产品的基础，也是业务能够快速迭代的发动机。通过其能力的不断迭代，我们可以进一步封装、约束我们的设计标准。以此来不断优化业务的生产流程，达到企业能够降本提效的目的。
对公司而言，我们节省的不仅仅是成本，更重要是时间。而在当前激烈的竞争环境下，市场的先机往往比金钱更加重要。
### 设计系统对设计团队的价值
一直以来，设计师在整个企业中的话语权是不高的。特别是在国内，设计师更多时候是一个不太重要的”资源“。有时候大家都会打趣到，这个项目可以没有设计投入，但研发不能没有啊。虽然这只是个玩笑，但它背后的本质还是在于设计师这个角色缺少不可替代性。这也是为什么在国内很少有设计角色进入企业最为核心管理层的原因。
而在我看来，这也是设计团队发展至今最为核心的能力和资产，是设计团队提升影响力，成为业务核心能力的重要基础。
### 设计系统对设计师的价值
在日常的项目设计工作中。设计师的能力都是通过一个个具体的项目来体现，大部分时候它很难沉淀为一种核心能力展现在其他人面前。
设计系统的发展，让设计师有机会能够向”架构师“的方向进行发展。将自己在设计和行业方面的经验进行体系化的沉淀并转化成产品能力来进一步放大自己的价值。同时，它也将可能推动设计师的岗位向下一个阶段发展，衍生出新的角色：产品型设计师和架构型设计师。
当然，除了对我们的价值层面，我们还需要从更多的方面向公司去介绍它的价值。如果大家不太清楚应该如何去组织、表达，可以阅读下面这篇文章进一步了解。
> 延展阅读 👉 如何向你的主管和团队介绍 Design System 的重要性
> 💡 延伸阅读：
> - 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
================================================================
# 如何向你的主管和团队介绍 Design System 的重要性
- **发布日期**：2024-03-07
- **原文链接**：https://www.thefivekey.com/how-to-prove-the-value-of-design-system-to-your-boss/
- **Markdown 原文**：https://www.thefivekey.com/how-to-prove-the-value-of-design-system-to-your-boss/index.md
- **标签**：设计系统, 求职面试, 职业发展
> 设计系统 (Design System) 是当前设计领域最热门话题之一，但其价值并非所有人都清晰认识。本文以一份完整 PPT 为基础，从外部环境变化、阿里实战案例、设计系统的层级与构建思路、设计师角色演变等维度，提供一套向主管和团队推行 Design System 的完整话术框架。
> **TL;DR**
>
> 这是一份完整的「向主管和团队推行 Design System」的 PPT 分享内容，覆盖：为什么要做（外部环境变化）、阿里的真实实践案例、设计系统的三种层级、构建思路与三个阶段、以及设计师角色演变。
>
> 可以直接拿去给你的老板、团队同学讲清楚 Design System 的价值。
> 这是节前应邀进行了一次关于 [Design System](/tags/design-system/) （设计系统）的“布道”分享。我将 PPT 内容进行了一些细化和调整，在这里分享给大家。大家在对内进行宣导的时候可以以此 PPT 为基础，给你的老板、团队同学讲解为什么要做设计系统。
> 这次分享也是对过往前面几期文章的一个不同视角的“串联”，从这个视角再来回顾这几篇文章相信大家会有更多不同的理解。欢迎大家有时间读完后来群里进一步一起探讨。
## 本次 Design System 分享 PPT 的内容定位
设计系统的理论和案例，相信大家在日常工作中已经看过不少，也不是本次的分享的重点。因此这份 PPT 不聊细节，而是基于这些年在设计系统、协同过程中的一些感受来给大家聊聊我是如何看待设计系统的。
## 为什么要做 Design System：价值与外部环境变化
### Design System 的价值及重要性
### 外部环境的变化
互联网早已不是新鲜产物，我们生活的方方面面都已经逐步的互联网化。也正式因此，互联网公司也越来越受到国家政策、经济环境的影响，而身处互联网行业的设计师，我们工作也与之息息相关。
就近一年的观察，我觉得这三块变化和我们还是有很大的关联的，所以先拿出来和大家分享一下：
- 就像我们每个公司都有自己的目标，政府这个最大的平台也对近 5 年整个国家的数字经济发展有一个明确的目标。这四五十亿的预期增长目标的背后有大量的需求增加，显然依靠现有的生产模式是无法解决的；
- 今年大形势不太好，所有的企业都在做降本提效。降本很多团队都在做，但光降本还不够，提效同样也需要抓。我还在阿里的时候，你和人聊设计系统，人家没那么感冒。哦一下。你说这个东西可以提效，减少开发周期。那么大家眼前一亮，可以聊聊。
- 软件开源，也是十四五规划中非常重要的一点。如今的中美关系、国际形势使得大家的意识上越发的明确，国内企业、公司、政府不能长期依赖外部的产品和工具。开源是促进整体发展中非常重要的一环，互联网头部企业比如腾讯、字节、阿里都在其中承担着非常重要的带头作用。
### 一次关于 Design System 的调研
19 年的 Ucan，我做了一次关于设计系统的工作坊。大家都是带着好奇来参加的，真正在开展设计系统工作的团队并不多。而到了今年我做了一次调研，虽然有效样本只有 100 多个，但还是具备一些代表性的。大家可以看到无论是公司对设计系统的认知，还是投入的程度都有了非常大的变化。
关于这次的调研分析，大家可以进一步阅读设计系统 2022 调研总结
## 阿里 Design System 实践：真实案例与业务价值
### 在阿里 Design System 的真实案例
在阿里有两套主流的设计系统，分别是我们设计中台的 Fusion Design 和蚂蚁的 Ant Design。
两套设计系统都是差不多在 16 年左右启动的，发展至今它俩支撑了三大集团（阿里、菜鸟、蚂蚁）的全部数百条业务线。在一些我们重点合作的业务里，已经可以达成帮助设计师提效 50%，研发提效 30%的成果。当然，这些成果不只是源于设计系统，还需要有一系列的配套流程和工具。
### 设计系统的价值
在企业里工作，讲清楚一件事情的价值很重要，比如做设计系统就经常会面临很多人的疑问。19 年 Ucan 工作坊上我也收到过同样的问题，但我觉得当时回答的不太好，更多还是偏向于强调对设计、对设计师的价值。
但随着接下来这些年在阿里很多业务中的摸索，有成功也有失败，我认为从以上三个方面来回答这个问题会更容易获得大家的认同。
## Design System 的三种层级与案例解析
### 设计系统的三种类型
这些年业内出现了很多的设计系统，国内、国外有很多。大家在聊起设计系统时候经常会说起这家怎么怎么好，那家怎么怎么不好。为什么会有这些不同的开发？是因为大家所面临的问题以及对它们的定位有所不同。
比如字节的 Arco、Semi、腾讯的 TDesign，有很多人说他们过于简单，也缺少差异性。如果你带着对解决业务实际问题的角度看待它们，那确实很难满足大家的要求。因为他们的定位都是企业中后台的领域级系统，它的目的就是尽可能的减少同质化的基础工作，业务的部分并不在这套系统的目标范畴内。
有了这个定位的概念，我们就可以再来将我们曾经看过的这些[设计系统](https://www.thefivekey.com/tag/design-system/)做一下分类。（如上图）。从系统级→领域级→业务级，他们本质上是一个从抽象到具象的过程，大家可以关注一下这里，不同类型的设计系统在定义和要求上是有差异的。
对于我们绝大多数设计师而言，主要的工作都发生在业务级，基于一套底层的系统去构建符合业务述求的设计系统。比如阿里云的 BDesign，就是在 Fusion Design 的基础上“生长”出来的。
### 领域级设计系统案例 AWS CloudScape
AWS 的 [CloudScape](https://cloudscape.design/) 是近期我看到完成度最高，最值得大家学习的设计系统。总体来说我会将它的优点总结为以下三点：
**01. 内容简练务实，指导准确有效果**
相较于很多设计系统的站点，CloudScape 提供的内容非常简练，没有太多对这套设计系统设计理念、价值观的讲解，更多还是落在实际应用指导。它更像是一本面向实操的指导手册，每一个 Component 和 Pattern 都提供了清晰准确的定义、场景以及使用说明。而且大部分都提供了在线配置调试功能，帮助使用者更好的理解和使用。
**02. 定位明确，领域性强**
从 2016 年启动到现在已经有了 6 年时间， 经过了 AWS 这么多年业务中的打磨后 CloudScape 给我的一个感觉就是清晰和明确。特别是在 Pattern 的部分，35 个虽然不算多，但基本都是这个领域的内的一些标准场景的抽象。基本上云产品业务需要的场景它提供了指引，相信做过相关产品的同学会有更强的体感。
**03. 强约束性 & 可控自由度**
设计系统就是要对场景进行抽象、封装并逐步进行合理有效的约束，达成体验上的和谐和统一。CloudScape 坚定的给出了很多强约束来保障产品的基础体验一致性和有效性，同时它也在可行的范围内提供了一些自定义空间，来确保产品设计过程中的差异性。
详细内容大家可以参考过往文章 「[设计系统案例分析 – CloudScape Design System](https://www.thefivekey.com/aws-cloudscape-design-system/)」
### 领域级设计系统案例 AWS CloudScape – 新功能发布
业务级的设计系统，很多时候面向的是业务中的具体问题。这些问题不是指下拉操作怎么做、填写表单报错怎么弄，这些都太过于“底层”，本就应该封装起来。
这里给大家举个例子「新功能发布」应该怎么做？
CloudScape 对新功能发布给出了一个明确的解决方案，通过三种设计来解决不同颗粒度的功能发布通知诉求。
**01. 服务级的功能发布 – 图中 ①**
如果新发布功能会影响到该服务中的所有页面，可以使用系统中视觉最强的组件 FlashBar 来进行提示引导
**02. 页面级功能发布 – 图中②**
页面级功能发布是针对新增页面或服务中有新功能增加所提供的通知方式，在侧边栏中使用弹出气泡提供提示引导。
**03. 页面内功能发布 – 图中③**
页面内功能发布是针对某个具体功能页中新模块增加所提供的通知方式，在页面模块中使用类似 Flashbar（视觉强度较低）的通知模块提示引导。
## 如何构建 Design System：思路与三个阶段
### 设计系统的构建思路
前面我们讲了设计系统的三种类型，但到自己做的时候该怎么入手呢？我给大家推荐两种思路。
- 一种是基于领域级设计系统，适合偏 Web 端的产品，有很好的 0 到 1 基础。重点关注行业领域的特性，去抽象业务组件、业务 pattern
- 另一种是基于系统级去构建，适合偏移动端的场景，直接业务级往上去做
这里在领域级，我推荐大家可以去使用阿里、字节、腾讯这几家的产品，因为迭代速度和维护有更好的保障。
### 设计系统的三个阶段
## Design System 时代设计师角色的演变
### 设计师岗位的变迁
03 年毕业工作至今，有幸经历了从“美工”到设计师的整个历程。时至今天设计师这个职能已经被行业、被公司所认可，职能和领域也在不断演变。设计系统的不断发展让设计的“架构”逐步成型。
19 年左右第一次在委员会和大家提出了架构型设计师和产品设计师的构想，不过当年的时机确实还不够成熟。随着这些年在团队内部的试验，我相信架构型设计师是未来设计师职能中非常重要的一种类型。
关于这个话题，我在 [📬 成为架构型设计师](https://www.thefivekey.com/become-an-architectural-designer/) 的文章中有更详细的讨论。
### 设计师岗位的变迁
有人说，和 DesignOps 很像。对，但我觉得在国内还需要些时间，但架构型设计师是可以先尝试的，它更偏向于具体的工作，为业务为团队发展所服务。
架构型设计师核心工作是设计系统构建，但不能只做这个，还需要能建立流程、方法来促使它们真的落地。
## Take Away：向主管推行 Design System 的核心要点
> 💡 延伸阅读：
> - 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
> - 入门基础：[设计系统 · 我们为什么要做 Design System](/why-we-need-design-system/)
> - 学习路径：[设计系统学习指南 - 国内外 Design System 案例解析](/how-to-learn-from-other-design-systems/)
> - 深度案例：[如何规划 B端 设计系统？深度解析 AWS CloudScape](/b-end-design-system-deep-dive-aws-cloudscape/)
> - 角色演变：[成为架构型设计师](/become-an-architectural-designer/)
================================================================
# 设计师的简历作品集应该关注什么？
- **发布日期**：2024-03-03
- **原文链接**：https://www.thefivekey.com/how-to-effectively-present-your-resume-portfolio/
- **Markdown 原文**：https://www.thefivekey.com/how-to-effectively-present-your-resume-portfolio/index.md
- **标签**：求职面试
> 阿里做面试官看过上千份简历作品集后，我发现大部分作品集最容易出现的三个问题：流水账记录、缺少「解决问题能力」的体现、忽略了对「用户需求」的关注。本文从面试官视角拆解作品集的真正评估标准：不是看你做了什么，而是看你解决了什么问题。
> **TL;DR**
>
> 面试官看作品集，不是看你"做了什么"，而是看你"解决了什么问题"。
>
> 作品集最常见的三个坑：流水账记录、缺少解决问题能力的体现、忽略用户需求。
>
> 好的作品集要从"用户需求"切入，展示你看问题、拆问题、解问题的完整思路。
作品集 的制作是每个设计师都会经历的工作，也是大家最难做的设计之一。最近两周帮几位会员同学看了不少 ，我发现大家的文档基本都是至少 30 页打底，有的甚至到了 60 多页，信息量很大。看得出都在想尽可能全方位的向面试官展示自己的能力，但这些冗长的文档里也都出现了一个明显的共性问题，那就是缺少对自己能力优势的有效表达。
这里主要会体现在以下几个方面：
- 流水账记录。通篇按照时间线将自己做过的项目罗列了一遍；
- 缺少「解决问题能力」的体现；
- 忽略了对「用户需求」的关注。
这些问题不仅仅会出现在求职简历作品集里，所有基于文档的“沟通”场景，比如晋升答辩、汇报分享等场景也都会遇到。所以，这一期的文章我想和大家聊聊自己关于作品集、项目的汇报的一套写作方法。
## 作品集 ，从你的「用户需求」开始
作为设计师，我们时刻都在思考用户遇到了什么问题，我的这个设计方案是不是能解决他们的问题。可是到了写 PPT、作品集的时候往往却忽略掉了这一点，更多的去想“我”要表达什么，忽略了“用户”想要看到什么。
在阿里这些年做面试官也看了上千篇简历，面试了几百人。从“人肉数据分析”的角度来看，除去定向挖人之外，简历作品集水准较高的候选人确实更容易走到最后。
当然，这不是说作品集水准高就代表能力一定强，而是它能够在一定程度上反映出设计师的思考深度。所以我一直说找人帮忙改简其实并不靠谱，简历虽然改了但你的思维模式并没有发生变化，进入到正式[面试环节](https://www.thefivekey.com/tag/求职面试/)还是容易出问题。
## 从用户需求的视角来看作品集
回到「用户需求」，在不同场景下我们的「用户」和「用户需求」都有会存在一些差异。
- 投递简历时，我们的「用户」是专业面试官、HR，他们会关注候选人的业务背景、专业能力及团队匹配度等；
- 晋升面试时，我们的「用户」是专业评委，他们会关注候选人挖掘问题的能力、设计过程及发展潜力；
- 专业分享时，我们的「用户」是设计师，他们会关注你的解题思路以及背后的思考。
如果你也是设计师，正在需要寻求面试过程中的帮助，可以预约我的模拟面试服务。
> 💡 延伸阅读：
> - 进阶实操方法：[好的简历作品集，需要有层次的表达](/how-to-structure-portfolio-expression/)
> - 跨行业面试时的直觉校正：[进入新行业，如何校正你的产品直觉](/calibrate-your-product-intuition/)
================================================================
# 表单设计的基础设计逻辑
- **发布日期**：2024-03-01
- **原文链接**：https://www.thefivekey.com/design-strategies-for-form-design/
- **Markdown 原文**：https://www.thefivekey.com/design-strategies-for-form-design/index.md
- **标签**：设计系统, 表单设计
> 表单是互联网产品中最重要的交互能力之一，但好的表单设计不仅是组件堆砌。本文提供一个三层思考模型（基础体验、行业特性、业务特性）帮你系统思考表单设计。
> **TL;DR**
>
> 表单看起来简单，但好的表单设计需要同时考虑三层：基础体验（组件/交互/反馈）、行业特性（金融严谨 vs 电商快捷）、业务特性（转化率/字段必要性）。
>
> 本系列提供一个由下至上的"通关"思考模型，帮你设计出真正好用的表单。
这篇表单设计的文章出自于4 年前 PinDesign 期刊中的文章。前段时间整理了一下旧文档，虽然时间有点久，但还是有不少内容的思路放到当前依旧有用，所以我会陆续修改一些过去的文章，重新更新在这里，希望对大家有帮助。
## 关于 表单设计
如果从功能角度来划分，表单一定是互联网产品中最为重要的能力之一，它也是用户与产品之间进行交互的一个重要渠道。如果没有表单产品的体验将变得非常的被动，用户只能消费平台所提供的内容。
作为用户我们在日常会遇到各式不同的表单，我们会发自内心的喜欢某个产品的设计，也会因为一些糟糕的设计而吐槽。每一个组件都没有问题，但合在一起就是不好用。如果仔细分析，你会发现其实它并不是一个简单的设计问题，除了表单基础体验它还和所处行业、业务特性有着较大的关联。
如果从 Design System 的角度来看，这似乎又是一个很成熟的工作。输入框、单选、复选、日期、按钮…… 每一个组件都是用户所熟知的，它们是产品设计最底层、基础的元素，也完全有可以系统化的去沉淀。
## 为什么表单设计值得专门拆解
作为[设计系统](https://www.thefivekey.com/tag/design-system/)中讨论最多的部分之一，网络上有很多关于表单的设计资讯，但它们都有比较强的指向性。有一些更关注表单的交互，有一些则更关注表单的逻辑，但真正将它们融合在一起结合产品设计一起来讲述的并不太多（特别是针对移动端产品）。回过头来看自己这十几年的工作经历，互联网产品的方向和载体不断的在发生变化，但表单依旧还在那里，基础的交互形式也依旧是那些。
从表现上来看表单似乎很简单，即使是新入行的设计师也能很快的掌握基础的元素来搭建一个表单界面。但结合上业务的复杂度再来看待一个表单，它就变得不那么简单了。想要设计一个用户愿意填写且使用体验上还不赖的表单，除了设计本身，还需要我们结合产品、技术一起来思考。
此前已经写过几篇相关的文章，但出发点也是某个具象的角度，也不够系统化。在工作上近段时间里的一部分中心又开始回到到了表单的设计上，但在要求上需要更加的全面和系统化，这也让自己需要去重新梳理对它的思考。借这个机会也正好强迫自己将对思考系统的总结下来，也希望能在这个“课题”上带给大家实质性的帮助。
## 表单设计系列的完整内容框架
正如前面所言，表单复杂度在于除了设计自身，还与产品、技术有着较强的关联。所以这个系列会将这些因素整合在一起来进行讲解，大体上它会分成以下几大部分：
### 01. 理解设计表单的意义
如果将表单比作一个工具，那么我们将它比作 sketch。 这个工具自身内置了很多基础元素的能力，每个人都可以用它做出不同的设计，但脱离业务场景单独去评价这个设计的好坏其实是没有意义的。一个明确的设计目标（产品目标）才是从设计上可以去尝试的方向，也是衡量它的一个直接标准。
在这部分内容中我们将站在一个商业产品设计的角度去将表单进行剥离，去分析在每一个层级中设计需要关注的核心本质是什么。也只有先将这个部分搞清楚，才能确保我们设计的表单是在当前情景下真正有效、易于使用的。
### 02. 表单基础设计规范
我们前面提到，表单是一个在产品设计中被大量使用的能力。正因为如此，它也非常有必要被“约束”起来。一套完整、有效的设计规范能够让我们在具体的界面设计中将关注点更多的放在业务诉求上，避免表单字段的规范带来对设计的干扰。
当然，表单的设计规范并不是只能一种。根据你的业务领域，它可以有更多不同的角度和形式去体现。这部分的核心是基于一个整体性的框架，以一个具象的领域为代表做一次案例的示范。希望大家最后得到不是这套表单的规范，而是如何去创建一套属于自己业务的表单规范。
### 03. 表单的设计实例
虽然我们可以通过基础元素随意的“组装”不同的表单，但在互联网产品的发展中它们已经形成了很多特定的使用场景，这也是我们在很多站点上能看到的实际案例。
如果只是简答的从表现层面来看，我们可能并不能去评判它的优劣，也不知道我们该如何去借鉴他们的思路。所以在这部分我们将以这些常用的场景（如注册登录、发布评论、搜索筛选等…）为案例从设计思路上来进行逐个的分析。这些可能也将是大家在日常工作中最为有用的部分，所以我们会用更多的篇幅来讲解这部分内容。
## 在产品设计中，表单是用来干什么的？
我们先来关注一个更宏观一些的问题。在一个产品中，表单是为了收集用户的信息（需求），再由系统做出一系列的处理返回展示给用户来满足用户的诉求。从表现上来看，它大多由一系列的输入框、选择框以及一组按钮所组成。
沿着这个思路往下走，作为设计师我们则会在一堆表单组件中打转，通过各种不同的组合来应对业务所提出的诉求。但这可能会让我们渐渐的忽略了这件事情的本质，我们究竟为什么要提供表单？
如果我们转化一下思路，将目光从做表单转移到用户身上，那么我们需要思考的问题则会转变成在当前场景下用户的需求是什么？
- 注册成为用户 – 想要获取会员才能查看的信息；
- 搜索关键词 & 筛选 – 想要快速获得所关注的信息；
- 填写地址信息 – 将货物准确的送到我需要的地方；
- ….
以上的几个案例，通常情况下我们都会用一个表单来处理，让用户自行录入。但大家仔细分析一下就会发现，注册、搜索、填地址这些操作并不是用户真正的目的，只是在产品设计上比较“粗暴”的解决方法之一。
- 如果我们接入更为通用的第三方登录，用户只需要几次点击就可以他所感兴趣的信息；
- 如果我们允许用户保存自定义搜索条件（请参看 ebay），用户只需要一次设置，后续再无烦扰；
- 如果我们提供当前位置定位和识别，用户将大幅减少信息输入，快速完成信息的录入。
如果我们更多的去关心用户填写表单的目的，那么可能有很多的表单都不应该出现在用户的面前，因为表单也只不过是解决问题的方法之一。
我们曾经在 109 期的文章中曾提到过，用户放弃完成某个页面有很大的比例是由于复杂、冗长的表单。对于用户来说，表单其实是一种“麻烦”，特别是对于移动设备来说，输入信息是一件极大影响用户使用心情的事情。
所以站在整个产品的角度来看，原则上我们尽可能减少向用户提供表单。每当出现一个表单，我们都需要问问自己这是不是一定需要通过表单来处理。如果可以从产品角度来进行规避，那么我们应该更多的去思考如何通过产品功能规划来解决；如果实在不行，我们在来考虑如何设计一个表单，并在这个过程中不断的思考其必要性（字段）、易用性及设计的表现力。
## 表单遇到了哪些问题？
之前我们讨论这个话题更多是站在使用者（用户）的视角，但如果换到一个表单系统的角度，表单最终的使用者和设计它的设计师都是我们的用户。所以这里我们也将从这两个不同的视角来看看我们会遇到哪些问题。
### 对于使用者（用户）：
对于最终使用表单的用户而言，表单最重要的问题就是具有较大的心理成本和操作成本，影响的是最终的完成率。本质上来说，在目前的环境下我们还无法消灭表单，只能说站在整个产品的角度来思考如何让用户更容易的获得 Ta 所需要的资讯。
**01. 心理成本**
心理成本是一个容易被忽略的因素，很多人认为我把表单交互做的简单一些，那么用户填写起来也会轻松一些。但其实有研究曾提到过，对于表单用户看到的第一时间是先扫读一下，看看需要填写的内容有多少，估算一下自己需要多久完成。所以为了不吓到用户，很多长表单会选择进行分拆，降低用户的心理压力。
除此之外，用户也会看一看表单中的字段有没有特别难填写的。比如在很多支付流程中的信用卡信息，需要用户从钱包里找出卡再对应着一步步的填写进去。
这是一个麻烦且容易出错的流程，很多用户会卡在这一步。所以在产品设计上会加入扫描信用卡识别来降低用户首次输入的成本，同时还可以记录信用卡信息来方便下次的支付操作。
用户对于一个表单的心理成本在填写过程中起到了至关重要的作用，表单的字段也多，用户内心的抗拒则越大。
**02. 操作成本**
至于操作成本这个因素，大家相对都还比较理解。比如下方的这个案例，很明显就是在交互设计上有些欠考虑，用户完成表单的实际点击、输入的操作步骤非常多、繁琐。
### **对于设计师：**
设计师日常都会去看很多的案例，希望将它们设计好的地方借鉴到自己的工作中，但到了具体的设计中却发现并不一定适用。这背后的关键其实是如何去分析别人的案例，如何将设计的思路带入到自己的设计中，而这也才是学习借鉴的真正意义。
我们所看到的每一个具体案例它背后面向的其实也是一个具体的问题，只不过由于我们忽略了它背后的用户述求以及设计的“解题”的模式，关注点更多的放到了设计的“表象”上。
这个并没有捷径，只有结合其产品的背景进行分析才能真正搞清楚其设计意图。而对于设计师而言，想要更深入理解某一类功能的设计还需要找到更多的同类但不同设计形式的案例放在一起来进行思考。最终得到的才能会是更为全面、科学的结论。这也是为什么接下来我们会花大量篇幅来讨论具体 Pattern 的原因。
## 如何来看待表单设计？
基于以上的分析，我们可以发现在具体的项目设计中，它其实是一个结合了基础体验、行业特性及自有业务的工作，这也是为什么我们说它并不简单的原因。
在期刊的第 101 期中，曾经给大家提出了一个思考的模型。由上至下我们将一个表单的设计分为基础体验、行业特性和业务特性三个维度。我们要做的则是由下至上一层层的“通关”，也只有想清楚了每一层，我们才能让表单具备更好的使用体验。
在这整个过程中，一套完备的表单基础规范定义了每一个组件、Pattern 的使用规则以及所有可预见的交互。在系统的解决了这个问题之后，我们在之后的工作中则不再需要关注这个基础问题，将更多的精力放在对业务诉求的体现和用户需求的满足上。
> 💡 延伸阅读：
> - 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
> - 设计系统入门：[设计系统 · 我们为什么要做 Design System](/why-we-need-design-system/)
> - 布局框架理论：[设计系统核心理论篇 – 布局框架](/design-system-layout-framework/)
> - 模式 vs 组件：[设计模式库与设计组件库到底有什么区别？](/difference-between-design-pattern-and-design-component/)
================================================================
# 半年过去了，AI 设计的进展如何?
- **发布日期**：2023-09-04
- **原文链接**：https://www.thefivekey.com/progress-of-ai-design-in-ui-interface/
- **Markdown 原文**：https://www.thefivekey.com/progress-of-ai-design-in-ui-interface/index.md
- **标签**：AI, 设计工具, 体验设计
> AI Design 在过去一年多时间里引起了广泛关注，国内外众多产品纷纷投入探索。然而，随着冷静期的到来，越来越多的人意识到让AI真正融入日常设计工作远比预期复杂。本文将从业务视角切入，深入分析了AI在UI界面设计中的发展潜力和挑战，揭示了真实业务的复杂性对AI设计的影响和未来可能性。
> ⚠️ **本文已有更新版本**
>
> 这篇文章发布于 2023 年 9 月，是我对 AI 设计的早期观察。我在 2024 年 6 月写了一篇更深入、更全面的更新版：[一年过去了，AI design 的进展如何？](/current-trends-ai-design-in-interface-design/)，建议优先阅读新版。
# 篇首语
今年年初 AI 浪潮席卷了整个科技互联网领域，从海外的 UIZard 到国内的即时设计、MasterGo，大家都在不断尝试探索新的模式将 AI 与 UI 界面进行结合。我也一直都在密切关注着它对设计行业所带来的变化，特别是在界面设计领域。
时间一转眼已经到了 9 月，尽管前面提到的这几家公司在文生 UI 领域都投入了大量的资源和精力，也获得了一些初步的成果，但就目前的结果来看AI 在界面设计方面依旧处于一个比较初级的阶段。与此同时大家可能也会发现，这几家公司对这方面的发声也在慢慢变少，整个领域似乎进入了一个相对沉寂的时期，这股热潮似乎在默默的消退。
上周与一位老同事喝咖啡，一起深入探讨了一下当前 AI 设计的能力进展、现实中客户的真实需求以及未来的发展趋势。回来后我又重新整理了一下思路，想在这篇文章中，与大家分享一些我对当前AI 界面设计的思考和想法。
# UI 界面设计的复杂性
与创意设计领域中Stable Diffusion、MidJourney 飞速进化相比，AI 在 UI 界面设计上的能力进展显然是缓慢的。
创意设计侧重于高概念的构思发散，而界面设计则是深入到具象的业务实现。这也就意味着从产品逻辑到交互模式，都是需要基于深入的用户洞察和对业务逻辑的细致理解。
这种差异化和复杂性为 AI 在界面设计方面的发展带来了巨大的挑战，迫使我们需要做更多深入的研究和基础建设才有可能获得实质性的进步。这里我们可以展开细说一下：
**01. 业务导向的多维度设计**
UI 界面不仅仅是产品功能的呈现，它还更需要综合用户需求、数据反馈来进行设计从而向达成业务目标前进。
这也就意味着在设计的过程中我们不仅需要关注产品的界面美观和使用体验，还需要考虑如何结合这些背景信息来进行产品的设计。这就让设计变得不那么“纯粹”，也没有足够明确的规律可遵循，更多的依赖于人的判断。
**02. 复杂的设计目的性**
相较于创意设计，UI 界面设计的目的性会复杂得多。每一个界面都可能需要满足用户不同场景下的多个诉求。
例如，一个电商平台的商品列表页不仅要向用户直观地展示具有吸引力的商品，还需要向用户提供商品的筛选 & 比价、加购 & 凑单以及平台的功能导航等不同场景下的用户使用路径，而这些功能在不同的状态下可能还会存在不同的逻辑。
这些需求的层层叠加会让产品的界面设计变得异常复杂，这就要求设计师在界面的布局和功能分配上进行精细的权衡，确保用户在不同的场景下都能快速找到自己需要的功能模块并完成后续的操作。
**03. 通用与特定的设计标准**
就像之前在设计系统的话题中我们一直讨论的，不同的行业和具体的业务中，都会存在其特有的设计需求和习惯。比如金融类产品中需要强调正式感和安全性，而社交娱乐型产品则更关注轻松、互动性的交互氛围。
系统级的设计系统为我们提供了普适性的界面设计原则和交互标准，但它无法为特定的业务提供具象的设计指引，更别说体现产品的品牌特性和“人设”了。这也就要求设计师针对于特定的行业、用户进行深入的研究，定义出符合业务的品牌特性。
**04. 持续迭代的设计过程**
产品的界面设计并不是一次性任务。它需要随着技术的进步、用户需求的变化以及市场环境的演变，来进行界面设计的不断优化和更新。这不仅仅是为了提供更好的产品使用体验，也是为了适应业务的发展和变化，确保产品始终保持竞争力。
由此可见，UI 界面设计是一个复杂且多维度的设计过程，涉及范围大、业务耦合度高，AI 想要在这个领域中真正的占有一席之地是还是非常难的。
过去的时间里，我们对 UI 界面设计的 AI 能力聊得还比较“宏观”，围绕着 AI 的潜在能力和可能性上。这其中的能力层次以及具体的困难，实际上大家探讨得都不多。今天借这个机会，正好也和大家聊聊我自己的理解。
## 产品设计的难度层级
如果将一个产品从设计工作的视角进行“解构”，我们大概可以将其拆解成组件、模块、页面、流程、功能及应用六个难度层级。
- **应用：**代表整个产品或软件，涵盖了一个业务单元中所有的功能和特性，也是产品体验的总体框架；
- **功能：**产品的核心功能，它是产品为用户提供的主要价值点，影响了产品的主要用途和目标用户群体；
- **流程：**用户为完成某项特定任务时的产品互动路径，流程设计的优劣很大程度上影响了用户的操作体验，决定了用户完成任务的效率和对产品的满意度；
- **页面**：产品功能的具体界面或视图，是用户号与产品互动的主要场景，它的设计将直接影响到用户的具体感知和体验；
- **模块**：页面中的特定区块或组合组件，在设计过程中会被大量的重复使用；
- **组件**：页面构成的基础元素，如输入框、按钮、文本、富媒体等，是构件页面体验的最小基础单元。
在现实的工作场景中，它们的设计难度是由左至右依次递增的。即便是不考虑业务属性叠加的情况下，想要很好地完成这些层级的设计，对 AI 来说也依旧有很大的挑战。
在「应用」这一层级上，当前 AI 的能力显然并不具备可行性，所以在接下来的讨论中，我们会暂时忽略它，将重点关注从组件到功能的这五个层级中。
## 功能 vs 组件，两个极端
撇开**应用**不聊，**功能**和**组件**是整个难度层级中的两个“极端”。
功能的设计需要将用户需求、业务目标进行整体思考。它不仅仅页面、流程的组合，还需要关注它们的可用性、逻辑性，确保产品的使用体验能够满足用户的实际需求。
相比之下，组件的设计更加具体和微观。它关注的是单一的组件或部分，比如一个具体动作的交互形式、风格色彩、甚至是一个 icon、一句文案。这些元素虽然在设计中起到了基础的作用，但它们本身并不涉及过多复杂的逻辑，并且在互联网的长期发展中已经形成了基础标准。
这也是为什么在基于组件的模块和简单界面设计上 AI 的应用效果尚可的原因。通过对大量物料的学习和专家经验的植入，AI 可以快速的生成大量各种风格的模块和界面。
但一旦涉及到具体的产品功能或流程，AI 则需要更多的上下文背景、行业知识以及更为深入的用户和业务洞察。以当前的情况来看，想要很好的实现这部分需求，在能力上还是有一定差距的。
## 流程和页面：AI 设计的“中间层”
在功能和组件之间，我们还有非常“硬核”的两个部分，即流程和页面。页面是用户与产品进行交互的主要界面，而流程则是用户完成某个任务所需要的界面的集合，并且还具有更为复杂的业务逻辑。
流程设计关注的是用户如何通过不同的步骤或操作来完成特定的任务。这需要对用户的需求、行为模式以及可能遇到的障碍有深入的了解。
例如，一个购物网站的购买链路会包含选择商品、添加购物车、选择地址、选择支付方式等一系列的步骤。这其中的每一个环节都需要尽可能的考虑到用户操作的易用性和对促进购买的引导，已达成提升购买转化率的目的。
页面设计则更加具体，它关注的是如何将各种元素和组件组合在一起，形成一个统一且和谐的界面。这包括了页面的布局、模块和交互形式的选择以及色彩的搭配、文字的排版等工作，为用户提供一个预约的使用体验。
在现实工作中，流程和页面的设计是绝大部分设计师都具备的能力，它需要设计师对于业务、数据、用户的理解。但对于目前的 AI 能力而言，即没有这些信息的输入，也没有足够的理解能力，这些依旧属于难以达成的“极端”。
# AI 的当前能力与用户的真实需求
随着技术的进步和市场的不断“炒作”，AI 被快速地推向了实践、落地。然而这种现象并没有给这个行业带来太多积极、正向的影响，反而进一步加剧设计师工作环境的变坏，同时也让很多人对 AI 的能力开始产生质疑。
### 企业对 AI 设计的期望
在当下的经济环境中，大多数企业都在想方设法尽可能的降本提效。而 AI 作为当前最大的热点和风口，势必会被很多的企业的管理者所关注，将它看作是解决设计成本投入的一个很好方法。
但是在目前，最让人担忧的其实并不是 AI 本身对设计师所带来的冲击，反而是很多管理者对 AI 能力的认知偏差从而导致对团队带来的一系列负面影响。事情没弄成，反而把团队、业务搅得一团糟。
最近的这段时间里与一些企业的管理者有过一些交流，他们大多数来自产品、市场或技术领域，对设计其实都并不太了解。
大家似乎都有着一个共同的观点，认为 AI 设计可以帮助他们至少在部分场景中直接替代掉设计师，有的甚至已经开始用一些 AI 产品来替代设计师，但最终发现事实和他们所预想的并不太一样。他们并不了解的是，AI 在设计领域的应用和发展，其实还处在一个比较初级的阶段。
顺带聊两句，虽然这些企业都有自己的设计团队，但他们几乎都没有从自己团队中获取到对设计行业及其发展的了解，所以也只能按照自己的理解和工具平台的介绍来自己做决定了。设计师们则被自然而然的当做了“工具人”，当更合适的工具出现时，他们就可能成为牺牲品被淘汰掉了。
在国内的环境中设计一直都是一个相对位置边缘一些的岗位角色，设计的价值很容易被公司和管理者所忽略，这个问题其实无论是在小公司还是大厂都一样。所以，如果不想自己不明不白的轻易地被取代，就需要设计团队 Leader 或设计师自己多一些给公司管理者的“布道”。不要有过多的顾虑，机会还是只能得靠自己争取来。
再回到我们的话题里来。对于企业而言，他们的期望的是通过 AI 能够帮助完成大部分的设计工作，可以将更多的资源投入到产品的研发和市场推广中。但事实上以 AI 现有的能力，它最多只能覆盖组件、模块和部分页面的工作，如果再考虑到叠加上业务自有的特性，这个效果可能难以满足要求。
真实的业务场景，设计师的工作与业务信息和数据高度关联，而几乎现有所有的平台型 AI 设计产品在这方面都还是“孤岛”。现有的平台型 AI 能力只能基于自有的数据进行训练和生成。这也是为什么我们现在能得到的生成结果如此“飞机稿”的原因，而飞机稿显然是无法直接参与到业务生产中的。
### 设计师对 AI 设计的期望
相较于企业对 AI 的期望，作为设计师大家还是会务实得多。和很多设计师探讨过这个问题，大家并不期望 AI替代自己的工作，而是希望 AI 能够成为他们的得力助手，在设计的过程中打辅助，帮助他们更高效地完成设计工作。
例如，设计师们希望 AI 能够帮助快速填充内容，这样他们就不必花时间来找寻文案或图片进行手动输入；希望 AI 能够自动生成界面的基本框架和模块，这样他们可以更专注于业务逻辑的还原和体验的优化，不必像我们在前面文章中聊到的那样面对「空白页综合症」。
还有在具体功能设计过程中提供可参考的Check list， 以及类似 MasterGo 已经在内测中的组件检查功能，以此来确保设计的完整性和一致性，减少设计过程中的错误发生。
图片来源：[https://mastergo.com/blog/ai-beta-test](https://mastergo.com/blog/80?MasterGo%20AI%20%E5%86%85%E6%B5%8B%E8%BF%9B%E8%A1%8C%E6%97%B6%EF%BC%81%E5%88%86%E4%BA%AB%E4%B8%80%E6%B3%A2%20TA%20%E4%BB%AC%E7%9A%84%E4%BD%BF%E7%94%A8%E6%84%9F%E5%8F%97%EF%BC%81)
总的来说，设计师对 AI 设计的期望更多地体现在如何提高工作效率上，而不是完全依赖 AI 来直接生成。同时大家也期望在设计的过程中 AI 能够提供一些辅助功能，为设计的交付提供一些有效的基础保障。
# **AI 设计的双向发展路径**
虽然前面我们说了这么多 AI 设计当前的问题，以及 AI 在设计辅助上的价值。但在我仍然相信在生成式的这条路上依旧充满了非常多的可能性。但如何选择其路径，还需要我们更为细致的探索和分析。
我们还是回到前面的产品设计中的难度层级，如果以「页面」作为中心点，我们会有两条完全不同的发展方向：
这条路径不仅仅是简单地生成界面，更多的还需要将业务的核心逻辑和思路准确的还原出来。所以，小到一个业务组件，大到一系列的交互模式在这里都需要能足够的明确。
由于涉及到企业的信息和数据，这类 AI 能力通常需要进行私有化部署，以达成与业务生产环节的真正融合。当然，以现在的平台能力而言，具备私有化部署的能力还为时过早，大概率还是企业内部自建会更早的出现。
在这条路径下，企业中的设计师将会成为这个 AI 能力最为重要的产品设计者。参与其中的设计师的定位和职责也会发生一些变化。
首先，设计师需要参与到策略的制定中，确定哪些部分应该由 AI 进行完成，哪些需要人工的介入。确保 AI 的应用能够真正为企业带来价值，而不是简单的替代人工投入。
其次，设计师需要成为训练师参与到 AI 的模型建设中。对业务规则和行业特性进行抽象，为业务 AI 能力的训练提供基础的数据支撑。与此同时，设计师还需要进一步将业务级的设计系统进行 AI 化，为界面的 AI 生成提供明确的设计约束。
在这个场景中，AI 设计的能力是不会孤立存在的，大概率会类似于 Salesforce 一样融入到业务生产的环境中。所以，设计师还需要兼顾一定的产品经理的工作，从产品的视角将 AI 设计工具融入到企业内部的工作流中。
# 写在最后
随着技术的发展与进步，AI 能力一定会逐步达成我们所期望的样子。无论是平台型 AI 设计还是定制型 AI 设计，它们都将成为领域中不可获取的一部分。如今我们所面临的大环境，只不过是加速了这一变化。
但同时我们也需要坚信的是，AI 并不能简单的取代设计师，而是在提高设计师门槛的同时成为我们的伙伴，协助我们更高效的完成设计工作。而设计师的角色和定位也会在这个过程中随之发生变化，从过往的设计实现转变为真正的产品设计者、AI 训练师、策略制定者。
在这个快速变化的时代，变化本身并不可怕。可怕的是在变化的过程中还在原地不动，错失了与时俱进的机会。
2023.09.04 杭州
================================================================
# 设计系统在 PPT 领域的应用
- **发布日期**：2022-12-16
- **原文链接**：https://www.thefivekey.com/design-system-in-ppt/
- **Markdown 原文**：https://www.thefivekey.com/design-system-in-ppt/index.md
- **标签**：设计系统, PPT
> 设计系统不是 toB/中后台的专利。本文通过 iA Presenter、Paste 等 PPT 新工具，展示设计系统理念如何在 PPT 这个"古典"工具领域带来革新：从自由排版走向结构化约束，让 PPT 制作从画图变成组织信息。
> **TL;DR**
>
> 设计系统不只是 toB/中后台的专利。
>
> iA Presenter、Paste 等新一代 PPT 工具正在用"设计系统"的理念改造这个领域：用结构化约束代替自由画布，让用户专注于信息组织而不是视觉细节。
>
> 本文拆解这些工具的设计思路，以及设计系统理念在非 toB 领域的更多可能。
设计系统 一直以来应用最多的领域还是在 toB 端，让很多人误认为[设计系统](/tags/design-system/) = 中后台设计。我们之前聊到过，设计系统实际上是对设计的抽象和约束，toB 端只是因为其场景在当下更容易达成一致，但不代表只有它可以做到。其他的领域只要能对规则进行抽象和定义，设计系统同样是成立的。
最近一直在关注 PPT 工具领域，试用了一些新理念的产品，比如 [iA Presenter](https://ia.net/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，也就是自由式设计和结构化设计。
PhotoShop、Sketch 以及PPT 制作工具 PowerPoint、Keynote 本质上都属于自由式设计。它们都是给用户一张画布和一系列的元素，在画布上拖拽排放、调整样式来完成最终的设计。
自由式设计的优势就在于“自由”，用户可以随心所欲的发挥创造力创建自己独特的设计。这些年因为做汇报太多，深入研究了下 Keynote。发现它真的是非常强大，用它来做设计做原型也没啥问题。
但也正式由于过于“自由”，普通用户想要用好这些工具还是有不小的学习成本。组织内容加上做好表达，想要做出一份出色的 PPT 确实不是一件容易的事情。
## PPT 制作需要解决什么问题？
还是先回到用户需求，做出一份好的 PPT 到底应该如何定义？我认为还是需要满足以下三条：
1. 内容信息好，值得大家聆听、学习
2. 表达逻辑好，便于大家查看、理解
3. 表现形式好，给予大家好的观感、体验
这里的第一条（内容信息）是一个 PPT 最基本也是最重要的部分，这是工具目前还无法解决的问题，还是依赖于作者对选题的思考、理解。当然，满足了第一条但表达逻辑和变现形式不佳，它依旧可能会成为一个糟糕的分享。而这里，就是目前工具可以给予一定帮助的地方了。
随着这几年技术和理念的进步，PPT 工具领域终于也被“盯”上，出现了一些新的“古典” PPT 工具的挑战者。它们主要有以下两个趋势：
### 01. 协同在线化
作为最常用的办公文档之一，PPT 其实是有很强协作需求的。几乎所有的团队目前合作写 PPT 还是文档传来传去，只要几个版本弄下来一定会出现很多的细碎问题，效率着实不高。
以前我们做汇报，大家都是将各自的内容截图到钉钉中，大家讨论反馈后再将最终源文件发给其他人，一次汇报做下来电脑里至少十几个 keynote 文档。
PPT 的协同中，无论是独立写还是合作写，最核心的问题其实就是评论反馈和实时更新两个点。而这两个点偏偏也是传统工具目前无法解决的问题，自然它们也就成为了 PPT 工具发展的新方向。
### 02.模板产品化
我们前面提到，PPT 的模板市场相当的丰富。但对于普通用户来说，有模板也不一定能用得好。模板只是设计师做好的一套结果产物，在 PowerPoint 和 Keynote 这些自由式设计工具中，如果不熟悉工具可能还是会弄得一团糟，拿模板改版反而更耗费时间。
如何让做好的模板让用户能够“无脑”使用，还能保证最终的效果呢？最好的办法还是将模板产品化进行一定的约束，让用户给予模板进行 PPT 的搭建。让用户做选择题和填空题而不是开放题，尽可能的避免买家秀和卖家秀的问题出现。
其实对于在线搭建来说，无论你要做的是网页、海报还是 PPT，对它来说都是同一个逻辑，只不过设计的基础规则和展示形式有所差异。相对于搭建网页，PPT 的结构和设计会相对简单一些，基于模板进行在线设计的操作难度也会更低。
## **设计系统 在 PPT 工具**中的应用
聊完 PPT 工具的背景信息和趋势，接下来给大家挑选两款新方向下的 PPT 工具和大家聊聊它们与设计系统的关联。
### iA Presenter
如果大家经常使用 Markdown 写东西，应该听说过 iA Writer。iA Presenter 是这家公司近期新推出的一款 PPT 工具。不懂设计的用户也能通过它轻松的做出一些还行的 PPT，比如下图中的这些示例。
iA Presenter 目前还处于测试阶段，感兴趣的同学可以在文章底部获取内测版下载链接。
严格意义上来说 iA Presenter 也不完全算 PPT 工具，打开应用的界面你会发现它居然是一个文档编辑器，以写文档的方式来写 PPT。
粗略一看你会觉得 Presenter 有些故弄玄虚，其实就是一款基于 Writer “升级”出来的新工具。简单来说就是 iA Writer + Theme = iA Presenter，结合主题对 Markdown 标签进行格式化来生成 PPT。
但仔细想想你会发现这款新产品的核心理念还是非常独到的。
> iA Presenter’s text interface puts the focus on the story, saving time and nerves.
>
> iA Presenter 让你将关注点放在故事上，节省你的时间和精力。
之前在「如何缓解写 PPT 的焦虑」一文中就提到过，**写 PPT 最核心的就是需要先写大纲，再拆分成每一页 slide 组织内容，**最后才是设计 PPT 或套用模板。
一份 PPT 文档的好坏首先是内容，其次才是设计。iA Presenter 这款产品是以 PPT 模板为基底，以结构化写作为切入点为用户提供写 PPT 的一个新的选择。
写作是 iA 的老本行这里就不聊了，我们重点来看看它的 PPT 能力。应用窗口的右侧是一个辅助面板，提供文字样式（markdown 标签）、素材库、样式配置三大功能板块。
简单的做一些全局配置后就可以将重点放在 PPT 内容的写作上了，结合对文本标签的使用，Presenter 就可以帮我们套用系统模板生成一个完整的 PPT 了。
目前的版本里模板能力比较简单，配置面板内只开放了字体选择和一些字段的开关。默认提供的十套模板也只是一些简单的配色调整。官方自定义主题文档里提供了 Slide 的 HTML 结构，配合对 Style 样式的调整，我们也可以按照喜好定义自己的 PPT 主题。
Presenter 对于模板还是比较克制的，页面的布局不多，主题可配置的空间也不大。究其根本还是希望用户“淡化” PPT 的设计，将精力回归到对内容的关注上。看上起似乎有些偏执，但到也符合 iA 这家公司的一贯理念。
### **Paste**
Paste 是一款在线的 PPT 工具，相较于 iA Presenter 它的产品形式大家会更为熟悉，主打在线协同和模板化。样式和排版已经做好了基础设定，用户可以调整的只有字号、颜色和布局，用户打开新页面关注内容部分就好。
一个基础的图文模块，Paste 提供了上下排布、左右排布、背景图 5 种模式。
Slide 页面提供了多列布局模式，最多可以支持 6 列排布。
相较于 iA Presenter，Paste 提供的模板能力会稍微丰富一点。从页面布局到模块排版再到文本样式，虽然还是比较简单，但 PPT 常见的模式基本都已经满足，做一份合格的 PPT够用了。
大家可能已经发现，iA Presenter 和 Paste 的主题模板虽然简单但也已经可以形成一套 mini 的设计系统了。但即使它很简单，在将其产品化之后价值确实非常明显的。
## **PPT 的 mini 设计系统**
之所以将它称为 mini 设计系统，是因为相较于传统的产品界面设计，PPT 的模式、交互还是会简单很多，最核心的就是栅格、布局、字体和色彩。
PPT 的栅格体系其实很早就有被提出过，但并不像产品界面一样达成了大家公认的标准。不过大部分的 PPT 都是基于 1920 的尺寸设计的，所以我还是倾向延续在 web 端的思路使用 12 栅格体系。
接着按照我们在 Web 界面上布局的方式，我们很容易就能实现出 PPT 中常用的排版布局。
PPT 的页面排版没有特别复杂，我们很容易就能将常用的一些布局穷举出来。
栅格的具体数据这里就不标注了，源文件我附在文章底部，感兴趣的同学可以下载查看。
有了这些布局，再结合上文字排版、色彩的定义，我们就能够将它们制定成具体的规则进行产品化。用户只需要选择模板、填入内容也可以制作出和设计师一样美观的 PPT 了。
## **尾声**
类似的 PPT 工具还有很多，但无论主打什么特性，大家在 PPT 页面的设计上都倾向使用主题模板，以此来降低用户在制作上的精力消耗。不过目前这些模板的都还比较基础，都只是做到了“还行”的程度。
在线设计（或在线搭建）的能力如今其实已经非常成熟了，复杂的 toB 端页面或前台营销都可以搞定，PPT 这个场景自然也完全没有问题。
虽然 PPT 的最为重要的是内容和表达逻辑，但设计依旧是大家非常关注的问题，目前的这些“产品化”模板还无法满足大家复杂的 PPT 诉求。想要丰富主题模板，一套完整、可拓展的 PPT Design System 非常的有必要。
大家如果有兴趣，不妨可以来尝试思考一下，给自己制定一套。我自己也在考虑明年发布一套 PPT 的 Design System，欢迎大家来一起交流。😊
> 💡 延伸阅读：
> - 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
> - 基础视角：[设计系统 · 我们为什么要做 Design System](/why-we-need-design-system/)
> - 学习路径：[设计系统学习指南 - 国内外 Design System 案例解析](/how-to-learn-from-other-design-systems/)
> - 深度案例：[如何规划 B端 设计系统？深度解析 AWS CloudScape](/b-end-design-system-deep-dive-aws-cloudscape/)
================================================================
# 体验设计师 未来三年应该如何发展？
- **发布日期**：2022-10-02
- **原文链接**：https://www.thefivekey.com/ux-designers-in-the-next-three-years/
- **Markdown 原文**：https://www.thefivekey.com/ux-designers-in-the-next-three-years/index.md
- **标签**：职业发展, 求职面试
> 体验设计师的职业路径在未来三年会怎么走？从美工到 UX 再到架构型设计师，设计师岗位一直在演变。本文从阿里的岗位演化经验出发，预测未来三年体验设计师的两个发展方向：架构型设计师与产品设计师，并拆解各自需要的核心能力。
> **TL;DR**
>
> 体验设计师的未来三年，岗位会继续分化：一条路走向"架构型设计师"（构建设计系统、资产管理、设计运营），另一条路走向"产品设计师"（深入业务、参与决策、从交付到创造）。
>
> 继续做通用 UX 是最危险的位置，因为它正是最容易被 AI 和产品经理上下夹击的中间层。
体验设计师 , 突然这个角色在互联网行业似乎已经存在很久了。我从 03 年毕业工作至今，有幸经历了从“美工”到设计师的整个历程。时至今日，这个职能已经逐步被行业、被公司所认可，职能和领域也在不断演变。
15 年左右，我们在阿里开始逐步进行对设计师岗位的优化，从原有的交互 & 视觉调整为体验设计 & 创意设计。
## 体验设计师岗位的变迁
19 年开始组建集团的设计中台团队后，设计系统一直是我们非常重要的一项能力。在与各业务设计团队的合作中我发现设计团队的工作模式在发生变化，从以往的划分业务接需求，向通过设计系统的“架构设计”进行演变。
经过这几年的不断磨合，设计系统已经成为很多设计团队最为重要的核心能力之一。
在这个阶段中团队中也逐步出现了一些新的工作要求，负责设计系统的构建及推广应用，**我将它成为「架构型设计师」。这也是我认为接下来几年体验设计师发展的一个非常重要的方向。**
既然有了明确的岗位，我们就需要明确它的工作职责。结合这些年在阿里的实践，我会将其定义为以下三个方面：
## 架构型设计师的职责
### **01. 构建设计系统**
在当下，架构型设计师的首要职责就是构建业务级设计系统。为业务提供明确的设计约束和指引，帮助团队快速实现业务逻辑，减少不必要的浪费。
这里的设计系统绝对不是做一套风格样式输出 UI Kit，也不是基于 Ant Design 这类的开源系统复制一遍。而是需要真正基于所属领域和业务的特性去解决实际问题，例如在之前[**介绍 CloudScape Design System 的文章**](https://xiaobot.net/p/offdesign/posts/2177379497287028736)中所提到的那些 Pattern。
### **02. 设计资产管理与维护**
前面一直和大家提过「齐套」的概念，而它也是架构型设计师非常重要的一项工作。
新的协作模式下，支撑业务的设计师需要基于业务设计系统去实现一个个具体的需求，那么在开始工作之前想过的组件、模板、素材、icon 甚至是文案都应该是准确无误的。
### **03. 设计运营**
在阿里，我们有业务通过设计系统的运作获得了 30% 多的整体提效。但这个结果不仅仅是靠一套好的设计系统，还需要在流程、工具上做大量的工作和运营。
除了设计系统和资产的管理，架构型设计师还需要向外去衔接设计的上下游，去不断优化整体的工作流程来帮助设计系统能真正的落实到底、发挥出有效价值。
随着互联网红利的消退以及经济形式带来对企业降本提效的要求，互联网企业以及设计团队都将面临对生产模式、工作流程的进一步优化。
设计系统已经逐步成为各大互联网设计团队的重点投入方向，**我的判断是在未来三年，架构型设计师一定会成为设计团队中最为重要岗位职责之一**。关于这个话题的更多讨论，大家可以阅读之前的文章「[成为架构型设计师](/become-an-architectural-designer/)」。
> 💡 延伸阅读：
> - 职业瓶颈真实案例：[做了 5 年互动设计，我遇到了设计师职业发展天花板](/five-years-later-i-encountered-a-career-ceiling/)
> - 宏观环境分析：[这两年设计师找工作是不是越来越难了？](/designers-employment-development/)
> - 新人入职阶段：[入职新公司，学会问问题才能少踩坑](/ask-questions-when-starting-new-job/)
> 本文出自专栏 **[OFF DESIGN](https://xiaobot.net/p/offdesign)** 免费内容
================================================================
# 从 Adobe 收购 Figma 的背后看设计协同
- **发布日期**：2022-09-19
- **原文链接**：https://www.thefivekey.com/adobe-acquisition-of-figma/
- **Markdown 原文**：https://www.thefivekey.com/adobe-acquisition-of-figma/index.md
- **标签**：设计协同
> Adobe 200 亿美元收购 Figma 背后，是设计协同时代的来临。本文从这次收购事件切入，分析 Adobe 与 Figma 的竞合关系、国内设计协同工具的真实处境、以及 Figma 未来的演化方向，为设计团队选择协同工具提供决策参考。
> **TL;DR**
>
> Adobe 200 亿美元收购 Figma 不是一次简单的 M&A，而是设计协同时代正式到来的信号。
>
> Figma 用协同打赢了 Adobe 的单机工具阵营，Adobe 只能"买下来"。
>
> 本文从这次事件切入，聊设计协同的本质、国内设计协同工具的真实处境（不如预期美好），以及 Figma 未来会走向什么方向。
这期的话题本来已经写得差不多了，但突然看到了 Adobe 斥巨资收购 [Figma](/tags/figma/) 的消息，事儿很突然，但也确实不太意外。这几年在集团内部做设计协同类的产品，和 Adobe 也打了很长一段时间的交道，看到这个这个消息还是有些感触。所以临时改变主意，和大家和聊聊关于设计协同的一些想法。
## Adobe 为什么一定要收购 Figma：干不掉就买下来
[Adobe 历史上收购过很多产品](https://en.wikipedia.org/wiki/List_of_acquisitions_by_Adobe)，上一宗大家比较熟悉的 case 就是在 2005 年以 35 亿美元收购了当年火极一时的 Macromedia，这里面有很多我们熟悉的软件，比如网页三剑客 Dreamweaver、Flash、Fireworks，只不过很可惜，在被 [Adobe](https://www.thefivekey.com/tag/adobe/) 收购后这些产品最后也都陆续被关停掉了。
这次 200 亿美元（现金+股票）收购 [Figma](https://www.thefivekey.com/tag/figma/) 的消息公布后，市场出现了非常强烈的反应。Adobe 股票立马就暴跌了 16 个多点，差不多蒸发了 1 个半 [Figma](https://www.thefivekey.com/tag/figma/)，这也是 Adobe 近十多年在股市上最惨烈的一天。
按照 Adobe 新闻稿的披露，[Figma](https://www.thefivekey.com/tag/figma/) 的 2022 年的ARR（年度经常性收入）预估为 4 亿美元，只占 Adobe ARR（140 亿美元）2.8%，而 [Adobe](https://www.thefivekey.com/tag/adobe/) 为此次收购却所付出了相当于其市值约 10% 的费用。**显然 Adobe 的决策层是非常看重它的，又或者说是已经被完全的逼急了。**
按照 Adobe 9 月公布的财报来看，目前公司所持有的现金也就差不多 60 亿美元。想要在 2023 年完成整体的收购，看样子 Adobe 后续得要得要做不少动作去找钱了。
## 从阿里与 Adobe 合作中看到的设计协同真相
2019 年初，因为设计中台的业务我们开始和 Adobe 有了一些沟通并尝试一些合作。当时的 Adobe 目的非常明确，就是希望借 XD 的免费和多平台与各大专业群体合作，来抢回一些被 Sketch 占领的市场，特别是它们这么多年心心念念但又久攻不下的中国市场。
也是在这一年，陪同老板去一趟美国参加 Adobe MAX 设计大会，拜访了一些 Adobe 的高层的同时也和 Adobe 的很多软件团队做了一些沟通，寻找合作的机会。
整个行程下来，给我的一个感觉就是这家公司当时最关注的还是软件的自身能力，协同并非重点。要做协同那也只是 Adobe 全家桶软件之间的协同。比如如何让 Substance 生成的 3D 模型快速导入到 AI 中继续工作。
**但设计协同究竟是设计师与设计师的协同，还是设计师与上下游角色的协同？很快 Figma 就和 Sketch 一起给了 Adobe 一个答案。**
这个时候的 Figma 刚刚发布了社区功能，内容的丰富也使得越来越多的设计师和工程师群体进一步开始看到更多的优秀案例和可能性，从而开始进一步尝试。而此时的 Adobe，还在拼命的投入资源推广 XD 与 Sketch 抢占市场。
而作为一个典型的 B 端大客户，此时的阿里还处于一个比较复杂的情况。体验设计师使用 Sketch，产品经理使用 Axure，创意设计师还是深度依赖 Adobe 家族产品。虽然也有一些团队想要尝试，但由于公司对数据安全的高度要求，短时间基本上没有任何可行性。
所以设计中台这个部门非常重要的工作之一，就是通过自建产品能力来衔接不同工具为不同角色提供设计协同上的支持。与 Adobe 的合作则因为“绕不开”的 XD 难有比较显著的进展。
从 PhotoShop 到 Sketch，再从 Sketch 到 Figma，表面上看是设计群体生产工具的迁移，但究其根本其实是背后需求和环境的变化。
早期平面时代 Adobe 以其强大的专业工具能力统治这个市场十多年，但同时也变得越来越臃肿、难用。Sketch 的兴起是源于数字产品 UI 设计需求的爆发，也是广大用户群体诟病多年的“反抗”。
一个新兴产品的快速崛起背后大多数时候都伴随着一个老牌产品在这个专业领域的失势。Adobe 关停 Fireworks 后，Adobe 在产品 UI 设计领域并没有太好的应对产品。PhotoShop 用起来不顺手，XD 的进展又太慢，等到发布的时候这个市场基本上已被 Sketch 给占据。
而也就是这个时候，我们身边的环境也在逐步发生变化。疫情对远程办公的影响、业务竞争对迭产品迭代速度的诉求、经济环境对效率的诉求，都让「协同」变得越来越重要。
对于协同，Sketch 和 Figma 显然有着不同的想法。Sketch 关注的设计师之间的协同，其他的相关角色的需求不是其重点关注的方向。于是这里就留出了一片空间，出现了类似 inVision、蓝湖之类的产品辅助 Sketch 来衔接其他的角色和场景。不过国内的场景比较特殊，由于多方面原因这类产品很难真正的打入那些大型互联网公司，同时也催生了大厂的自研而走出了另一条完全不一样的路。
回头再看 Figma，从一开始就认定协作是面向产品研发链路上的所有相关角色，而并非仅仅是设计师。加上近些年浏览器及相关技术的快速发展，打破专业工具对「客户端」的依赖，使其在当下背景下会更好的贴合「协作」需求。赢得用户和资本市场的青睐。
从 2021 年 100 亿美金的估值，再到今天 200 亿美元被收购。Adobe 一定不是想不清楚，而是等不及了，担心它继续发展下去。还没赶上 Sketch 却又迎来了新的挑战。**干不掉对手，那就干脆买下它吧。**
## 国内"Figma 们"的另一番景象：设计协同工具的真实处境
相较于海外市场，国内的情况则要复杂得多，这里我们把设计协同平台（如 inVision、蓝湖）和在线协同设计工具（Figma）放一起，姑且统称设计协同。
我们先来看看这几年国内的环境发生的一些变化：
- 19 年至今的疫情，催化了协同办公的加速发展，远程办公已逐渐被大家所接受；
- 经济环境的持续影响，各大企业开始缩减开支，降本提效成为企业发展重要战略之一；
- 中美局势和 Figma 大疆事件加速了国家对软件自主的要求，信创成为国家和各大互联网公司关注的重点。
根据福布斯的数据统计，全球有2,000 万 UI 设计师，而在中国就有 300 万，如果我们再把与设计相关的产品群体包含进来，所联动起来的用户还要再增加 5 倍。
有市场需求、有政策影响、再加上成功案例，这个体量足以支撑一个资本竞相追逐的市场，所以大家会发现这两年也就会不断听到资本进入的消息了。不过，国内的市场环境如果只是这样似乎就有些太简单了。
Figma 的走红使得资本市场催生了一波“模仿” 的独角兽，如 MasterGo、即时设计、Pixso，而国内互联网公司行事风格则又催生了一波大厂自研的设计协同平台，比如腾讯的 CoDesign、京东的 Relaaay以及我在阿里负责的设计中台。至于字节，目前虽并未有明确的产品发布，但从多方信息来看这一块它们势必是要做的，只不过以什么样的产品形态出现还不得而知。
回过头再来看这几家公司，它们都有自己的云服务业务。阿里、腾讯一直占据市场份额的前两位，字节的火山引擎也在开始快速追赶。而腾讯则是在去年年底第一个向市场推出了细分场景的腾讯设计云。
头部互联网公司的入局，让整个市场变得复杂起来，不过他们的出发点和国内的这些独角兽并不太一样。
起初这些产品的出现，纯粹是为了补全 Sketch 场景下与上下游相关协作。但越往下做你会发现的需求越多，需要投入的人力也越来越多。在阿里我仅仅是对集团内对服务，产设研就投入了大几十号人，腾讯在发布腾讯云之前也有上百人团队的投入。
大厂，人贵。自研是高度满足了适应企业内部个性化需求，但它却很难满足公司的财务要求。国内这两年用户付费的习惯虽然有所改变，但要想达到它的付费规模还是有难度的。反而是这两年 toB 业务的发展，整合自研产品提供整体 SaaS 化解决方案售卖反而是个更好的选择。
## 设计协同真的那么美好吗：理想与现实
聊了这么多的市场和环境，我们还是得回到用户这边，看看真实的场景里在发生着什么。
首先，大家都知道设计师的职业环境和话语权与海外还是有所差异的。在国内设计这个职能更偏向于执行，这么多年各大厂的设计 VP 屈指可数，设计出身的业务大佬也寥寥无几，所以单看设计师协同它从来不是公司关注的重点。
Figma 对设计上下游协作的定位在国内对，但也不全对。一个业务需求的生命周期不仅仅只有这一段，往前有业务需求的管理，往后有研发、发布、测试、数据等很多环节的管理。这部分内容大部分大厂都会早已完成自研，而不是向海外的企业集成多家产品服务。
大量自研系统带来的一个问题就是外部采买的产品很难融入到整条业务生产链路中，你想让蓝湖针对性的进行定制？为了拿下几个大厂的案例它也许会乐意，但真正实施起来它就会被拖死。所以这也就是为什么腾讯、阿里、字节会选择自研，也只有这几家具备相当体量设计师的公司具备自研的条件之一。
在阿里做设计中台的这几年，发现一个比较尴尬的现状。我们可以做的东西有很多，但它们更多还是在设计域自己的环节里，真正能显著作用于业务的比较少。业务方作为付钱的甲方，很难去关心作为支持部门的效能该如何提升。
当然，这里也有例外。设计系统（结合在线设计）就是少数几个业务方看得明白也感知得到的产品能力，因为它能让业务直接感知到研发周期的改变。这也是为什么最后一年我们以设计系统为核心去给 Boss 和 CTO 做提案的原因。
## Figma 的未来：被 Adobe 收购后会走向何方
前面说了很多，似乎都有些“悲观” ，实际上对于设计协同的未来我还是非常看好的。无论怎样，时代已经将它们推入到了大家关注的焦点中。
**如果我的判断没错，未来的 2 到 3 年内国内设计协同领域的市场格局会逐步稳定，赢家应该会出现在阿里、字节和腾讯之中。**
互联网头部企业如阿里、腾讯、字节、美团、京东、华为等都会主推自研，服务自己的同时也对外开发为其他大型企业提供整体服务，从蒙牛、伊利之类的传统企业到理想、小鹏之类的新兴产业都将成为他们服务的对象。
而如今的独角兽会将服务对象调整为更小量级的中小型企业，同时继续通过免费加服务抢占 C 端用户市场以提升自身估值，在合适的时机将自己卖给阿里、字节或腾讯，缔造设计领域的另一个”神话“。
当然，这些仅仅只是获得了资本市场的胜利。设计协同或者设计提效不仅仅依赖强有力的工具，还需要更多流程、制度和资产才能发挥其真正的价值，这也将是未来设计团队最为需要关注的部分，也是一个团队能力最为重要的体现。
> 💡 延伸阅读：
> - 自建协作工具的决策框架：[要不要自己开发一个设计协作工具？](/design-collaboration-for-team/)
> - 设计系统与协同的关系：[设计系统 · 我们为什么要做 Design System](/why-we-need-design-system/)
> - 架构型设计师的角色：[成为架构型设计师](/become-an-architectural-designer/)
================================================================
# 设计模式库与设计组件库到底有什么区别？
- **发布日期**：2022-07-14
- **原文链接**：https://www.thefivekey.com/difference-between-design-pattern-and-design-component/
- **Markdown 原文**：https://www.thefivekey.com/difference-between-design-pattern-and-design-component/index.md
- **标签**：设计系统, 设计模式, 职业发展, 体验设计
> 设计组件库（Components）和设计模式库（Patterns）的区别是设计系统里最容易被混淆的概念。用小龙虾 SOP 做类比，本文讲清楚：组件是 SOP 中的单个步骤，模式是把这些步骤组合起来解决完整任务的方案。
> **TL;DR**
>
> 设计组件库（Components）像做菜的单个步骤（切菜、焯水、炒制），是解决单点操作的工具；设计模式库（Patterns）则是把这些步骤组合起来完成"做一道小龙虾"的完整方案。
>
> 组件提供基础能力，模式提供业务解法，两者缺一不可。
设计系统 （Design System）中有两个重要的概念，设计系统和设计模式。对于这两者之间的区别，很多人都比较困惑。**其实用一个例子就能很好的解释，比如大家都喜爱的小龙虾 🦞。**
## 用一个例子来解释
小龙虾好吃，但真做起来并不是所有人都会。不过你可以在各类美食应用上看到它的「制作 SOP」，大致会有以下这些步骤
## 制作小龙虾 SOP：
- 去虾线
- 清洗小龙虾
- 准备小料
- 下龙虾过油
- 加入小龙虾调料翻炒
- 加入啤酒闷煮
- .…
你不一定懂小龙虾的制作方法，但刷个小龙虾一听就能明白，把这些步骤组合在一起，你也能做出一盘色香味俱全的小龙虾了。
## 设计系统 中的 SOP：
在[设计系统](https://www.thefivekey.com/tag/design-system/)中，每个组件就像 SOP 中的某个步骤，是解决某一个具体操作的方法，而将这些组件组合起来处理一件事情或任务，就是我们所理解的 Pattern 模式库。
所以，洗小龙虾、过油它们都是“组件”，做小龙虾是“模式”。
如果十三香小龙虾已经成为一个行业标准，大家做得基本完全一个样，那么小龙虾也可以被进一步的收敛，成为你做晚餐的一个标准“组件”了。
当然，如果你家的小龙虾和别人有些差异，比如重甜、重辣、或者说是三分熟（😁），那它的做法就具备较强的特色，成为你的业务级设计模式了。
## 设计系统 延展阅读
- 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
- [设计系统 · 我们为什么要做 Design System](https://www.thefivekey.com/why-we-need-design-system/)
- [设计系统 · 这么多 Design System，我们应该怎样去学习？](https://www.thefivekey.com/how-to-learn-from-other-design-systems/)
> 💡 延伸阅读：
> - 推行话术：[如何向你的主管和团队介绍 Design System 的重要性](/how-to-prove-the-value-of-design-system-to-your-boss/)
> - 深度案例：[如何规划 B端 设计系统？深度解析 AWS CloudScape](/b-end-design-system-deep-dive-aws-cloudscape/)
> - 学习路径：[设计系统学习指南 - 国内外 Design System 案例解析](/how-to-learn-from-other-design-systems/)
> - 决策机制：[设计系统中的决策树：让设计决策更简单](/design-system-decision-tree/)
================================================================
# 成为架构型设计师
- **发布日期**：2022-07-14
- **原文链接**：https://www.thefivekey.com/become-an-architectural-designer/
- **Markdown 原文**：https://www.thefivekey.com/become-an-architectural-designer/index.md
- **标签**：设计系统, 设计模式, 体验设计, 职业发展
> 架构型设计师是设计师在设计系统时代的新职业方向：他们不直接做界面，而是通过构建设计系统、管理设计资产、设计运营，让整个设计团队的产出更高效。本文系统介绍架构型设计师的职责、能力要求，以及如何从体验设计师转型为架构型设计师。
设计师 是我的第一份工作。从 2003 年毕业后的第一份工作在一家网络公司，从界面设计到 Flash 动画再到跑客户、贩卖 3721 网络实名，几乎和网络建站相关的工作全都得做，当然，那个时候对设计的要求并没有那么高，我们都被称之为美工。
一晃快 20 年过去了，伴随着中国互联网行业的高速发展越来越多优秀的人才进入到设计领域，设计已经成为一个非常有深度专业工种，设计师也已经成为互联网企业最为重要的专业力量之一。
上一期的文章里，我们在[设计系统](https://www.thefivekey.com/tag/design-system/)的话题中聊到通过「规范沉淀」「物料管理」「场景消费」三个方面来优化在产设研（产品、设计、研发）环节的工作模式，也提及了一个新的、也是非常重要的角色 – 架构型设计师。关于这个新的角色，上周分别与两位会员读者在设计团队能力建设的话题中也多次聊到。所以这一期我想正好顺着话题和大家聊聊什么是架构型设计师，以及如何成为架构型设计师。
> **TL;DR**
>
> 架构型设计师不直接画界面，而是通过构建设计系统、管理设计资产、推动设计运营，让整个团队的设计产出标准化、规模化。这是设计系统时代设计师最重要的新职业方向。本文系统介绍架构型设计师的职责、素质要求、以及和「产品型设计师」的分工边界。
## **设计师 Job Title 的变迁**
### **交互设计师 & 视觉设计师 ➔ 体验设计师 & 创意设计师**
2008 年加入阿里时，设计团队内将设计师主要分为交互设计师和视觉设计师两类。交互设计师负责与产品一起实现承接商业需求、制作产品原型，再交由视觉设计师进行设计稿的最终输出并交付给开发工程师。
这样的分工一直延续到了 2015 年左右，阿里开始逐步对设计师的 Job Title 进行调整，由原来的交互设计师和视觉设计师调整为了体验设计师和创意设计师，并在 2017 年基本完成了全集团设计团队的调整。
相较于之前交互 & 视觉的定位，体验设计师在原有交互能力基础之上增加了对视觉、商业意识、用研等综合能力的要求，期望能够培养更加一专多能的设计师。这个变化在当年其实让很多设计师感觉到有些“难受”，特别是一些视觉、交互能力均较平的同学来说，对于未来的职业发展方向迎来了第一个较大的困惑和挑战。
不过在我看来这个调整是合理的，也是必然会发生的。互联网在发生着巨大且快速的变化，这也势必导致设计师的工作流程发生变化，以前的工作模式已经已经无法跟上业务的高速发展。到如今时间已经过去了 6、7 年，这种“不适感”在设计行业内已经慢慢消失了，两个新的岗位角色逐步进入正轨，找到了各自的发展方向也延展出了很多新的领域细分能力。
### **架构型设计师 & 产品型设计师**
时间推移到 2018 年，我终于筹建了阿里集团的设计中台团队，为各业务设计团队提供设计过程中的工具及能力服务。在与大家的合作过程中，我发现一些自然而然在发生的变化，业务线的一些设计师已经开始逐步跳出原有岗位的定位，以更加综合、系统化的方式进行思考和工作推进，这个时候已经出现了一些“架构”的雏形了。
在思考并参与了一段时间后我向设计委员会做了一次汇报，尝试提出新增架构型设计师这个新的岗位。可惜的是在当时无论是团队建设还是整体的环境还不够成熟，这个提议并未通过，所以只能暂时的放一放。
不过这倒是不影响我自己继续去尝试，在接下来的日子里我在负责的四个业务中进行了一番调整，为每个业务团队增加了一个架构型设计师的岗位，开始将我之前对[设计系统的思考](https://www.thefivekey.com/why-we-need-design-system/)付诸于尝试。虽然这个新增的岗位也是在大家不断的摸索、试错中前行，但新的工作模式为大家打开了新的思路，也带来了非常多正向的结果产生。
## **什么是架构型设计师**
一提到架构这个词，大家很容易就联想到软件开发领域，设计领域也会有吗？过去这个概念可能与设计无关，但现在乃至未来它一定是存在的。当然，我们大家目前在这个领域都还是在边摸索边做，还达不到架构师的程度，所以我会先称它为架构型设计师。
和大家聊起这个话题时，我发现有些设计师会将这个角色理解为专业型的 Leader，精于设计、懂用研、能做好项目管理，也能够在专业角度上带团队。这种从能力项的定义的视角我认为还是在过往的思维模式里，不太准确。
「设计」作为业务生产中的一个技术工种，它在保障专业能力不断精进的同时，还需要确保业务生产的有效性和确定性，从业务视角去看团队的整体作战能力及专业能力的先进性。
基于以上这些背景信息，我会这样定义架构型设计师：
> **架构型设计师是设计团队专业能力的推动者，基于公司业务发展规划并构建精深的专业能力及高效的协作模式，协助设计团队为业务生产提供高质高效的设计专业能力。**
架构型设计师不一定是团队管理者，Ta 会将更多的精力放在专业能力建设而不是人事工作；架构型设计师也不一定是一个人，Ta 可能是一个独立团队或是几位设计师组成的虚拟小组。
### 架构型设计师的职责
之前的专栏文中中我给大家画了这么一张图。我将它 zoom out 一下放到整个业务的生产流程中，架构型设计师的工作就围绕在这设计的前、中、后环节来开展。
在整个业务生产流程中，架构型设计师的核心工作主要会围绕以下三层来进行：
#### 第一层：解决设计域内专业能力及效率问题
上一期的文章里，我们聊到了「齐套」这个概念，希望基于中台化的思路来提供基础能力、减少浪费。这里面大部分的工作都需要架构型设计师来进行承担，核心主要围绕设计系统和设计资产两部分。
**01. 设计系统的建设与维护**
设计系统如今已经成为设计团队先进生产力的重要组成能力之一，也是设计团队专业能力的重要体现。产品一旦进入稳定期，就需要考虑进行设计系统的建设和推进，来后续的产品迭代提供良好的底层能力基础。
我始终认为设计系统并不适合给全团队所有人分配任务共同推进，而是需要由团队里有经验（或是抽象思考的较好）的设计师来牵头制定，然后通过与业务中的设计师不断对焦来反复打磨。
架构型设计师的首要工作，就是需要结合业务的实际情况来构建业务级的设计系统。从底层的基础组件定义到业务级的 Design Pattern，同时配合品牌设计师进行产品的品牌风格定义，与研发工程师配合进行设计研发一体化的推进，为产品的业务生产提供底层服务能力。
**02. 设计资产管理**
每个产品都有其行业属性以及业务的特殊性，市面上没有任何一个资产库会是完全满足自己需求的。为了减少业务生产环节中的”浪费“，我们需要构建符合业务需求的设计资产库，这也是架构型设计师非常重要的一项工作。
这里的设计资产不仅仅是 icon、插画，设计过程中所用到的领域级或业务级文案、具体商品图或产品图、品牌 press kit 等都属于设计资产「齐套」的范畴。目的也非常明确，尽可能的确保设计师在设计过程中清楚的知道用什么、在哪里能找到。
#### **第二层：解决业务生产过程中的协同问题**
「产品流程优化一步，胜过设计改十步」，这句话放在协同里同样成立。生产质量和效率的问题很多时候根源就是在流程上，很多看似顽疾的问题随着流程的优化自然也就解决了。比如我们老生常谈的设计还原度问题，搬个小板凳天天做研发旁边问题依旧，通过设计研发一体化就能很大幅度的缓解，如果再能有在线搭建设计，这个问题几乎就没有了。从这个角度来看，设计验收工具似乎就成为了一个伪命题。
到了这一层，架构型设计师就已经不再仅仅局限于设计域内部来思考问题，而是更多的站在业务生产的全流程中去思考设计团队能够如何配合其他工种一起优化生产协作模式，从协作和流程上来提升设计团队产出的质量和效率。比如在第一层中所提到的设计系统和设计资产，在它们都已完成后，我们还需要用合适的流程和工具来让它们的管理和使用更加的简单和高效。
除此之外架构型设计师还需要负责对团队内设计工具进行评估和选型。与设计资产一样，市面上不太会有一款产品或工具完全符合自己的需求，所以架构型设计师还需要推动一些具产品能力自建，帮助构建符合业务和团队的团队工作流。
#### **第三层：设计能力探索**
除了以上两层直接作用于业务生产的工作以外，架构型设计师还需要考虑帮助设计团队面向未来的发展。无论是新的设计方式、协同模式还是专业工具、技术手段，架构型设计师都需要从中找到适合自己业务、团队的部分进行一些探索和尝试，不断丰富和增强团队的整体能力。
相较于前两者，设计能力探索的投入占比可以适当降低，当下的工作重心还是考虑以「设计域专业能力及效率」和「生产过程中的协同」为主，先解决论证这个岗位的价值，为设计团队提供能力上的支持。
到这里有些同学可能会发现，架构型设计师的工作和 DesginOps 的理念很类似，不再单纯的从技能角度去组织分工，而是从将设计工作融入到整体的业务工作流程中，重新组织新的工作模式。在我看来 DesignOps 更多的是一种理念和模式，而架构型设计师是一个具体的岗位角色。
其实这几年在阿里已经有一些设计团队设置专人开展架构型设计师的工作，只不过还未增设具体的岗位角色。从运作的情况来看都取得了不错的结果，特别是阿里云、菜鸟以及一些 toB 型的业务，已经开始成立了自己面向业务的设计中台团队，作为设计团队中非常重要的一个能力服务于设计师和整个业务生产。
## **架构型设计师的素质要求**
和软件领域的架构师一样，架构型设计师对于设计师的经验和能力会有着更高的要求，从个人的角度来看，我会比较注重以下几点的能力，也是我在面试过程中的重点考察方向。
### **抽象思维能力和逻辑能力**
既然是架构型设计师，那么抽象思维和逻辑能力必然是最为看重的部分。特别是在设计系统的工作部分，需要设计师有非常强的抽象能力来在繁杂的业务场景中找出共性诉求，抽象并沉淀为标准解决方案，同时也为未来的系统生长提供良好的可扩展性。
### **业务领域能力**
我们在前面的文章里提到过，大部分的设计师的相关工作都会是在业务级和领域级设计系统中。想要成为这个领域或业务的架构师，首先需要设计师在这个领域或业务的经验足够丰富，只有看得久、做得多你才会对这个领域或业务有足够深入的了解。
### **专业视野**
架构型设计师需要帮助设计团队拓展专业的深度和广度，首先需要对设计这个领域有足够的了解。专业的视野决定了扩展能力可能性的边界，同时设计如今也是一个高速发展的领域，也只有时刻保持着对这个领域发展的关注和敏锐度才有可能帮助团队找到更为适合的能力和方向。
#### **沟通协作能力**
架构型设计师关注事情远高于关注人，往往需要和很多不同的团队、角色来协作共同推进工作并最终得以落地。它需要设计师有非常好的沟通和协作推能力。
## **产品型设计师**
前面我们在聊设计师 Job Title 变迁的时候，除了架构型设计师还提到了另一个新的岗位 – 产品型设计师。其实这个概念也并不新鲜，海外的很多公司的设计团队早些年就已经出现了这个岗位。
在我看来，独立的来增加这个岗位是很难成立的，至少在国内一定很难，因为大家日常工作中的绝大部分时间都被无休止的设计细节所消耗掉了。架构型设计师的出现（或存在）能够帮助业务减少这些不必要的让费，让（或逼迫）设计师更多的将精力放到对业务流程和产品逻辑的关注上，让自己更加深入对所在行业领域、业务的了解，能够更有底气的去“挑战”那些不合理。
正如七年前「交互设计师 & 视觉设计师」向「体验设计师 & 创意设计师」的转变一样，架构型设计师和产品型设计师是相辅相成的进化而来的，也是行业发展一定会带来的变化。未来的设计团队里未必一定会出现这两个岗位，但工作方式、协作模式一定会朝着个这个方向慢慢变化。希望本期的这篇文章能够给予大家个人或是团队的发展提供一些帮助。如果你或你的团队也刚好处于这样一个变化期，非常欢迎找到我咱们继续讨论。
> 💡 延伸阅读：
> - 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
> - 选择架构 vs 业务：[设计师的下一站，成为架构师，还是走向业务？](/designer-architect-or-business/)
> - 设计系统价值起点：[设计系统 · 我们为什么要做 Design System](/why-we-need-design-system/)
> - 深度案例参考：[如何规划 B端 设计系统？深度解析 AWS CloudScape](/b-end-design-system-deep-dive-aws-cloudscape/)
> - 体验设计师未来：[体验设计师 未来三年应该如何发展？](/ux-designers-in-the-next-three-years/)
> - 架构型设计师的 AI 新工具：[把设计系统变成 Markdown：让 AI Coding 真正读懂你的设计约束](/design-system-as-markdown/)
================================================================
# 设计系统 · Design System 应该做到什么程度才够？
- **发布日期**：2022-07-08
- **原文链接**：https://www.thefivekey.com/what-should-a-design-system-look-like/
- **Markdown 原文**：https://www.thefivekey.com/what-should-a-design-system-look-like/index.md
- **标签**：设计系统
> 设计系统究竟要做到什么程度才算 OK ？在上一期的文章里，我们从「业务」和「经营」两个视角讲解了为什么要做 设计系统 。相信大家对于设计系统的意义已经非常清楚了，但在自己的团队里，设计系统究竟要做到什么程度才算 OK ？这是文章发出后大家会提到最多的一个问题。
在上一期的文章里，我们从「业务」和「经营」两个视角讲解了为什么要做 设计系统 。相信大家对于设计系统的意义已经非常清楚了，但在自己的团队里，设计系统究竟要做到什么程度才算 OK ？这是文章发出后大家会提到最多的一个问题。
每个团队规模、业务进展都不一样，都以同样的标准进行设计系统建设的确是不切实际的。设计系统是一个长期、持续性的工作，一次性到位肯定是不可能的，所以这次的文章我们就来聊一聊设计系统的三个不同阶段，以及我们应该在何时进入、如何定义阶段目标。
**开始之前，我们先简单回顾一下上一期文章里的几个关键信息:**
## 设计系统的三种类型：
- 系统级：操作系统级别的设计系统，提供最底层操作系统级的设计及研发指引；
- 领域级：聚焦于某一类通用场景的设计及研发指引，当前最为成熟的还是在企业级应用（B 端）场景；
- 业务级：基于系统级或领域级的二次加工定义，为具体的产品或业务提供设计及研发指引。
## 做设计系统的目的：
- 提升业务生产效率。当下互联网红利逐步消失，业务生产的模式需要发生改变，来帮助企业留着利润
- 回归业务本质问题。逐步抽象封装业务模块，让产品回归业务逻辑本身；
- 统一“业务语言”。建立包含业务、产品、设计、技术的共同业务语言，提升团队沟通效率；
- 提升体验一致性。让设计系统团队专注于系统本身，优化并统一用户使用体验，降低用户使用成本；
- 更先进的协作模式。通过设计系统的引入，优化业务生产环节中生产协作模式；
- 提升团队战斗力。帮助新加入成员或生态合作伙伴更快的融入，提升整体生产力。
## 延展阅读：
- 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
- [设计系统 · 我们为什么要做 Design System](/why-we-need-design-system/)
- [设计系统 · 如何向你的主管和团队介绍 Design System 的重要性](/how-to-prove-the-value-of-design-system-to-your-boss/)
- [如何规划 B端 设计系统？深度解析 AWS CloudScape](/b-end-design-system-deep-dive-aws-cloudscape/)
- [设计系统学习指南 - 国内外 Design System 案例解析](/how-to-learn-from-other-design-systems/)
> 节选自专栏 **[OFF DESIGN](https://xiaobot.net/p/offdesign)** #02: 设计系统应该做成什么样子
================================================================
# 这两年设计师找工作是不是越来越难了？
- **发布日期**：2022-06-25
- **原文链接**：https://www.thefivekey.com/designers-employment-development/
- **Markdown 原文**：https://www.thefivekey.com/designers-employment-development/index.md
- **标签**：职业发展, 求职面试
> 这两年互联网的形势确实不太好，设计师就业越来越难。本文从「十四五」数字经济规划的宏观视角、政治-社会-经济三层趋势分析，到企业对设计师岗位认知的本质变化，系统解释为什么设计师找工作越来越难，以及在新环境下设计师真正需要关注的能力方向。
> **TL;DR**
>
> 设计师找工作变难，表面原因是互联网寒冬，深层原因是企业对设计师的价值评估发生了本质变化：从"能画界面"变成"能为业务创造商业价值"。
>
> 在宏观上机会依然存在（十四五数字经济规划），但能抓住机会的设计师需要重新思考自己的能力结构。
设计师找工作 这两年的确是越来越难。前两天和一位猎头朋友正好在聊这个话题，一些想法分享给大家。
## 宏观环境：十四五数字经济规划中的设计机会
这两年互联网的形势确实不太好，各大互联网平台多多少少都受到了政策的影响。也正是因此，国内的环境我们更需要关注国家层面的思考。毕竟绑定到「核心的 KPI」才能在获得更好的发展环境。
去年的年底国务院发布了「“十四五”数字经济发展规划」，大家可以关注一下这里面的数字经济发展主要指标。
来源：http://www.gov.cn/zhengce/content/2022-01/12/content_5667817.htm
大家可以算一下 IT 服务业规模、工业互联网平台、网上零售、电商、政务几个领域到 2025 年的预期性增长，加起来有 40 多万亿。
## 政治、社会、经济三层趋势分析
除去国家对于核心 KPI 的预期，我们也还需要看看整体的宏观趋势。
### 01. 政治层面
国际形势目前还是相当复杂的。国家鼓励信息技术的自主创新，核心技术自主可控。同时也鼓励各大科技企业的开源，通过技术手段赋能给实体经济，帮助实体经济进行数字化转型。
### 02. 社会层面
互联网的红利消退，各大互联网企业在 C 端市场基本都已经触顶。加上疫情影响，toB 市场的需求增长迅猛。在线、异地办公已经逐渐成为新的常态。
### 03. 经济层面
全球经济放缓，企业用工人力成本也在不断持续上升。企业也迫切的需要通过数字化的手段降本提效。而近些年云计算、5G、物联网、AI 等技术的发展也为企业效率提升带来了明显的变化。
## 企业对设计师的要求正在发生本质变化
从宏观层面上来，无论是 UI 、交互还是 UE，市场的需求是明确存在的。就业环境也会随着整体情况的稳定逐步下来。
当然，这里面依旧发生的很大的变化，对于人才的要求的变化。设计的目的是解决问题，不同的阶段需要解决的问题不一样，设计师的工作也就有所差异。
营利是企业最为重要的目的之一，包括设计师在内的所有岗位都是为之服务的。在大环境的影响之下组织不得不重新审视每一个岗位角色在经营环节中所提供的商业价值。
企业需要解决什么问题？这个问题哪些是设计可以发挥价值的？这些价值点中需要设计师什么样的能力？这些问题才是在目前环境下设计师就业或者说是职业生涯最需要关注的。
> 💡 延伸阅读：
> - 具体案例：[做了 5 年互动设计，我遇到了设计师职业发展天花板](/five-years-later-i-encountered-a-career-ceiling/)
> - 方向选择：[体验设计师 未来三年应该如何发展？](/ux-designers-in-the-next-three-years/)
以上，希望对你有所帮助。
================================================================
# 做了 5 年互动设计，我遇到了 设计师职业发展 天花板
- **发布日期**：2022-06-24
- **原文链接**：https://www.thefivekey.com/five-years-later-i-encountered-a-career-ceiling/
- **Markdown 原文**：https://www.thefivekey.com/five-years-later-i-encountered-a-career-ceiling/index.md
- **标签**：职业发展, 求职面试
> 设计师职业发展天花板是很多工作 5 年左右的设计师都会遇到的真实困扰：晋升受阻、方向迷茫、被更年轻便宜的设计师替代。本文通过一位阿里 5 年互动设计师 X 的真实故事，拆解天花板背后的三层原因：行业成熟度、个人能力结构、以及组织对设计师的期待变化。
> **TL;DR**
>
> 设计师的职业天花板，很少是"能力不够"的问题，更多是"能力结构没跟上行业需求变化"。
>
> 当行业从增量走向存量，组织对设计师的期待从"做好界面"变成"推动业务"。
>
> 工作 5 年左右的瓶颈期，需要的不是更努力地做设计，而是重新定位自己的能力坐标。
前段时间在群里针对设计系统 Design System 的建设和应用拉了个群并做了一个小调查。回收了 80 多份，不多但也足够反映大致的现状。理了理也给大家做一个分享。
设计师职业发展 ，是我的会员群中经常被讨论到的一个话题。前段时间正好有机会和一位同学也是集团内的一位设计师有一次喝咖啡的沟通。内容有些意思，记录下来与大家分享一下。
## 本期主人公：一位工作 5 年的阿里互动设计师 X
这已经是 X 君参加的第五个 618 大促了，与往年不同的是这次结束后他并没有调整休假，而是立马调头回到了了另外两条业务线的迭代工作中。支持的资源在变少，但需求却并没有发生变化。自己似乎已经遇到了职业发展天花板。
X 君是 90 后，美院毕业后没多久就加入了目前这家公司，目前负责两个大型互动产品的设计工作，同时还需要在各类大促期间支持相关互动玩法以及营销活动。
在公司的这 5 年时间过得很快也很充实，密集的项目压得人透不过气，但也带来了更多的机会和挑战。也正是因为其优秀的表现，X 君在加入公司的第四年顺利完成了自己的第二次晋升，成为了互动产品的主设计师，扛起两条核心业务线的设计工作。
## 一位工作 5 年的设计师对 设计师职业发展 的困扰
> 太忙了，而且是周期可预见性的忙。时间几乎全部被工作所占据，以往的爱好被纷纷搁置了。
我对手机 OS 以及很多的创新设计非常感兴趣，以前时间比较充裕的时候会去捣鼓一些小创新。看到自己的一些创意想法在网络上获得了大家的认同，有些甚至出现在了各厂商的发布会上，这种满足感会让我 high 很久，我想这应该就是设计师最纯粹的快乐吧。
但很可惜我已经很久没有打开那些设计稿了。日常的项目交替着各种大促活动，往往一个项目还没结束下一个就开始拉人启动了。画画飞机稿？不好意思，真的没有时间也没有那个精力了。
作为设计师，我们需要跟进项目的完整流程。项目的前期沟通讨论、需求明确后的各种设计产出、开发后的还原度和测试。每天有各种各样的会需要参加，真正设计工作往往只能在结束了一天的会议后加班做，回到家也只想“躺着”了。
> 设计师话的语权太低了，我们很难对业务产生深度的影响。
视觉表达有种很特殊的魔力，能够带给大家感官上的愉悦。对于自己的专业我还是有自信的，业务方大多数时候很难从专业角度去挑战我们。但这也仅仅是在我的专业领域中，对于业务的决策、活动玩法的设计，作为设计师我们的话语权确实不高，很难插的上手。
产品的背后是商业，商业的目的还是要带来业务指标的增长。从决策链路上我们就已经站在了业务方的后面，大多数时候作为设计师我们很难去挑战他们，甚至连验证的机会都没有。当如如果业务方向从一开始出了问题，我们的设计做得再好也很难获得好的结果。即使有了好的结果，这里面有多少是由设计师给带来的，我们很难讲清楚。
作为项目组的一员，我们还得每天参与到各种沟通会、评审会，业务上的决策建议提了不一定被采纳（除非正好和某些角色的想法不不谋而同），不提又显得自己参与感不足。每天大量的时间都在反复的会议、沟通，真正做设计的时间被压缩得非常紧张。
这些问题叠加在一起，就让很多人整天都在纠结中渡过。除了体累还有心累，但似乎也并没有更好的办法。
> 做了 5 年互动设计，我遇到了职业发展瓶颈。
有复杂度的业务、持续的有效产出，所以绩效一直都还不错，这也让我的两次晋升都很顺利。但在晋升后的第二年我又有了新的焦虑，自己怎样才能到达下一个层级？新的层级，不进则退，又该如何能让自己一直获得好的绩效结果？下一个阶段应该如何走我开始有些迷茫了。
团队里同层级的设计师有好几个，有些在当前层级已经好几年了；越往上走，对设计师综合能力的要求越高，单凭设计技能是很难有更好的发展的；工作上能使上力的还是做好业务支撑，想从设计侧发起做一些专业深度事情一直都很难，如今的环境，变得更加难了。
说实话，我确实有些困惑了，不知道还能做些什么来帮助自己打破这个“僵局”。
## 关于设计师职业未来的思考
我坚信设计师应该打造自己独立的品牌 IP，去表达自己对这个世界的认知、对设计的理解。今天大家所看到的一切都有设计参与其中，也有很多设计师心中的「会心一笑」。我想尝试着做做「内容」，用短视频的形式表达我把这些告诉大家，也分享一下我对设计的理解。
图形处理、视频剪辑这些对于我来说都不是问题，每一位设计师都有发现美、发现有趣的能力，我希望自己能用通俗易懂的方式帮助表达出来，让大家了解设计，发现这个世界的美妙。
至于工作本身，我还是比较坚信「设计是来解决问题」，而不是纯粹的信息表达。随着行业的发展，传统的设计师能力竞争力会越来越小，未来的设计师还是需要有更多对业务、商业的理解能力。
13 点 45 分，X 君来回点了几次手机屏幕。离我们取好咖啡坐下已经过去了 1 个半小时，咖啡已差不多喝完，我们的聊天也差不多结束了，相互道别以后 X 君也快步的向着公司方向而去，估计一会应该还有某个棘手的项目评审会在等着他吧。
> 💡 延伸阅读：
> - 宏观视角看环境：[这两年设计师找工作是不是越来越难了？](/designers-employment-development/)
> - 具体方向选择：[体验设计师 未来三年应该如何发展？](/ux-designers-in-the-next-three-years/)
> - 突破口之一：[好的简历作品集，需要有层次的表达](/how-to-structure-portfolio-expression/)
## 写在最后：突破设计师天花板的关键
像 X 君一样的设计师有很多，大家都被加班、晋升、个人发展等各种问题所困扰。就近一个多月了解的情况来看，目前的大环境下确实没有太多好的办法，尽可能的先稳住吧。
一些建议给到 X 君，同时也在这里抄送给大家吧。
01. 从商业角度去思考设计价值
营利是企业最为重要的目的之一，包括设计师在内的所有岗位都是为之服务的。在大环境的影响之下组织不得不重新审视每一个岗位角色在经营环节中所提供的商业价值。仅从设计专业的角度聊价值而忽略（或没有）对商业的影响，会让自己后面的路更加艰难。
02. 跳出具体设计，找到自己的理论后盾
公司从来不排斥做理论，只是不需要脱离业务之外空谈理论。就像前面我们一直在聊的设计系统一样，它建立在解决业务生产效率的角度上去构建。同时作为设计师我们也必须构建自己的专业理论并在实际业务中去论证它。这样我们才能更合理的告诉主管、评委或是面试官，虽然业务结果是多方共同努力的结果，但至少设计的这一部分，我是能够讲清楚背后的逻辑的。
03. 不用冲动跳槽，但也要做好两手准备
千万不要一时冲动跳槽，除非你已经有了非常合适且确定的机会。但同时我们也不能“苟”着，随时做好需要换工作甚至换城市的准备，毕竟当下的环境可能比大家想象的还要不好。
推荐阅读：
体验设计师 未来三年应该如何发展？
设计师找工作 这两年是不是越来越难了？
================================================================
# 设计系统 · 我们为什么要做 Design System
- **发布日期**：2022-06-14
- **原文链接**：https://www.thefivekey.com/why-we-need-design-system/
- **Markdown 原文**：https://www.thefivekey.com/why-we-need-design-system/index.md
- **标签**：设计系统
> 设计系统 (Design System) 是当前设计领域最热门的话题之一，但其价值并非所有人都清晰认识。本文从阿里 Fusion Design 实战经验出发，系统讲清设计系统解决的 5 个核心问题：业务效率、体验一致性、业务语言统一、团队协作、人才培养，以及为什么每个重视设计效能的团队都应该构建自己的设计系统。
> **TL;DR**
>
> 设计系统不是"画规范"，而是用系统化方式解决业务效率、体验一致性、团队协作三大痛点。
>
> 它的本质是把设计从"手艺"升级为"可复用的资产"。
>
> 本文结合我在阿里搭建 Fusion Design 的经验，回答为什么每个认真做数字产品的团队，都应该拥有自己的设计系统。
## 为什么现在是讨论设计系统的最佳时机
2018 年的 10 月，我在专栏里发布了第一篇关于设计系统的文章。那是我在阿里建立设计中台部门的第一个季度，作为部门三大重要方向之一，我们已经用 Fusion Design 支撑了集团内（除蚂蚁）几乎所有的 B 端产品。
2019 年的夏天，我在 Alibaba UCAN（现更名 U Design Week）做了一次 关于设计系统的工作坊，和来自不同公司的设计师朋友们一起聊了 3 个多小时。那个时候已经有不少的小伙伴开始思考如何借助设计系统的体系化思维来进行设计交付。
那个阶段大家大多都还处在理论和实践摸索期，更多的还是站在体验一致性的角度来思考如何构建设计系统。而当年专栏的差不多二十篇文章也更多是从工具书的视角，再带上一些公司里实践的经验给大家介绍设计系统。
时间一晃快 4 年，环境在发生变化，我们对于设计的理解也在发生变化，这本“工具书”也是时候该进行升级了。前段时间在读者群里做了一次调研，发现很多公司对于设计系统的关注和投入都在明显的变化。
> - 近 70% 的设计师所在团队都已经完成或正在建设设计系统，40% 团队由设计师和前端工程师共同参与；
> - 90% 多的公司期望通过设计系统来提升整体的设计研发效能。
从阿里离职以后也不想再找一家公司继续两点一线的生活了，希望还是能够多一些闲暇时光体验不一样的生活。想了想继续码字还是最适合我当下的状态，同时也能将这些年在阿里工作的经验和思考分享给大家，而「设计系统的构建与应用」就是这其中的重要板块之一。
## 这个设计系统系列将覆盖的内容
在设计系统调研问卷的最后我留了一个开放问题给大家，想看看对于设计系统还有什么疑问。
> 1. 设计系统的完整体系是怎样的？
> 2. 如何面向行业、业务去定义设计系统？
> 3. 设计系统需要做到什么程度？覆盖多少业务体量才算够？
> 4. 什么样体量的团队需要设计系统？不同类型的公司做设计系统有没有什么差别？
> 5. 如何看待设计系统的约束与创新诉求？
> 6. 如果跨团队达成设计的共识？
> 7. 如何衡量设计系统的价值？
> 8. 市面上这么多开源设计系统，他们的差别是什么？
> 9. 如何确保设计系统的落地？有没有具体的流程和方法？
> 10. 设计系统启动之前有多的想法和思路，但在构建过程中出入又很多，有哪些道与术可以借鉴？
> 11. 如何验证你所设计构建的系统就是当前最有效的方式？
通过以上内容你会发现大家不再是盯着规范如何制定、文档怎么写等相对具象的问题，而是更多的站在设计工程、业务价值、跨团队协作等更深入的角度进行思考。而这些，也是近几年我在集团内各业务做实施中感受最深的地方。
所以，这次设计系统专栏的重启我会先花一些篇幅和大家聊聊在阿里做设计系统的故事，聊聊背后的一些思考和决策逻辑。我们大家先在“基础土壤”上做到信息对齐，这样我们后面的讨论也会更加顺畅。
整个「设计系统的构建与应用」专栏我会主要围绕以下几个部分来写：
- 设计系统背后的思考
- 创建设计系统流程工具书
- 设计系统案例解析 & 应用案例解析
- Design Pattern 案例解析
- 设计系统对协作模式的影响以及面向未来的思考
**专栏的第一期，我们将先从 Why 开始，聊一聊为什么要建立设计系统。**
## 2022 年国内外设计系统的发展现状
在开始聊 **Why** 之前，我想还是先和大家一起回顾一下当前互联网产品设计领域设计系统的一些现状。首先还是会上次 UCAN 的工作坊一样，将设计系统定义为**系统级、领域级、业务级**三类。（关于这三个层级各自代表什么、国内外有哪些典型案例，可以看这篇延伸阅读：[设计系统学习指南 - 国内外 Design System 案例解析](/how-to-learn-from-other-design-systems/)）
#### **系统级：**
顾名思义，就是操作系统级别的设计系统，我们日常会涉及到的主要就是 Apple、Google 和 Microsoft 三家所提供的。
[Human Interface Guidelines - Human Interface Guidelines - Design - Apple Developer](https://developer.apple.com/design/human-interface-guidelines/guidelines/overview/)
[https://material.io/design](https://material.io/design)
[Microsoft Design](https://www.microsoft.com/design/fluent/)
其实我们也可以将它“简化”一下，将它们比作支付宝或微信的小程序就更容易理解了。支付宝和微信经过多年的运作累积了海量的用户和流量，于是很多的企业（或开发者）希望能够进驻到平台，为用户提供服务并获取响应的收益。
为了给用户带来一致、优质的服务和使用体验，支付宝和微信向企业（或开发者）提供一整套完整的设计指导原则和开发框架，也借此来帮助提升小程序的开发效率，降低产品的实现成本。而企业（或开发者）也会尽可能的去遵守它们的规则，以获得更好的业务上的合作扶持。
也正是因为系统级的定位，它们所需要服务的产品类型会有着非常大的类型跨度。所以这些设计系统的定义会更加的“底层”，会更注重对设计世界观的定义。这也是为什么它们会更多的去模拟、还原真实的世界。
注：这里顺便简单说一下对设计系统的定义。如上述我们不能将它们简单理解为一套设计规范或是设计语言，而是一整套面向业务生产（产品开发）的设计 + 工程的整体解决方案。以后我们会详细聊，这里先不展开。
相较于其他两类，系统级的数量并不会太多。毕竟它的出现是依托于几大主流操作系统之上，而我们大家参与的设计系统，大多也是以这几家为基础来构建的。以目前的市场格局来看突然再出现一家的几率不太大，所以作为设计师我们只需要保持好对以上三家的关注就好。
#### **领域级：**
相较于系统级，领域级的设计系统会更加聚焦于某一类通用场景。比如 IBM 的 Carbon Design，阿里的 Fusion Design，蚂蚁的 Ant Design 以及字节的 Semi Design、Arco Design、腾讯的 TDesign，并且这些设计系统大多数也是开源的。
[Carbon Design System](https://carbondesignsystem.com/)
[Ant Design - 一套企业级 UI 设计语言和 React 组件库](https://ant.design/index-cn)
[](https://fusion.design/)
[Semi Design](https://semi.design/zh-CN/)
[Arco Design - 企业级产品的完整设计和开发解决方案](https://arco.design/)
[TDesign - 开源的企业级设计体系](https://tdesign.tencent.com/)
如果对以上这些名字有过一定的了解，你应该发现它们基本面向的都是企业级应用场景，或者是我们常说的 B 端场景。造成这种“扎堆”现象的原因其实还是因为企业级（B 端）场景是当下最适合被抽象并达成产品和用户两侧的共识。
这里的共识并不是说它简单、对设计的要求不高。而是在企业级的场景下，高效、一致、简洁等关键词是每一个设计系统最为核心的设计原则，目的是让用户能够更为有效、轻松的完成当下的任务。再加上如今蓬勃发展的 B 端业务，设计系统的价值在这里可以得到很好的验证和体现。
有些同学可能还记得 2018 年底 Ant Design 的圣诞风波，当时在国内外网络上轩然大波甚至还有人因此被离职，可见作为一个小团队投入的 Ant Design 默默的服务了多少用户和产品。
**为什么领域级大多是企业级场景，别的场景难道就不能做吗？**
坦白讲，理论上是肯定可行的，但事实上当下还是有比较大的难度的。一年多前我们在设计委员会有过一次命题，希望建立一套完整的 Alibaba 设计语言，将阿里的设计讲清楚，并在此基础上延展出电商、物流、出行、金融、娱乐、企业级应用等不同领域的设计系统。
花了半年多的时间，我们完成了 Alibaba 最底层根基的设计语言，但到了领域这一层的时候我们却暂停了。因为我们发现除了企业级应用，其他的领域在目前大家还比较难达成真正的共识。无论是哪个领域，当下其业务属性都要远超过其领域属性。所以在当下，这些领域更多还是会以业务级设计系统的形式存在，服务好各自的业务。
注：这件事儿虽然没有最终完成，但 Alibaba 底层根基建立过程是个很有趣的事情，后面有机会给大家展开聊一聊。
#### **业务级：**
业务级是为某个具体的产品或业务进行服务的，比如业内较为知名的 Lighting Design、Fiori Design，以及我之前专门拆解过的 [AWS CloudScape](/b-end-design-system-deep-dive-aws-cloudscape/)（一个 B端 业务级设计系统的最佳实践案例），和各位正在公司里所做的设计系统。
[Lightning Design System](https://www.lightningdesignsystem.com/)
[SAP Fiori Design Guidelines](https://experience.sap.com/fiori-design/)
这类设计系统都有一个共同点，它们基本上都是基于系统级或领域级的设计系统之上进行二次加工定义的。这一类设计系统的领域会非常广泛，大家需要做的是基于这个领域的特性再叠加上业务特性进行准备的定义，帮助企业在对应的生态中快速开展业务，提供服务。
举个例子，2016 年我把整个团队的精力都投入在 AliExpress 的设计系统中，基于 iOS 和 Android 的系统级规范去定义 AliExpress 的设计系统。这其中耗时最久的就是在寻找平衡，在遵守系统级规范的同时去定义电商领域中这个产品独有的设计理念、思路。
虽然最后我们看似轻松拿到了 Google Editors' Choice，但这背后和 Google 设计、研发团队的沟通、耗时之久可能是大家没能想象的。是的，真正的业务级设计系统往往就是朴实的，因为它还是以解决业务的实际问题为首要前提的。
## 设计系统要解决的核心问题
**这里我们再简单回顾一下这三类设计系统**
- 系统级：操作系统级别的设计系统，提供最底层操作系统级的设计及研发指引；
- 领域级：聚焦于某一类通用场景的设计及研发指引，当前最为成熟的还是在企业级应用（B 端）场景；
- 业务级：基于系统级或领域级的二次加工定义，为具体的产品或业务提供设计及研发指引。
#### **对于设计系统的思考变化**
这里我们聊的思考变化不仅仅是指在设计师角度，更多的是公司的角度来看待设计系统以及它所提供的价值。
以前我们聊设计系统，很多都是设计师和前端从认知、从兴趣的角度出发来尝试更为先进的业务生产模式。而很多公司的管理者对它的理解是设计的一致性、设计体验的提升，而对于降本提效至少在工程上我们也并没有特别明显的价值产出。
**经营视角的转变**
这两年随着互联网红利的逐步消失、疫情的影响，成本、收益都都面临的巨大的考验，连各大互联网公司也不再放任大家去不断的“试错”。阿里在一年多前也逐步的开始对每个团队实行经营责任制，让大家必须认真思考每一次的资源投入。
虽然大家诸多抱怨，但宏观上来说我认可这是一件正确的事情。它也倒闭着团队管理者们通过更科学、高效的工作模式来运作团队，杜绝浪费。同时也就在这个时刻，因为业务的特性，一些企业级产品从相关方到管理者都开始重新审视设计系统所能带来的价值，有些想清楚的也早早的开始并已经获得了相当明显的收益。
这里面的逻辑其实也并不复杂，给大家举个例子：某事业部 CTO 线的核心交付就是各类中台系统，宏观角度可以拿页面数进行计算。
> **单页面成本 = 平均工时工资 x 单页面交付时长**
这里提供了两个影响成本的变量，要么降低工时工资，要么降低单页面交付时长，但对于企业来说非常时期往往两手都得抓。平均工时工资不在我们的把控范围内，但单页面交付时长对于设计师和研发来说就有很多事情可做了。设计系统的投入和产出价值可以很清晰的算笔账，只要方案制定得合理，大概率这个 ROI 是满足预期的。
**业务视角的转变**
还是说回前面那次关于设计系统调研，你会发现产品经理的出现了，设计系统不再只是一个设计和研发的工作，产品经理也需要参与其中一起制定规则。
> 受访者中有 16% 表示团队中的设计系统参与者为设计师、前端工程师、产品经理。
产品经理为什么要参与？因为在设计系统的角度，设计师和前端工程师定义的是解决某一类问题的界面交互模式。而产品经理的日常工作是创建实例，解决某个具体业务流程问题。
想象一下产品经理在写 PRD 的时候如果是这样的场景:
**这是一个新品报名系统**
> - 模块 1：注册登录
> - 模块 2：报名表单
> - 子模块 1：用户身份认证
> - 子模块 2：商家资质认证
> - 子模块 3：…
> - 模块 3：报名管理
> - 模块 4：商品管理
这背后每一个模块、子模块，除了交互模式上的定义，还需要从产品上进行业务逻辑的定义。好的业务级设计系统应该让产品经理将重心放在业务流程本身，而不必去关心某一个具体按钮、弹框。而作为设计系统的制定者也不用再整天纠缠在业务细节中，将工作的重心放在对业务 Pattern的抽象、制定中。
> 我们曾经在某个面向商家的业务中做过一次尝试，但失败了... 这个案例后续有机会和大家详细聊。
当然，这类模式并不是一件容易的事情。它首先需要设计师、前端工程师、产品经理达成共识：
- 我们需要的不仅仅是规范，还需要更多的确定性的“约束”，将达成的共识封装成模块供使用；
- 非必要情况下，我们要做无畏的“设计创新”，一切以切实解决问题为优先；
- 如果需要对制定好的规则进行改变，不要修改实例。去给已封装的模块提需求。
## 为什么每个团队都值得构建设计系统
以上聊了这么多，这里我们再总结一下为什么要做设计系统
- 提升业务生产效率。当下互联网红利逐步消失，业务生产的模式需要发生改变，来帮助企业留着利润；
- 回归业务本质问题。逐步抽象封装业务模块，让产品回归业务逻辑本身；
- 统一“业务语言”。建立包含业务、产品、设计、技术的共同业务语言，提升团队沟通效率；
- 提升体验一致性。让设计系统团队专注于系统本身，优化并统一用户使用体验，降低用户使用成本；
- 更先进的协作模式。通过设计系统的引入，优化业务生产环节中生产协作模式；
- 提升团队战斗力。帮助新加入成员或生态合作伙伴更快的融入，提升整体生产力。
## 设计系统的未来趋势与展望
去年年末国务院发布了「十四五数字经济发展规划」，这里面有几个信息很值得关注。
> **加快推动数字产业化**
> 增强关键技术创新能力。瞄准传感器、量子信息、网络通信、集成电路、关键软件、大数据、人工智能、区块链、新材料等战略性前瞻性领域，**::发挥我国社会主义制度优势、新型举国体制优势、超大规模市场优势，提高数字技术基础研发能力::。**以数字技术与各领域融合应用为导向，推动行业企业、平台企业和数字技术服务企业跨界创新，优化创新成果快速转化机制，加快创新技术的工程化、产业化。鼓励发展新型研发机构、企业创新联合体等新型创新主体，打造多元化参与、网络化协同、市场化运作的创新生态体系。**::支持具有自主核心技术的开源社区、开源平台、开源项目发展，推动创新资源共建共享，促进创新模式开放化演进。::**
> 营造繁荣有序的产业创新生态。**::发挥数字经济领军企业的引领带动作用，加强资源共享和数据开放，推动线上线下相结合的创新协同、产能共享、供应链互通。鼓励开源社区、开发者平台等新型协作平台发展，培育大中小企业和社会开发者开放协作的数字产业创新生态，带动创新型企业快速壮大。::**以园区、行业、区域为整体推进产业创新服务平台建设，强化技术研发、标准制修订、测试评估、应用培训、创业孵化等优势资源汇聚，提升产业创新服务支撑水平。
> 软件信息服务、工业互联网平台、在线政务服务规模都被放到“十四五”数字经济发展的主要指标中。
自主、开源是国家未来的重要方向，除了阿里很早就已经对外开源的 Fusion Design、Ant Design，腾讯和字节也已经加入设计系统开源的行列中。信息化服务、产业数字化、数字政务，这些未来几年最重要的数字经济指标已经带来了一个巨大的市场空间。这背后需求与 IT 从业人员数量之间还是存在一个不小的缺口，而设计系统相关的人才诉求已经悄然的在扩大了。
> 💡 延伸阅读：如果你正准备向主管或团队推行设计系统，可以参考 [如何向你的主管和团队介绍 Design System 的重要性](/how-to-prove-the-value-of-design-system-to-your-boss/)；如果你关心"设计系统该由谁来建"这个组织问题，可以看 [设计系统究竟应该由谁来负责？](/who-should-own-design-system/)
## 建设设计系统需要什么样的人才
我所管理的设计中台部门只有 3 位设计师全职投入设计系统的工作，阿里有数百个设计团队，数千位设计师在支持着各式各样的业务，但一直以来稍有团队专门负责这项工作。但随着设计系统的发展，这两年内部已经有多个设计团队成立了设计系统相关的团队或小组，但这类人才依旧很难找。我花了 3 年时间也只从 IBM 的 Carbon Design 团队招募到一位设计系统架构师，其他大多数相关设计师我们都是在边做边学。
在我准备离职的前一段时间，有一位猎头找来说字节飞书开放了一个设计系统的高端岗位，准备大力投入做飞书的设计系统，而且目前团队已经有了 10 多个人的规模。而就在最近腾讯 TDesign、字节抖音也在开放设计系统相关岗位，但猎头依旧在和我抱怨人太难找了。
是的，设计系统在设计领域中还是一个相对小众的话题。即使是包括一直在关注着设计系统的的各位，也只是在中国几百万设计师里非常小的一部分群体。但环境始终是在变化的，尤其是互联网行业，三年前和大家提体验设计师角色的演变（体验架构师和产品设计师）已经在一步步显现。很高兴设计系统在大家的团队、公司里越来越被重视，而已经参与其中的各位也将比其他人更早的进入下一个更为重要阶段。
共勉！ 💪🏻
> 💡 延伸阅读：
> - 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
================================================================
# 设计系统 · 2022 Design System 调研总结
- **发布日期**：2022-05-21
- **原文链接**：https://www.thefivekey.com/design-system-survey-2022/
- **Markdown 原文**：https://www.thefivekey.com/design-system-survey-2022/index.md
- **标签**：设计系统
> 一份 80+ 设计师参与的 2022 年 Design System 团队现状调研。覆盖团队投入、参与角色、使用情况、公司期望、是否设有专职架构设计师等维度，为关注设计系统建设的团队提供横向参考数据。
> **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）的开放性问题
总结了一下大概是以下这些方面：
1. 设计系统的完整体系是怎样的？
2. 如何面向行业、业务去定义设计系统？
3. 设计系统需要做到什么程度？覆盖多少业务体量才算够？
4. 什么样体量的团队需要设计系统？不同类型的公司做设计系统有没有什么差别？
5. 如何看待设计系统的约束与创新诉求？
6. 如果跨团队达成设计的共识？
7. 如何衡量设计系统的价值？
8. 市面上这么多开源设计系统，他们的差别是什么？
9. 如何确保设计系统的落地？有没有具体的流程和方法？
10. 设计系统启动之前有多的想法和思路，但在构建过程中出入又很多，有哪些道与术可以借鉴？
11. 如何验证你所设计构建的系统就是当前最有效的方式？
## 总结：2022 调研反映的设计系统趋势
从这 80+ 份问卷中我们可以看到几个明显的趋势：
- 设计系统已经成为团队的"标配"，近 70% 团队已启动相关工作
- 它不再是设计师的独角戏，40% 团队由设计师与前端工程师共建
- 公司对它的期望高度一致，90%+ 希望借此提升设计研发效能
但同时也暴露出一些问题：专职架构设计师稀缺、体系化建设方法论缺失、跨团队协作共识难以达成。这些问题背后的根因，需要回到更底层的讨论。
> 💡 延伸阅读：
> - 📚 主题枢纽：[设计系统完整指南](/design-system/)｜涵盖三层架构、案例、AI 时代的完整路径
> - 基础视角：[设计系统 · 我们为什么要做 Design System](/why-we-need-design-system/)
> - 学习路径：[设计系统学习指南 - 国内外 Design System 案例解析](/how-to-learn-from-other-design-systems/)
> - 推行话术：[如何向你的主管和团队介绍 Design System 的重要性](/how-to-prove-the-value-of-design-system-to-your-boss/)
---
## 关于引用
本站所有文章原创于 5key，转载或 AI 引用请注明：
- 作者：5key
- 原文 URL：对应文章的 HTML 链接
- 网站：https://www.thefivekey.com/
付费专栏：https://www.thefivekey.com/premium-design-subscription/