Posts on Hi, I'm 5key

Heptabase VS Tana，两种不同的知识管理逻辑

Wed, 05 Nov 2025 00:00:00 +0000

篇首语

2022 年，我离开了公司。十多年陆陆续续做的记录，随着电脑一起交还了回去。那一刻其实挺好，终于不用再去维护那些零散、混乱的信息了。

对我来说，这是一次从零开始的机会。没有历史包袱，也不用考虑数据迁移。我可以重新搭建一套属于自己的知识体系，围绕我接下来真正关心的领域和命题，重新构建思考的框架。

后来我陆续接触了 Heptabase 和 Tana。

这两款工具的思路完全不同，一个强调空间，一个强调结构。这几年里我也在它们之间来回切换，想找到一个最合适的方式，但却又始终没能真正解决我的问题。总觉得哪里不太对，却又说不清。

直到今年，我才慢慢意识到，问题并不在工具本身，而是我把自己困在了「All in One」的执念里。总想着在一个工具里解决所有场景的需求，结果什么都顾不上，也什么都没做好。

所以，这一期的文章，我想重新聊聊知识管理这件事。聊聊我这几年在工具之间的反复和困惑，以及我现在怎么看「如何选择一款知识管理工具」。

Heptabase vs Tana

这两款产品的特点其实非常鲜明，差异也很大。

从表面来看，Heptabase 更像是一个帮助你看清全局、发散思考的工具。它把笔记这件事彻底空间化，让你能像警察办案那样，在一块白板上把所有线索思路连接起来。

那些原本散落在各个角落的想法，突然被放在同一个平面里，变得可以移动、组合、连接。你能清楚地看到思考的路径，也能在重新排列的过程中，发现新的关系与洞见。

当然，让我真正决定付费的并不是当时的产品形态，而是它背后的理念。Heptabase 的核心并不是「记录」，而是「理解」——它让思考变成一个空间事件，而不是文字的堆叠结果。

创始人 Alan 对如何思考知识这件事的理解，远比市面上大多数笔记产品要深。大家感兴趣的可以去阅读一下他这篇文章。

Heptabase: My Vision Project Meta

而 Tana 的重心则完全不同。它关注的不是「全貌」，而是「结构」以及结构化之后组织信息的方式。

我一直很喜欢节点式、大纲型的工具，因为它足够简单、快速，最适合即时记录想法。

还在公司的时候，我用过很长一段时间 Logseq 和 OmniOutliner，它们都很好用，但问题也很明显。内容容易变得零散、粗放，彼此之间缺乏联系。每条笔记都像是一个孤岛，你知道它们存在，但很难串联成体系。

Tana 出现后，演示视频立马就吸引了我。它在大纲的基础上引入了 Supertag，让每个节点都可以带上语义结构。从「记录信息」变成了「组织知识」。

这种方式极大地弥补了 Logseq、OmniOutliner 在信息管理上的不足，也让我真正感受到笔记其实可以是「有逻辑的网络」，而不是一堆堆分散的文本。

当然，Tana 也是我接触过学习门槛最高的一款工具。

它不像 Heptabase 那样容易理解，而是要求你具备相当强的结构化思维能力。你得自己去定义、去构建、去设计那套逻辑关系。这个过程很难，也注定需要反复的尝试。坦白讲，我中途放弃过好几次，直到最近一年后才真正用顺手。

进一步展开聊聊

工具类产品有很多，但真正有生命力的，从来都不是因为功能的堆砌，而是因为它背后都会承载着一套独特的思考方式。

每一个好的工具产品，其实都是创始团队对某个领域的理解外化。他们看问题的方式，决定了产品的形态，也决定了使用者被引导去思考的路径。换句话说，工具不只是一个被动的载体，它也是一种思维的表达。

Heptabase 和 Tana 正是这样两种典型的外化结果。一个是把「思考」空间化，一个把「知识」结构化。

业务思考力，设计师跳出执行的起点

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

我们一直强调，设计是要服务于业务目标的。但在实际工作中，这句话往往会变了味。

大多数时候，业务目标是由一系列数字呈现的。数字看起来明确、量化、可追踪，所以也就理所当然地变成了决策依据、优先级判定标准。但问题也就出在这里，我们每天面对的是 KPI，而不是目标本身，这就让设计工作很容易变得看起来合理，实际上却偏离了核心。

KPI 是起点，但并不是答案

KPI 本意是为了帮助我们从目标回推行动，但在实际工作中，它往往变成了另一种“任务指令”。指标一旦被拆解到每个人头上，就很容易变成一个明确的执行目标，而不再是一个值得分析的问题。

我们会习惯性地围着 KPI 做设计：DAU 要上涨，那就提升 Push 的频次；GMV 要提升，就改按钮、调样式；点击率要提升，那就多加俩弹层。

这些操作不一定错，但很多时候，它们只是“指标驱动”下的机械响应，而并未真正回到目标本身的去理解它的目的，从而反过来思考我们究竟应该选择什么样的路径和方法来达成？

事实上，很多的需求在流转过程中逐步失焦，并不是因为老板瞎定目标，也不一定是 KPI 本身出了问题，而是大家在拆解 KPI 时，把它当成了终点，而不是线索、问题。这也是最常见、也最隐蔽的认知错位。

KPI 是我们实现业务目标推理链路上的线索节点。你需要做的，是搞清楚它和目标之间的逻辑关系，以及它和当前设计工作之间的传导逻辑。

如果你发现这之间没有可验证的连接，那你就要停下来问一句：我现在做的，是为了实现目标，还是只是为了完成一个动作？

用户反馈不等于业务问题

如果说 KPI 让我们在执行上会失焦，那用户反馈的问题则往往会让我们在方向上跑偏。

很多设计师在面对用户的声音时，会本能地站在「同理心」的一边。我们习惯说，“要为用户而设计”，于是只要用户说“这个地方不好用”或者说“我希望能有某个功能”，我们就会将它们一通整理，然后写一个 PPT 告诉需求方，产品需要改进、体验需要优化。

这看起来很负责任，也很为用户着想，但同时也可能会出现跑偏的问题。

用户说的，真的是他的本质问题吗？他描述的是需求，还是他自己想象出来的解决方案？

大多数情况下，用户反馈的是某个体验层的卡顿感。比如“流程不合理”“步骤太多”“结构不清晰”。但这些感受并不等于问题本身，它们往往还存在着更深层次的问题。

你得顺着这些反馈往下挖。你要问的不是“他说了什么”，而是“为什么他说这个”。更重要的，是判断这个问题是否真的和我们的目标相关，是否值得投入资源去解决。

而判断的标准，不是谁的声音大、谁抱怨多谁就对（对于产品经理的沟通同理）。而是这个问题，是否来自我们真正要服务的那一类人、那一类场景？

不是所有用户的问题都需要被解决。一个产品的核心竞争力，恰恰来自于它知道该为谁解决问题，也知道不为谁解决问题。

所以下当一次我们面对用户的问题，不妨思考一下：这是症状，还是根源？是个体，还是代表？是“我们要服务的用户”，还是“我们暂时不解决的场景”？

看到这里，相信你对「设计师如何理解业务目标、判断需求价值」已经有了一些新的思考。

那么，后面的内容将更值得你深入了解。

在这篇文章剩下的付费部分，我将继续展开三个关键问题：

01. 如何判断一个需求值不值得做？
拆解业务目标，建立需求与转化路径之间的连接逻辑。

02. 如何构建自己的业务本体结构？
用一个案例，展示如何将获取到的信息转化为思考、决策的支撑。

03. 有了判断，如何把握时机？
不是表达得快就有效，而是要谋定而后动，选对节奏精准出手。

欢迎订阅我的小报童专栏，解锁本期文章全文内容。

从做设计，到构建秩序

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

很多设计师在工作中，常常会陷入一个熟悉又尴尬的状态。想着怎么把界面做得更漂亮一点，交互更高级一点，细节更精致一点。希望用这些工作，来提供更好的用户体验。

这事儿听上去没毛病，说到底是想把用户体验这事儿做到极致。但慢慢你会发现，这条路会越走越窄。

你推敲界面布局、打磨交互模式、调整风格样式，几乎把所有能做的细节都做到了。可产品体验还是没太多变化。用户依旧困惑，流程依旧卡顿，业务数据还是一样没有变化。

这其实是因为，体验从来就不仅仅是设计的事情。你看到是界面设计，但用户真正感受到的，是整个业务逻辑、产品流程以及界面设计的综合表达。

而业务逻辑和产品流程，大多数早在设计师接手之前，就已经决定了。于是就出现了一个常见的悖论：越想体现设计的价值，越容易深陷在细节里死磕。结果忙活了半天，却忽略了真正影响体验的地方。

说白了，这种状态，就是为了设计而设计。

听上去挺专业的，其实很多时候，不过是我们对自我价值的一种焦虑回应。但企业看重的不是这些。他们关注的是整个产品是否高效可控，是团队能否稳定产出，是设计投入能不能带来实际的商业价值。

他们要的，不是设计的最大化，而是业务价值的最大化。

想要改变这一点，设计师就不能总窝在自己的世界里打转。我们得往前多走一些，去看业务逻辑、产品流程，甚至是整个产品的服务流程。

但问题是，我们想往前走，得先把眼下的事儿理清楚。一个设计方案落不落地，一套组件库是否通用，一个交互模式是不是每次都得争… 这些问题不解决，哪还有空去谈体验的本质？

所以，在我们想办法改善设计的价值之前，先得想办法让设计这件事本身，变得更稳定、更高效、更少争议。

而这背后的关键，就是确定性。

什么是确定性？

所谓的确定性，就是不用每次项目都得重新判断、重新选择、重新争论。流程清楚、形式明确、结果可预期。越稳定的系统，越容易复制，越能高效地产出。而设计这个环节，恰恰是最缺确定性的地方。

一个设计师换一套风格，每个项目抠自己的交互细节，左滑右滑各有各的说法…… 本来只是想要增加一个用户提示，最后还得为弹窗是否可以关闭争论个半天。

所以我们需要的是一个工具，来把混乱收敛成秩序。而设计系统，正是用来解决它们的一套有效机制。

设计系统中的确定性

在一款产品的诞生过程中，通常有三个关键角色。

产品经理决定做什么，工程师负责怎么实现，而设计师，通常负责的是怎么呈现。也就是把业务逻辑、业务的意图，用一种清晰、易懂的方式传达给用户。

但现在的问题是，大部分互联网产品的形态早已稳定下来，能重新发明的地方越来越少。大多数时候，设计并不需要创造一个新界面，而是用最小的代价，给出一个稳定的解法。

而在这种背景下，设计系统的重要性就体现出来了。

说到设计系统，时至今天，依旧有很多人对它有着错误的认知。认为它只是一套样式手册，或者一堆组件拼起来的 UI 组件库。这些当然都是它很重要的一部分，但如果只停留在这个层面，其实是极度低估了它的价值。

设计系统不是样式手册，更不是一个 UI 仓库。它的本质，是一套帮助企业构建秩序的工具。目标很明确：用结构化的方式抽象最佳实践，压缩设计成本、减少沟通代价、降低出错概率。

不同设计师有不同的习惯，不同团队有不同的理解，结果是就是一个业务模块，看起来像三个人分别做了三套界面。更麻烦的是，这些差异背后往往还要伴随着大量的时间消耗。光是到底怎么做这件事，团队就要反复争论、推翻、重来。设计资源被反复浪费，方向也在拉扯中开始跑偏。

这些混乱堆在一起，带来的就是企业层面的设计磨损。

而设计系统，就是试图用结构、规则和共识，把这些磨损控制在可预期的范围内。它不是限制你的发挥，而是减少那些不必要的浪费。已经验证过的方式，不需要每次都重来一遍；早就清晰的交互，也没必要每次都开会讨论一遍。

