做产品久了会发现一个残酷的事实用户根本不读使用说明书也不愿意仔细研究你的布局逻辑。他们打开页面第一眼能看懂就继续用看不懂就关掉然后去评论区说不好用。所以“让产品自己说话”不是一个营销口号而是一个很具体的工程要求产品里的每一个功能区域、点击入口、操作状态都要通过界面、文案、反馈和流程自然地告诉用户这里能做什么、现在是什么状态、下一步该怎么走。功能清楚一看就明白不是靠设计师天赋而是靠一套可执行的方法。这篇就按我自己的实战顺序拆一遍。1. 先搞清楚“自己说话”到底要求产品做什么1.1 自解释不是“功能简单”而是“被理解成本低”很多人把“让产品自己说话”理解成“把功能做简单”这是错的。功能可以很强大也可以很复杂但用户在理解它的时候不应该感到迷茫。比如一个专业剪辑软件功能一点都不简单但好用的剪辑软件打开后你依然能知道“素材在左边预览在中间时间轴在下面”。它没有用对话框把每个功能解释一遍而是靠空间位置、区域命名和操作手感让用户迅速建立假设。这个就叫做自解释。所以“功能清楚”不等于功能少而是用户看到这个页面时能在几秒内判断出“这是什么、我在这里能干什么、如果做了会有什么结果”。这个判断成本越低产品就越会自己说话。1.2 “自己说话”的四个基本层次我一般会把“让产品自己说话”拆成四个层次分别是能看见、能看懂、能操作、能反馈。第一个层次是能看见。功能入口要在它该出现的位置出现不能藏在某个角落。第二个层次是能看懂。看见之后用户能通过图标、文案、颜色、上下文知道它大概是什么作用。第三个层次是能操作。点击、滑动、输入这些动作要符合用户习惯不能反直觉。第四个层次是能反馈。操作之后产品必须给出明确反馈成功了、失败了、正在处理、还要等一下。这四个层次缺一个产品就会变哑巴。最常见的问题是界面上“能看见”但“看不懂”或者“能看懂”但点击后没有任何反馈用户以为没点上又点一次最后重复提交。所以我们在评估任何一次改动时都可以拿这四个层次去套这个功能用户能在哪里看见看见后能理解吗操作路径顺不顺做完之后会收到什么反馈如果有一个环节答不出来那这里就是在让产品“沉默”。1.3 常见误区以为“加了说明文字”就是说明白了很多团队为了让自己产品“说话”会在页面上塞各种提示气泡、问号图标和帮助文档。结果用户更加看不懂。原因是当解释本身需要用户额外阅读就说明这功能的设计还不够直白。真正有效的做法是让默认状态本身就带着答案。比如一个上传头像区域正常状态看到的是自己的头像鼠标悬停时显示“更换头像”用户不需要看帮助文档就知道点这里。反过来如果页面上放一个抽象的齿轮图标旁边再加一行小字“点击可修改个人照片相关设置”用户反而要停一下才能理解。所以“说明文字”是补救手段不是第一手段。优先靠信息架构、位置、大小、颜色、对比度和操作习惯让功能自解释实在无法避免的歧义才用一句话去补足。2. 为什么你的功能明明做了用户还是当成不存在2.1 功能被做成了“藏宝图”我见过很多后台管理系统功能上什么都有但用户真正用的只有两三个。原因不是用户懒而是产品把功能做成了藏宝图入口藏在二级菜单里要经过三个页面才能找到而且入口名字还很抽象。比如“数据配置”和“数据管理”看起来差不多用户根本分不清。明明功能做了用户却当它不存在根本原因就是路径太深、命名太模糊。判断路径是否过深有一个简单标准从打开产品的第一屏开始用户点击多少次才能完成他心里的那个目标。目标如果只是“新建一个项目”点击三次还没看到入口就必须重新审视导航。注意这里说的“新建项目”是用户语言不是产品内部模块名。2.2 界面信息密度过高每个元素都在抢注意力另一个常见问题是一个页面恨不得把十个功能都展示到首屏。于是每个图标都差不多大每个按钮都用了高亮色整个页面处处是重点结果等于没有重点。用户眼睛扫过时无法在短时间抓住最重要的行动点自然会忽略一些功能。解决信息密度问题不一定要砍功能但一定要定层级。核心操作要给足视觉重量比如更大的按钮、更高的对比度、更贴手的区域次要操作就弱化用文字链接、次要色、折叠或“更多”承载。如果所有元素都一样醒目用户就只能靠猜而猜错的概率非常高。2.3 缺少默认状态和中间反馈用户不知道操作是否生效还有一种情况更加隐蔽功能其实出现了用户也看到了甚至点击了但产品没有给出任何明确的点击反馈。比如按钮按下去颜色没变页面不跳转没有loading也没有提示用户就会怀疑自己是不是点错了。连续几次没有反馈用户就彻底放弃这个入口。所以判断一个功能“有没有被看见”不能只看它是否出现在界面上还要看它交互时用户能不能感知到“我在操作它”。按钮至少要有按下和松开的状态变化需要处理时间的操作要显示进度完成操作后要给结果页或提示反馈。没有反馈的操作在用户心里等同于不存在。2.4 很多问题不是设计问题而是技术实现粗糙我再强调一个容易被忽略的点有时候功能“自己说不了话”真不是产品设计的问题而是技术实现太粗糙。比如图片加载不出来只留一个破碎图标数据请求失败页面直接空白异步加载时没有骨架屏用户以为是页面坏了。这些状态下用户当然不会认为产品在“说话”他会直接认为产品坏了。所以想要产品自己说话前端和客户端团队要做的事情与设计师密切相关把加载、空、失败、异常这些边界状态都做成设计的一部分而不是等出bug了再补。空页面不能只写“暂无数据”而要告诉用户“这里现在没有内容但我可以怎么做”。失败页面不能只说“加载失败请重试”最好说明“可以检查网络也可以点击刷新”。3. 界面上最容易让用户“一看就懂”的五个落点3.1 页面结构和视觉重心的设计顺序要让用户“一看就明白”第一件事不是加文案而是先把页面结构理清楚。结构决定用户视线往哪儿走。我的设计顺序是先确立页面目的再确定主操作区最后补充次要信息和辅助操作。比如一个结算页面页面目的是“让用户完成付费”所以“确认付款”按钮必须在视线最直接能到达的位置金额必须放在离按钮最近的地方配送信息、优惠券、发票这些是次要信息可以在不干扰的情况下展示。如果页面目的不明确结构就会乱用户看哪都行最后就不知道从哪开始了。3.2 按钮状态可点、不可点、加载中、完成按钮是产品说话的主战场。用户扫描页面时最先注意到的往往是可点击的元素。一个按钮至少需要四态默认态、悬停态、按下态、禁用态还要根据场景加入加载态和完成态。我在验收开发效果时会特别注意几个细节。禁用按钮不能只改个灰色还要加上说明最好是保留可点击点击后弹提示说明为什么暂时不能点加载中的按钮要防止重复点击同时保持视觉上的反馈操作完成后的按钮要变成“完成”或“已提交”不能让用户以为任务没执行。3.3 空状态第一次使用就能明白这个页面能装什么空状态是“产品自己说话”最容易翻车的地方。我看到过太多空列表只写了一行“暂无数据”用户看完完全不知道这个页面是用来做什么的也不知道下一步该怎么办。合理的空状态要包含三个信息这里是哪里、这里将来可以有什么、用户现在能做什么。比如一个收藏夹页面空状态可以这样设计一个大图标示意“收藏”主文案写“还没有收藏任何内容”副文案写“看到感兴趣的内容可以点击收藏按钮保存”再放一个“去逛逛”按钮。用户即使第一次进来也不会迷茫。3.4 输入框和选择器的自解释输入框要自己说话最主要靠“占位提示”和“实时规则校验”。但占位提示不是万能的。比如一个手机号输入框只写“请输入手机号”是不够的它没告诉用户“是不是11位”“要不要加区号”。更稳的做法是输入时实时反馈输入完成自动校验出错后立刻提示具体原因而不是等提交时才统一报错。比如用户输入了12位数字如果前端能实时显示“手机号应为11位数字”用户马上改比最后提交报错要友好得多。另外选择器也一样默认值应该是大多数用户会用的选项而不是“请选择”。好的默认值能让用户跳过选择直接进行下一步。3.5 图标不能裸奔必须搭配文字或上下文图标在设计稿里很好看但在真实用户眼里经常看不懂。尤其是一些自定义图标设计师知道那是代表“分享”用户却可能觉得是“菜单”或“更多”。我的经验是除了极少数的通用图标如放大镜表示搜索、齿轮表示设置、房子表示首页其他图标尽量不要裸奔。要么放在文字旁边要么用带说明的提示框要么确保它在上下文语境中不会产生歧义。如果一个图标需要解释用户才懂那就不是一个好图标。宁可多几个字也不要让用户猜。如果做移动端空间紧张可以只用图标但至少要保证用户第一次点击后有明确的反馈帮助他建立“这个位置代表什么”的记忆。4. 让文案会说话按钮、提示、错误信息不再像机器翻译4.1 按钮文案要说“操作结果”不要说功能名很多产品的按钮文案喜欢用内部术语比如“提交”“保存”“确认”。这没有错但不够好。更好的按钮文案是描述操作结果让用户知道点了之后会发生什么。比如“确定删除”和“删除文件”后者更清楚“保存修改”比“保存”好“创建项目”比“确定”好。我在审核文案的时候会先问一个问题用户点击这个按钮他能预见到结果吗如果结果是破坏性的文案里必须出现这个动作本身。比如删除按钮只写“确定”用户根本不知道自己删除了什么这就有风险。至少写成“删除这条记录”把对象写明。4.2 错误提示要告诉用户“怎么解决”而不是只报“失败”错误提示是“产品自己说话”最关键的场合因为用户这时候本来就困惑、着急。如果只展示“提交失败”“请求超时”“系统错误”用户只会觉得这个产品很蠢。好的错误提示应该符合三段式发生了什么、为什么发生、用户该怎么办。比如登录密码错误提示“密码不对请重新输入”比“登录失败”清楚得多如果可能是账号被锁定要说明“连续输错5次账号将锁定30分钟”如果是网络问题可以说“网络不太顺畅已自动重试若仍失败请检查网络后刷新”。要注意的是错误提示不要堆砌技术术语比如“HTTP 500”“数据库连接超时”对普通用户没有意义。技术日志是给开发看的要把用户语言和日志分开。4.3 帮助文案越短越有效短到像人话很多产品帮助文案的最大问题是“不像人话”。比如“本模块用于对用户提交的订单进行审核与状态维护”用户读完要反应一下。如果改成“在这里查看并处理用户订单”是不是更直接写帮助文案有个笨但有效的办法把页面功能讲给旁边同事听看他用什么词复述那些词就是用户能理解的语言。比如你说“这个页面可以做优惠活动的创建、配置、发布和效果查看”同事可能复述成“就是搞活动的地方”那页面副标题就不如写“创建和管理营销活动”。另外帮助文案的位置也有讲究。不需要在页面上放一大段说明应该把最可能产生歧义的那一个点用一句话放在它旁边。其他内容放到帮助文档里。信息越短越容易被看见和吸收。5. 用流程设计降低理解成本引导、演示、默认值5.1 新手引导不是教学录像而是最简路径的提示很多产品喜欢在新用户第一次进入时展示一整套教程每一步都指向一个功能用户刚想操作就被引导打断。这种指引其实体验很差。新手引导的正确姿势应该是在用户可能产生疑问的那一刻用最小的浮层提示他下一步最优操作。比如首次进入后台不需要强制播放五步动画只需要在“新建项目”按钮旁边加一个淡出的小标签写“从这里创建你的第一个项目”用户想点就点不点也不影响。真正好的引导让用户感觉是自己摸索出来的而不是被教育出来的。5.2 演示数据能让人快速建立心智模型如果一个页面完全是空的用户很难知道这个页面的正确用法。尤其是表格、统计、报表类页面空荡荡的一堆列标题用户对数据含义、长度、格式都没有概念。这时候可以提供一个“载入演示数据”或“查看示例”的入口。用户点击后看到一行行真实的示例数据就能立刻理解这些字段代表什么、将来能放什么内容。但要注意演示数据必须足够典型最好同时包含长文本、日期、金额、状态等别用一堆“test”没有说服力。5.3 默认值和撤销机制是产品自说话的后备保障即使设计得再好用户还是会做错。产品要“自己说话”除了把功能讲清楚还要能够兜底。两个非常重要的兜底机制一个是合理的默认值一个是撤销或恢复。比如一个复杂的筛选器默认情况下不要选中“全部”而是选中最常见、用户最可能需要的那一项。再比如一个表单能自动填写的字段就不要让用户手动填。这些都是降低理解成本的隐性设计。更重要的兜底是撤销机制。用户在桌面端执行删除、移动、批量修改时如果没有二次确认就要允许撤销。撤销不只是保护用户也是在告诉用户这个操作不是不可逆的你放心用。6. 怎么验证产品是不是真的会“自己说话”6.1 找没参加过这个项目的人做第一眼测试很多团队在内部演示时总觉得产品已经“说得挺清楚”因为大家都参与了讨论都知道按钮是什么意思。但真实用户没有这些背景知识。所以我建议任何一个功能上线前都找两三个没有参加过这个项目的人让他们打开页面然后只说一句话“你看到这个界面觉得自己能做什么”然后记录他们的回答。注意不要给他们任何任务指引也不要提示“你点击看看”。如果他们能准确说出页面的核心功能和主要操作说明产品确实在说话。如果他们东问西问比如“这是什么”“点击这个会发生什么”那就说明这里还没有说明白。6.2 用行为数据看卡点停留、退出、重复点击光靠主观测试还不够线上数据能暴露真实问题。我会重点看三个指标用户在某个页面的平均停留时间、用户是否快速退出、某个按钮是否被反复点击。如果是新用户首次进入某个核心页面停留时间特别短大概率是没看懂如果某一步骤流失率特别高可能就是用户看懂了但不想做或者根本没看懂如果同一个按钮被快速点击多次很可能是点击后没有反馈或者反馈不明显用户以为没点上。这些指标不能单看要结合功能本身的复杂度做判断。一个目的复杂的配置页停留时间长是正常的一个简单的“确认支付”页停留太久就需要警惕。6.3 把“用户求助率”当作核心指标比“用户时长”“留存率”更直观的指标是“用户求助率”。比如产品内置帮助是否有检索客服工单中“这个功能在哪里”“怎么用”的比例高不高社区、群里被提问最多的问题集中在哪些功能上。如果求助率集中在少数几个模块上那这些模块大概率“没有自己说话”。可以建立一个小台账把用户主动来问“这个功能怎么用”的问题整理成清单每周看一遍。这些问题每一个都对应一个改进机会不一定都要做新功能很多其实只是改一个文案、调整一个入口、给一次反馈就能解决。7. 产品自查清单把看不见的设计问题找出来7.1 从“用户视角”重新走一遍关键路径最后给出一个我每次上线前都会做的自查清单。这套检查不是从产品经理视角看功能完成度而是从用户视角看“我能看懂多少”。把产品最核心的五条关键路径写下来。比如注册登录、创建第一个项目、完成第一笔订单、邀请同事加入、查看数据报表。然后以一个新用户身份不点开帮助文档不走内部培训一步一步走边走边问这个页面让我干什么这个按钮点了会怎样我走错一步能退回来吗凡是中间任何一步需要回忆、猜测、记笔记就把它标记为“不自己说话”的环节重新设计。7.2 最常用的十句话像不像同事之间的正常交流可以试着把产品里最常见的十句话提取出来包括按钮文案、空状态、错误提示和帮助标题。读一遍然后问自己这句话我会对同事口头说吗比如“提交”这个词现实里我们说“提交一下表单”吗更多是“把单子发给我”。所以按钮用“提交订单”比“提交”好“发反馈”比“提交反馈”更自然。如果一句话念出来生硬、冗余、像机器翻译那就要改。文案不是文学创作是让认知成本降低的工具。7.3 边缘状态加载、失败、空白、过期——最见功力最后一个自查项也是最容易遗漏的加载、失败、空白、过期。这四类边缘状态往往是最能体现“产品自己说话”的地方。一个好的产品在等待时会有进度或骨架屏在失败时会给原因和动作在空白时会给方向和入口在会话过期时会给“重新登录”的明确指引而不是把用户踢到登录页一句话不说。如果你把这四个状态都做得让用户心里有数那这款产品的基本功就算扎实了。我个人的经验是边缘状态不要最后才补应该在设计核心流程时同步考虑。因为边缘状态的文案、布局和交互往往需要和核心流程的视觉语言保持一致。补得越晚越容易做出临时应付的样式用户体验就越割裂。“让产品自己说话”最终要的是一种产品态度宁可自己多设计一层结构、多写一句话、多给一次反馈也不让用户多猜一次。功能清楚、一看就明白的产品不是靠某个天才灵感而是靠一次次走查、一遍遍问用户、一次次修改文案和状态堆出来的。下次再看到用户不会用某个功能先别急着怪用户去打开那个页面像第一次见到它一样看看它到底说了什么。
做产品久了会发现一个残酷的事实用户根本不读使用说明书也不愿意仔细研究你的布局逻辑。他们打开页面第一眼能看懂就继续用看不懂就关掉然后去评论区说不好用。所以“让产品自己说话”不是一个营销口号而是一个很具体的工程要求产品里的每一个功能区域、点击入口、操作状态都要通过界面、文案、反馈和流程自然地告诉用户这里能做什么、现在是什么状态、下一步该怎么走。功能清楚一看就明白不是靠设计师天赋而是靠一套可执行的方法。这篇就按我自己的实战顺序拆一遍。1. 先搞清楚“自己说话”到底要求产品做什么1.1 自解释不是“功能简单”而是“被理解成本低”很多人把“让产品自己说话”理解成“把功能做简单”这是错的。功能可以很强大也可以很复杂但用户在理解它的时候不应该感到迷茫。比如一个专业剪辑软件功能一点都不简单但好用的剪辑软件打开后你依然能知道“素材在左边预览在中间时间轴在下面”。它没有用对话框把每个功能解释一遍而是靠空间位置、区域命名和操作手感让用户迅速建立假设。这个就叫做自解释。所以“功能清楚”不等于功能少而是用户看到这个页面时能在几秒内判断出“这是什么、我在这里能干什么、如果做了会有什么结果”。这个判断成本越低产品就越会自己说话。1.2 “自己说话”的四个基本层次我一般会把“让产品自己说话”拆成四个层次分别是能看见、能看懂、能操作、能反馈。第一个层次是能看见。功能入口要在它该出现的位置出现不能藏在某个角落。第二个层次是能看懂。看见之后用户能通过图标、文案、颜色、上下文知道它大概是什么作用。第三个层次是能操作。点击、滑动、输入这些动作要符合用户习惯不能反直觉。第四个层次是能反馈。操作之后产品必须给出明确反馈成功了、失败了、正在处理、还要等一下。这四个层次缺一个产品就会变哑巴。最常见的问题是界面上“能看见”但“看不懂”或者“能看懂”但点击后没有任何反馈用户以为没点上又点一次最后重复提交。所以我们在评估任何一次改动时都可以拿这四个层次去套这个功能用户能在哪里看见看见后能理解吗操作路径顺不顺做完之后会收到什么反馈如果有一个环节答不出来那这里就是在让产品“沉默”。1.3 常见误区以为“加了说明文字”就是说明白了很多团队为了让自己产品“说话”会在页面上塞各种提示气泡、问号图标和帮助文档。结果用户更加看不懂。原因是当解释本身需要用户额外阅读就说明这功能的设计还不够直白。真正有效的做法是让默认状态本身就带着答案。比如一个上传头像区域正常状态看到的是自己的头像鼠标悬停时显示“更换头像”用户不需要看帮助文档就知道点这里。反过来如果页面上放一个抽象的齿轮图标旁边再加一行小字“点击可修改个人照片相关设置”用户反而要停一下才能理解。所以“说明文字”是补救手段不是第一手段。优先靠信息架构、位置、大小、颜色、对比度和操作习惯让功能自解释实在无法避免的歧义才用一句话去补足。2. 为什么你的功能明明做了用户还是当成不存在2.1 功能被做成了“藏宝图”我见过很多后台管理系统功能上什么都有但用户真正用的只有两三个。原因不是用户懒而是产品把功能做成了藏宝图入口藏在二级菜单里要经过三个页面才能找到而且入口名字还很抽象。比如“数据配置”和“数据管理”看起来差不多用户根本分不清。明明功能做了用户却当它不存在根本原因就是路径太深、命名太模糊。判断路径是否过深有一个简单标准从打开产品的第一屏开始用户点击多少次才能完成他心里的那个目标。目标如果只是“新建一个项目”点击三次还没看到入口就必须重新审视导航。注意这里说的“新建项目”是用户语言不是产品内部模块名。2.2 界面信息密度过高每个元素都在抢注意力另一个常见问题是一个页面恨不得把十个功能都展示到首屏。于是每个图标都差不多大每个按钮都用了高亮色整个页面处处是重点结果等于没有重点。用户眼睛扫过时无法在短时间抓住最重要的行动点自然会忽略一些功能。解决信息密度问题不一定要砍功能但一定要定层级。核心操作要给足视觉重量比如更大的按钮、更高的对比度、更贴手的区域次要操作就弱化用文字链接、次要色、折叠或“更多”承载。如果所有元素都一样醒目用户就只能靠猜而猜错的概率非常高。2.3 缺少默认状态和中间反馈用户不知道操作是否生效还有一种情况更加隐蔽功能其实出现了用户也看到了甚至点击了但产品没有给出任何明确的点击反馈。比如按钮按下去颜色没变页面不跳转没有loading也没有提示用户就会怀疑自己是不是点错了。连续几次没有反馈用户就彻底放弃这个入口。所以判断一个功能“有没有被看见”不能只看它是否出现在界面上还要看它交互时用户能不能感知到“我在操作它”。按钮至少要有按下和松开的状态变化需要处理时间的操作要显示进度完成操作后要给结果页或提示反馈。没有反馈的操作在用户心里等同于不存在。2.4 很多问题不是设计问题而是技术实现粗糙我再强调一个容易被忽略的点有时候功能“自己说不了话”真不是产品设计的问题而是技术实现太粗糙。比如图片加载不出来只留一个破碎图标数据请求失败页面直接空白异步加载时没有骨架屏用户以为是页面坏了。这些状态下用户当然不会认为产品在“说话”他会直接认为产品坏了。所以想要产品自己说话前端和客户端团队要做的事情与设计师密切相关把加载、空、失败、异常这些边界状态都做成设计的一部分而不是等出bug了再补。空页面不能只写“暂无数据”而要告诉用户“这里现在没有内容但我可以怎么做”。失败页面不能只说“加载失败请重试”最好说明“可以检查网络也可以点击刷新”。3. 界面上最容易让用户“一看就懂”的五个落点3.1 页面结构和视觉重心的设计顺序要让用户“一看就明白”第一件事不是加文案而是先把页面结构理清楚。结构决定用户视线往哪儿走。我的设计顺序是先确立页面目的再确定主操作区最后补充次要信息和辅助操作。比如一个结算页面页面目的是“让用户完成付费”所以“确认付款”按钮必须在视线最直接能到达的位置金额必须放在离按钮最近的地方配送信息、优惠券、发票这些是次要信息可以在不干扰的情况下展示。如果页面目的不明确结构就会乱用户看哪都行最后就不知道从哪开始了。3.2 按钮状态可点、不可点、加载中、完成按钮是产品说话的主战场。用户扫描页面时最先注意到的往往是可点击的元素。一个按钮至少需要四态默认态、悬停态、按下态、禁用态还要根据场景加入加载态和完成态。我在验收开发效果时会特别注意几个细节。禁用按钮不能只改个灰色还要加上说明最好是保留可点击点击后弹提示说明为什么暂时不能点加载中的按钮要防止重复点击同时保持视觉上的反馈操作完成后的按钮要变成“完成”或“已提交”不能让用户以为任务没执行。3.3 空状态第一次使用就能明白这个页面能装什么空状态是“产品自己说话”最容易翻车的地方。我看到过太多空列表只写了一行“暂无数据”用户看完完全不知道这个页面是用来做什么的也不知道下一步该怎么办。合理的空状态要包含三个信息这里是哪里、这里将来可以有什么、用户现在能做什么。比如一个收藏夹页面空状态可以这样设计一个大图标示意“收藏”主文案写“还没有收藏任何内容”副文案写“看到感兴趣的内容可以点击收藏按钮保存”再放一个“去逛逛”按钮。用户即使第一次进来也不会迷茫。3.4 输入框和选择器的自解释输入框要自己说话最主要靠“占位提示”和“实时规则校验”。但占位提示不是万能的。比如一个手机号输入框只写“请输入手机号”是不够的它没告诉用户“是不是11位”“要不要加区号”。更稳的做法是输入时实时反馈输入完成自动校验出错后立刻提示具体原因而不是等提交时才统一报错。比如用户输入了12位数字如果前端能实时显示“手机号应为11位数字”用户马上改比最后提交报错要友好得多。另外选择器也一样默认值应该是大多数用户会用的选项而不是“请选择”。好的默认值能让用户跳过选择直接进行下一步。3.5 图标不能裸奔必须搭配文字或上下文图标在设计稿里很好看但在真实用户眼里经常看不懂。尤其是一些自定义图标设计师知道那是代表“分享”用户却可能觉得是“菜单”或“更多”。我的经验是除了极少数的通用图标如放大镜表示搜索、齿轮表示设置、房子表示首页其他图标尽量不要裸奔。要么放在文字旁边要么用带说明的提示框要么确保它在上下文语境中不会产生歧义。如果一个图标需要解释用户才懂那就不是一个好图标。宁可多几个字也不要让用户猜。如果做移动端空间紧张可以只用图标但至少要保证用户第一次点击后有明确的反馈帮助他建立“这个位置代表什么”的记忆。4. 让文案会说话按钮、提示、错误信息不再像机器翻译4.1 按钮文案要说“操作结果”不要说功能名很多产品的按钮文案喜欢用内部术语比如“提交”“保存”“确认”。这没有错但不够好。更好的按钮文案是描述操作结果让用户知道点了之后会发生什么。比如“确定删除”和“删除文件”后者更清楚“保存修改”比“保存”好“创建项目”比“确定”好。我在审核文案的时候会先问一个问题用户点击这个按钮他能预见到结果吗如果结果是破坏性的文案里必须出现这个动作本身。比如删除按钮只写“确定”用户根本不知道自己删除了什么这就有风险。至少写成“删除这条记录”把对象写明。4.2 错误提示要告诉用户“怎么解决”而不是只报“失败”错误提示是“产品自己说话”最关键的场合因为用户这时候本来就困惑、着急。如果只展示“提交失败”“请求超时”“系统错误”用户只会觉得这个产品很蠢。好的错误提示应该符合三段式发生了什么、为什么发生、用户该怎么办。比如登录密码错误提示“密码不对请重新输入”比“登录失败”清楚得多如果可能是账号被锁定要说明“连续输错5次账号将锁定30分钟”如果是网络问题可以说“网络不太顺畅已自动重试若仍失败请检查网络后刷新”。要注意的是错误提示不要堆砌技术术语比如“HTTP 500”“数据库连接超时”对普通用户没有意义。技术日志是给开发看的要把用户语言和日志分开。4.3 帮助文案越短越有效短到像人话很多产品帮助文案的最大问题是“不像人话”。比如“本模块用于对用户提交的订单进行审核与状态维护”用户读完要反应一下。如果改成“在这里查看并处理用户订单”是不是更直接写帮助文案有个笨但有效的办法把页面功能讲给旁边同事听看他用什么词复述那些词就是用户能理解的语言。比如你说“这个页面可以做优惠活动的创建、配置、发布和效果查看”同事可能复述成“就是搞活动的地方”那页面副标题就不如写“创建和管理营销活动”。另外帮助文案的位置也有讲究。不需要在页面上放一大段说明应该把最可能产生歧义的那一个点用一句话放在它旁边。其他内容放到帮助文档里。信息越短越容易被看见和吸收。5. 用流程设计降低理解成本引导、演示、默认值5.1 新手引导不是教学录像而是最简路径的提示很多产品喜欢在新用户第一次进入时展示一整套教程每一步都指向一个功能用户刚想操作就被引导打断。这种指引其实体验很差。新手引导的正确姿势应该是在用户可能产生疑问的那一刻用最小的浮层提示他下一步最优操作。比如首次进入后台不需要强制播放五步动画只需要在“新建项目”按钮旁边加一个淡出的小标签写“从这里创建你的第一个项目”用户想点就点不点也不影响。真正好的引导让用户感觉是自己摸索出来的而不是被教育出来的。5.2 演示数据能让人快速建立心智模型如果一个页面完全是空的用户很难知道这个页面的正确用法。尤其是表格、统计、报表类页面空荡荡的一堆列标题用户对数据含义、长度、格式都没有概念。这时候可以提供一个“载入演示数据”或“查看示例”的入口。用户点击后看到一行行真实的示例数据就能立刻理解这些字段代表什么、将来能放什么内容。但要注意演示数据必须足够典型最好同时包含长文本、日期、金额、状态等别用一堆“test”没有说服力。5.3 默认值和撤销机制是产品自说话的后备保障即使设计得再好用户还是会做错。产品要“自己说话”除了把功能讲清楚还要能够兜底。两个非常重要的兜底机制一个是合理的默认值一个是撤销或恢复。比如一个复杂的筛选器默认情况下不要选中“全部”而是选中最常见、用户最可能需要的那一项。再比如一个表单能自动填写的字段就不要让用户手动填。这些都是降低理解成本的隐性设计。更重要的兜底是撤销机制。用户在桌面端执行删除、移动、批量修改时如果没有二次确认就要允许撤销。撤销不只是保护用户也是在告诉用户这个操作不是不可逆的你放心用。6. 怎么验证产品是不是真的会“自己说话”6.1 找没参加过这个项目的人做第一眼测试很多团队在内部演示时总觉得产品已经“说得挺清楚”因为大家都参与了讨论都知道按钮是什么意思。但真实用户没有这些背景知识。所以我建议任何一个功能上线前都找两三个没有参加过这个项目的人让他们打开页面然后只说一句话“你看到这个界面觉得自己能做什么”然后记录他们的回答。注意不要给他们任何任务指引也不要提示“你点击看看”。如果他们能准确说出页面的核心功能和主要操作说明产品确实在说话。如果他们东问西问比如“这是什么”“点击这个会发生什么”那就说明这里还没有说明白。6.2 用行为数据看卡点停留、退出、重复点击光靠主观测试还不够线上数据能暴露真实问题。我会重点看三个指标用户在某个页面的平均停留时间、用户是否快速退出、某个按钮是否被反复点击。如果是新用户首次进入某个核心页面停留时间特别短大概率是没看懂如果某一步骤流失率特别高可能就是用户看懂了但不想做或者根本没看懂如果同一个按钮被快速点击多次很可能是点击后没有反馈或者反馈不明显用户以为没点上。这些指标不能单看要结合功能本身的复杂度做判断。一个目的复杂的配置页停留时间长是正常的一个简单的“确认支付”页停留太久就需要警惕。6.3 把“用户求助率”当作核心指标比“用户时长”“留存率”更直观的指标是“用户求助率”。比如产品内置帮助是否有检索客服工单中“这个功能在哪里”“怎么用”的比例高不高社区、群里被提问最多的问题集中在哪些功能上。如果求助率集中在少数几个模块上那这些模块大概率“没有自己说话”。可以建立一个小台账把用户主动来问“这个功能怎么用”的问题整理成清单每周看一遍。这些问题每一个都对应一个改进机会不一定都要做新功能很多其实只是改一个文案、调整一个入口、给一次反馈就能解决。7. 产品自查清单把看不见的设计问题找出来7.1 从“用户视角”重新走一遍关键路径最后给出一个我每次上线前都会做的自查清单。这套检查不是从产品经理视角看功能完成度而是从用户视角看“我能看懂多少”。把产品最核心的五条关键路径写下来。比如注册登录、创建第一个项目、完成第一笔订单、邀请同事加入、查看数据报表。然后以一个新用户身份不点开帮助文档不走内部培训一步一步走边走边问这个页面让我干什么这个按钮点了会怎样我走错一步能退回来吗凡是中间任何一步需要回忆、猜测、记笔记就把它标记为“不自己说话”的环节重新设计。7.2 最常用的十句话像不像同事之间的正常交流可以试着把产品里最常见的十句话提取出来包括按钮文案、空状态、错误提示和帮助标题。读一遍然后问自己这句话我会对同事口头说吗比如“提交”这个词现实里我们说“提交一下表单”吗更多是“把单子发给我”。所以按钮用“提交订单”比“提交”好“发反馈”比“提交反馈”更自然。如果一句话念出来生硬、冗余、像机器翻译那就要改。文案不是文学创作是让认知成本降低的工具。7.3 边缘状态加载、失败、空白、过期——最见功力最后一个自查项也是最容易遗漏的加载、失败、空白、过期。这四类边缘状态往往是最能体现“产品自己说话”的地方。一个好的产品在等待时会有进度或骨架屏在失败时会给原因和动作在空白时会给方向和入口在会话过期时会给“重新登录”的明确指引而不是把用户踢到登录页一句话不说。如果你把这四个状态都做得让用户心里有数那这款产品的基本功就算扎实了。我个人的经验是边缘状态不要最后才补应该在设计核心流程时同步考虑。因为边缘状态的文案、布局和交互往往需要和核心流程的视觉语言保持一致。补得越晚越容易做出临时应付的样式用户体验就越割裂。“让产品自己说话”最终要的是一种产品态度宁可自己多设计一层结构、多写一句话、多给一次反馈也不让用户多猜一次。功能清楚、一看就明白的产品不是靠某个天才灵感而是靠一次次走查、一遍遍问用户、一次次修改文案和状态堆出来的。下次再看到用户不会用某个功能先别急着怪用户去打开那个页面像第一次见到它一样看看它到底说了什么。
