应用程序导航流程：小型团队做出更好决策的工具

在小团队中，每一个错误的导航决策都会付出两次代价：一次是构建，一次是重做。在生产后重做导航流程是应用程序可以要求的最昂贵的事情之一，因为它改变了架构、代码和已经学会了旧方法的用户的思想。

导航流程正是在一行代码存在之前最好解决的问题类型。坏消息是，小团队经常跳过这一步，认为他们会“在构建时解决这个问题”。他们几乎永远不会发现。他们积累了彼此不交谈的屏幕。

本文适用于那些人手很少，并且希望使用正确的工具一次性完成流程的人，或者至少在纸上犯一个廉价的错误，然后在代码中犯下代价高昂的错误的人。

为什么流量比漂亮的屏幕更重要

打开 Figma 并开始绘制美丽的画布是很诱人的。但 screen 是名词，flow 是动词。用户不使用孤立的屏幕；他穿过一条路去执行任务。如果路径混乱，就没有漂亮的屏幕保存。

对于小团队来说，这具有直接的实际意义：设计导航流程所花费的时间比打磨像素所花费的时间更多。清晰的流程可以减少返工、减少支持、减少放弃。这是精益团队在用户体验方面可以进行的最高杠杆投资。

为小团队选择工具首先有一个标准：它需要适合您现有的人员。需要专职专家的强大工具是小团队无法维持的奢侈品。

在视觉设计之前是地图。 FigJam、Miro 和 Whimsical 很好地解决了用方框和箭头映射用户路径的步骤。它们价格便宜、具有协作性并且需要零培训。对于两到三人的团队来说，从这里开始，在任何屏幕之前将流程绘制为图表，可以节省数周的时间。

这些工具的真正优势在于它们使流程变得毫无意义。墙上的图表迫使对话“等等，用户如何从这个屏幕返回？”发生在代码之前，这正是成本较低的地方。

Figma 是事实上的标准，并且有充分的理由：可点击的原型、可重用的组件以及适合启动预算的计划中的实时协作。对于小型团队来说，无需编写代码即可将线框转换为可导航原型的能力使您可以在投入工程之前与真实用户一起测试流程。

Maze 和 Figma 自己的原型功能允许您运行廉价的远程可用性测试。您不需要实验室，您需要五个用户和一个链接。

应用上线后，Firebase Analytics 或 Mixpanel 等工具会显示用户在实际流程中陷入困境的位置。对于小型团队来说，这些工具的免费级别通常足以使用很长一段时间。重要的是从一开始就检测流程决策点，而不是在问题出现之后。

先映射，后绘制，始终验证。从 Whimsical 或 FigJam 中的流程图开始。只有当路径清晰时，才转到 Figma 中的原型。与五个真实用户进行测试。调整。然后才进行构建。

这种顺序似乎很明显，但这正是小团队在“尽快交付”的压力下跳过的。讽刺的是，跳过流程阶段并不能加快交付速度，反而会延迟交付，因为返工会来得更晚，而且规模更大。

典型的错误是将运动与进步混为一谈。绘制的屏幕给人一种进步的感觉。但如果底层流程出了问题，那么每一个新屏幕都是债务。我看到小团队构建了二十个与导航流程相关的漂亮屏幕，要求用户点击七次才能完成本应点击两次的操作。

另一个错误是采用太多工具。小团队不需要 FigJam、Figma、Maze、Mixpanel 和其他三个。您需要一张地图、一张原型图和一张测量图。太多的工具会变成太多的许可证、太多的上下文，而没有人真正掌握其中任何一个。

小团队没有时间或剩余用户来发明新的浏览方式。这种限制远不是一个问题，而是一个优势：统一的导航模式之所以存在，是因为它们有效并且用户已经了解它们。

底部的主要区域选项卡、一致的后退手势、父子屏幕之间清晰的层次结构。 Android 的 Material Design 和 Apple 的人机界面指南等系统详细记录了这些标准。对于小型团队来说，遵循这些准则可以节省数十个设计决策，并交付用户无需学习即可理解的应用程序。

精益团队的创造力应该集中在产品的独特之处、价值主张、核心功能上，而不是重新发明用户在屏幕之间导航的方式。导航的发明是将学习成本扔到用户的腿上，并让用户卸载。

此处工具的良好使用包括利用 Figma 为这些设计系统提供的现成组件套件。该团队不是从头开始设计每个导航元素，而是从经过测试的块开始，并将精力集中在产品的差异化上。对于人手较少的人来说，这是生产力倍增器。

没有任何工具可以为您设计良好的流程。它只是让流程更快地可见，而修复它仍然很便宜。成功的小团队的区别不在于拥有最昂贵的工具，而在于在构建之前有考虑用户路径的习惯。

对于人手较少的团队来说，这种习惯是真正的竞争优势。当您的竞争对手重做生产流程时，您已经在纸上验证了您的生产流程。

如果您领导一个小团队并且现在正在设计应用程序的导航流程，那么值得讨论如何在不使团队臃肿的情况下构建此流程。博客上还有其他关于原型设计、移动用户体验和产品验证的文章直接讨论了这个主题。