你有没有遇到过这种场景：产品功能明明已经上线，用户却总在问“这个按钮在哪”“这个功能怎么用”“我保存之后去哪了”。客服群里每天涌入大量类似问题，问题本身却和 Bug 无关；产品后台的数据也显示，用户进入某个页面后很快就退出了，甚至没有点击页面上的主要操作。
如果这个情况反复出现，问题大概率不在用户，而在产品本身：功能是存在的，但产品没有“把话说清楚”。这篇文章想讨论的，就是怎么让产品自己说话，让用户第一眼就明白功能是什么、能做什么、当前处于什么状态。它不是一个听上去很虚的设计理念，而是一套可以执行、可以验证、可以落到代码里的工程方法。接下来，我会从可视层、交互反馈、工程固化、验证方法四个维度展开，并把真实项目里容易踩的坑一起讲清楚。
1. 这篇文章真正要解决的问题
先说一个我经常在项目复盘里看到的结论：当用户不会用某个功能时，团队的第一反应往往是“用户教育不够”，然后去补文档、加新手引导、做操作视频。但问题往往不是用户不想理解，而是产品界面本身没有给出足够的理解线索。
一个功能要被用户顺利使用，至少要满足三个条件：第一，用户能发现这个功能；第二，用户能理解这个功能是干什么用的；第三，用户操作后能获得明确反馈，知道自己做对了没有。很多产品的失败，就是这三个环节里出现了断层。
第一个断层常见于功能入口太深。功能被放在四级菜单里，用户根本不知道它存在，再好的能力也没有价值。
第二个断层常见于页面文案过于“抽象”。按钮上只写“提交”“确认”“处理”，用户不清楚点了之后会发生什么，所以不敢点、不愿意点。
第三个断层常见于反馈缺失。用户点击之后，页面没有任何反应，用户不知道操作是否成功，于是反复刷新、反复点击，甚至误以为系统崩溃。
这篇文章要解决的，就是这三类问题。它不是只讲“交互设计有多重要”这类空话，而是希望给你一套能落地的思路：界面文字怎么写、空状态怎么设计、错误提示怎么给、组件库怎么约定、设计规范怎么在工程链路里生效、以及用什么方法验证功能真的“一看就明白”。
适合读这篇文章的人，不只是产品经理和交互设计师。前端工程师、测试工程师，以及负责整个模块的技术负责人，都应该关注这件事。因为“功能清楚”终究要在代码里实现，在组件库里沉淀，在联调里验证。团队里只要有一个人掌握这套方法，产品的“可理解性”就会往前走一大步。
2. 核心概念：功能清楚是一种可设计、可验证的产品能力
“让产品自己说话”并不是一个文学化表达，它在产品设计领域有一个专业说法：自解释性（Self-explanatory）。意思是，用户不需要借助外部帮助，就能从界面上理解产品的结构、功能和操作方法。
与之相关的一个概念是“示能”（Affordance）。比如一个按钮因为带有阴影和按压效果，看起来就像可以被点击；一个输入框带有边框和底部提示文字，用户就知道该在这里输入内容。这些视觉和交互上的暗示，就是产品“说话”的方式。
理解这个能力，需要先接受一个观点：用户在看一个页面时，依赖的是快速认知，而不是深度阅读。绝大多数用户不会仔细研究你的产品说明书，而是凭第一印象做判断。如果他们看到一个区域，不知道它是什么，就会直接跳过，或者离开页面。这个过程非常快，快到你的页面只有几秒钟的机会把信息传达出去。
从认知心理学角度看，这里涉及一个关键概念：认知负荷（Cognitive Load）。用户在一个页面上需要理解的信息越多，他的决策成本就越高；决策成本越高，用户放弃操作的可能性就越大。好的界面不要求用户做大量思考，而是把这些思考隐藏在清晰的层级、合理的归组和明确的文案中。
举个最简单的例子：
- 传统思维：为了让用户知道某个设置项的作用，我们在下方写了一整段说明文字。
- 自解释思维：说明文字尽量精简，同时通过对设置的默认值、选项名称、图标和示例值的设计，让用户即使不读说明也能做出正确选择。
再比如，过去我们习惯用“确定”作为弹窗按钮的文案，但“确定”到底确认什么？用户在弹窗里选择了“删除文件”，如果他点的是“确定”，他并不知道这个操作会不会删除文件。换成“删除文件”“取消”，用户就不需要思考。这两者的差别，看起来只是文案，实际上是在帮用户降低认知负荷。
| 维度 | 传统做法 | 自解释做法 |
|---|---|---|
| 功能入口 | 依赖菜单层级和文档说明 | 在页面结构中提供明确的视觉线索和上下文 |
| 操作命名 | “提交”“确定”“确认” | “保存草稿”“发布文章”“删除项目” |
| 反馈方式 | 一个系统提示，告知操作失败 | 在操作位置提示原因，并给出下一步建议 |
| 空状态 | 空白页面，用户不知所措 | 告诉用户“这里应该有什么”以及“怎么添加” |
| 帮助体系 | 帮助中心或用户手册 | 上下文帮助，解决当下这一步的问题 |
但这里要避免一个误区：自解释不等于“把界面上所有信息都铺出来”。信息堆得越多，界面越拥挤，用户反而越难判断重点。真正自解释的界面，做的是取舍，是让用户在当前场景下只看到当前需要的信息，并在需要时提供帮助。
我的判断是：功能清楚不是一个感性的指标，它和性能、稳定性一样，可以被定义、被测量、被迭代。你完全可以在一次版本迭代里，把“用户能否在 5 秒内说出页面的主要功能”作为验收条件来推动团队改进。
3. 可视层的改造：界面结构、文案和视觉层级
要让产品“自己说话”，首先要看用户打开页面后第一眼能看到什么。这个“第一眼”不是靠用户读完所有文字，而是靠视觉层级建立的。
3.1 先有层级，再谈美观
很多人做界面设计时，习惯先追求“好看”，结果页面是漂亮了，用户却找不到重点。正确做法应该是先确定信息优先级：这个页面最重要的操作是什么？用户最需要先了解什么？
一个合理的视觉层级至少包括三个层次：
- 页面标题和主操作，应该在视觉上最突出。
- 次要功能、辅助说明，应弱化但不能消失。
- 低频操作和高级设置，可以通过折叠、分组或弹窗隐藏。
比如一个“新建项目”的页面，主操作是“创建项目”，辅助操作可能是“导入已有项目”，低频操作可能是“修改高级配置”。设计时应该让“创建项目”这个按钮拥有最强的视觉权重，让用户一进来就知道第一步该做什么。
3.2 文案是功能的一部分
文案不是设计完成后再补上去的“装饰”，它就是功能本身的组成部分。按钮上的文字会把用户引导到操作结果上，错误提示里的文字则决定了用户是否知道如何修复问题。
我们来看一组常见的按钮文案对比：
| 场景 | 模糊文案 | 清晰文案 |
|---|---|---|
| 表单提交 | 确认 | 保存修改 |
| 删除操作 | 删除 | 删除这条数据 |
| 发布内容 | 提交 | 发布文章 |
| 关闭页面 | 取消 | 放弃修改并返回 |
“确认”这个词的问题在于，它没有确认的对象；“删除这条数据”则明确告诉用户，这个操作影响的是一条数据，而不是整个列表。
类似的，页面上的说明文字也应该遵循“能少写就少写”的原则。新手容易觉得“多说一点用户就懂了”，但实际上，用户很少会读长文本。一个更有效的做法是：把最关键的约束直接放在控件上。比如输入密码时，与其在旁边写一段“密码需要包含字母和数字，至少8位”，不如直接在输入框内给一个示例如：Abc@123456，或者在输入框下方动态显示当前密码是否满足要求。
从工程角度讲，文案还应该被当成可维护的代码资产，而不是散落在页面里的硬编码。这一点我会在第5节详细讲。
3.3 视觉元素的一致性
“功能清楚”还要求相似的功能在视觉上保持一致。用户一旦学会了一个按钮的样式，他会期待另一个同类型按钮有同样的表现。如果团队里没有设计规范，不同的开发同学按自己的习惯写了不同样式的按钮，用户就会困惑：这两个按钮是不是不同的功能？
在实际项目中，解决方案是建立基础组件库。按钮、输入框、卡片、空状态、标签这些基础组件必须有统一的样式、命名和交互行为。组件库看起来是在服务开发效率，实际上它同时也在建立用户对产品的认知模型。
4. 交互反馈：通过状态变化让功能“主动开口”
界面结构解决的是“看不见”和“看不懂”的问题，交互反馈解决的则是“做错了怎么办”和“做完了吗”的问题。一个产品能不能“说话”，很大程度上要看它在用户操作过程中和操作完成后，有没有给出足够清晰的反馈。
4.1 空状态，是产品解释自己的最佳机会
很多产品在页面没有数据时，直接显示一个空白区域，用户完全不知道这里应该展示什么。空状态是一个极有说服力的“说话”机会：它应该告诉用户三件事——这里是什么、为什么是空的、接下来可以做什么。
比如一个“项目列表”的空状态，如果只是显示空白页面，用户会怀疑是不是系统出错了。好的空状态应该类似于：
<!-- src/components/EmptyProjectState/index.html --> <!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>空状态示例</title> <link rel="stylesheet" href="styles.css" /> </head> <body> <main class="empty-state"> <div class="empty-state__icon">📂</div> <h1 class="empty-state__title">还没有项目</h1> <p class="empty-state__desc">创建第一个项目后，它会显示在这里，方便你快速进入和继续上次的工作。</p> <button class="empty-state__action" type="button">创建第一个项目</button> <a class="empty-state__link" href="/docs/getting-started">不了解项目？查看快速上手</a> </main> </body> </html>/* src/components/EmptyProjectState/styles.css */ .empty-state { display: flex; flex-direction: column; align-items: center; justify-content: center; min-height: 360px; padding: 24px; text-align: center; border: 1px dashed #d0d7de; border-radius: 8px; background: #f6f8fa; } .empty-state__icon { font-size: 48px; line-height: 1; margin-bottom: 12px; } .empty-state__title { font-size: 20px; margin-bottom: 8px; color: #1f2328; } .empty-state__desc { font-size: 14px; color: #656d76; max-width: 320px; margin: 0 auto 16px; } .empty-state__action { padding: 8px 16px; background: #0969da; color: #fff; border: none; border-radius: 6px; cursor: pointer; font-size: 14px; } .empty-state__link { margin-top: 12px; font-size: 13px; color: #0969da; text-decoration: none; }这样做的价值是：即使用户第一次进入产品，也不知道这个页面是干什么的，但只要看到“创建第一个项目”和说明文字，就完成了理解并进入操作流程。它比任何文档都能更快地帮助用户上手。
4.2 表单校验要第一时间给出原因和方向
用户填表单时最怕两种体验：一种是点击提交后才告诉你“输入错误”，但不告诉你哪里错了；另一种是在输入过程中一直没提示，到提交时才弹出一个大红色错误框。
更好的做法是即时校验，并在需要用户修正的位置给出具体原因和修改建议。
<!-- src/components/LoginForm/index.html --> <!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8" /> <title>表单校验示例</title> <style> .form-item { margin-bottom: 16px; } .form-label { display: block; margin-bottom: 4px; font-weight: 600; } .form-input { width: 100%; padding: 8px 10px; border: 1px solid #d0d7de; border-radius: 6px; font-size: 14px; } .validation-message { display: none; margin-top: 4px; font-size: 13px; color: #cf222e; } .form-input:invalid:not(:placeholder-shown) ~ .validation-message { display: block; } </style> </head> <body> <form class="form" novalidate> <div class="form-item"> <label class="form-label" for="email">邮箱</label> <input class="form-input" type="email" id="email" name="email" placeholder="name@example.com" required /> <p class="validation-message" role="alert">请输入正确的邮箱格式，例如 name@example.com</p> </div> <button class="form-submit" type="submit">获取验证码</button> </form> </body> </html>在上面的示例中，使用了 HTML 原生的type="email"并搭配:invalid状态。用户一旦输入了不符合邮箱格式的内容，输入框下方就会立刻出现一条原因明确的提示。这里的触发逻辑利用了原生校验状态，减少了 JavaScript 的复杂逻辑，也保证了语义化。
但要注意，原生校验在高版本浏览器中会触发浏览器自带的错误气泡，不同浏览器样式不同。如果你希望提示风格与产品完全一致，可以配合noValidate和 JavaScript 做自定义校验。核心原则不变：错误信息必须靠近触发错误的控件，并明确告诉你“哪里错了”和“怎么改”。
4.3 操作成功或失败后，给用户下一步的选择
用户提交完数据后，页面不应该“静悄悄”。一次操作完成后，至少要有一个结果反馈，并且最好给出下一步操作的入口。
比如用户成功创建了一个项目，结果反馈可以写成：
- 标题：项目“新官网改版”创建成功
- 说明：团队所有成员已可以访问。
- 操作：进入项目 / 邀请成员 / 返回列表
如果把创建成功页面做成一个空白页，用户又会开始寻找“我接下来该干嘛”。产品在此时“说话”的方式，是替用户预判下一步。
5. 工程层面：把“一看就明白”固化到代码和组件规范中
如果“让产品自己说话”只是靠一次设计改版，效果很难持续。它的真正价值，在于把它变成团队日常开发和代码评审的一部分。要做到这一点，需要从工程机制上落实几件事。
5.1 文案资源集中管理
文案是产品清晰度的重要组成部分，但它经常被当成“最后一步”来处理。很多项目里，文案散落在各个页面文件里，改一个词要全局搜索，而且容易出现中英文混杂、语气不统一的问题。
更稳妥的做法是把文案抽离成独立的资源文件，统一管理、统一评审。以 JSON 为例：
{ "productName": "协众文档", "emptyState": { "projectListTitle": "还没有项目", "projectListDesc": "创建第一个项目后，它会显示在这里，方便你快速进入和继续上次的工作。", "projectListAction": "创建第一个项目", "projectListHelpLink": "不了解项目？查看快速上手" }, "form": { "emailPlaceholder": "name@example.com", "emailInvalid": "请输入正确的邮箱格式，例如 name@example.com", "submit": "获取验证码" }, "feedback": { "createProjectSuccessTitle": "项目“{projectName}”创建成功", "createProjectSuccessDesc": "团队所有成员已可以访问。", "goToProject": "进入项目", "inviteMembers": "邀请成员", "backToList": "返回列表" } }这样的资源文件，放在src/i18n/zh-CN/product.json下，可以让前端开发直接引用。对团队协作来说，它还有两个额外价值：第一，产品经理可以在这个文件里直接评审文案，而不需要打开一个个页面；第二，后续做多语言时，不需要改动业务代码，只需要增加新的语言资源文件。
5.2 组件层强制规范
为了让所有团队成员的页面保持一致的清晰度，在基础组件设计时就应该约定和约束一些必要属性。
这里举一个按钮组件的 TypeScript 定义示例：
// src/components/Button/types.ts export interface ButtonProps { /** 按钮视觉样式 */ variant: 'primary' | 'secondary' | 'danger' | 'ghost'; /** 操作结果必须具体，不能只写“确定” */ actionText: string; /** 如果不满足，无法渲染按钮，必须补充说明 */ ariaLabel?: string; /** 允许在按钮下方附带一句简短说明，用于解释操作影响 */ helperText?: string; disabled?: boolean; onClick?: () => void; }在这个约束下，开发者写按钮时就会逼自己想清楚：这个点击操作到底会产生什么结果？如果按钮文案只是“确认”，代码评审时就能借助组件约束，把这个不清晰的表达揪出来。
组件规范不只是在“样式”上约束，还应该在语义、可访问性、文案结构上进行约束。类似的组件还包括：
- 输入框：支持
placeholder、hint、errorMessage等字段。 - 空状态组件：强制传入
title、description、action。 - 错误提示组件：包含
title、reason、suggestion字段。
这些看起来是技术细节，但它们决定了一套设计原则是不是能真正落地到每个页面。
5.3 可访问性与语义化
“功能清楚”本身就是可访问性的底层要求。无障碍设计（A11y）里强调的很多内容，例如语义化标签、键盘操作、焦点管理、ARIA 标签，和“让功能自解释”的目标高度一致。
语义化 HTML 标签能帮助辅助技术屏幕阅读器正确理解页面：按钮使用<button>，导航使用<nav>，标题使用<h1>/<h2>。这样不仅让读屏用户可以理解，也有利于搜索引擎理解页面。与此同时，使用aria-describedby关联帮助文字，可以让屏幕阅读器用户在获得焦点时读到更多上下文。
更重要的是，无障碍设计并不只是照顾障碍群体。一个在高铁上单手操作手机的用户，一个在嘈杂环境中用手机的用户，都会因为按钮更大、文案更明确、反馈更及时而受益。所以，在开发阶段引入eslint-plugin-jsx-a11y之类的检查工具，或者在代码评审中关注aria-label、焦点状态，都不是额外的负担，而是产品清晰度的工程化保证。
6. 帮助体系：给用户一个“可被找到”的解释通道
即使产品设计已经尽量做到自解释，总有一些低频、复杂的功能，不可能在界面上把所有信息一次性讲清楚。这时候需要一个兜底的帮助体系，但关键在于：帮助体系要在用户需要的时刻出现，而不是一开始就轰炸用户。
6.1 新手引导不是越多越好
很多产品上线时，会做一个 5 步以上新手引导，强制用户看完才能进入。从数据上看，这样做的结果是大量用户跳过引导，甚至直接流失。新手引导更适合用一个简短的第一步任务来替代，让用户通过完成一个真实操作来学会产品，而不是让用户用几分钟阅读规则。
如果确实需要做引导，也应该把它设计成可重复访问的。也就是说，用户第一次跳过引导，之后仍然可以通过“帮助”入口或“重看引导”按钮再次查看。切勿把学习路径做成一次性、不可逆的流程。
6.2 上下文帮助优先于全局帮助
用户遇到问题时的第一反应，往往是在当前页面上寻找解决方案，而不是去帮助中心搜索。因此，在产品上提供上下文帮助，比在帮助中心写一百篇文章更有效。
实现方式有很多种：在复杂表单旁边放一个“为什么需要这个字段”的图标，点击后展开说明；在功能模块右上角放一个“了解该功能”的链接；在操作失败的错误提示里直接附上相关文档链接。
需要注意的是，上下文帮助不要默认全部展开，否则页面会变得很长。更合适的做法是默认只展示关键信息，把解释入口放在用户需要时可触达的位置。
6.3 帮助中心应该和产品内容保持同步
这个坑很经典：产品做了 2.0 大改版，功能名称改了，操作路径改了，但帮助中心还停留在 1.0 的文档里。用户在产品里找不到某个功能，搜到帮助中心，却发现帮助中心里的功能也和产品不一致。这种体验对信任感的伤害，比没有帮助中心更大。
解决方式是把“帮助内容更新”放入版本发布的完成定义中。产品功能上线前，需要同时完成相关文档的更新、帮助中心结构的新增或修改，以及关键词的同步。这项工作最好由负责功能的开发或产品同学发起，而不是等用户投诉之后再补救。
7. 怎么验证“一看就明白”真的做到了
如果团队听完前面几节，马上回去改了一版文案和空状态，这还不够。你还需要一种方式，确认改动确实让用户理解了。否则，我们可能只是在按自己的喜好“自嗨”。
7.1 第一眼测试和 5 秒测试
第一眼测试是最简单有效的方法。让一个没有使用过该产品的人，看页面 5 秒钟，然后移开屏幕，问他三个问题：
- 这个产品是什么？
- 这个页面上最重要的事情是什么？
- 你接下来会点击哪里？
如果三个人里有两个能给出接近正确答案，说明页面的自解释性是不错的；如果回答完全偏离，说明需要调整结构和文案。这个测试不需要严格的实验室设备，只需要找一些不参与该项目的新员工，或者在线可用性测试工具，就能获得有效反馈。
7.2 任务成功率测试
第一眼测试解决“看没看懂”，任务成功率测试解决“能不能完成”。设定一组核心任务，比如“创建一个新项目并邀请一个人”“修改个人资料并保存”“删除一条数据后找回”，让测试用户在不接受任何外部帮助的情况下完成。
在记录时，至少关注三组数据：任务完成率、完成任务的时间、以及操作中是否出现犹豫或错误点击。完成率高不代表体验好，如果用户花了很长时间才完成，同样说明产品没有把话说清楚。
7.3 线上数据验证
除了测试，线上数据也能暴露出问题。常见的数据指标包括：
- 功能入口点击率：如果功能上线了一周，入口点击率极低，说明用户可能没看见，或者看见了不知道它是干什么的。
- 表单提交成功率：如果用户开始填写，但提交成功率很低，通常是因为字段说明不清或校验反馈不及时。
- 错误提示后的重试率：如果用户输入错误后，立即修改并成功提交，说明错误提示是有效的；如果用户直接离开，那说明提示没有帮助到用户。
- 页面退出位置：通过页面停留时长的分布，可以判断用户是在某个区块陷入困惑。
这里尤其要提醒一点：不要只看总流量，要看“首次使用路径上的行为”。新用户第一次进入页面后的行为，最能反映产品的自解释能力。
7.4 走查清单
在迭代上线前，可以建立一份“清晰度走查清单”，每一条都对应一个可执行的检查项。例如：
- 页面标题是否与用户当前任务一致？
- 主操作按钮是否在首屏可见？
- 按钮文案是否说明操作结果，而不是“确定”“提交”这类笼统词？
- 是否有空状态？空状态里是否说明“为什么为空”和“下一步做什么”？
- 表单错误提示是否在控件旁边显示，并给出具体修正建议？
- 复杂功能是否有上下文帮助入口？
- 帮助文档和帮助中心是否与当前版本功能一致？
- 键盘操作和读屏软件是否可以完成核心流程？
这份清单可以放进团队的“上线前检查”里，和死链检查、回归测试放在同一层级，避免“清晰度问题”永远在最后一刻被放弃。
8. 常见问题与排查思路
在实际项目中，不同团队遇到的问题表现各不相同，但根因往往有共性。我整理了几类常见现象和对应的排查方向，方便你在迭代时对照使用。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 功能上线一周，点击率很低 | 入口层级太深，或者按钮文案不够明确 | 查看页面热力图，观察用户滚动和点击分布；做第一眼测试 | 将入口提前到主操作区，把按钮文案改为“创建第一个项目”等具体操作 |
| 用户总问“这个功能怎么用” | 页面结构缺少上下文帮助，或功能命名与用户认知不一致 | 分析客服提问关键词，对照功能模块标注帮助入口 | 在对应模块增加上下文帮助入口，重命名功能名称 |
| 表单提交失败率高 | 校验提示不清晰，用户不知道格式要求 | 查看错误日志，统计失败字段；抓取提交失败时的表单值 | 增加即时校验和字段示例，将错误提示放在控件下方，并给出修改建议 |
| 新用户跳过引导后仍不会用 | 新手引导被设计成一次性流程，用户跳过后缺乏再次学习入口 | 查看引导完成率数据和重复访问数 | 保留帮助入口，允许用户主动重看引导；把引导改成完成一个关键任务的模式 |
| 帮助文档和产品功能对不上 | 版本发布时未同步更新文档 | 对照版本号检查帮助中心内容 | 把文档更新加入发布完成的定义，强制同步 |
| 用户反馈界面太复杂，不知道先做什么 | 页面上主次不分明，所有信息都在抢注意力 | 做 5 秒测试，观察用户第一反应 | 强化主操作视觉层级，弱化低频辅助功能 |
这个表格里的每一条，都建议在真实项目中用数据去验证，而不是凭感受判断。很多团队在排查清晰度问题时，最容易犯的错误，是产品经理和开发各执一词，最后用“用户习惯不同”来解释。实际上，只要把问题翻译成“用户在哪个位置产生了困惑”，排查就会变得具体。
9. 最佳实践与工程落地建议
最后总结几条有操作性的实践建议，方便你直接引入团队流程。
一、把清晰度纳入完成定义。“功能完成”不应该只等于“代码写完、接口联调完、Bug 清零”，还应该包括：页面文案经过评审、空状态已覆盖、错误提示已明确、帮助入口已就位、可访问性检查通过。这几乎不需要新增开发成本，只需要把它放进定义里。
二、建立文案评审机制。文案不要在产品细节全部开发完以后才补。建议在需求评审阶段就拟定主要文案，在开发阶段把文案资源提交到独立的 JSON 文件，由产品经理在代码评审时一并确认。文案评审关注的是可理解性，不是语言润色。
三、组件库要约束“帮助信息”字段。在设计基础组件时，给按钮、输入框、空状态等组件准备helpText、ariaLabel、errorMessage等字段。这样，“把功能说清楚”就不是某个页面的自觉行为，而是所有页面继承的默认能力。
四、用真实用户验证，而不是用团队直觉。团队内部对产品多少都有“知识诅咒”，很难设身处地感受到新用户的不理解。至少在每个迭代做一次小规模的 5 秒测试或任务测试，成本低，效果直接。
五、要克制“自我表达”的欲望。产品文案和界面设计的目标是帮助用户完成任务，不是展示团队的文字功底。能用一个词说清楚的，绝不要用一句话；能用一个默认值说明的，绝不要加一个输入框。简洁本身就是清晰度。
六、建立“功能变更 + 文档变更 + 引导变更”联动流程。功能改名、操作路径变化、字段调整，都需要同步更新文档和引导，前文已经强调过。这件事可以在项目管理工具里做成一个发布模板，避免每次上线都遗漏同步。
七，也是最后一点：不要把责任推给用户。如果一个功能需要用户阅读文档才能使用，产品就没能“自己说话”。技术团队应该把功能清晰度当成产品的一个正向资产，持续投入和衡量，而不是等到用户投诉了再补救。
下次当你提测一个新功能时，可以打开页面，假装自己完全没有看过需求文档，尝试回答这三个问题：这个页面是什么？我能在这里做什么？我现在处于什么状态？如果答案在三秒内说不出来，那么用户大概率也说不出来。这时候，与其修改用户，不如先修改产品。
