设计思考 on Hi, I'm 5key

从做设计，到构建秩序

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

TL;DR

一个产品的好体验，从来不是靠界面细节"卷"出来的，而是来自清晰的流程和稳定的结构。

设计师追求"细节极致"会陷入越走越窄的死胡同。

真正的破局点是从"做设计"升级到"构建秩序"：通过设计系统提供确定性，让团队从重复的样式决策中解放，专注于真正影响业务的问题。

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

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

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

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

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

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

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

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

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

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

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

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

什么是确定性？

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

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

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

设计系统中的确定性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果你也正在面临开头提到的那些困扰。那么也许，是时候换一个更结构化的方式来看待设计这件事了。

💡 延伸阅读：

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

系统化思维深度：设计系统 · 我们为什么要做 Design System

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

欢迎订阅我的小报童专栏，解锁后续全文。

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

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

TL;DR

设计系统逐步完善之后，体验设计师的角色正在分化为两类：一类继续深入构建系统、制定规则（架构型设计师）；另一类深入业务一线，把 Pattern 和组件当成"标准件"拼装，推动产品落地（业务型设计师）。

继续做通用 UX 是最危险的位置，识别自己的倾向并主动选择，是设计师当下最需要做的事。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

设计师未来的两条路径：架构型 vs 业务型

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

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

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

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

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

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

💡 延伸阅读：

架构方向深度展开：成为架构型设计师

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

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

AI 时代的新抓手：把设计系统变成 Markdown：让 AI Coding 真正读懂你的设计约束

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

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

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

TL;DR

设计师跳出执行的关键，是建立自己的业务思考力。

两个最常见的认知错位：把 KPI 当成终点而不是线索（围着 KPI 做设计，但偏离了真正的业务目标）；把用户反馈直接等同于业务问题（响应症状而非根源）。

学会用业务视角反推设计决策，是从执行者走向决策者的起点。

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

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

KPI 是起点，但并不是答案

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

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

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

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

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

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

用户反馈不等于业务问题

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

💡 延伸阅读：

如何用业务语言表达：设计的意义，得用业务语言讲明白

设计师未来的两种路径：设计师的下一站，成为架构师，还是走向业务？

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

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

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

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

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」从一个测试服务，逐渐演变成了一种产品设计理念。

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

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

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

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

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

我在 Heptabase VS Tana，两种不同的知识管理逻辑里也聊过类似的思考：Heptabase 这类空间化白板工具的核心价值，恰恰就是把「思考」从线性文档解放出来，变成可以被看见、被移动、被组合的过程。设计的前期工作其实和它是一回事。

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

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

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

TL;DR

设计师和产品经理之间的争执，根本不是"你觉得不行、我觉得可以"的口味之争，而是双方在用不同语言系统沟通。

设计要被业务认可，需要用业务语言（数据、价值、KPI 关联）来重新表达。

本文介绍一个实用框架：功能价值指数（FVI），帮你把"我觉得这个体验更好"翻译成"这个改动能带来 X% 的业务收益"。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

业务 Owner 的视角是什么？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 笔记法。我才发现原来有人早就把这种“结构信息”的思路整理成了一套方法。

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

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

TL;DR

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

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

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

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

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

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

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

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

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

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

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

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

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

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

阅读全文

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

💡 延伸阅读：

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

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

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

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

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

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

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

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 到设计稿，如何避免设计遗漏带来的坑？」。

💡 延伸阅读：

设计的业务价值表达：设计的意义，得用业务语言讲明白

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

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

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

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

TL;DR

设计师跨行业（比如从电商到医疗）时，过往的"产品直觉"可能会失效，因为直觉是在具体领域里慢慢建立的。

本文从一次面试案例切入，讲清楚产品直觉的两个来源（用户代入 + 领域深耕），以及如何主动校正直觉，让跨行业 landing 更顺滑。

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

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

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

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

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

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

产品直觉是如何形成的

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

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

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

💡 延伸阅读：

新工作入职的提问艺术：入职新公司，学会问问题才能少踩坑

跨行业面试的作品集策略：设计师的简历作品集应该关注什么？