Grouping and Naming
Grouping is your stand on "how users should understand this product." Get it wrong and every later search starts with another round of guessing.
What you will run into
- 用户找不到功能，但你觉得分类逻辑很清楚
- 新功能不知道归到哪一组，只能新开一组
- 导航项需要配一句说明才能看懂
The most common mistake is grouping by the system's internal structure. Names like "Data Management" and "Business Config" are clear to developers because they map to code modules; but the user has no such mental map — they're thinking "I want to see how much came in this month."
What to Group By
| 分法 | 什么时候适合 | 风险 |
|---|---|---|
| 按任务 | 大多数情况的默认选择 | 任务本身要够稳定，否则改版时结构要重来 |
| 按对象 | 产品里有明确的核心实体，比如项目、客户 | 用户如果不是围绕实体思考，会觉得绕 |
| 按角色 | 不同角色用的功能完全不重合 | 一人多角色时会来回切换，很烦 |
| 按频率 | 作为二级排序用，不适合当主分组 | 频率会变，而且不同用户的频率不一样 |
| 按系统模块 | 几乎没有合适的时候 | 这是把你的实现细节丢给用户去理解 |
Four Rules for Naming
- Use the words users say, not your internal jargon. Internally it's a "ticket"; users call it a "problem." Use "problem."
- One name for one thing, across the whole site. "New" in the sidebar, "Add" in the empty state, "Create" in the modal — that's one action with three names.
- The name should say what's inside, not what type it is. "My Projects" beats "Project Management" — the first sets an expectation of contents.
- Avoid "More," "Other," "Tools." These three words are an admission of failed categorization. If something truly doesn't fit, it probably doesn't belong at this level.
| 别用 | 改成 | 为什么 |
|---|---|---|
| 数据中心 | 我的记录 | 用户不觉得自己在管理数据 |
| 业务配置 | 规则设置 | 「业务」是内部说法 |
| 工作台 | 待我处理 | 前者说不清里面有什么 |
| 更多 | 拆开归到各组 | 杂物间只会越来越满 |
How to Validate
Three low-cost validation methods — run them and you can basically confirm whether the grouping is right.
- 找五个人做反向测试。给他们一个任务（「你要查上个月的收入」），看他们第一次点哪里。三个人以上点错，这一组就该改。
- 让他们自己给功能分组。把功能写在卡片上，让用户来分，比你自己拍脑袋准（见卡片分类）。
- 试着往里加三个未来功能。加不进去、只能新开一组，说明当前的分组逻辑不够抽象或者切错了维度。