产品设计 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

吸引并任用优秀的人才。