我最近做了一个工具，功能很简单：你在输入框里贴一段文字，它会自动帮你格式化。上线前我花了一整天写了一个"使用说明"——从格式要求到快捷键，从常见问题到注意事项，洋洋洒洒一千多字，我觉得自己写得特别贴心。
上线后，我打开后台数据，发现了一个让我崩溃的事实：80% 的用户根本没有打开过使用说明。他们打开页面，直接就在输入框里粘贴文字，然后点击格式化按钮。如果结果不对，他们不会去读说明——他们直接关掉页面，再也不回来了。
那一刻我明白了两件事：第一，用户不是傻子，他们只是太忙了。第二，如果用户需要读说明才能用对，那是你的设计有问题，不是用户有问题。
扫描，而不是阅读
用户在使用产品时，大脑处于一种特殊的模式：扫描模式。他们不会逐字逐句地读你的文案，而是快速扫过页面，寻找那些"看起来像是我要找的东西"。
这不是因为他们不尊重你的劳动成果，而是因为人的注意力是一种稀缺资源。在任何一个普通的工作日里，你的用户同时要处理工作消息、回复邮件、刷社交媒体、接孩子放学……他们打开你的产品时，脑子里可能在同时想着三件事。他们根本没有多余的精力来"读"你的产品。
你必须接受一个残酷的事实：99% 的用户不会认真读你的产品说明。他们不看，不是不尊重你，是他们真的很忙。设计要做的，是在用户不读的情况下也能用对。
那怎么办？我总结了三个原则。
原则一：让界面自己解释自己
好的界面是不需要说明书的。它的每一个元素都应该自解释——用户看到它，就知道该怎么做。
举个例子，我做过一个图片压缩工具。最开始我在页面顶部放了一行文案："请上传需要压缩的图片，支持 JPG、PNG、WebP 格式，单文件不超过 10MB。"你猜用户怎么做的？他们直接拖了一张图片到页面上，根本没看那行字。如果拖上去的格式不支持，他们就走了。
后来我改了一个设计：页面上放了一个大大的虚线框，框里写着"拖拽图片到这里"，框下面标注了"JPG / PNG / WebP · 最大 10MB"。用户不需要"读"——他们"看到"虚线框就知道这里是放图片的，看到格式提示就知道什么能传。这个改动之后，错误操作率下降了 70%。
关键区别在于：说明是在告诉用户"怎么做"，而设计是在让用户"自然就会做"。
原则二：默认值要聪明
如果你的产品需要用户做大量配置才能用，那你的产品就是失败的。用户不应该为了用你的产品而做选择题。
我做过一个代码格式化工具，里面有一个"缩进风格"的选项。我一开始觉得"Tab 还是空格"这个问题很简单，用户自己选一下就好了。结果发现大量用户在这个选项上卡住了——他们不是不知道选什么，而是根本不想选。他们只是想格式化代码，结果你让他们在两种技术信仰之间站队？
后来我把默认值设置成了"使用空格，每级缩进 2 个空格"——这是最通用的配置。同时我加了一行小字"点击这里可以修改缩进设置"。结果呢？95% 的用户根本不会去改那个设置。他们不需要选择，他们只需要一个合理的默认值。
这个教训告诉我：用户每做一次选择，都是在消耗他们的耐心和注意力。你的工作不是提供"尽可能多的选项"，而是替用户做出绝大多数选择，只把真正影响结果的关键选择留给他们。
原则三：减少选择，而不是增加引导
很多产品的思路是"用户不懂怎么用，那我加个引导吧"。于是一个引导弹窗、一个说明气泡、一个新手教程……用户还没有开始用你的产品，就已经被三段引导打断了。
但更正确的做法是：减少需要引导的东西。
我反思过自己的工具站，很多工具之所以需要"使用说明"，不是因为工具本身复杂，而是因为我把界面设计得太复杂了。一个工具页面上摆着五六个参数、七八个选项，用户当然需要引导。但问题不是"引导不够"，而是"界面本身就太复杂了"。
后来我给自己定了一个标准：如果一个工具需要超过 30 秒的说明才能让用户上手，那这个工具的设计就有问题。我需要重新设计，而不是写更多的说明文档。
这个标准很苛刻，但正是因为它苛刻，才逼着我去思考：哪些参数是真正必要的？哪些选项可以合并？哪些功能可以拆成单独的步骤而不是堆在一个页面上？
把用户的时间还给他们
回到开头那个故事。那个被我写得洋洋洒洒的使用说明，我后来删掉了。取而代之的，我在输入框里放了一段示例文本，用户一打开页面就能看到"格式化后的效果"。他们不需要读任何说明，看一眼就知道这个工具能做什么。
用户打开一个工具，对照着示例文本，粘贴自己的内容，点击按钮——完成。整个过程不到 10 秒。这才是好的设计。
你的用户不是不愿意花时间学习你的产品，他们只是想把时间花在真正重要的事情上。你的产品只是他们完成某个任务的工具，不是他们生活的全部。每一个需要用户"多读一份说明"的设计，都是在剥削他们的时间——而他们，只会用"离开"来回应你的剥削。
所以，下次你写产品说明之前，先问自己一个问题：如果用户不读这个说明，我的产品还能用吗？如果不能——那就先改产品，再写说明。