分组与命名
你怎么分组，用户就怎么理解这个产品。
分组是你对「用户怎么理解这个产品」的一次表态。分错了，之后每一次找东西他都要重新猜一遍。
你会遇到的现象：
- 用户找不到功能，但你觉得分类逻辑很清楚
- 新功能不知道归到哪一组，只能新开一组
- 导航项需要配一句说明才能看懂
最常见的错误是照着系统内部结构分组。「数据管理」「业务配置」这类名字对开发者是清晰的，因为它对应代码里的模块；但用户脑子里没有这套划分，他想的是「我要看这个月收了多少钱」。
按什么分组
| 分法 | 什么时候适合 | 风险 |
|---|---|---|
| 按任务 | 大多数情况的默认选择 | 任务本身要够稳定，否则改版时结构要重来 |
| 按对象 | 产品里有明确的核心实体，比如项目、客户 | 用户如果不是围绕实体思考，会觉得绕 |
| 按角色 | 不同角色用的功能完全不重合 | 一人多角色时会来回切换，很烦 |
| 按频率 | 作为二级排序用，不适合当主分组 | 频率会变，而且不同用户的频率不一样 |
| 按系统模块 | 几乎没有合适的时候 | 这是把你的实现细节丢给用户去理解 |
按任务分组还有个附带好处：任务清单本身就是你的功能范围。列不进任何一个任务的功能，多半可以砍掉。验证成本也很低：找五个人，给一个任务（「你要查上个月的收入」），看他们第一次点哪里。三个人以上点错，这一组就该改。
命名的四条
- **用用户会说的词，不用你们内部的词。**内部叫「工单」，用户嘴里叫「问题」，那就用问题。
- **同一件事全站只有一个叫法。**侧边栏叫「新建」，空状态叫「添加」，弹窗里叫「创建」，这是同一个操作换了三个名字。
- 名字要能说清「里面有什么」，不是「这是什么类型」。「我的项目」比「项目管理」好，前者能预期里面是什么。
- **避免「更多」「其他」「工具」。**这三个词等于承认分类失败。真放不下的东西，说明它不属于这个层级。
| 别用 | 改成 | 为什么 |
|---|---|---|
| 数据中心 | 我的记录 | 用户不觉得自己在管理数据 |
| 业务配置 | 规则设置 | 「业务」是内部说法 |
| 工作台 | 待我处理 | 前者说不清里面有什么 |
| 更多 | 拆开归到各组 | 杂物间只会越来越满 |
命名做完再整体读一遍侧边栏。把导航从上到下念出来，想象用户第一次看到：能不能在五秒内说清每个入口里有什么？如果有一条要停下来想，它就是下一次改版要处理的对象。
怎么验证
三个成本很低的验证方法，做完基本能确定分组对不对：
- **找五个人做反向测试。**给他们一个任务（「你要查上个月的收入」），看他们第一次点哪里。三个人以上点错，这一组就该改。
- **让他们自己给功能分组。**把功能写在卡片上，让用户来分，比你自己拍脑袋准。这就是卡片分类法的思路。card-sorting-wiki
- **试着往里加三个未来功能。**加不进去、只能新开一组，说明当前的分组逻辑不够抽象或者切错了维度。
三个方法都不需要正经的用研流程，半小时以内就能跑完。分组和命名是最容易被「我以为」支配的地方，花这几十分钟，能省掉之后几个月里用户每次找不到东西的怨气。