★ FEATURED ARTICLE 最近帮一个刚转岗做B端产品的同事评审设计稿他指着一个后台页面的侧边栏问我“这就是次导航吧它到底解决了什么问题”说实话这个“次导航”的说法在日常工作里出现频率很高但很多人对它的理解是模糊的——有人觉得侧边栏就是次导航有人觉得面包屑算次导航还有人把Tab栏和筛选器也归进这一类。如果只给一个定义那太草率了。次导航不是某一个具体组件而是一类“非主入口”的导航机制的总称。它在信息架构里的位置、产品形态上的变化、交互上的分寸感都直接影响用户能不能顺畅地用下去。这篇文章就结合我自己做过的Web端后台、电商前台和工具类产品把次导航这件事从概念、作用、设计方法到踩坑记录完整摊开来讲。1. 次导航到底是什么先厘清概念再说作用1.1 从信息架构的视角理解“次”很多把次导航理解成“页面里第二个导航条”的人实际上是在用视觉位置判断层级这容易出偏差。我习惯从信息架构的角度切一个产品的信息空间通常有三层深度第一层是用户进入产品后最先看到的结构比如门户首页的顶部频道、后台产品的顶级模块第二层是在某个顶级模块内部区分不同子功能的路径第三层才是页面内部长页面里的锚点定位。次导航对应的就是第二层它的“次”不是指地位低而是指它在访问路径上位于主入口之后、距离具体内容更近的那一级。举一个自己做过的大型后台例子。左侧一级导航放的是“订单中心”“商品中心”“客户管理”“数据报表”这类大板块用户点进“商品中心”以后页面里又出现了一个三栏结构——左侧有一组竖向菜单顶部有几个Tab右侧才是内容列表。这个竖向菜单和Tab就是次导航。它们不承担“从零开始认识产品”的职责承担的是“已经进了这个板块接下来要去哪个子页面”的职责。所以判断一个导航是不是次导航核心看它在寻路链条里的位置。能够直接点到的区块入口、建议路径、分类页如果它们的上级还有更宏观的入口那它们基本上就是次导航的范畴。1.2 次导航和主导航、页内导航的关系我见过最混乱的用法是把面包屑、分页器、锚点链接全部都叫次导航。这会把设计讨论带偏因为它们解决的问题完全不是一回事。这里用一个简单的分层表来讲清边界导航类型承担职责典型形态访问深度主导航一级导航定义产品整体结构告诉用户“这里有什么”顶部全局导航、首屏侧边大菜单第1层次导航二级导航在模块内部组织子功能帮助用户“去某个具体位置”侧边栏菜单、二级页顶部Tab、分类页次级栏目第2层页内导航在同一个长页面内做锚点跳转减少滚动目录索引、锚点链接、楼层条第2.5层或更深路径提示显示当前位置帮助回溯而不是向前跳转面包屑、步骤条伴随所有层级从这个表能看出次导航是“向前指路”的它的目标是让用户知道有哪些子目标、当前在内层的哪个位置、如何切换到兄弟页面。面包屑主要回答“我从哪来”锚点回答“这一页还有什么”它们和次导航的交互逻辑差别很大。设计评审时先把这个分类对齐了后面沟通才顺畅。1.3 为什么容易把次导航和“侧边栏”画等号后台系统里次导航最常见的形态确实是侧边栏尤其B端后台几乎成了标配用户登录后左侧一条深色竖栏挂着一组二级菜单。久而久之很多人下意识把“侧边栏”等同于“次导航”。其实侧边栏只是次导航的一个载体。电商前台首页顶部的横向分类栏目、视频资讯类App的顶部Tab栏、知识库里的目录树它们都是次导航。形态取决于设备、产品密度和用户对内容深度的预期不能因为长得不像侧边栏就否认它的次导航身份。我优化过一个在线文档工具它每个文档页面内都有一组横向Tab分别是“协作成员”“版本历史”“评论记录”。这组Tab虽然是页面内的小控件但它干的是“在子功能间切换”的活本质上仍是次导航。只盯形态去设计很容易把次导航做成一堆互不相认的组件先明确职责再选形态就不会乱。2. 次导航的核心作用不是“辅助”那么简单2.1 把大信息空间变成可巡游的路径很多产品功能一多初级用户最大的障碍不是看不懂某个按钮而是根本不知道这个产品里“存在什么”。次导航的第一个作用是在用户已经确定模块的前提下把模块内部的子能力显性化让他不用靠猜或者靠搜索去发现下一个页面。做电商后台订单模块时我面对的业务方提了一堆需求订单列表、待发货订单、售后处理、异常订单、批量导入、对账下载。如果把这些全部塞进一个页面页面会变成一张超长报表用户找一个入口的成本会非常高。我用次导航把订单模块拆成了五条子路径业务员每天开工先扫一遍左侧菜单今天要处理哪一类就点哪一类心智负担小很多。这里有个关键的交互逻辑次导航里面出现的信息都是系统主动给用户的“可能性清单”。用户不需要记得具体有哪些功能只要知道“那个功能应该在订单模块里”就够了——次导航帮他完成最后一步定位。2.2 建立用户的分层心智模型用户使用一个产品其实是在心里慢慢搭一棵“功能树”。主导航告诉他根和主干在哪儿次导航告诉他每根主干上挂着哪些枝杈。如果枝杈从来没有被展示过他心里的树就是残缺的每次使用都像走一条陌生的路。我经历过一个反例。有个数据平台早先版本把所有图表都堆在首页用户只能往下滚动去找想要的报表。后来我们做了改版在数据模块下增加了“实时监控”“历史分析”“导出订阅”三组次导航。结果第一次灰度测试用户找报表的平均时间从40秒降到了12秒。表面上看是增加了点按步数实际上用户获得了“可视化地图”预判路径的时间大幅缩短了。这个结果给团队的最大启发是次导航不是多一个点击的累赘它是在帮用户压缩不确定性。清晰的分层心智比少点一次鼠标重要得多。2.3 让跨模块的横向切换有稳定的“差位感”提到导航很多人只关注上下层级的跳转忽略了同一个层级内的兄弟切换。比如用户正在看“近30天销售报表”想切到“渠道报表”如果页面没有一个常驻的次导航他只能返回上级目录再选择。多两次点击倒还好关键是那份“我在哪里”的坐标系会被打断。次导航承担了这个横向切换的稳定器角色。无论用户在子页面的哪个角落只要次导航还在视野内他知道自己身处哪个模块、可以平移到哪个相邻模块。这个体验在设计工具类产品时尤其重要因为用户往往在一个大任务里频繁切换视图每切换一次都要重新建立上下文就太痛苦了。2.4 在关键路径上提供上下文感知高阶的次导航不只是静态菜单它还能根据当前状态做出反馈。比如高亮当前所在项、在子项上显示待办角标、把最近访问的子页面排在前面。这些反馈让次导航从一个“地图”升级成了“带路的人”它对用户说你现在在这里而且这里是需要注意的地方。我做过一个工单系统最初次导航菜单是纯静态的用户并不知道有几个工单还没处理。后来我们在“待处理工单”这个子项上加了未读数角标并且把有积压的子项用橙色小圆点标出来上线后工单处理时效提升了大概10%。这已经不只是导航了但它的入口仍然是次导航——把信息推送到用户寻找路径的地方效率永远最高。3. 不同产品类型下次导航的形态设计与取舍3.1 后台系统侧边栏为主注意层级上限后台产品是次导航最“重”的场域功能条目多、层级深、使用者是高频专业用户所以设计时优先考虑的是“可扫描性”而不是“亲和力”。我最常用的是左侧固定侧边栏宽度控制在200到240像素之间菜单项高度36到40像素视觉密度高但不过分拥挤。层级深度建议控制在三级以内。一级按角色或业务流程划分二级放核心操作路径三级只是极少数低频补充项。超过三层用户就很难记住路径了。菜单项命名要动宾结构比如“新建投放计划”“配置告警规则”直白告诉用户点了会发生什么。菜单项超过15条时建议分组并加小标题避免一列到底造成扫读负担。次导航的展开状态尽量记忆化。我用过一个财务系统每次刷新都恢复成全部折叠状态财务同事每天都要重新展开找常用菜单怨气很大。后来改成记住上次菜单展开状态再叠加常用项置顶体感立刻好很多。3.2 内容型前台横向Tab与楼层的配合内容型产品资讯、视频、电商、SaaS落地页的次导航常见形态是横向Tab栏。这类产品的用户目的性强比如只想看“穿搭类视频”或者“手机数码商品”所以次导航要能帮用户快速筛选内容还要能感知用户当前兴趣。做电商全站时次导航的横向Tab和分类楼层我用了两套方案第一屏上方是横向Tab对应用户的高频分类比如服装、数码、家居页面向下滚动后楼层区再次出现对应的分类次级导航这时候它是以锚点形态出现的。核心逻辑是用户盯着顶部Tab时处于“找分类”状态滚动浏览时处于“逛内容”状态两套次导航服务不同决策时刻不冲突。内容型产品的次导航设计还要考虑SEO。如果是公开Web站横向Tab中的分类别名要尽量用真实业务词不要用营销口号替代“手机数码”这样的明确类目名否则搜索引擎对页面内容的理解会打折扣也会影响站内搜索的召回效果。3.3 工具型产品收起式次导航与搜索兜底工具型产品设计软件、在线文档、项目管理工具的用户主要是“带着任务来的”次导航需要尽量不打扰沉浸式操作。这类场景里我推荐次导航做成可折叠的竖栏但要注意三点默认展开、收起状态记忆化、提供搜索兜底。我看到过把菜单默认收起、只露出图标的工具型产品新用户根本认不出那些图标代表什么次导航等于形同虚设。工具型产品的主操作区域需要大面积画布这是合理的但菜单默认展开至少140像素宽度等用户形成肌肉记忆之后再自由选择收起是比较稳妥的节奏。工具型产品里菜单项之间往往有显式关联比如设计工具里的“画板”“图层”“资源”三块内容次导航切换时要保持上下文不丢。我处理这类问题时会把用户当前选中对象的信息留在视口底部次导航只管切换面板不管清空状态体验就顺了。3.4 移动端的次导航底部标签栏和掌心内的取舍移动到移动端“次导航”的概念会进一步模糊因为屏幕小层级被压扁了。一个常见方案是把一级模块做成底部标签栏而模块内部的子入口做在页面顶部的分组导航里——本质上这就是移动端形态的次导航。移动端次导航设计的一个原则是单屏内次导航容量不超过七个入口最好五个。手指点击目标最小44像素七个以上要么字太挤要么行数变高占内容区。部分产品用“更多”按钮收纳低频率入口虽然是妥协但符合信息优先级选择。还有个很容易踩的坑移动端页面顶部放了一组可横向滚动的标签如果标签文字超过两个字用户会经常担心漏看后面的内容。实测下来加上“全部”作为第一个标签并让用户感知到可横向滚动通过露出一点点下一个标签的边滚动率会显著提升——这属于次导航移动化的微交互细节很值得优化。4. 如何设计和落地一套合理的次导航4.1 第一步梳理信息架构梳理的不是菜单而是任务每次有人找我做次导航方案我第一件事不是画线框图是先让他把所有功能列表摊在桌面上然后用“任务场景优先”的方式重新分组。实际操作时我会拿用户高频完成的十个任务做标的比如“查看未读消息”“导出上月报表”“给客户改合同”然后问一个关键词完成这个任务你第一反应会去哪个区域找把十个任务映射到功能列表上重合度最高的那些功能就应该被放进主导航有些任务需要先经过某大模块再进入具体操作页这些具体操作入口就应该出现在对应模块的次导航里。这个方法能有效避免“按照组织架构图做导航”的常见病——公司有什么部门产品就有什么菜单那是给老板看的花架子不是给用户用的路线图。信息架构梳理完之后下一步是给每个次导航项写一句话描述写不出来就直接淘汰。这个动作看似简单但对后面界面设计、测试文案甚至埋点命名都有很大帮助。4.2 第二步用卡片分类法和用户测试验证层级菜单和入口的归并合理不合理不能只由产品经理说了算。我常用的工具有两种一种是卡片分类法把所有功能名称写在卡片上让目标用户自己归类观察他们自然分类的方式和我们的设计差异另一种是树状测试给用户一个任务和一个层级结构看他在不看到具体内容的情况下能不能快速找到目标位置。举一个实际案例。做物流SaaS时我们把“运费预估”“轨迹地图”“签收统计”三个功能都放进了“运单管理”的次导航下。树状测试却发现受访者中有接近一半的人会先去“数据报表”找“签收统计”。这个分歧如果没被发现上线后用户就会在错误分区里反复兜圈。最后我们把“签收统计”同时放在两个区域的次导航里并在一段时间后观察点击数据再决定主归置。树状测试对时间要求不高工具也很多一次测试找5到8个人基本能暴露大部分问题。前期花一天做测试好过上线后花两周优化点击路径。4.3 第三步确定次导航的排序逻辑与分组标题次导航内部顺序不是随意排的通常有三种排序逻辑按用户任务频率从高到低排按业务流程从开始到结束排按从总览到明细的认知顺序排。流量和工具型产品优先用频率排序参考后台菜单点击热力图高频项放上方。业务型产品优先用流程排序因为用户可能每天只按固定流程走完所有步骤打断顺序会让他觉得“缺了什么”。还有一个常用细节是次导航第一个放“总览/概览”最后一个放“设置/管理”这种首尾固定模式可以降低学习成本让用户更快建立路径记忆。分组标题尽量用名词短语而不是口号比如“运营中心”比“让增长更简单”更合适在次导航里做分组小标题。分组标题要能帮助用户回答问题“这里面的东西和我有什么关系”而不是表达企业愿景。4.4 第四步把这套导航交给前端时的交互规范到了开发层面次导航需要明确的交互规范才能让设计和工程不跑偏。我的经验是把几个关键状态做成设计标注默认态、悬停态、选中态、展开态、有角标态、禁用态。选中态是最重要的最好用背景色加文字加粗双重强调不要只用一个颜色变化来表示否则色弱用户很难识别。次导航如果支持展开收起收起动画建议控制在150到200毫秒之间太慢用户会烦躁太快则看不出层级变化。菜单项较多时收起状态要给到悬浮气泡提示展开后的名称。还需要处理极端情况菜单项文字太长中文超过5个字后要换行还是省略这块必须在规范里写清楚不能交给前端临场发挥。我经历过一个事故二级菜单项名称超过7个字前端临时用了单行省略用户悬停才能看到全名结果被业务方投诉“找不到我的报表入口”。后来我要求二级菜单一律保留全名宁可菜单撑高一点也不能截断关键信息。5. 常见问题、歧义场景与踩坑记录5.1 面包屑到底算不算次导航我的结论不算它是路径提示。面包屑的经典交互是“点击上一级返回”它的位置始终在内容区上方但它的作用是告诉用户从首页到当前页经历了什么路径以便回溯。次导航的作用是“向前计划下一步去哪里”而面包屑是“回顾来路”两者在交互方向上正好相反。不要混淆它们还有一个现实原因如果面包屑承担了次导航职责用户会认为那里可以切换兄弟页面但我们通常不会把同级页面全部塞进面包屑里最后用户就会困惑。面包屑做好自己的事次导航的活交给菜单和Tab分工明确产品才不乱。5.2 顶部Tab和筛选器怎么区分有些页面上方一组“全部”“正在进行”“已结束”看起来特别像次导航但它其实是筛选器。判断标准是切换后是跳转到不同URL或独立页面还是仅仅在当前列表内做数据过滤。前者是次导航后者是筛选器。做过项目后台的“任务状态”Tab一开始我做成页面级次导航每个Tab都是独立页面结果一个任务状态对应一份列表数据结构大量重复。后来重构为同页面的筛选条件Tab切换只改查询参数页面不跳转内容区刷新交互更轻量开发也更省心。所以看到Tab先做这个判断能少写不少代码。5.3 次导航项要不要带图标图标是双刃剑。在后台侧边栏不建议每个菜单项都加图标尤其是当功能名称本身就是清晰动词时图标只会增加视觉噪音。但如果菜单是纯图标模式或者菜单项名称抽象度较高图标又能成为重要识别线索。经验做法是一级导航用图标做快速定位没问题二级次导航尽量不配图标改成更干净的文本行这样信息密度更高、扫描速度更快。如果产品调性偏活泼如SaaS免费版、面向中小团队的工具次导航配圆角小图标会增加亲近感但必须保证图标语义一致不能随手找一套杂的图标库混用。5.4 次导航点击数据的埋点视角次导航设计得好不好数据最有发言权。我最常用的埋点指标有三个菜单项点击次数、菜单内搜索使用率、用户平均路径深度。菜单项点击次数能反映排序是否合理搜索使用率高说明用户在次导航里找不到想要的东西路径深度偏深则需要评估是否应该把某些高频项提到一级导航。上线后的前两周尤其重要。我会拉一份次导航各入口的七日点击数据如果某个二级入口的点击量比一级入口还高那就说明它的位置层级放低了应该考虑升级或增加快捷入口。这种做法能倒推信息架构的调整方向比单纯看视觉美观度有用得多。5.5 多端同步时次导航的“塌缩”问题同一个产品同时有Web、App、小程序多端时次导航很容易出现“一端有、一端无”的接口断裂。比如Web端有一个完整的二级菜单体系到了小程序被砍成了首页金刚区加几个列表入口用户跨端使用时会怀疑是不是同一个产品思维模型。多端同步的底线是核心信息架构的三层结构不塌缩主模块一致、次导航的分组逻辑一致、关键子页面必须能从某一条路径到达。表现形式可以不同比如小程序里用折叠面板替代侧边栏但寻路的可能性不能少。跨端设计时那几组高频次导航的分组位置尽量固定这比多端UI像素级一致更重要。6. 次导航设计的一些个人经验和收尾提醒做了这么多年产品我对次导航最大的体会是它是产品信息架构最真实的投影。用户很少会直白地抱怨“次导航设计得不好”他们只会说“这个产品让人找不到东西”而“找不到东西”大概率就是次导航在某一个环节失守了。最后分享一个提高效率的小技巧在做次导航方案时把每个次导航入口当成一个独立页面来设计单独命名、单独描述用途、单独评估价值。这样做即使需求变了入口被收走或挪动产品经理也能快速判断影响范围不会互相牵连导致改一处全盘要动。低耦合设计不只适用于代码也适用于信息架构。次导航这个主题听起来基础但它串联着信息架构、交互细节、数据验证和跨端一致性。希望这篇文章能帮你下次面对“这是次导航吗”“次导航该放哪里”这类问题时快速形成自己的判断。
阅读完成 · 觉得有帮助？
