导航结构设计:让用户三步内找到东西

基于内容清单做信息架构,给出分组依据与命名规则。

什么时候用:网站功能越加越多,导航栏挤成一行,用户还是找不到,只能靠搜索。

提示词(整段复制)

你是信息架构师。请为下面这个站点重做导航结构。

站点与业务:{{站点}}
现有内容/功能清单:{{清单}}
用户主要任务:{{任务}}
现有导航问题:{{问题}}

输出要求:
1. **任务排序**:按「发生频率 × 重要性」给用户任务排序,说明数据来源或假设。
2. **分组方案**:给出顶层 5~7 个入口,每个入口一句话说明「收哪些内容、不收哪些」。分组依据要写出来(按任务/按对象/按流程,选一个并说明为什么)。
3. **命名**:每个入口的名字控制在 4 字内,说明为什么用这个词而不是内部术语(如用「账单」不用「账务中心」)。
4. **层级深度**:说明为什么控制在 2 层,超过 2 层的内容如何处理。
5. **交叉入口**:列出 3 组「同一内容有多个合理入口」的情况,给出主入口与次入口的取舍。
6. **验证方法**:给一个低成本验证方式(如 5 人卡片分类、树测试),说明看什么结果判定失败。

约束:
- 不按组织架构分组(那是内部视角)。
- 顶层入口不超过 7 个。

复制时把 {{变量}} 换成你自己的内容;变量名不要改,改了模型容易把它当普通文字。

要替换的变量

变量示例值
{{站点}}一个企业服务商的官网 + 客户后台
{{清单}}产品 6 个、解决方案 8 个、案例 30 个、文档、定价、支持、登录
{{任务}}了解产品(新客)、找文档(已购)、看案例(评估中)
{{问题}}现在按「产品/方案/资源」分,用户不知道案例该去哪个区找

实操建议

常见问题

顶层到底放几个?

5~7 个。超过 7 个用户的扫视效率明显下降,这时应该考虑合并或下沉。

案例要不要单独成一级?

看它是不是核心决策依据。B 端通常值得单独成一级,或放在「解决方案」下的显著位置。

配套工具