它提供的，是一种可复用的稳定方案。把那些可以标准化的部分，抽离出来，封装成可直接使用的 Pattern，让每个设计师在面对同类问题时，不用再从头来过，也不用在细节上反复纠结。

说到底，设计系统真正想做的，是把你从反复判断中解放出来，把你真正的脑力，留给更重要的地方。

所以它强调的是一种有界的自由，解决设计过程里的不确定性。

Pattern，设计系统中的秩序单元

你可能也意识到了。要解决“为了设计而设计”的困境，光靠经验和努力是不够的。

真正能帮你跳出细节死角、建立稳定机制的，是一套结构化的认知方式。

而 Pattern，正是这套结构的关键思考模式。它不是样式手册，不是组件集合，而是一种让设计思维从“界面设计”走向“秩序构建”的方法和思考模式。

在接下来这篇文章的付费部分，我想继续和大家深入聊聊：

Pattern 如何构建“团队共识”？
为什么说它才是设计系统中最核心的秩序单元？
当 Pattern 成为基础能力，设计师又该如何改变自己的角色？

如果你也正在面临开头提到的那些困扰。那么也许，是时候换一个更结构化的方式来看待设计这件事了。欢迎订阅我的小报童专栏，解锁后续全文。

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

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

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

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

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

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

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

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

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

这事儿的可行性有多高？

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

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

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

产品界面的 AI 生成，不是一个新鲜话题了，每隔一段时间我们都会拿出来讨论一下。过去两年我陆续就写过一些相关的文章。那个时候，这个方向正热，无论是海外的 Uizard，还是国内的各大设计协同平台，大家都在推“用一句 Prompt 来生成界面设计”，似乎接下来这些界面设计的工作都可以交给 AI 来完成了。

看上去方向已经跑通了，行业共识几乎已经形成。但热闹了一阵子后，这些平台却都渐渐地没了声音。这有是什么原因呢？在我看来，核心在于在经过了初期的探索、兴奋之后，大家逐步意识到，从“能够生成”到“能够在业务中使用”之间，存在一条看不见的鸿沟，而这条鸿沟我们暂时还无法跨越过去。

如果把这个问题拆开来分析，你会发现其实背后卡住我们的，核心并不是某些技术上的难题，而是存在着三个不同层次的问题叠在了一起，导致了现在的“停滞”局面。

从“能用”到“能用”，中间隔着的三道坎

在这里，「能用」这个词其实有两层含义。

设计师的下一站，成为架构师，还是走向业务？

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

在上一篇文章「从做设计，到构建秩序」里我们提到，设计系统的真正价值不在于样式和组件的统一，而在于提供确定性。

尤其是通过 Pattern 这种面向问题的抽象思路，把常见问题的解法沉淀下来，帮助设计师跳出细节，专注更高阶的业务思考。

当这套机制建立起来，设计师不再需要花精力来每一次都从头开始。那么问题来了，当这些重复性的工作被系统接手之后，设计师的角色会走向哪里？

今天这篇文章，我就想接着这个问题往下讲讲。

当设计不再从零开始，设计师应该往哪儿走？

设计系统完成某个阶段后，设计师的日常开始变得熟悉甚至有些重复。你会发现，很多事情都已经被提前定义好了，你要做的，仅仅是 “照着来”。看起来轻松了不少，但也开始让人感到焦虑：

如果我的工作变成使用既定的方案，那么我还能创造什么价值？

这是一个很现实的问题，也是在设计系统逐步成熟之后，许多设计师共同的焦虑。

但大家要知道，设计系统的建设从来不是一劳永逸的事。它更像是一个持续演进的过程。随着业务的拓展、产品形态的变化，系统也需要不断被更新和迭代。

它没有“最终版”，也不存在“完成时”。

也正因为它变成了一项长期存在的基础设施，也就不可避免地，带来了设计协作方式的变化。设计逐步走向一定的中心化，秩序逐步显性化。

设计系统构建团队负责制定通用规范，其余设计师则深入到业务，以这些规则为基础推动产品演进。大家在各自“既定边界”内创造更大的价值。

有些人会继续深入到行业和业务中，提炼共识、持续地构建确定性；而其他更多的设计师则走向业务，将 Pattern 和组件当作“标准件”拼装调度，用设计去解决实际问题，推动产品落地。

如果没意识到这种转变，那么依旧会停留在执行细节里原地打转。今天改布局，明天调动效，每天都在赶交付、救火、填坑，忙得身心俱疲，却不知道这些工作是否真的还有价值。

这些看似必不可少的工作，其实设计系统早就在一点点接管。你还在一块块堆砖头，人家已经在起楼了。

但如果你能看清这个变化，意识到设计早就不是把需求一个个画出来。它不是在手动复刻业务流程，而是用系统化的方式，把重复劳动压缩到最小，让真正重要的部分浮出来。比如业务逻辑、产品流程、信息结构等等。

当你开始把这些问题当成你需要解决的设计问题来看，那么就会发现你的设计空间，不是变小了，而是被重新打开了。

其实早在 2020 年，我在负责集团设计中台团队时，就隐约意识到一个趋势：未来的体验设计师，会逐步分化为两类角色。一类负责构建设计系统、制定规则的架构型设计师，另一类则深入业务一线，推动产品落地与业务增长，是更偏执行与协同的业务型设计师。

当时只是作为一个内部判断提出，并不确定是否成立。但几年过去，越来越多的团队和公司，正在沿着这个方向演进。

这不是因为谁预判得准，而是因为这本就是行业走向成熟、协作方式系统化之后的自然结果。

但这两个方向，真的有清晰的边界吗？我们又该如何判断自己适合哪一条路？这些角色背后，又分别隐藏着哪些挑战和机会？

在这篇文章的下半部分，我想带你一起聊聊我对这两类设计师的理解和观察。

如果你正面临选择，或者正在寻找突破瓶颈的新方向，希望这些内容能为你提供一些思路。

欢迎订阅我的小报童专栏，解锁本期文章全文内容。

当用户喝多了，需要找代驾

Fri, 21 Mar 2025 00:00:00 +0000

一个找代驾的故事

前两天晚上有个饭局，朋友喝得有点多，准备叫个代驾回酒店。他低头打开手机，目光呆滞地盯着屏幕，手指在屏幕上划来划去，捣鼓了半天。几分钟后，一脸不爽的把手机扔到了桌上，嘟嚷了一句，什么破玩意，太难用了。

最后，他女朋友接过手机，把代驾叫好。无奈地笑笑说：“确实有点复杂，喝多了还真不好操作。”

这时我在想一个问题：是不是所有喝多了需要代驾的人，都会遇到同样的麻烦？头昏脑胀、眼神飘忽、手指不听使唤，这种状态下，掏出手机还能顺利下单吗？

我不喝酒，所以也从来没有经历过醉酒后叫代驾的场景，因此我没法靠亲身体验来判断。但作为一名设计师，我对这个问题有点兴趣。

回到家，我打开某出行 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）。

多邻国 Handbook 中文版

Sat, 22 Feb 2025 00:00:00 +0000

本文档由 5key 借助 DeepL、Perplexity 进行翻译，并结合个人理解完成校正，旨在为网友提供学习参考。如有翻译不当之处，敬请谅解。

原文 PDF 文档见底部链接。

转载请注明出处：https://xiaobot.net/post/a615ae51-416a-40c4-92a9-9412eb644202

我们的使命是发展世界上最好的教育，并普及到全世界。

CEO 路易斯的来信

Duolingo 是一个古怪的地方。

我们的文化并非照搬科技初创公司的行事准则。它是由几十个书呆子在宾夕法尼亚州匹兹堡一家体育酒吧楼上的一间办公室里从零开始打造的。

对于大多数早期员工来说，Duolingo是他们第一份真正的工作。由于缺乏经验，我们不得不在基本问题上不断摸索：我们应该雇佣谁？开发一款应用程序的最佳方式是什么？我们应该如何组织开发工作？这样做需要时间。但最终，没有什么比这更能促进我们的文化和取得成功。

随着时间的推移，我们逐渐完善了对这些问题以及更多问题的回答。如今，十四年过去了，我们决定将这些答案写下来，并阐明我们是如何做这些事情的。

这本书的核心是五项原则。这些原则并非空想，而是我们从经验中总结出的教训。但它们也是鲜活的思想：它们内部存在矛盾，有些地方并不总是适用。我们希望您仔细研究、挑战它们，帮助我们改进这本书的下一版本。

感谢您的阅读，欢迎来到 Duolingo。

TL;DR

01. 放眼长远，从长计议

我们致力于打造一款永续发展的产品，将用户的长期留存放在首位。

我们招聘卓越的人才，与 Duolingo 共同成长，并塑造未来数年的发展方向。

我们正在创建一个百年品牌，赋予其令人愉悦且独特的角色形象，使其成为学习者生活的一部分。

02. 提高标准

我们交付的每个功能都必须直观、令人愉悦、实用且精致。

我们确保关键任务有明确的负责人。

我们不断内部测试自己的产品，发现问题并提出改进建议。

我们提供坦率的反馈，关注“问题是什么”，而非“是谁的问题”。

03. 快速交付

我们优化流程效率，尽量减少步骤之间的间隙以保持工作节奏。

我们每周运行数百次实验，以持续改进我们的产品和组织。

我们无情地优先处理影响最大的项目，并迅速淘汰无效的内容。

只有当新流程能帮助我们做出更快、更好的决策时，我们才会引入它。

04. 用结果说话，而不是解释过程

我们以工作成果为导向，而不是讲述努力的过程。

我们的产品无需自我解释，它们应该对所有人都直观易懂。

当我们意见不一致时，我们会测试想法，并让数据和指标来决定。

05. 让一切变得有趣

我们的产品以“玩”为基础，通过游戏化和设计让学习变得有趣。

我们的品牌健康向上但又不拘一格：我们专注于让粉丝发笑，即使并非所有人都能理解笑点。

我们的办公室和文化设计充满古怪和欢迎感，激发快乐并在团队成员之间建立联系。

The Green Machine

吸引并任用优秀的人才。

明确成功的定义。

设定安全边界，并着眼于长远规划。

构建产品并建立反馈循环。

从「白板」开始你的设计工作

Thu, 13 Feb 2025 00:00:00 +0000

你会如何开启设计工作

很多设计师拿到一个新需求时，第一反应往往是习惯性的打开设计工具，比如 Figma 或 Sketch 开始设计。

为什么会这样？

其实这不仅仅是工作习惯的问题。更重要的是这些设计工具已经成为我们的“主场”，是我们的舒适区。就像工程师需要记录点信息时，第一反应是打开自己的代码编辑器。我们都在各自的安全领域中“安营扎寨”，在工具中舒适地“解决问题”。

这其实也并不是什么坏事，毕竟趁手的工具干起活来效率高。但问题就在于这种依赖性，其实会把我们“圈”得死死的，导致我们很多时候不自觉地陷入细节，而忽略了更重要的思考。

想象一下，当你打开设计工具，面对那些熟悉的界面和准备好的模板、组件库，会让我们不自觉地进入到设计的实现中，开始沉迷于界面设计的细节。一会改一个布局，一会调整一下组件的位置。于是，我们就掉进了细节的陷阱里，开始在“小问题”上耗费大量时间，最终不自觉地忽略了背后的更重要的业务需求、用户痛点，甚至我们本该考虑的设计策略，也是在最后评审时“反向推理”出来的。

设计得虽然好看，但可能并没有能真正的解决问题。

而事实上，一个真正好的设计方案的核心，并不是能画出多少炫酷的界面，而是是否能理解业务需求、分析用户问题、找到合适的设计策略。这些前期的思考环节做得足够扎实，最后的设计实现才能真正的站得住脚。

总的来说，一个好的设计方案，其实应该是：七分思考分析，三分设计实现。可是，现实往往是我们花了七成时间搞设计实现，剩下的时间都用来在思考上“打酱油”。

企业如何看待设计师的专业能力？

