默认错误：应该优化时却重建
导航问题往往会引发两种反应之一。第一种："我们的导航坏了，需要重新设计整个系统。"第二种："让我们调整几个标签，看看是否有帮助。"两种反应都有失败模式。完全重建耗时费钱，会干扰已记住现有导航的老顾客——而且通常是为了应对一些症状而实施的，而这些症状的根本原因本可以用更低成本的方式解决。调整标签和小幅改动成本低、风险小，但当基础导航架构存在结构性错误时，这些方法又不够充分。
选择错误的成本在两个方向上都很显著。一次不必要的完全重建可能花费3,000–10,000美元的开发时间，加上数周的团队干扰，而实际问题只是三个需要重命名的类别名称。对结构性损坏的导航应用纯优化方法，最多只能产生边际改进，而底层架构持续产生转化损失。重建与优化之间的决定应由诊断驱动，而不是由挫败感的严重程度或推动变革者的热情驱动。
"我们花了8,000美元进行了完整的导航重新设计，因为我们的跳出率很高。六个月后，在与分析顾问合作后，我们意识到跳出率问题是由访客误解的两个类别名称引起的——大多数访客认为'Collections'和'Styles'是同一件事，因此一半的导航流量去了错误的地方。重命名这两个标签最多花几百美元。重新设计解决了问题，但重命名也会解决，而且我们不会干扰已记住旧结构的30%的顾客。"
— Navi+客户，服装品牌
指向优化的信号（而非重建）
导航分析中的几种模式表明，有针对性的优化将在不进行架构变更的情况下解决问题：
导航参与度高但目标选择错误。 如果分析显示访客正在积极与导航互动（菜单打开率高，每个会话有许多导航点击），但经常退回（点击一个类别，返回菜单，点击不同的类别），问题可能是标签清晰度而非架构。访客在使用导航；他们只是因为标签误导而做出错误选择。重命名、拆分或合并类别可在不进行结构变更的情况下解决此问题。
特定的高退出导航路径。 如果分析揭示导航到某一特定类别的访客的退出率明显高于其他类别的访客，问题可能特定于该类别——其产品、页面设计或子类别结构——而非整体导航。对问题部分进行有针对性的优化是合理的；重建整个导航则不然。
特定于移动端的导航问题。 如果移动端的跳出率和导航放弃率明显高于桌面端，而导航结构本身在逻辑上是合理的，问题可能是移动端呈现而非架构。从汉堡菜单转换为Tab Bar、改善触摸目标大小或调整Slide Menu的打开行为，都是不需要重建类别结构的优化决策。
指向重建的信号
类别结构不再反映目录。 当现有顶级类别是为与当前不同的目录设计的——产品更少、不同的产品线、不同的客户群——无论多少标签优化都无法修复这种不匹配。为三个类别中80个产品构建的导航，不经过结构变更无法服务于12个类别中的500个产品。当架构本身已变成错误的形状时，重建是合理的。
阻碍优化的技术债务。 一些导航实现建立在主题代码上，使增量更改成本高昂——每次优化都需要开发人员参与、测试和部署，使优化周期费用高得令人望而却步。当每次优化的成本超过改进的价值时，切换到能够快速迭代的自管理导航平台是一种重建，通过减少未来优化成本而实现自我资金回收。
当前实现中缺少导航组件。 如果当前导航缺少能够显著提高转化率的功能——移动端没有Tab Bar、尽管目录深度需要但没有Mega Menu、关键操作没有Floating Action Button——重建是在添加真正的新功能，而非修复现有问题。重建的ROI是根据新功能带来的转化率改善来计算的，这比用略好的功能性导航替换功能性导航更容易证明合理。
| 问题信号 | 可能原因 | 推荐方法 |
|---|---|---|
| 访客选择错误类别后退回 | 标签名称模糊 | 优化：重命名类别 |
| 移动端跳出率远高于桌面端 | 移动导航格式不佳 | 优化：转换为Tab Bar + Slide Menu |
| 导航结构与当前目录不匹配 | 架构不匹配 | 重建：新的类别层次结构 |
| 每次导航更改都需要开发者工单 | 实现中的技术债务 | 重建：切换到自管理平台 |
决策框架
重建vs优化的决策归结为一个核心问题：导航架构——顶级结构、组件类型、移动格式——是否适合当前商店，还是已经在结构上出现了错误？如果架构正确而特定元素有问题，则优化。如果架构本身是问题所在，则重建。在决定之前进行导航审计——检查分析数据了解访客在哪里流失、用少量新访客测试导航标签、比较移动端与桌面端性能——将情感驱动的决策转变为诊断性决策，几乎总是能减少解决实际问题所需的总投资。