信息组织架构（拓展） 信息组织架构（拓展） APP导航设计1.docx

APP导航设计 关于移动端导航模式，我想你身边已经有很多很多类似的文章了，什么“标签式导航”、“抽屉式导航”、“列表式导航”、“葫芦娃喷火式导航”、“天马流星式导航”…甚至你以为掌握这些，就能游走产品信息架构中的任何和导航有关的问题。现实是：当你在真正运用时，你才发现“咦？刚才葫芦娃喷火式导航是咋用的啦”？所以在开始之前，你需要明白一个事实：用户体验是一个整体，脱离产品方向去解释那些所谓的“葫芦娃喷火式”毫无意义。 你的产品为什么需要导航设计 导航设计的目的就是需要突出产品的核心，扁平化用户的任务路径。无论是PC还是移动端，很难想象一个没有导航的产品会是什么样子，我们可能都会成为“瞎子”，闷头乱撞。当然，那些有导航的也别50步笑百步，错误的使用导航模式，和没使用导航的效果是一样的，你的产品没那么不言而喻，等待你产品的只有死路一条。 因此明白了导航设计的目的：突出产品核心，扁平化用户任务路径，下面的就是对产品的理解，产品的核心是什么？什么样的导航模式最能反映产品的核心，包括是否起到了扁平用户操作的作用？ 它没有描述中的那么神乎 抽屉式导航？它其实就是一种化繁为简的“超级整理术” 抽屉式导航更多的被应用于信息流产品设计中，这类产品注重核心内容的展示，用户的任务路径较为单一，几乎都是用于浏览产品的核心内容；至于其他比较低频的模块入口则会隐藏在当前界面后方，避免冗余的模块抢夺用户的眼球。 其实我并不喜欢将其称为“XXX导航”，因为可能在我解释完所有内容之后，等你在工作中再遇到相似的情境，你可能又会疑问“咦？那个XXX导航是怎么用的来着”。 抽屉式导航本质是什么？有人可能会说：“一种交互风格”；再具体一点，有人可能又会说：“交互风格中的一种导航风格”。如果今天你也看了我这篇文章，请你忘记这以上这两种回答。抽屉式导航说到底就是一种化繁为简的“超级整理术”。“2/8”法则告诉我们，80%的用户只用那些20%功能，这20%功能就是信息流里面的核心功能；如果那80%不常用的功能也占用着最重要的位置，那么用户就会被打扰，产生臃肿感，甚至会放弃使用产品。 标签式导航？它仅是让用户任务路径更加扁平 同样的，我们经常会讲到的，标签式、标签式，那么标签式导航的的本质是什么呢？ 在设计规划期间，我们通过产品的信息架构可以直观的了解产品的核心功能，以及各功能之间的一个关系。当产品的整个体验流中是以几个常用功能模块（PS：一般不超过5个）贯穿的，意味着用户需要在多个标签入口之间来回切换；为了保证切换的效率，将贯穿产品整个体验的流的模块平铺在Tab Bar位置，保证了用户任务路径的扁平。 桌面式导航？它只是对于扁平比较独立的用户任务路径模块的另一种思考 我前面提到了“当产品的整体体验流是由几个常用功能模块贯穿而成时，为了保证用户任务路径的扁平，我们将这几个模块平铺在Tab Bar上，后来被冠以’标签式导航‘的称呼”。那么当产品的整体体验流不能由有限个（一般不超过5个）功能模块贯穿时；或者说，整个体验流是由无限个（PS:这里的“无限”是相对的概念，一般数十个以上都可称为无限个）功能模块集成而成的，那么这是我们是不是还可以平铺在“Tab Bar”上呢？ “Tab Bar”就算了，因为通过相关竞品分析，我们发现使用“桌面式”导航的应用，每一个入口往往是比较独立的信息内容，用户进入一个入口后只处理与此入口相关的内容，这就意味着用户在几个任务之间频繁切换的概率比较低，这就意味着就算有标签式导航，也是个鸡肋导航。但是由于功能入口众多，我们还得前面提到的“平铺”，不过这里的“平铺”意义已经不太一样了，Tab Bar是为了保证来回切换任务的扁平，而这里的“平铺”是用来保证用户搜索行为的扁平，因此对展示功能入口数量的限制没有Tab Bar那么苛刻，所以Table View就成了最好的舞台，也就是我们一直神叨叨的“桌面式导航”。 菜单式导航？相比于扁平用户任务路径，凸显产品的核心会显的更加重要 对于像微博这样开放性的信息流，用户在不同情景和不同时段下可能会有不同的兴趣域，我想看一下我喜爱明星最近的动态放松一下、我想看一下我的专业领域达人的动态学习一些干货…不同的人的需求是不一样的，同一个人不同时段的需求也是不一样的，可能前一秒你还是“酷爱足球运动的财经男”，下一秒你很可能又会成为那个喜欢娱乐八卦的“清新女”。 通过相关竞品与用户访谈分析，我们发现：该类产品的用户在某个时间段的兴趣域几乎是特定的。比如我现在就想刷一些大V的干货，因此决定了用户频繁切换的概率是比较低的。 说到这里，有人可能觉得这句话好像在哪里听过？是的，桌面式导航也是这种情境——用户频繁切换的概率是比较低的，那么我们可不可以也像“桌面式导航”那样，将这些兴趣频道入口平铺在Table View上呢？ 首先你想到了这一层，