曾经，企业可能更关心设计师的技能树。你能掌握哪些设计工具？擅长哪些设计方法？能不能做出一些酷炫的交互原型？但现在，企业更在乎的是你能不能用设计帮助公司获得增长，帮助公司营利。

设计不光是为了好看，它最重要的任务是好用。能让用户更舒服地使用，进而带来商业价值。如果设计最后还是不能解决问题，再精致再华丽也不过是“空中楼阁”，根本不能为公司创造实际价值。所以，设计师的角色已经不再是做个漂亮的界面那么简单了，再好看的设计也不能忽视「生意」的本质。我们还得成为「问题的解决专家」。

AI vs 设计师，应该选哪个？

当我们还在死守专业的时候，不要忘记了在另一边还有一股“力量”在试图替代我们。随着这两年 AI 能力的突飞猛进，我们的传统技能，比如设计流程、画界面之类的活儿，已经越来越容易被机器取代。

以为对专业工具的操作和界面设计的能力就足够形成牢固的壁垒了吗？不好意思，AI 也能干，而且比我们更快，还没有情绪、不需要休息。虽然它们现在可能只具备一个实习生的能力，但它的“晋升”速度可能会比我们想象的快得多。

去年年底兴起的 Cursor、Windsurf，能够帮助我们直接完成需求文档到产品实现的路径。甚至更进一步的 Devin ，我们已经可以把它当成团队里的一位新成员，它们能做的事，可能比我们想象的还多。

虽然 AI 在设计实现方面的能会越来越强大，但这里依旧在某些方面暂时还无法替代我们。那就是对业务的理解、问题的分析、策略的制定，总的来说，就是我们对业务思考的能力。而这些，也正好是企业对不仅仅是设计师的每一个角色在当下最核心的期望。

从白板开始你的设计工作吧

我们前面提到，设计师的工作应该是“七分在分析，三分在设计实现”。也就是说，设计师应该花更多时间思考和分析，而不是直接进入设计工具进行细节的实现。

理解我们需要进行思路的转变不难，难的是如何实施。在我看来，工具是一个具备可行性的切入点。白板就是这种思维方式的具体体现。

白板不仅仅是一个工具，它是一个思考的空间，是设计师跳出工具局限，全面分析问题、构建解决方案的地方。

接下来的付费内容中，我将通过一个实际的案例，向大家展示如何利用「白板模式」进行设计的前期工作。确保我们的设计思路清晰，决策有依据。

入职新公司，学会问问题才能少踩坑

Wed, 22 Jan 2025 00:00:00 +0000

刚入职新公司时，如何问问题对设计师来说常常是一件让人头疼的事情。满脑子的疑问，却又害怕问多了显得蠢，被同事觉得自己不够专业。于是，问题被默默地藏在心底，想着自己慢慢摸索吧。

最后，当你满怀激情、疯狂熬夜加班，准备打响自己的第一炮时，方案却在讨论的那一刻暴露出了不少偏差。虽然大家并没有责怪你，但从同事们的礼貌微笑里，你仿佛能看到一层不易察觉的尴尬。他们的眼神似乎告诉你：“这位新同学，可能并没有大家期待的那么好。”

你会开始意识到，搞清楚公司的业务背景和现状，才是当下最重要的事情。此时你才明白，不问问题，比问问题的“蠢”更可怕。

没有人指望你刚加入就了解一切。真正让团队失望的，是你在面对疑问时选择沉默，不敢开口。当你不敢提问，怎么能够融入团队，如何去了解业务的脉络，进而做出有效的设计呢？

为什么问问题如此重要？

作为设计师，你的工作远不止是做做设计稿。设计的核心，是在真正理解业务需求的基础上，提出有价值的解决方案，推动产品的前进。可是，如果连业务的基本情况都还没弄清楚，交出的设计方案怎么可能靠谱呢？

想象一下，你满怀信心，花了几天时间精心完成了设计方案，终于准备好召集团队进行评审。结果，当方案一摆上桌，大家的反馈让你有点懵。那些你精心雕琢的设计细节，可能与真实需求严重脱节，功能安排也显得不合逻辑。

更糟糕的是，你意识到这些问题其实应该在前期通过沟通来避免。你明明可以在设计初期问清楚这些背景信息，却因为纠结于要不要问问题，最后把自己搞进了死胡同。

如果在开始前没能把核心需求和目标搞清楚，那么设计就可能完全跑偏。结果不仅浪费了团队的时间，还可能让你成为“误事”的源头。大家虽然嘴上不说，但眼神里的意思已经溢于言表：“下次，记得先问清楚。”

在团队里，大家希望设计师能解决问题，而不是增加麻烦。一次失误，大家或许能理解，笑一笑就过去了。但如果你一直“盲目设计”，凭空猜测，缺乏沟通和反馈，信任就会悄悄溜走，像沙漏中的沙子一样，渐渐流失。

为什么新人总是害怕问问题？

新人不敢提问，大多不是因为问题太难，而是害怕“别人怎么看我”。其实，你真正应该害怕的，不是别人觉得你笨，而是你假装懂，却把事情搞砸了。无知不可怕，装懂才真正可怕。

三大提问阻力：

01. 别人会觉得我很蠢吗？

每个新人都会有这样的担心。“我才刚进公司，怎么敢问这些基本问题，万一让别人觉得我不够聪明？”但你需要明白，没人指望你一进公司就什么都懂。

真正让人失望的，是那些不懂装懂，最后把事情搞得一团糟的人。如果你能坦诚地提问，反而能让人看到你对工作和团队的尊重。

02. 会不会打扰打扰别人？

团队里的每个人都很忙，特别是那些资深的“老同事”。他们看上去忙得像机器一样。但忙并不代表不能问，关键在于你提问的方式和时机。

如果你提前整理好问题，简洁明了地提出，没人会觉得你是在打扰他们，反而会觉得你在节省他们的时间。问得合适，大家反倒会觉得你是个“懂事”的新人。

03. 会不会显得自己没准备？

这种担心也挺正常的。尤其是当你发现，自己能通过文档或调研先找到答案时，再提问可能会觉得不够“专业”。但问题在于，如果你没有先做功课，或者做的功课不够深入，那提问其实是一种对自己工作的负责。

做功课是对问题的尊重，但如果真的无法解决，提问才是提升自己效率的关键。提问不是为了展示自己的“无知”，而是为了避免浪费时间和资源。

你付出的不是“问题的成本”，而是错过答案的代价。在团队里，最容易被浪费的资源就是沟通。你不问，别人不会主动告诉你，而你在盲目猜测和反复修改中耗费的时间和精力，才是最大的成本。

举个例子：

有个新人负责设计一个OMS（订单管理系统）页面，满怀信心地交付给团队进行评审。

结果，设计方案被推翻了：“这个页面的功能布局完全不符合我们流程的要求，我们的用户群体主要是大型企业客户，为什么要设计成这么简单的界面？”

产品经理的一句话让新人有些懵。

如果他在初期就主动提问，花几分钟确认需求和用户场景，这一切本可以避免。结果，不仅浪费了自己的时间，还浪费了团队的时间，甚至让自己成了“误事”的源头。

如何开始问一个好的问题？

问问题，远远不只是开口那么简单，它是一门技术活。什么时候问？怎么问？问到什么程度才算到位？哪些问题最好别问？是我们最需要关注的。这些细节决定了你在团队中的形象，是一个“能搞定事”的人，还是一个“搞不清事”的麻烦制造者。

在接下来的付费内容中，我会跟你聊聊更深入的话题，包括：

问问题过程中的常见坑：那些你一问出口，别人就开始翻白眼的问题，为什么总是让你踩到？
问问题前的准备工作：为什么有些问题问得精准、有深度，而有些问题让人觉得你毫无思考？秘诀全在开口之前的准备。
如何递进式地提问：问一个问题是起点，但问出连贯有逻辑的问题，才是真正解决问题的关键。
什么时候提问最合适：提问的时机，直接决定了回答的质量。问得聪明的人，总是能在恰好的时机获得恰好的答案。

加入 OFF DESIGN，你将解锁本期付费内容。以及全年更新的不低于 100 篇的专栏文章。

好的简历作品集，需要有层次的表达

Tue, 14 Jan 2025 00:00:00 +0000

在设计师的职业生涯中，能遇到一个真正从 0 到 1 的项目无疑是一种幸运。它的复杂性和系统性让人抓狂，但同样，它也给了你在面试中大放异彩的机会。

当你终于完成了产品背景、行业调研、实际案例、竞品体验分析和设计方案，并把这些成果整理到作品集中的时候，一个疑问突然冒出来：我这些内容该怎么讲？面试官会不会根本就不会看？

0 到 1 项目的优势和困惑

0 到 1 项目的优势显而易见。它能讲的内容非常多，从业务背景到设计落地。

你可以用一个系统化的链路去展现自己的专业能力，也可以从细节中体现你如何深度参与每个环节。但问题也随之而来。很多人在面试的时候，开始心生顾虑：

讲太细：面试官可能对前置研究没兴趣，会觉得你在浪费时间。
讲太少：又担心自己表现不够全面，面试官无法理解你到底干了什么。

于是，有的人选择按部就班，把所有流程从头到尾摊开来讲。还有人干脆一头扎进细节中，试图用竞品分析的表格和数据直接“砸晕”面试官。结果呢？对方可能微微一笑，轻轻地打了个哈欠。

如何破局？分层表达是关键

对于 0 到 1 的项目，最重要的不是“讲多少”，而是“怎么讲”。我的建议是：对内容进行分层，把流程和细节拆开，用不同的方式呈现。

第一层：项目流程，提炼出方案主线

这部分是向面试官展示你思路清晰、能抓住关键问题的能力。

你的表达逻辑可以是这样的：

业务问题：为什么会有这个项目？你要解决什么问题？
核心指标：业务方的关注点是什么？你们设定了什么衡量成功的标准？
产品能力：从业务问题到产品方案，中间的链路是什么？
设计策略：在确定方向后，你具体采取了哪些设计策略来支持目标？
设计方案：最终呈现的产品是什么样的？它解决了哪些问题？
数据验证：结果如何？通过什么数据说明你成功了？

这一层的重点不是细节，而是做了什么、得到什么结论、推动了什么进展。

面试官不需要了解业务的所有背景，但需要知道你的目标是什么，你的方法是什么，你的结果是什么。你是如何通过逻辑推导，逐步解决问题的。

第二层：实施细节，为主线提供弹药

这一部分是用来深入展开的。当面试官对某些结论产生兴趣时，你可以从容地打开“工具箱”，为主线提供更细节的支撑信息。

比如：

行业调研中，你用了哪些方法？得到了哪些关键发现？
竞品分析中，你关注了哪些维度？为什么这些维度很重要？
设计方案中，有哪些具体的创新点？它们如何与核心目标挂钩？

这里的关键是“可展开但不赘述”。细节只是你的支撑材料，而不是主线内容。

好的表达是需要有层次的

不管是面试还是作品集，缺乏层次感的表达往往会让人觉得枯燥乏味。很多失败的案例，问题并不是内容不够多，而是没有组织好内容的逻辑。

试想一下，你有一个非常绝妙的创意。但如果你把所有的细节从头到尾一股脑讲给面试官听，可能只会让人迷失在细枝末节里，不知道你的重点在哪里。

而如果你能先提炼出创意的核心价值，再用关键细节去充实和证明它，面试官会更容易被你的思考和成果打动。

如何让作品集“站住脚”

对于 0 到 1 的项目，作品集的陈述方式其实是可以学习“讲故事”的方法的。

从结果反推整个流程：

用一句话概括项目的最终成果，比如“通过优化流程，成功将操作效率提升了 30%”。再一步步拆解，你是如何达成这个结果的，形成一个清晰的故事链路。

突出个人贡献：

让面试官知道，这个项目中哪些部分是你主导的，哪些地方体现了你的思考和价值。

