一级导航放几个
一级导航的数量由用户能记住多少决定，四到七个是比较稳的区间。少于四个通常说明还可以合并，多于七个则开始互相掩盖，用户扫视时容易漏看。
一级导航的命名要用用户的语言，不用内部项目代号。财务里的对账、门店里的交接班，都是用户自己会说的词；数据中台、业务域这类说法只有内部人懂，放上导航等于给用户增加翻译成本。
如果一级项实在超过七个，先回头检查是不是把子任务提到了顶层。另一种常见偏差是追求对称，把模块数量凑成整齐的几组，结果每组内部并不相关，用户反而记不住。把导出、打印这类动作放进页面内，而不是让它占一个导航位，往往能一次减掉两三个。
判断放在哪一层
判断标准有两条：使用频次，以及它是否属于某个任务组。每天多次使用的功能，无论页面多小都值得放一级；一个月用一次的功能，即使很重要也适合放二级。
归属关系比频次更能解释层级。查看订单和查看订单详情是同一件事的两个层次，后者自然属于前者；查看订单和配置运费规则属于两件事，不该挤在同一层里。
一个实用的验证方法是把导航项念一遍，看是否存在包含关系。如果 A 的页面里必然会出现 B 的入口，B 大概率不该和 A 平级。
混合结构什么时候用
顶部主导航配左侧二级菜单，是中后台常见也比较好用的组合：顶部解决去哪一类事，左侧解决在这一类里看哪一页。这样两级之内能覆盖大部分功能，用户也始终知道自己在哪。
需要警惕的是把左侧菜单做成第二套主导航。当左侧项目数量超过十几个并且还在增长，说明信息架构该重新分组了，再加一层折叠只是把问题往下压。
移动端不适合照搬这套结构。屏幕宽度决定了一级导航通常放在底部，二级用列表页承接，深度控制在一到两层，再深就要考虑用搜索或筛选来替代逐层进入。
用命名测试验证
架构定稿前做一次低成本的验证：找几个目标用户，给出五个核心任务，请他们先写下会怎么走，再看导航找出对应路径。能直接指出来，说明命名清楚；在不同的词之间犹豫，或者在两个相近的项之间来回看，就说明这里有歧义。
记录每个人走错的地方，错两次以上的位置优先改。改动通常不是加一项，而是换词或换位置，这类调整成本很低，收益却直接体现在用户的第一次使用上。信息架构不是一次成型的。上线后看搜索词和退出来源，哪里的搜索量长期偏高，那里往往就是命名或归类的破口。
每次调整导航都要记录原因和观察到的现象，否则过一段时间就会有人凭印象再改回去。判断依据留在文档里，后续讨论才有共同的出发点。
