G2.02.2flat navigation for limited peer destinations设计研究
适合内容量有限且并列的场景
别名: 并列去处 · peer destinations · 小站点导航
概念解释
扁平导航不是一种更先进的结构，而是一种匹配条件：内容量有限，且各去处彼此并列。有限，指主去处少到可以在一屏里作为终点列出，不必再发明中间类。并列，指这些去处没有稳定的父子关系——「概览 / 日历 / 消息 / 我的」是四个任务入口，不是一类下面的四个子类。硬给它们加父级，用户反而要先猜那个假类是什么。
内容一多，或去处开始分出真正的上下级（商品类目、法规章节、课程体系），扁平就从「省一层」变成「把树假装成一排」。
机制
并列去处共享同一抽象层：每一个都是「进了产品之后立刻能做的一件事」，没有谁包含谁。人的任务模型已经是一张短名单，导航只要把名单外化。再插入一层分类，等于要求用户先学习一个他们任务里不存在的父概念，气味被稀释。
有限保证名单能被当成一张完整地图来学。六到八个终点一旦稳定，空间记忆和名称记忆都能覆盖全集；再多，全集不再可学，扁平所依赖的「我见过全部去处」不再成立。内容量增长时，失败模式不是选项稍微难扫，而是新去处无处可放：要么挤进已经并列的项里造成名不副实，要么偷偷加回第二层，结构在声明上仍叫扁平、在走法上已经是树。
怎么研究
先判定内容是不是并列集合，再比较扁平与强行分层。
- 范式：开放式卡片分类——若用户拒绝分组、或分组极不稳定，说明他们把条目当并列终点。再做两项任务对照：扁平列出 vs 加上一层人工父类。
- 自变量：去处数量、是否存在自然父类、父类名来自设计者还是用户。
- 因变量：首次点击是否仍落在「假父类」上、完成时间、用户事后能否画出完整去处名单。
- 方法论注意点：内部团队很容易给并列项发明听起来合理的父类（「工作台」「发现」）。要用目标用户的分组，不要用设计工作坊的分组。能背出全部去处，是「有限」成立的行为标准，不是设计师的直觉。
边界
工具型应用、小机构站点、功能固定的设置页，常常满足有限且并列。媒体库、政务服务、大型电商的去处既多又有真实层级，扁平顶栏只能覆盖少数主任务，其余仍要树或搜索。并列关系会随产品演进破裂：三个功能长大成三条产品线之后，继续扁平会让第一屏变成杂烩。多角色产品里，对 A 角色并列的入口，对 B 角色可能是一条深路径。
怎么落地
- 列出所有「用户进来就要能直接到达」的终点，数个数。能在一屏作为终点摆下、且卡片分类里分不出稳定父类，才维持扁平。
- 不要为了看起来「有信息架构」而给并列项加「平台 / 生态 / 中心」这类空父级。
- 新增第五个、第六个主去处时重新判定：是继续并列，还是已经出现了该切开的真父子。
- 验证：请未参与设计的人在三十秒内从导航复述全部主去处。复述不全，或把两个去处讲成从属关系，说明已经不是有限并列，该改结构而不是再加一个图标。