通过细节增强可信度：比如，在行业调研中，你是否发现了某个重要的用户痛点？在竞品分析时，你是否提出了某个有洞察的结论？

最后的建议

作品集的作用不只是展示你的能力，更是让面试官理解你的思考方式。

对于 0 到 1 的项目来说，最忌讳的是“从头到尾讲流程”——因为每个人的流程其实大差不差，难以突出亮点。对于 0 到 1 的项目，最好的方式是提炼主线、分层表达。

让面试官不仅知道你做了什么，还知道你为什么这么做、你的方法论是什么、你解决问题的能力又如何。记住，内容的“底料”可能大同小异，但如何组织和表达，才是拉开差距的关键。

设计的意义，得用业务语言讲明白

Wed, 08 Jan 2025 00:00:00 +0000

每一个重要的项目里，设计师和工程师都不会缺席。设计师负责将业务的想法界面化，工程师负责将这些界面和功能工程化。但几乎每一次项目中，设计师多少都会与产品经理、运营人员之间出现一些不同意见。有时候甚至会发展成争执，最终演变成“你觉得不行、我觉得可以”的局面，弄得大家都不太愉快。

问题出在哪？设计师和产品经理的逻辑难道就永远对不上吗？答案其实并不复杂。

我们工作的环境，始终是一个商业环境。而这个环境中，每个角色的目标与视角有着天然的差异。

运营人员和产品经理，是企业对商业需求的具体化表达，他们的目标非常明确：拉新、转化、留存、盈利。而设计师和工程师，尽管同样为这些目标服务，却更倾向于用自己的专业语言看世界。一个关注用户体验的美感与流畅，一个专注于技术实现的逻辑与效率。

这种视角的差异就像在用两种不同的语言互相喊话。设计师的“这交互更符合用户习惯”，和产品经理的“能不能提高点击转化率”，往往成了两种语言体系，彼此不理解，谁也无法完全说服谁。摩擦因此变得不可避免。

商业环境下，设计师的天然“劣势”

企业的核心始终是商业，而问题的本质最终也得用业务视角来解读。对于以专业视角为主的设计师来说，这是一个天然的劣势。我们精通设计的语言，但在商业这套逻辑中，却很难用专业的话语去表达设计的价值。

为什么设计师很难在业务的“牌桌”上拥有发言权？因为我们习惯把设计结果当成目标。而产品经理甚至是管理者更关注的是设计对商业目标的推动。

换句话说，设计师工作的重点不是“设计得好不好看”，而是“设计是否为商业提供价值”，最终是不是能解决业务问题。

产品经理关心的是最终的商业数字：这次改版能提升多少转化率？这个页面的点击量有没有提高？这条用户路径是否更高效？而设计师往往沉浸在自己的专业领域，视觉呈现、交互逻辑，甚至是一些设计师眼中的设计情怀。但如果设计无法转化成商业结果，那么在业务视角里，它可能就是“无效产出”。

这也是为什么，设计师可能在项目会上自信满满地展示了新设计，却被运营人员一句“这个流程复杂会不会降低转化率”击得无话可说。

设计师用体验的逻辑看待问题，但企业期待的是用增长和盈利的语言解答问题。

为什么设计师需要业务 Owner 精神？

我们常说，设计师需要具备“业务 Owner 精神”。这话听起来有点虚，很多人并不理解是什么意思？它不是让我们只用专业去解决业务问题，而是跳出专业视角，把自己当成业务 Owner，站在业务视角重新定义问题，看待设计。

业务 Owner 的视角是什么？

如果设计师在乎的是“这个界面好不好看”，**那业务 Owner 关心的则是“这个功能能不能帮我留住更多用户？”。**如果设计师想着“这个交互是否符合最佳实践”，那业务 Owner 关注的则是“这个流程是否能让用户更快完成操作？”。

简单来说，业务 Owner 精神就是要求你把业务的成败当成自己的责任，而不是单纯完成一张图、一套交互逻辑就算了。界面漂亮是一回事，但业务跑不动，你也得真心地发愁。

业务 Owner 精神不仅仅是调整视角的问题，还要求设计师在日常工作中主动去接触、理解业务的数据和问题。这就意味着，无论是设计方案的产出还是业务会议的讨论，我们的身份都应该是业务的 Owner。我们需要用业务发展的视角看待一切问题，设计只是我们最擅长的一项技能而已。

所有这些，都是在帮助你跳脱“专业”的局限，把设计的价值与业务目标紧密结合。

当设计师转为产品 Owner 时会发生什么变化？

在做了十多年的设计后，我开始转向了产品工作，一晃也五年了。当你真正开始为一个业务的生死负责时，思考方式针对会发生巨大的变化。每天我最关心的，不再是设计本身做得如何，而是更具体、更紧迫的问题：

用户量怎么样？
活跃度是否达标？
商业收入能不能支撑下个月的运营？

设计的确重要，但它只是这整个体系中的一环。每天琢磨如何让产品活下去时，你才会真正的体会到，设计不仅要服务于用户，更重要的是还得为商业目标负责。

于是，我会要求团队里的设计师要用业务的视角来看设计。如果一个设计对业务没有贡献，那它再精致也是失败的。

设计师需要从“设计好不好看”，走向“设计对业务有没有价值”。这样的转变并不意味着抛弃专业，而是要求我们从专业的层面出发，为业务创造更大的价值。设计是帮助业务实现目标的工具，而不是业务的负担。

而首先，我们需要从真正的理解业务开始。

理解业务的第一步,数据和设计的语言转化

企业中，业务目标的语言是数据：转化率、收入、月活、日活… 这些指标是衡量成败的信号灯。

产品经理常说：“这个页面转化率太低了，能不能调整一下流程？”设计师回答：“调整流程会牺牲体验啊，用户可能觉得麻烦。”

表面看起来，这像是两个无解的问题，实际上，这恰恰是我们在职场工作中最大的劣势。我们需要学会用数据和专业语言对话。我们需要学会用商业语言和专业语言对话。

设计师只有从数据中找到设计的依据，把自己的专业思考转化为商业逻辑，才能更好的与产品经理和运营人员进行同频的沟通。

也才能够更加成熟的思考设计于商业的价值。

如何正确地理解数据，并让数据真正为设计所用？关键在于为业务问题和设计方案之间建立清晰的关联。

首先要做的是切换到业务数据的视角，了解问题的本质，而不仅仅停留在表层的体验数据上。接着，还需要借助一套强有力的观察指标，帮助我们建立设计与商业目标之间的连接。

这不仅能论证设计的价值，也能让我们反思设计的必要性，确保每一个方案都在为业务增长服务。

在做设计中台产品的那个阶段里，有大量的时间在做汇报。我需要有一个能够同时面向于老板们和团队内的指标，来让大家对产品的有一个共性的直观感知。

所以我创建了一个观察指标，我将它称之为功能价值指数（FVI）。

在对 FVI 指标不断优化的过程中，我开始逐渐找到了一个商业与设计之间理解数据的平衡点。同时帮助团队更好地建立商业目标与设计之间的链路。

接下来，我将在本期文章的后半部分（付费）内容中，通过具体案例详细解析如何用 FVI 将设计与商业目标挂钩。

在付费文章中，你将看到：

功能价值指数（FVI）详解，及其在数据中挖掘设计洞察的应用
以 Spotify AI DJ 为例，解析 FVI 如何量化设计的业务价值

加入 OFF DESIGN，你将解锁本期文章的全文内容。以及全年更新的不低于 100 篇的专栏文章。

HQ&A 笔记法：让你的思考更有效 (上)

Sun, 29 Dec 2024 00:00:00 +0000

女儿的历史复习资料中有这么一段 Highlight 的知识点。

汉武帝从政治、经济、军事等方面巩固了大一统的局面，使西汉王朝开始进入鼎盛时期。

到期中测验的时候，考题却问的是：汉武帝在政治、经济、军事等方面采取了哪些具体举措？考完试女儿就怒了，抱怨历史老师太不地道了。我只能笑笑安慰，恭喜她正式地感受到了「教你一滴水，考你一片海」的精髓。

其实，这种“水与海”的逻辑不仅存在于学校里，在我们的日常工作中也很常见。比如，项目需求会上你认真记录了一堆关键信息，觉得自己已经掌握了全局。可一到业务分析会议，大家讨论得热火朝天，你却发现，记了很多，但也聊不出啥。

“复习点”与“考点”之间的鸿沟，是学习和工作的常态。要跨越这道鸿沟，我们需要用方法，把“看似懂了”变成“真正明白”。在这一类场景里，HQ&A 笔记法就是一个非常不错的选择。

什么是 HQ&A 笔记法？

HQ&A 是 Highlight（标记重点）、Question（提出问题）、Answer（回答问题）的缩写。它的核心在于，将复杂的知识点层层剥开，化整为零，再重新组合成逻辑清晰的体系。

第一步：Highlight（标记重点）

首先，将你在日常中认为有价值的信息记录下来，比如一句话、一个结论，甚至是一个关键词。这里要注意，不要贪多，不要把整段内容一股脑保存下来。重点是提取关键信息，而不是为笔记增加负担。

第二步：Question（提出问题）

接下来，对标记的重点提出问题。建议从自己的角度思考三个问题。比如：

这个结论是怎么来的？
它的前提是什么？
它可能带来的影响有哪些？

提问的过程，其实就是将信息解构和挖深的过程。

第三步. Answer（回答问题）

最后，根据你的理解，尝试回答这些问题。回答时，尽量结合上下文或相关知识进行分析和拆解。这个环节不仅让你对问题有了更清晰的思路，还能帮助你把知识点转化为自己的洞见。

现在，我们用 HQ&A 方法再试试

汉武帝从政治、经济、军事三方面巩固了大一统

这句话看似言简意赅，但如果直接背诵，很可能只记住几个关键词，一旦考试题目展开可能就抓瞎了。为了真正吃透这个知识点，我们可以用 HQ&A 方法来拆解，逐层深入挖掘背后的逻辑。

先从最基础的开始，我们可以对前面那条知识点提出三个问题：

问题 1：汉武帝在政治方面采取了哪些具体措施？

汉武帝在政治上推行“推恩令”，通过让诸侯王分封子弟，逐步削弱了诸侯的权力，最终加强了中央集权。

问题 2：汉武帝在经济方面采取了哪些具体措施？

汉武帝实行盐铁官营和均输平准政策，加强了国家对经济的控制，增加了财政收入，同时缓解了社会矛盾。

问题 3：汉武帝在军事方面采取了哪些具体措施？

汉武帝多次对匈奴发起大规模军事行动，打击了匈奴的威胁，扩大了汉朝疆域，加强了边疆地区的稳定，为国家统一与发展奠定了基础。

在此基础之上，我们还可以进一步挖掘更深入的问题：

问题 4：汉武帝是如何削弱诸侯权力，加强中央集权的？

问题 5：“罢黜百家，独尊儒术”的背景是什么？这项政策对西汉社会产生了什么影响？

问题 6：张骞出使西域的意义是什么？这对汉武帝的军事和经济策略有何帮助？

通过这种层层递进的方式，原本单薄的知识点被扩展成了一个清晰、立体的知识网络。老师划的重点、可能涉及到的考点，基本上就都可以抓住了。

HQ&A 方法看似简单，但它的每一步都能引导你把信息从“记录”升级为“理解”，再进一步成为有用的知识资产。它让你从“看似懂了”走到“真正明白了”。就像徒手剥开一个榴莲，第一步虽然有点扎手，但当你吃到果肉的那一刻，就知道这一切值得了。

将 HQ&A 的思路用在工作中

在工作中，我们每天都会接收到大量的重要信息。

团队今年的整体设计策略、项目中的用户反馈、跨部门会上看似随口一提的观点……这些信息看起来都非常有用，值得记录，但如果不深入思考，它们最终只会停留在笔记里，难以真正产生价值。

