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