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