如果你只机械地记录，很快就会发现这并没有太大价值。再聪明的脑袋，面对如此多的碎片信息，也总有被填满的那一天。关键在于，如何把“看起来懂了”变成“真正弄明白了”。这不是记忆的问题，而是理解的问题。而理解的前提，是主动提问。

在公司的那些年，每天接触到的信息和观点实在太多了。于是，我逐渐形成了一个习惯：每当获得一个重要的观点或信息时，总要再 Google 一下，或者直接问问相关的人。哪怕只是随口一句“这个为什么是这样？”“它背后还有什么？”看上去好像是“多此一问”，但实际上，这个习惯让我对信息的理解多了一层，也逐步形成了自己的思考体系。

这个习惯延续了很多年，直到几年前，我偶然发现一位英国博主 Jamie Miles 分享的 HQ&A 笔记法。我才发现原来有人早就把这种“结构信息”的思路整理成了一套方法。

设计师的 2024：边界在消失，2025 该怎么走？

Sun, 22 Dec 2024 00:00:00 +0000

写在开头

每到年末，我都会写点东西，总结这一年的起伏。总结，不只是为了回顾，而是为了看清下一步的方向。今年也不例外。

但是，今年的总结似乎又有些不同。2024年的设计行业，已经不再是过去那种按部就班的延续，而是在经历一次显而易见的本质变化。

过去，我们总以为设计行业会一年一年地稳步发展：工具更高效了，流程更完善了，用户需求更复杂了…

然而，事实是，变革早已悄然发生。边界正在被打破，规则正在被改写，连角色的护城河也开始崩塌。

今年，这些变化变得尤为明显，甚至显得近在咫尺。设计行业的边界正在模糊，角色的护城河正在被削弱，连游戏规则本身也在被重新书写。

这种变化不像以往那样渐进，而更像是一次推倒重来的重建。那些曾经熟悉的技能优势、行业规范和职业分工，如今似乎都站在了不确定的边缘。对于设计师来说，这不仅仅是工具的升级，而是一次重新思考自身角色与价值的挑战。

最近，我特别想和大家分享两件事情。它们看起来没有太大关联性，但仔细想想，变化其实早就在我们身边发生了。

01. 体验设计师 → 产品设计师

LinkedIn 上，一位朋友的岗位从「体验设计师」改成了「产品设计师」。他发了一条动态，说这并不是他的个人行为，而是公司的一次整体的调整。

原因很简单，公司希望大家别再沉迷于自己的一亩三分田了，别再只盯着设计细节、搞专业，而是把目光更多地放在业务价值思考上。换句话说，设计师要从「体验设计」转向「业务设计」。

Title 的变化只是表象，背后是公司对设计师期望的彻底重塑。 过去，体验设计师讲究的是“以用户为中心”，可企业的视角可不一样，它更在意的是设计为企业带来的增长和利润。

企业需要的是一个「利润中心」，而不是一个只烧钱、不赚钱的「成本中心」。

设计师的角色也随之发生了根本性的转变。从「体验设计师」到「产品设计师」，意味着设计师不仅要画界面、做优化，还得能想清楚：这个设计能不能提高转化率？能不能直接带来收入？

这背后是企业策略的转变，用更直接的话说，设计师不仅要设计“看得见的好”，还得为“看不见的利润”负责。这不仅仅是一个岗位名称的变化，而是设计行业的一场结构性调整。

02. AI 在敲门，边界在消失

上个月，我开始用 Cursor 和 Windsurf 做一些小工具。刚开始是写写脚本练练手，后来干脆用它们解决工作中的一些琐碎问题。就这样，一不留神，做出了 20 多个工具，这效果实在有点不像话了。更别说更为强大的 Devin，对于设计师来说，我们好像真的不需要工程师了。

过去，设计师不懂代码，这是个绕不过去的槛。很多时候冒出一些好点子都卡在“实现不了”这一步。

但现在，AI 工具把这道门槛给直接拆了。只要你有想法，它就能帮你把想法变成产品。AI 不只是帮你提升效率，更是在改变你的工作边界：设计师可以写代码，工程师可以设计界面，产品经理甚至能用 AI 生成原型。

更关键的是，这种能力不再只是“少数高手的特权”。AI 工具的门槛越来越低，工种之间的界限也越来越模糊。 设计师、工程师、产品经理原本泾渭分明的角色，现在正在被重新定义。

这才是最让人不安的地方。当角色之间的护城河被填平，接下来会发生什么？答案可能比我们想象的要快得多。

看似毫不相关的两件事，实际上指向了同一个方向：设计行业的角色边界正在消失。

一方面，设计师的职责边界正在变化。过去，我们只需要关注用户体验和设计本身，但现在，企业希望我们把目光放得更远一些，思考设计对业务的直接价值。设计师不只是画图的，更是业务的推动者。

另一方面，AI 让我们的能力边界得到了无限扩展。不懂技术？没关系，AI 补上这块短板。曾经因为技术限制而束手束脚的事情，现在只需要一点想法，再交给工具去实现就行了。我们不再只是设计师，我们可以做更多。

不过，别高兴得太早，这件事对所有人都是公平的。设计可以跨界到研发，研发也可以跨界到设计，而产品经理甚至可以抛弃所有人，把问题直接转化为需求，再利用 AI 生成完整的解决方案。

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

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

写在开头

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

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

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

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

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

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

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

领域级设计系统是什么？

开始之前，我们还是要再回顾一下领域级设计系统。在之前的定义中，我们将设计系统分成了：系统级、领域（行业）级、业务（产品）级三个等级。

从系统级到业务级，是一个对设计从抽象到具象的过程。从最底层的基础交互模式到具象到一个业务逻辑的执行流程。

领域级设计系统，简单来说就是一种针对某一个领域中进行设计的抽象和定义。通过分析同类场景的共性，制定出一套符合该领域特性的解决方案。

最典型的例子就是中后台领域的设计系统，这也是我们目前最常见、最成熟的领域级设计系统类型。如前面所说，领域级设计系统绝不仅仅局限于中后台。

事实上，只要在某个领域内的产品有足够多的共性，无论是电商、社交，还是金融，理论个上都能抽象出一套领域级设计系统。

这里大家可能会有问题，既然有共性即可，那为什么现实中，我们很少能见到其他领域的设计系统呢？这里就不得不再聊一聊领域级设计系统成立的几个前提条件。

产品形态已基本形成共识

产品复杂度可控

构建设计系统的时机成熟

设计系统的价值得到认可

关于这部分的细节，我们这里暂时不展开。详细的分析大家如果感兴趣，可以见全文内容中的讲解。

从 0 到 1：用 Cursor 做了两个小工具

Sat, 30 Nov 2024 00:00:00 +0000

从“融资利率计算器”到“百万计划”

在美股市场，偶尔会用到富途的融资。每次用融资之前，我总要在脑海中默算这笔钱会产生多少利息。这件事虽然不复杂，但计算的过程总让我有点烦躁。为什么不自己做一个呢？于是，就有了这个「融资利率计算器」小工具。

功能特点：

支持美股和港股的融资费用计算。
输入金额、天数后，快速得出利息成本。

前段时间，我的女儿问了我一个问题：“爸爸，存够 100 万需要多久？”这让我一时间有些语塞，但又觉得这是个很有意义的理财问题。与其给她一个简单的回答，不如用一个工具来帮助她理解存钱和投资的过程。于是，就有了这个「百万计划」小工具。

功能特点：

输入初始资金、月存金额、年化收益率，计算达成 100 万的所需时间。
支持不同利率和存入金额的调整，直观展示投资增值的概念。

从产品经理到“程序员”

其实，这两个工具都不是我写的。实际上，是 Cursor 帮我完成了它们。我只是作为产品经理和设计师，提出需求，规划功能，再通过 Cursor 帮我实现了我的想法。

在互联网行业工作了 20 多年，前面的十多年一直都是做设计，后面的几年开始做产品。多年来，我对编程一直抱有执念。

作为设计师和产品经理，我总会想到各种稀奇古怪的需求，但由于自己不会写代码，很多想法都无法尝试。虽然我尝试学过编程，但真正掌握编程的逻辑和语言始终需要投入大量时间，而这对于我来说，并不现实。

雇一个 Cursor 吧

有了 AI 工具，局面完全打开了。在过去，ChatGPT 让我能够改改代码，而如今 Cursor 则让我开始可以大胆的做一些更为复杂的工具了。

Cursor 对我来说最大的意义，是让我可以退回到产品经理的角色，只需要把握功能的需求和细节，把实现交给“它”来完成。

用 Cursor 完成我的第一个工具后，我毫不犹豫地决定付费订阅了。

一个月一百多块钱的成本，就像雇佣了一个“随叫随到的程序员”。对于我这种技术能力有限、却常有小想法的人来说，绝对是超值的投资。

接下来

接下来的日子里，我会继续用 Cursor 实现一些日常生活中“看到”的需求。它们不一定复杂，也不一定适合所有人，只是用来解决一些我自己感兴趣的问题，就像以前的 Notion 模板一样。

我会将用 Cursor 创建的小工具聚合在一起，如果你也感兴趣，那自然也是很好的。

https://www.toolsxyz.com

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

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

什么是 B端设计系统

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

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

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

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

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

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

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

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

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

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

B端设计系统属于什么类型

在之前的文章「设计系统学习指南 - 国内外 Design System 案例解析」里，我们曾介绍过设计系统的三个等级。

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

而 B端设计，在这里的定义就是领域级设计系统。我们通常说的 B端设计就是一个非常明确的领域，它需要聚焦于某一个具体的领域而产生具体的解决方案，例如大家经常提到的 Ant Design。

而我们今天要讨论的 AWS CloudScape Design System 也是如此。虽然从严格意义上来说它应该是业务级设计系统，主要是为 AWS 的业务所服务。但在我看来，抛开业务属性本身，它还对 B端设计的很多通用场景做了大量的深入和研究，非常值得我们学习和借鉴。

因此，我想专门用一篇文章来详细的介绍一下 CloudScape 这套 B端设计系统的构建思路，希望能给大家在构建自己的设计系统时有所帮助。

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

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

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

生成式 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 在界面设计领域的成功并非偶然，其背后有着深层的原因和逻辑。在我的付费专栏中，我将从以下几个方面更加深入地讨论这个话题：

为什么 Salesforce 的生成式画布能够取得成功？有哪些独特的策略和技术支撑？
用 Salesforce 的思路，我们的日常 B 端设计会有哪些改变？生成式 AI 是否能够带来设计效率的革命性提升？
生成式画布成功落地的关键因素是什么？它和设计系统又有哪些关联？

大家如果对生成式 AI 在界面设计方面的发展感兴趣

产品界面的 AI 生成式设计，为什么没人关注了？

Mon, 21 Oct 2024 00:00:00 +0000

不知大家是否有察觉到，曾经大受关注的界面 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%。

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

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

篇首语

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

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

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

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

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

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

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

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

阅读全文

以上内容节选自设计有得聊专栏 47 期文章「设计系统究竟应该由谁来负责？」。欢迎加入我的知识星球，阅读本期文章全文内容以及过往所有文章。

从 PRD 到设计稿，如何避免设计遗漏带来的坑？

Sun, 08 Sep 2024 00:00:00 +0000

篇首语

本期文章的这个话题源于与一位设计师的咨询。前段时间她刚刚经历了一次与主管的阶段性绩效 review，结果却让她有些失落。

她的主管给了她一个不太理想的评价，这其中有一点是日常做设计的过程中，总是会出现一些丢三落四的问题。要么是界面流程有遗漏，要么就是某些特殊状态没考虑清楚。无论是对接的业务方还是直接主管，都提到了这个问题，认为这个问题对项目的整体质量和速度都带来了一些影响。

对于这个问题，这位设计师她自己其实也有意识到，但还是会觉得有些委屈。在日常工作中，新需求一个接一个，很多时候产品需求文档也都还只是个初稿就提给设计了。加上项目的时间都十分的紧张，的确会出现一些考虑不全面的问题。

设计的前期其实都还好，但一旦进入到设计评审环节，研发团队加入进来后很多问题就都暴露出来了。而作为设计师提案者，自然也受到了大家的很多质疑。这些问题更多是由于PRD的不完善引起的，但最后却落在了设计身上，似乎一切问题都成了设计的责任。

这种情况我相信应该很多设计师都曾遇到过。当我们从 PD 手上接过产品需求文档开始进入设计时，方案的合理性和逻辑问题就不可避免的转移到了设计师身上。如果我们在设计的过程中没能发现问题，那么一旦设计稿输出了，无论是产品的功能还是使用的体验，作为设计师我们都会有不可推卸的责任。

如今的产品，复杂度越来越高，特别是哪些涉及到特定的业务逻辑的产品设计，难免会在设计的过程中遇到一些考虑不周或有所遗漏的情况。面对这样的情形，想要完全避免错误的确是件很难的事情。但我们还是可以借助一些流程和方法来尽可能的帮助自己减少这些问题的发生。

在本期的文章中，我想从产品需求文档（PRD）和设计需求文档（DRD）这两份文档出发，来和大家聊一聊在设计过程中的一些思路和方法，帮助我们能够更好地把控设计过程，在设计交付的时候更好地应对来自各方的挑战。

PRD vs DRD

在我们日常的设计工作中，很多设计师会遇到“设计遗漏”的问题，实际上，这种问题与两个非常重要的文档密切相关：PRD（产品需求文档）和 DRD（设计需求文档）。

对于设计师而言，理解这两类文档并做好 PRD 向 DRD 的转化非常重要，它将直接影响到我们的设计能否完整且准确地满足产品需求，避免设计遗漏的发生。

PRD 和 DRD 有什么区别

PRD 是我们在设计工作中最常接触的一类文档，产品经理会从业务和市场的角度描述产品的需求，在PRD 中详细列举产品的目标、功能、用户场景和技术约束。有些产品经理还会附上一些自己线框图，来表达自己对产品设计的一些想法。

在 PRD 文档中，虽然产品经理详细的描述了需求，为设计师的工作提供基础方向，但它始终不是专门面向设计师的交付。大家可以想一想，对比我们在设计交付给研发环节时的设计说明文档，其实 PRD 对设计工作的“友好度”是很差的。

这就意味着，如果我们的整个设计过程是完全依赖 PRD 去完成，这个过程是并不顺畅的，因为它的“格式”与我们的设计工作并不兼容。

为什么会出现这种情况呢？这里有非常核心的一点，PRD 是从产品和市场的视角出发，描述的是业务层面的需求，它所关注的是产品要实现什么功能、满足什么样的用户群体以及如何推动业务目标的达成。

如果设计师完全按照 PRD 所描述的功能需求一步步执行，那么在设计过程中很可能会遗漏掉一些关键的设计细节，或者由于对需求的理解不够深入而产生考虑不周全的问题。这是因为 PRD 仅仅提供了业务层面的框架，忽视了设计中的需求，这就是为什么设计工作中经常会出现设计遗漏的原因之一。

而设计需求则是完全是从另一个视角出发，更多地关注用户体验、交互逻辑、视觉设计等细节问题。可以说，PRD 是宏观的方向，而设计需求则需要更微观和具体的落地。所以，如果我们只是单单对照着 PRD 去进行做设计，就会容易遗漏掉一些关键的设计细节或是思考不全的问题发生。

阅读全文

以上内容节选自设计有得聊专栏 45 期文章「从 PRD 到设计稿，如何避免设计遗漏带来的坑？」。欢迎加入我的知识星球，阅读本期文章全文内容以及过往所有文章。

进入新行业，如何校正你的产品直觉

Wed, 03 Jul 2024 16:34:56 +0000

上个月的一次模拟面试中，一位同学聊了一下她的上一次面试的经历。这是一次线下的面试，面试官和 HR 一起参加。前面的环节聊得都还不错，但在最后结尾时 HR 的一个问题让她有点卡壳了，感觉自己回答得不是很好。

这位同学之前的工作经历都是在电商领域，而这次面试的是一个 toB 的医疗领域，这与她过往的业务领域截然不同。HR 问，虽然你在之前的领域里经验很丰富，但如果来到这个全新的领域，你如何能确保自己的经验和对产品的嗅觉还是同样有效呢？因为之前没有考虑过这个问题，都是将重心放在案例上，以至于一时间没能很好的组织语言，回答得磕磕绊绊。

先撇开 HR 的这个问题。其实转换领域对我们所有人来说都是一个很常见的现象，我们的职业生涯有几十年，不可能一直都处于同一个行业中。面对不同业务、不同行业的用户需求，如何让我们的专业能力和经验能够“平移”到下一个领域中的确是一个需要思考的问题。

我们做设计的经验和感觉往往都是基于在某个特定领域中长期工作而慢慢形成的，无论主动或被动，它都会慢慢的累积，形成对某一领域的直觉，也就是我们的产品直觉。

当我们进入到一个全新领域的时候，这个行业的特性和用户的需求可能是不一样的，比如前面提到的电商 vs 医疗。这个时候我们过去的产品直觉就可能会变得不在可靠了，我们不能再依赖过去的经验和直觉来做设计，而是需要通过学习和研究来校正我们的产品直觉。

这是所有设计师在进入新领域时都需要面临的问题，有些人会在“犯错”中逐步修正，而有些人会主动借助方法来进行快速地校正，来帮助自己更快更好地 landing 到新的业务中。

产品直觉是如何形成的

我们的产品直觉是如何形成的？这个问题我认为可以从两个方面来看，一方面是我们自己作为用户所代入的体验，另一方面则是我们对具体领域或产品的深入理解而形成的。

产品直觉的一个重要来源就是我们自己，作为一个真实用户的使用体验。以前面这位同学过去的电商领域为例，基本上我们大家都是这个领域中的用户。我们可能媒体都在发生在线购物的行为，因此我们对这个领域有着天然的理解和直觉。

以上是本期专栏文章的节选部分，这次我想和大家聊一聊产品直觉，看看如何借助方法来快速校正我们的产品直觉，帮助我们更快的进入到新的领域中。

用 AI 重命名截图 – Keep it shot

Wed, 19 Jun 2024 16:34:56 +0000

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 的接入。

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

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

AI 设计近一年来的发展

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

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

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

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

设计系统中的决策树

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

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

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

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

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

一年过去了，AI design 的进展如何？

Fri, 07 Jun 2024 16:34:56 +0000

去年年初 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 的潜在能力和可能性上。这其中的能力层次以及具体的困难，实际上大家探讨得都不多。今天借这个机会，正好也和大家聊聊我自己的理解。

产品设计的难度层级

如果将一个产品从设计工作的视角进行“解构”，我们大概可以将其拆解成组件、模块、页面、流程、功能及应用六个难度层级。

要不要自己开发一个设计协作工具？

Tue, 21 May 2024 16:34:56 +0000

昨晚和一位设计师朋友喝咖啡，聊聊设计协作的问题。想起之前在专栏里写过的一段话，算是这些年折腾设计协同产品的一些感受吧。

识别问题，远比捣腾工具有效

有些时候我们会因为某一款新工具（或个功能）而产生想要一些对工具自研的“幻想”。但这些想法往往只是对新功能的价值的假想，而忽略了团队中真实需要解决的问题。所以，不要急着有了新想法就往里扎。先好好思考一下它是不是一个真需求。

工具不一定要自己造，选择一个合适的先开始

我们经常会陷入到个性化需求的“陷阱”中，总想着针对性的为自己争取资源定制开发。这样往往会陷入大量的时间和资源的消耗，而且未必能达到预期的效果，最终可能给自己埋下一个又一个坑。所以，不妨先挑选一个合适的工具先进行尝试，等到摸索出一段时间，验证后再考虑自己研发。

与上下游达成一致，不要自嗨

协同不仅仅局限在团队内，更重要的还有上下游的相关人员。在探索协同效率的时候一定不要沉浸在自己的世界里，先将想法和上下游相关的同学聊一聊。相信我，没有上下游的支持，自己搞设计协同是玩不转的。

不要盲目改进，给自己制定一个目标

协同的目的是为了提升效率，这就意味着我们需要有一个明确的可衡量的目标，否则我们很容易陷入盲目的改进和迷失方向。

一定要先给这件事情定义一个清晰且有意义的目标（无论是定量还是定性），通过设定目标来持续监测改进的效果，并根据实际的情况进行调整和优化。

Notion Template · Daily Drafts with Voice and AI

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

Daily Drafts Journal 是一个非常轻量的 Notion Template ，它可以通过语音输入和 AI 能力帮助你实现日常灵感的快速记录和总结，让你不会再在开车时、走路时想到的好想法被不小心丢失。你需要的只是打开 Notion，用语音说出它们即可，Notion AI 将帮助你完成记录和分析总结。你可以到晚上回家之后再对它们进行整理，归档到你的日记或知识库中。

我的日常应用场景

平常开车或走在路上，会突然有一些灵感和想法想要记录。一般情况下我会用 iOS 端的 Drafts 用语音来输入记录，晚上回家再整理归档。这次的模板就是它的 Notion 版。相较于 Drafts（应用），它的好处是可以借助 Notion 的 AI 来帮我们进行总结，提取任务。

Notion Template : Daily Drafts Journal 介绍

用语音输入记录所有的灵感闪现

模板使用了一个数据库来记录每日的纪要，按时间排序。每天点击「新增今日纪要 」新增一条，将临时想到的事情用输入法键盘的语音识别功能说出来即可。

用 Notion AI 进行每日汇总，提取待办任务

今日纪要页面中主要包含两个部分：

记录今天发生的事情（下半部分）

这里是语音输入的每一条信息，当我在开车或是行走的时候我就会用它快速记录下我的一些临时的想法。

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

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

之前在设计有得聊专栏中，用了好几篇文章来和大家探讨设计系统的定义、价值，以及我们该如何去规划、使用它。相信现在大家已经对设计系统这个命题有了清晰的理解，接下来我们就开始分板块聊一聊各个重要的组成部分，帮助大家搞清楚设计系统的核心逻辑。

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

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

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

设计系统的 WWTF 原则

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

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

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

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

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

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

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

设计系统核心理论

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

**布局框架：**对屏幕空间进行规划和划分，定义各板块的具体用途；
**系统组件：**基于基础组件库抽象并定义业务组件，解决用户人机操作效率问题；
**Pattern 模式：**基于行业和业务特性进行模式的抽象，为解决通用问题提供可复用的设计方案；
**产品风格：**基于色彩、动效、文案等“系统设定”构建产品风格体系，定义产品的风格和气质；
**页面模板：**构建行业和业务可复用、可配置模板库，提升业务实现的效率。

以上这些内容大致需要十几期的篇幅来讲解，这一期的内容，我们先从布局框架开始。

设计系统布局框架

之前我们做过一次调研，在 toB 端场景中用户对功能跳转逻辑、任务流程逻辑有着非常多的抱怨，这些问题导致用户产生极高的系统操作成本、效率降低。这也是导致很多产品体验评价差的重要原因。而这两个问题，都和布局框架有着非常密切的关系。

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

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

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

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

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

设计系统的三个等级

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

等级 1：系统级设计系统

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

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

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

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

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

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

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

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

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

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

Design System 介绍 PPT

本次 Design System 的分享定位

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

Design System 的价值及重要性

外部环境的变化

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

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

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

一次关于 Design System 的调研

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

关于这次的调研分析，大家可以进一步阅读设计系统 2022 调研总结

在阿里 Design System 的真实案例

设计师的简历作品集应该关注什么？

Sun, 03 Mar 2024 16:34:56 +0000

作品集的制作是每个设计师都会经历的工作，也是大家最难做的设计之一。最近两周帮几位会员同学看了不少，我发现大家的文档基本都是至少 30 页打底，有的甚至到了 60 多页，信息量很大。看得出都在想尽可能全方位的向面试官展示自己的能力，但这些冗长的文档里也都出现了一个明显的共性问题，那就是缺少对自己能力优势的有效表达。

这里主要会体现在以下几个方面：

流水账记录。通篇按照时间线将自己做过的项目罗列了一遍；
缺少「解决问题能力」的体现；
忽略了对「用户需求」的关注。

这些问题不仅仅会出现在求职简历作品集里，所有基于文档的“沟通”场景，比如晋升答辩、汇报分享等场景也都会遇到。所以，这一期的文章我想和大家聊聊自己关于作品集、项目的汇报的一套写作方法。

作品集，从你的「用户需求」开始

作为设计师，我们时刻都在思考用户遇到了什么问题，我的这个设计方案是不是能解决他们的问题。可是到了写 PPT、作品集的时候往往却忽略掉了这一点，更多的去想“我”要表达什么，忽略了“用户”想要看到什么。

在阿里这些年做面试官也看了上千篇简历，面试了几百人。从“人肉数据分析”的角度来看，除去定向挖人之外，简历作品集水准较高的候选人确实更容易走到最后。

当然，这不是说作品集水准高就代表能力一定强，而是它能够在一定程度上反映出设计师的思考深度。所以我一直说找人帮忙改简其实并不靠谱，简历虽然改了但你的思维模式并没有发生变化，进入到正式面试环节还是容易出问题。

从用户需求的视角来看作品集

回到「用户需求」，在不同场景下我们的「用户」和「用户需求」都有会存在一些差异。

投递简历时，我们的「用户」是专业面试官、HR，他们会关注候选人的业务背景、专业能力及团队匹配度等；
晋升面试时，我们的「用户」是专业评委，他们会关注候选人挖掘问题的能力、设计过程及发展潜力；
专业分享时，我们的「用户」是设计师，他们会关注你的解题思路以及背后的思考。

如果你也是设计师，正在需要寻求面试过程中的帮助，可以预约我的模拟面试服务。

表单设计的基础设计逻辑

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

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

关于表单设计

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

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

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

为什么要写这个系列？

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

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

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

这个系列会包含哪些内容？

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

01. 理解设计表单的意义

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

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

02. 表单基础设计规范

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

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

03. 表单的设计实例

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

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

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

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

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

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

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

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

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

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

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

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

表单遇到了哪些问题？

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

对于使用者（用户）：

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

01. 心理成本

心理成本是一个容易被忽略的因素，很多人认为我把表单交互做的简单一些，那么用户填写起来也会轻松一些。但其实有研究曾提到过，对于表单用户看到的第一时间是先扫读一下，看看需要填写的内容有多少，估算一下自己需要多久完成。所以为了不吓到用户，很多长表单会选择进行分拆，降低用户的心理压力。

除此之外，用户也会看一看表单中的字段有没有特别难填写的。比如在很多支付流程中的信用卡信息，需要用户从钱包里找出卡再对应着一步步的填写进去。

半年过去了，AI 设计的进展如何?

Mon, 04 Sep 2023 16:34:56 +0000

篇首语

今年年初 AI 浪潮席卷了整个科技互联网领域，从海外的 UIZard 到国内的即时设计、MasterGo，大家都在不断尝试探索新的模式将 AI 与 UI 界面进行结合。我也一直都在密切关注着它对设计行业所带来的变化，特别是在界面设计领域。

时间一转眼已经到了 9 月，尽管前面提到的这几家公司在文生 UI 领域都投入了大量的资源和精力，也获得了一些初步的成果，但就目前的结果来看AI 在界面设计方面依旧处于一个比较初级的阶段。与此同时大家可能也会发现，这几家公司对这方面的发声也在慢慢变少，整个领域似乎进入了一个相对沉寂的时期，这股热潮似乎在默默的消退。

UI 界面设计的复杂性

与创意设计领域中Stable Diffusion、MidJourney 飞速进化相比，AI 在 UI 界面设计上的能力进展显然是缓慢的。

01. 业务导向的多维度设计

UI 界面不仅仅是产品功能的呈现，它还更需要综合用户需求、数据反馈来进行设计从而向达成业务目标前进。

02. 复杂的设计目的性

相较于创意设计，UI 界面设计的目的性会复杂得多。每一个界面都可能需要满足用户不同场景下的多个诉求。

03. 通用与特定的设计标准

04. 持续迭代的设计过程

由此可见，UI 界面设计是一个复杂且多维度的设计过程，涉及范围大、业务耦合度高，AI 想要在这个领域中真正的占有一席之地是还是非常难的。

产品设计的难度层级

如果将一个产品从设计工作的视角进行“解构”，我们大概可以将其拆解成组件、模块、页面、流程、功能及应用六个难度层级。

**应用：**代表整个产品或软件，涵盖了一个业务单元中所有的功能和特性，也是产品体验的总体框架；
**功能：**产品的核心功能，它是产品为用户提供的主要价值点，影响了产品的主要用途和目标用户群体；
**流程：**用户为完成某项特定任务时的产品互动路径，流程设计的优劣很大程度上影响了用户的操作体验，决定了用户完成任务的效率和对产品的满意度；
页面：产品功能的具体界面或视图，是用户号与产品互动的主要场景，它的设计将直接影响到用户的具体感知和体验；
模块：页面中的特定区块或组合组件，在设计过程中会被大量的重复使用；
组件：页面构成的基础元素，如输入框、按钮、文本、富媒体等，是构件页面体验的最小基础单元。

在现实的工作场景中，它们的设计难度是由左至右依次递增的。即便是不考虑业务属性叠加的情况下，想要很好地完成这些层级的设计，对 AI 来说也依旧有很大的挑战。

设计系统在 PPT 领域的应用

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

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

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

PPT 工具市场分析

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

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

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

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

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

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

PPT 工具有什么问题？

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

PhotoShop、Sketch 以及PPT 制作工具 PowerPoint、Keynote 本质上都属于自由式设计。它们都是给用户一张画布和一系列的元素，在画布上拖拽排放、调整样式来完成最终的设计。

体验设计师未来三年应该如何发展？

Sun, 02 Oct 2022 16:34:56 +0000

体验设计师 , 突然这个角色在互联网行业似乎已经存在很久了。我从 03 年毕业工作至今，有幸经历了从“美工”到设计师的整个历程。时至今日，这个职能已经逐步被行业、被公司所认可，职能和领域也在不断演变。

15 年左右，我们在阿里开始逐步进行对设计师岗位的优化，从原有的交互 & 视觉调整为体验设计 & 创意设计。

体验设计师岗位的变迁

19 年开始组建集团的设计中台团队后，设计系统一直是我们非常重要的一项能力。在与各业务设计团队的合作中我发现设计团队的工作模式在发生变化，从以往的划分业务接需求，向通过设计系统的“架构设计”进行演变。

经过这几年的不断磨合，设计系统已经成为很多设计团队最为重要的核心能力之一。

在这个阶段中团队中也逐步出现了一些新的工作要求，负责设计系统的构建及推广应用，我将它成为「架构型设计师」。这也是我认为接下来几年体验设计师发展的一个非常重要的方向。

既然有了明确的岗位，我们就需要明确它的工作职责。结合这些年在阿里的实践，我会将其定义为以下三个方面：

架构型设计师的职责

01. 构建设计系统

在当下，架构型设计师的首要职责就是构建业务级设计系统。为业务提供明确的设计约束和指引，帮助团队快速实现业务逻辑，减少不必要的浪费。

这里的设计系统绝对不是做一套风格样式输出 UI Kit，也不是基于 Ant Design 这类的开源系统复制一遍。而是需要真正基于所属领域和业务的特性去解决实际问题，例如在之前介绍 CloudScape Design System 的文章中所提到的那些 Pattern。

02. 设计资产管理与维护

前面一直和大家提过「齐套」的概念，而它也是架构型设计师非常重要的一项工作。

新的协作模式下，支撑业务的设计师需要基于业务设计系统去实现一个个具体的需求，那么在开始工作之前想过的组件、模板、素材、icon 甚至是文案都应该是准确无误的。

03. 设计运营

在阿里，我们有业务通过设计系统的运作获得了 30% 多的整体提效。但这个结果不仅仅是靠一套好的设计系统，还需要在流程、工具上做大量的工作和运营。

除了设计系统和资产的管理，架构型设计师还需要向外去衔接设计的上下游，去不断优化整体的工作流程来帮助设计系统能真正的落实到底、发挥出有效价值。

随着互联网红利的消退以及经济形式带来对企业降本提效的要求，互联网企业以及设计团队都将面临对生产模式、工作流程的进一步优化。

设计系统已经逐步成为各大互联网设计团队的重点投入方向，我的判断是在未来三年，架构型设计师一定会成为设计团队中最为重要岗位职责之一。关于这个话题的更多讨论，大家可以阅读之前的文章「成为架构型设计师」

本文出自专栏 设计有得聊 免费内容

从 Adobe 收购 Figma 的背后看设计协同

Mon, 19 Sep 2022 16:34:56 +0000

这期的话题本来已经写得差不多了，但突然看到了 Adobe 斥巨资收购 Figma 的消息，事儿很突然，但也确实不太意外。这几年在集团内部做设计协同类的产品，和 Adobe 也打了很长一段时间的交道，看到这个这个消息还是有些感触。所以临时改变主意，和大家和聊聊关于设计协同的一些想法。

如果干不掉 Figma，那不如干脆买下它吧

Adobe 历史上收购过很多产品，上一宗大家比较熟悉的 case 就是在 2005 年以 35 亿美元收购了当年火极一时的 Macromedia，这里面有很多我们熟悉的软件，比如网页三剑客 Dreamweaver、Flash、Fireworks，只不过很可惜，在被 Adobe 收购后这些产品最后也都陆续被关停掉了。

这次 200 亿美元（现金+股票）收购 Figma 的消息公布后，市场出现了非常强烈的反应。Adobe 股票立马就暴跌了 16 个多点，差不多蒸发了 1 个半 Figma，这也是 Adobe 近十多年在股市上最惨烈的一天。

按照 Adobe 新闻稿的披露，Figma 的 2022 年的ARR（年度经常性收入）预估为 4 亿美元，只占 Adobe ARR（140 亿美元）2.8%，而 Adobe 为此次收购却所付出了相当于其市值约 10% 的费用。显然 Adobe 的决策层是非常看重它的，又或者说是已经被完全的逼急了。

按照 Adobe 9 月公布的财报来看，目前公司所持有的现金也就差不多 60 亿美元。想要在 2023 年完成整体的收购，看样子 Adobe 后续得要得要做不少动作去找钱了。

在与 Adobe 的合作中所感受到的

2019 年初，因为设计中台的业务我们开始和 Adobe 有了一些沟通并尝试一些合作。当时的 Adobe 目的非常明确，就是希望借 XD 的免费和多平台与各大专业群体合作，来抢回一些被 Sketch 占领的市场，特别是它们这么多年心心念念但又久攻不下的中国市场。

也是在这一年，陪同老板去一趟美国参加 Adobe MAX 设计大会，拜访了一些 Adobe 的高层的同时也和 Adobe 的很多软件团队做了一些沟通，寻找合作的机会。

成为架构型设计师

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

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

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

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

设计师 Job Title 的变迁

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

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

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

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

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

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

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

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

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

什么是架构型设计师

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

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

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

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

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

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

架构型设计师的职责

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

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

第一层：解决设计域内专业能力及效率问题

上一期的文章里，我们聊到了「齐套」这个概念，希望基于中台化的思路来提供基础能力、减少浪费。这里面大部分的工作都需要架构型设计师来进行承担，核心主要围绕设计系统和设计资产两部分。

01. 设计系统的建设与维护

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

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

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

用一个例子来解释

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

制作小龙虾 SOP：

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

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

设计系统中的 SOP：

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

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

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

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

设计系统延展阅读

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

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

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

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

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

设计系统的三种类型：

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

做设计系统的目的：

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

延展阅读：

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

这两年设计师找工作是不是越来越难了？

Sat, 25 Jun 2022 16:34:56 +0000

设计师找工作这两年的确是越来越难。前两天和一位猎头朋友正好在聊这个话题，一些想法分享给大家。

这两年互联网的形势确实不太好，各大互联网平台多多少少都受到了政策的影响。也正是因此，国内的环境我们更需要关注国家层面的思考。毕竟绑定到「核心的 KPI」才能在获得更好的发展环境。

去年的年底国务院发布了「“十四五”数字经济发展规划」，大家可以关注一下这里面的数字经济发展主要指标。

来源：http://www.gov.cn/zhengce/content/2022-01/12/content_5667817.htm

大家可以算一下 IT 服务业规模、工业互联网平台、网上零售、电商、政务几个领域到 2025 年的预期性增长，加起来有 40 多万亿。

除去国家对于核心 KPI 的预期，我们也还需要看看整体的宏观趋势。

政治层面：

国际形势目前还是相当复杂的。国家鼓励信息技术的自主创新，核心技术自主可控。同时也鼓励各大科技企业的开源，通过技术手段赋能给实体经济，帮助实体经济进行数字化转型。

社会层面；

互联网的红利消退，各大互联网企业在 C 端市场基本都已经触顶。加上疫情影响，toB 市场的需求增长迅猛。在线、异地办公已经逐渐成为新的常态。

经济层面：

全球经济放缓，企业用工人力成本也在不断持续上升。企业也迫切的需要通过数字化的手段降本提效。而近些年云计算、5G、物联网、AI 等技术的发展也为企业效率提升带来了明显的变化。

从宏观层面上来，无论是 UI 、交互还是 UE，市场的需求是明确存在的。就业环境也会随着整体情况的稳定逐步下来。

当然，这里面依旧发生的很大的变化，对于人才的要求的变化。设计的目的是解决问题，不同的阶段需要解决的问题不一样，设计师的工作也就有所差异。

营利是企业最为重要的目的之一，包括设计师在内的所有岗位都是为之服务的。在大环境的影响之下组织不得不重新审视每一个岗位角色在经营环节中所提供的商业价值。

企业需要解决什么问题？这个问题哪些是设计可以发挥价值的？这些价值点中需要设计师什么样的能力？这些问题才是在目前环境下设计师就业或者说是职业生涯最需要关注的。

以上，希望对你有所帮助。

做了 5 年互动设计，我遇到了设计师职业发展天花板

Fri, 24 Jun 2022 16:34:56 +0000

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

设计师职业发展，是我的会员群中经常被讨论到的一个话题。前段时间正好有机会和一位同学也是集团内的一位设计师有一次喝咖啡的沟通。内容有些意思，记录下来与大家分享一下。

本期主人公 X

这已经是 X 君参加的第五个 618 大促了，与往年不同的是这次结束后他并没有调整休假，而是立马调头回到了了另外两条业务线的迭代工作中。支持的资源在变少，但需求却并没有发生变化。自己似乎已经遇到了职业发展天花板。

X 君是 90 后，美院毕业后没多久就加入了目前这家公司，目前负责两个大型互动产品的设计工作，同时还需要在各类大促期间支持相关互动玩法以及营销活动。

在公司的这 5 年时间过得很快也很充实，密集的项目压得人透不过气，但也带来了更多的机会和挑战。也正是因为其优秀的表现，X 君在加入公司的第四年顺利完成了自己的第二次晋升，成为了互动产品的主设计师，扛起两条核心业务线的设计工作。

一位工作 5 年的设计师对设计师职业发展的困扰

太忙了，而且是周期可预见性的忙。时间几乎全部被工作所占据，以往的爱好被纷纷搁置了。

我对手机 OS 以及很多的创新设计非常感兴趣，以前时间比较充裕的时候会去捣鼓一些小创新。看到自己的一些创意想法在网络上获得了大家的认同，有些甚至出现在了各厂商的发布会上，这种满足感会让我 high 很久，我想这应该就是设计师最纯粹的快乐吧。

但很可惜我已经很久没有打开那些设计稿了。日常的项目交替着各种大促活动，往往一个项目还没结束下一个就开始拉人启动了。画画飞机稿？不好意思，真的没有时间也没有那个精力了。

作为设计师，我们需要跟进项目的完整流程。项目的前期沟通讨论、需求明确后的各种设计产出、开发后的还原度和测试。每天有各种各样的会需要参加，真正设计工作往往只能在结束了一天的会议后加班做，回到家也只想“躺着”了。

设计师话的语权太低了，我们很难对业务产生深度的影响。

视觉表达有种很特殊的魔力，能够带给大家感官上的愉悦。对于自己的专业我还是有自信的，业务方大多数时候很难从专业角度去挑战我们。但这也仅仅是在我的专业领域中，对于业务的决策、活动玩法的设计，作为设计师我们的话语权确实不高，很难插的上手。

产品的背后是商业，商业的目的还是要带来业务指标的增长。从决策链路上我们就已经站在了业务方的后面，大多数时候作为设计师我们很难去挑战他们，甚至连验证的机会都没有。当如如果业务方向从一开始出了问题，我们的设计做得再好也很难获得好的结果。即使有了好的结果，这里面有多少是由设计师给带来的，我们很难讲清楚。

作为项目组的一员，我们还得每天参与到各种沟通会、评审会，业务上的决策建议提了不一定被采纳（除非正好和某些角色的想法不不谋而同），不提又显得自己参与感不足。每天大量的时间都在反复的会议、沟通，真正做设计的时间被压缩得非常紧张。

这些问题叠加在一起，就让很多人整天都在纠结中渡过。除了体累还有心累，但似乎也并没有更好的办法。

做了 5 年互动设计，我遇到了职业发展瓶颈。

有复杂度的业务、持续的有效产出，所以绩效一直都还不错，这也让我的两次晋升都很顺利。但在晋升后的第二年我又有了新的焦虑，自己怎样才能到达下一个层级？新的层级，不进则退，又该如何能让自己一直获得好的绩效结果？下一个阶段应该如何走我开始有些迷茫了。

团队里同层级的设计师有好几个，有些在当前层级已经好几年了；越往上走，对设计师综合能力的要求越高，单凭设计技能是很难有更好的发展的；工作上能使上力的还是做好业务支撑，想从设计侧发起做一些专业深度事情一直都很难，如今的环境，变得更加难了。

说实话，我确实有些困惑了，不知道还能做些什么来帮助自己打破这个“僵局”。

关于设计师职业未来的思考

我坚信设计师应该打造自己独立的品牌 IP，去表达自己对这个世界的认知、对设计的理解。今天大家所看到的一切都有设计参与其中，也有很多设计师心中的「会心一笑」。我想尝试着做做「内容」，用短视频的形式表达我把这些告诉大家，也分享一下我对设计的理解。

图形处理、视频剪辑这些对于我来说都不是问题，每一位设计师都有发现美、发现有趣的能力，我希望自己能用通俗易懂的方式帮助表达出来，让大家了解设计，发现这个世界的美妙。

至于工作本身，我还是比较坚信「设计是来解决问题」，而不是纯粹的信息表达。随着行业的发展，传统的设计师能力竞争力会越来越小，未来的设计师还是需要有更多对业务、商业的理解能力。

13 点 45 分，X 君来回点了几次手机屏幕。离我们取好咖啡坐下已经过去了 1 个半小时，咖啡已差不多喝完，我们的聊天也差不多结束了，相互道别以后 X 君也快步的向着公司方向而去，估计一会应该还有某个棘手的项目评审会在等着他吧。

写在最后

像 X 君一样的设计师有很多，大家都被加班、晋升、个人发展等各种问题所困扰。就近一个多月了解的情况来看，目前的大环境下确实没有太多好的办法，尽可能的先稳住吧。

一些建议给到 X 君，同时也在这里抄送给大家吧。

从商业角度去思考设计价值

营利是企业最为重要的目的之一，包括设计师在内的所有岗位都是为之服务的。在大环境的影响之下组织不得不重新审视每一个岗位角色在经营环节中所提供的商业价值。仅从设计专业的角度聊价值而忽略（或没有）对商业的影响，会让自己后面的路更加艰难。

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

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

我们为什么要做设计系统

序：

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

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

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

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

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

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

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

准备怎么写：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

设计系统的现状：

在开始聊 Why 之前，我想还是先和大家一起回顾一下当前互联网产品设计领域设计系统的一些现状。首先还是会上次 UCAN 的工作坊一样，将设计系统定义为系统级、领域级、业务级三类。

系统级：

顾名思义，就是操作系统级别的设计系统，我们日常会涉及到的主要就是 Apple、Google 和 Microsoft 三家所提供的。

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

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

本文出自专栏设计有得聊免费内容

关于 Design System 主要调研结论

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

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

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

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

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

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

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

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

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

如果你还想了解设计系统的价值，可以继续为什么我么需要设计系统。

Posts on Hi, I'm 5key

Heptabase VS Tana，两种不同的知识管理逻辑

篇首语

Heptabase vs Tana

进一步展开聊聊

业务思考力，设计师跳出执行的起点

KPI 是起点，但并不是答案

用户反馈不等于业务问题

从做设计，到构建秩序

什么是确定性？

设计系统中的确定性

Pattern，设计系统中的秩序单元

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

这事儿的可行性有多高？

从“能用”到“能用”，中间隔着的三道坎

设计师的下一站，成为架构师，还是走向业务？

当设计不再从零开始，设计师应该往哪儿走？

当用户喝多了，需要找代驾

一个找代驾的故事

The User Is Drunk

多邻国 Handbook 中文版

CEO 路易斯的来信

TL;DR

01. 放眼长远，从长计议

02. 提高标准

03. 快速交付

04. 用结果说话，而不是解释过程

05. 让一切变得有趣

The Green Machine

从「白板」开始你的设计工作

你会如何开启设计工作

企业如何看待设计师的专业能力？

AI vs 设计师，应该选哪个？

从白板开始你的设计工作吧

入职新公司，学会问问题才能少踩坑

为什么问问题如此重要？

为什么新人总是害怕问问题？

三大提问阻力：

01. 别人会觉得我很蠢吗？

02. 会不会打扰打扰别人？

03. 会不会显得自己没准备？

如何开始问一个好的问题？

好的简历作品集，需要有层次的表达

0 到 1 项目的优势和困惑

如何破局？分层表达是关键

第一层：项目流程，提炼出方案主线

第二层：实施细节，为主线提供弹药

好的表达是需要有层次的

如何让作品集“站住脚”

最后的建议

设计的意义，得用业务语言讲明白

商业环境下，设计师的天然“劣势”

为什么设计师需要业务 Owner 精神？

当设计师转为产品 Owner 时会发生什么变化？

理解业务的第一步,数据和设计的语言转化

HQ&A 笔记法：让你的思考更有效 (上)

什么是 HQ&A 笔记法？

现在，我们用 HQ&A 方法再试试

将 HQ&A 的思路用在工作中

设计师的 2024：边界在消失，2025 该怎么走？

写在开头

01. 体验设计师 → 产品设计师

02. AI 在敲门，边界在消失

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

写在开头

领域级设计系统是什么？

从 0 到 1：用 Cursor 做了两个小工具

从“融资利率计算器”到“百万计划”

从产品经理到“程序员”

雇一个 Cursor 吧

接下来

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

什么是 B端 设计系统

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

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

B端 设计系统属于什么类型

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

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

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

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

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

什么是 B端设计系统

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

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

B端设计系统属于什么类型

设计系统中的决策树

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

设计系统的 WWTF 原则

设计系统核心理论

设计系统布局框架

作品集，从你的「用户需求」开始

关于表单设计