一款APP设计的从0到1（启动页、引导页、搜索、登录注册、导航）
最近一直在花时间琢磨各种各样的app。看得多了，对于如何设计app有了一些自己的小心得，准备针对app的常见模块总结下自己的想法，以加深学习效果。
今天从app的启动页开始。
一、什么是启动页？
每个做产品的聊起来启动页都头头是道，但究竟什么启动页很少有人能够给一个定义。多数时候在解释不清楚的时候，我们会打开一个app，然后指著启动页说"喏，这就是启动页"。赞，漂亮地解决了问题。但在这里我还是想要说下启动页的定义。因为，从定义中我们可以看出一个东西的根本，有利于我们讨论如何设计它。
启动页的定义：
当应用程序被用户打开时，在程序启动过程中被用户所看到的过渡页面（或动画）都被我们统称为启动页。由于启动页在每次打开应用时都会出现，并且往往停留很短的时间，就像闪现的效果一样，所以也有人把启动页称之为闪屏。
以上这段定义是参考了网络上对启动页的各种描述后的总结，没找到标准的定义或系统设计官方的定义（ios人机交互指南里页没能搜索到）。个人觉得还是比较靠谱的。
二、为什么要有启动页？
由定义可以看出，启动页的作用在于过渡。也就是说，它是用户启动和真正能使用app功能的中间阶段。那么，必然地，时间尽可能地短成为了启动页的基本要求。让用户尽快用上功能才是王道啊。OK，既然应该让用户最快地使用app的功能，为什么不能没有启动页呢。当然，这是一种非常好的想法，ios人机交互指南也提到了：
"Start Instantly
It's often said that people spend no more than a minute or twoevaluating a new app. When you make the most of this brief periodby presenting useful content immediately, you pique the interest ofnew users and give all users a superior experience.
快速启动
常言说，人们至多花一两分钟来判断一个新应用。当你能够在最短的时间内向用户展现有用的内容时，你就勾起了新用户的兴趣，同时能够给所用用户一种卓越的体验。
As much as possible, avoid displaying a splash screen or otherstartup experience. It's best when users can begin using your appimmediately."
因此，要尽可能地避免展现一个启动页或其它启动体验。让用户立即用上你的应用是最好的。
摘录来自: Apple Inc. "iOS Human Interface Guidelines"。
但是，理想很丰满，现实很骨感啊。现实中，产品启动过程中多数时候是需要一定的时间的，特别大型的app，如绘图软件或是游戏，启动的时间都相对较长。此时，如果不给予用户合理的反馈，就会让用户觉得：
app是卡死、奔溃了？还是出什么问题了？
界面难看死了，一看就知道不是啥好app。比如启动页是一个进度条。
因此，理论上启动页应该是一种不存在事物，但却成为了一种合理的事物。
三、怎么设计启动页？
既然启动页不可避免，那么就应该设计好它，以给用户尽量好的体验。在这里要强调一句，从某种意义上说启动页是一种不得已的选择。因此，个人的观点是：
应用设计上，要让启动页展现的时间要尽可能地短。
由于展现时间短，启动页的设计要尽可能地简单。
以下是几种常见的启动页设计模式：
1.设计与主界面相似的图片，给用户快速启动的感觉。
这是ibooks的启动页。当我们在主屏幕上点击应用程序图标时会立即显示这个启动图像。真正启动后界面会把书展现出来。但由于启动页和真实界面上非常相似，会让你有启动了的错觉，好像应用启动很快。
这种启动页设计方式好像越来越少了。
2.使用应用logo和slogan作为主元素，传递品牌信息。
当然，也有更狠的，只放一个logo，更加简洁。但本质是相同的。这种模式目前比较普遍。
3.使用意境化启动页，引起情感上的共鸣
这种模式的重点在于情感共鸣，其实设计难度是最大的。建议没有必然的信心就别尝试了。
4.使用广告图片，赚钱或宣传其他。
这种模式简直了。不知道该说啥。而且，很多时候，为了能够让用户看到广告图片。app在设计上就故意给启动页留了几秒的时间。这完全让启动页变味儿了。完全不推荐。除非你不在乎用户体验或你的应用是网易新闻这种级别的，那你强奸用户我也没啥好说的。
5.动画。
这种模式以前见过，但一下子没找到合适的。不贴图了。同上一种模式一样，个人完全不推荐这种模式。完全违背了启动页的初衷。属于强奸用户。
四、如果我来设计启动页
那么：
在应用设计时，让启动页展现的时间要尽可能地短。
使用应用logo和slogan作为主元素，简单有效地传递品牌信息。要知道，很多公司为了让自己的logo和slogan能够出现在用户面前，不断加深用户对自己的印象，往往花费成百上千万只为让其在种种场景下出现。所以，在自家的应用上就不要浪费了。每一次启动都是一次印象的加深，都是增加粘性的机会。
从始至终，尽量用同一个启动页。理由同第二条。
始终记住启动页只是一个过渡，过渡就意味着应该快、不重要，没必要花费太多的精力在设计上（一次就够了）。
一、什么是引导页？
在网络上做了一些查询，没有找到引导页的官方或权威定义，决定从其字面意思来进行推论。所谓引导页，就是引导用户学习app用法或了解app作用的页面，其核心在于"引导"二字。在此情况下，若一个号称引导页的东西不能达到让用户学习app的用法，或了解app相关，都不能使真正意义上的引导页。
二、为什么要做引导页？
到底为什么多数app都会在很多情况下增加引导页呢？个人认为原因在于以下几点：
受传统pc时代软件说明书的影响。pc时代的一个软件，用户往往不知道如何操作，甚至需要上专门的课程学习某个软件才行，比如office系列。因此，每个软件一旦销售必然配备使用说明书，以帮助用户学习。但是，在移动互联网时代，对于轻量级的app使用说明书太重了，所以使用了引导页这种轻量级的方式。
app设计者假设用户会希望了解这个app到底是个什么东西？能干什么？怎么用？所以要做引导页来回答用户内心的这些问题。
app设计者看到别人有，没有多想，觉得自己的app也应该做一个。
然而，现实中的情况是什么呢？
在这个注重极致用户体验的时代，绝大多数app的设计已经可以做到不证自明的阶段。用户一看就知道这玩意儿应该怎么用，能用来干什么。
即使用户对某个app没有任何认知，在下载这个app之前也肯定会有一些前置了解来帮助自己决定是否有必要下载（产品狗除外，什么app都会划拉下来看看），或者道听途说，或者朋友推荐等等。因此，引导页能够告诉用户的多数情况下是他已经知道的。
即使还需要深入了解的app（甚至手机系统这么复杂的玩意儿），多数的用户还是会采取自我探索的方式来学习如何使用。而这种学习方式对于成长在互联网时代的90、00、10后更是如此。（我四岁的侄女不识字照样可以用手机拍照、看动画片）。
用户打开app的目的是使用其功能来完成任务，往往不希望有任何障碍。因此，真正有耐心看完引导页的用户很少，多数会直接快速滑动跳过。即使引导页做得再好。
很多公司其实已经注意到了这种情况，所以他们在引导页上添加了"跳过"按钮，来防止用户对翻好几页引导页而反感。
因此，从某种意义上来说，引导页的存在其实是一个大家觉得存在没什么不对，但是却又没太多人用的这么一个东西。
那么，是不是不需要做引导页了呢？我想说的是：对，不需要做引导页了。除非：
你的app是一个全新概念的app，是市面上没有人有过的玩法。即使用户能够从各种途径了解到相关信息，但也无法完全理解你所想要传达的信息。你有不说就死的理由。此种情况下，你可以做引导页，也许能够让部分用户加深对app的了解。
你的app增加了非常大块的功能，大到可能改变整个app的使用场景，值得你重点强调。就像发布一个全新的app一样。
你的app新增加了非常重要的功能，但又无法在界面上重点展示（离线下载的控制），非常有必要向你的用户强调。
你的app使用了别人不曾用过的或用户难以想到的操作方式，同时又对使用app有重大影响，必须介绍。
三、怎么做引导页？
说完为啥，接下来说说怎么做。
做引导图可以有很多不同的方式来做，但总体来说，可以分为以下几种：
功能介绍型：
从整体上采取平铺直叙型的方式介绍app具备的功能，帮助用户大体上了解app的概况。这种适用于前面说的第一种情况。但问题在于往往介绍的功能太多，会导致用户记不住。若能够找到一个最重要的功能（必然能够找到一个最重要的功能），将其讲透，可能效果会更好。如：
使用说明型：
对于具体的功能如何使用进行说明。其实这种做法也可以在用户使用app时再进行引导。但在用户使用过程中弹出引导页会打断用户操作，容易引起用户反感。个人觉得如果要做使用说明型，放在启动后的引导页会更好一些。适用于前面说的第三、第四条情况，即增加了重要功能或非常规操作方式。如：
讲故事型：
（摘自：移动端引导设计技巧1：前置的引导页，个人感觉自己没法写得比这篇文章更好了，想看详情的可以直接看原文，适用于前面提到的第一、二条情况。）
讲故事型的核心在于建立与用户使用情景匹配的场景，让用户能建立一种熟悉的感受，能让用户对引导的功能点感同身受。
串联的故事一般而言都是多页的形式。一步抛出一个需告知的点，循序渐进的解说。故事可以只围绕一个功能点来叙述，也可以将多个功能点串联起来变成一个故事。形成一个完整的故事。由于每次一个告知点，多会采用聚焦的设计手法，把视觉注意力吸引到每个告知点上。
讲故事的主要目的是希望构建用户与产品之间的联系。让用户感觉到产品与自己是有关系的，现在所说的内容是与我相关的，我需要花费精力来关注一下。如果完全建立不起关联，很容易让用户忽略。
讲故事型可以通过以下几种方式来告诉用户如何使用app或app到底对我有什么用。
常规描述：用故事讲述用户使用产品会怎么样。
微信4.0的引导就是一个编故事建立关系的好例子。在微信在推出4.0版本的时候，新增加了类似Path和Instagram一样的相册功能，并且可以把相册分享到朋友圈。这个功能的加入拓展了之间仅是沟通聊天工具的产品定义。在4.0版本的新功能引导中，它非常成功的讲诉了一个关于相册功能的故事，并且在设计内容时非常注意建立联系。在故事阐述中它一直强调用户可以怎么样，让用户能明确感觉到与自己的关系。
痛点渲染：从痛点出发讲述使用产品后的效果。
建立一个用户在实际生活中会遇到的类似的不便的场景，让用户能感受到共鸣，唤起用户对所述功能的需要感。然后给出该产品能给出的解决方案，可以让用户感觉。
戳痛点的手法比较适用于实用的工具性的功能引导。在设计中文案：可采用痛点式文案，或者是非常具有颤动性的文案。
榜样类比：通过建立用户熟悉的人物角色，来描述其他人会用这个产品来做什么。
这种方式可以拓宽对产品功能使用的场景与多种其他可能性。启发用户对这个产品的想象。建立的熟悉的人物形象会让描述变得具体而形象，会从而引发当前使用的用户形成一种类比的心理。
这种方式适用于对产品整体功能的介绍，对于新老产品的功能介绍都适用:
老产品用此方法可以启发用户拓宽对既有功能使用的其他的可能性，拓宽使用场景。
新产品用此方法可以让用户对这个产品的整体功能有更多的认识。
设计要点：
用户角色渲染得让人觉得可信，能让人很容易联想到自己也会遇到类似情况。
文案：可采用比较具有亲和力，质朴的文案。
（下图为印象笔记的引导截图）
四、还有什么想要强调的？
如果没有啥必要，真的不要做引导页。费时费力不说，做不好的话完全没有效果。引导页要想做好，是对产品经理文字提炼能力和设计师设计水平的一个考验，对于资源有限的小团队来说，做引导页就是一种资源的浪费。
如果非要做或不得不做，引导页做的越少越好。能一页搞定就不要再多，最多也不要超过5页。过多的页数用户根本不可能看。
引导页的图片要干净利索，主题突出。凡是对突出主题没用的元素就减减减、删删删。
文字也要精炼，两行就足够了。一行说说功能，一行说说给用户带来的用处，足矣。讲故事的话一行文字就够了。
引导页一次最好只说一个功能，从不同侧面引导用户，加深用户印象。什么都说等于什么都没说。
引导页就说到这里。
最后，结合启动页和引导页想要说一句：如果你希望用户在使用你的app时尽可能没有障碍。那么，就要压缩启动页的时间和引导页页数（最好是前者无限趋于零，后者等于零），然后让用户打开就可以使用app。那种打开启动页加上5秒广告，然后有八九页引导页的app，真得很让人烦躁啊。
无论是在app还是在web端，搜索都是一个发现内容的重要方式。与web端不同，app上的搜索功能在设计方面有自己独特的展现方式。
综合了解了豌豆荚、优酷、京东、天猫等一些app的搜索功能后，个人感觉app的搜索功能可以参照以下流程进行设计：
一、搜索功能的呈现：
在有搜索功能的app中，搜索往往会作为一个公共功能出现在几乎所有页面，就像在web端出现在导航类似。但与web端不同的是，搜索功能在不同的页面会有不同的展示方式。
如果一个app的核心在于搜索，比如豌豆荚，或者搜索的使用率非常之高，则在app的首页可以搜索框的形式展现，这样能够吸引用户足够的注意力。
如果搜索只是辅助功能，则可以搜索图标形式呈现，提示用户软件有搜索功能。
当然，在app的其它页面，搜索功能一般会以图标的形式呈现，以节约界面空间。
二、搜索功能的激活：
点击搜索框或者搜索图标后，app将会激活搜索功能。搜索功能将会以以下方式呈现：
1.在新界面打开。如有必要，新界面中展示搜索历史（未登录展示本机搜索历史，登录展示账号搜索历史）、热搜词、推广词、广告等。这些内容根据业务需要进行排序和组合。搜索历史、热搜词、推广词等选择后，被选择词作为搜索词展现搜索结果。
2.键入搜索词。要允许多词搜索；若有必要，提供关联词选项；若关联选项有对应的核心操作，也可直接展现，可方便用户直接进行操作。
三、搜索结果的呈现
键入搜索词进行搜索后，在本界面呈现搜索结果。在此界面，需要注意：
搜索结果根据业务不同展现不同内容。
搜索结果有可能会需要按照分类进行展示，需要考虑界面交互。
需要提供清除搜索词的操作图标，多数时候未"x"图标。
允许在搜索结果页面清除当前搜索此后再次搜索，不再打开新界面，当前界面再次展示新的搜索结果。
四、其它事项：
短期内，如果不是为了凸显自己的技术实力，不要添加语音搜索。测试了几个语音搜索，准确率不高。准确率高的对发音及音量大小等有比较严格的要求。方言就更不要说了。
尊重设计规范。前面所说的关于搜索的流程在android和ios系统上都是可行的。只是在设计上尽量遵循各操作系统的设计规范比较好。虽然很多公司的用一套设计来支持这两个操作系统。
按理说，没准备好就不应该写。但如果继续后推，等准备好再写，觉得自己就会放弃这块的总结。因此，在心里惶惶然的情况下，还是决定把目前自己的一些想法和总结写出来，算是阶段性的一个总结吧。
由于登录是注册之后的事儿，我首先来谈谈注册。
一、什么是注册？
我是一个喜欢追根朔底的人，本来想看看到底什么是"注册"，结果查询了很多资料也没有发现对"注册"的真正定义。唯一能够查到的竟然是新华字典。新华字典里对于注册的解释是：1.把名字记入簿册。多指取得某种资格。2.今指向有关机关﹑团体或学校登记备案。
虽然这个解释跟网站和APP好像没有什么关系，但个人觉得对于第一条解释还是可以用的。套用到网站或APP中，注册的意思大体应该是：把账号记录到网站或APP，以取得某种资格。
这个定义大家将就著看看就行，反正说起来"注册"，大家肯定会知道是怎么回事，对吧？
二、为什么要有注册？
由定义可以看得出，一旦注册就可以获得某种资格。那么，对于网站或APP，用户为什么要注册呢？我的观点是因为以下两点：
个人信息的多端同步、多平台同步，以方便用户在多个设备间和不同类型平台间都可使用自己的个人信息。
特权服务的获得。一些情况下，注册并登录的用户和未登录用户的所具有的许可权是不同的，注册并登录可以获得不同的特权服务。
三、什么时候需要用户注册？
要回答这个问题，取决于APP产品的产品形态。
如果产品既不需要个人信息同步，也没有任何特权服务提供，那么不要求用户注册是比较合理的。比如：计算器一般来说是不需要注册【登录】功能的。常见的便签也是。但如果便签提供了在不同设备之间的的同步、不同平台间的同步，则可能就需要用户注册并登录了。否则，同步信息无法进行。
如果产品却是为用户提供了不一样的服务，需要用户注册并登录，则要求用户注册的时机越往后越好。为什么呢？这意味着可以让用户对自己使用的服务有深入的了解，用户确实有需要才进行注册。而这时的用户将会觉得注册是顺理成章的，基本不会有任何反感。那些在用户还对产品一无所知的时候就强行要求用户注册的产品，除了给用户带来恶感外，最大的可能是会将用户挡在产品外。
可是，难道就没有一开始就要求用户注册和登录的产品吗？当然有。有一些产品，比如微信、陌陌、脉脉这类社交类为主的APP，就是必须一开始就注册登录的。如果不注册且登录，根本无法根据注册信息建立人与人之间的关系，也就根本无法使用产品的其他功能。但这一类的产品相对来说是少数，就跟不需要要注册登录的产品一样。
四、常见的注册类型
我们在网络上常见的注册类型包括邮箱注册、用户名注册、手机号注册、第三方账号注册这四大类。但对于APP来说，常见的类型主要有邮箱注册、手机号注册、第三方账号注册这三大类。接下来比较详细地逐一谈一下这三类注册的类型。
邮箱注册
邮箱注册在web时代就是一种比较常见的注册类型。在移动互联网时代，在APP注册也占据了主流的位置。一方面是由于多数web端产品采用了邮箱注册，而这些web端产品在移动时代自然也会开发APP产品。基于多端的一致性，邮箱注册自然就成为了一种比较主流的注册类型。另一方面，邮箱作为一种比较私人的联系方式，作为注册账号不仅能够完成注册，在找回密码、营销方面也有一定的优势（用户名注册就不行），因此成为主流也是自然。
不过，邮箱注册作为APP上注册的一个类型，也有其劣势：首先，邮箱一般来说都比较长，而且可能包括各种不同类型的字元，这在手机上输入非常不方便，效率低，很容易让用户感到烦躁。其次，邮箱输入后，验证不太方便（验证需要登录邮箱），比较难以确定邮箱的真实性。
鉴于邮箱注册与web端的一致性，短时间内这种注册方式可能还是主流。因此，作为设计者，能做的可能是尽量让用户在注册时更加简单、容易一些。
那么，在APP上的邮箱注册究竟应该怎么做比较好呢？以下是个人的一些总结：
如果没有必要，尽量不要在注册的时候要求用户同时填写昵称、姓名等其他信息，就是简单的邮箱和密码。
在输入邮箱的时候，如果可能，对呼出的键盘进行自定义，最大化方便输入。
不要求用户重新输入密码以验证前后两次密码是否正确（web端可以这样做）。为了让用户能够确认自己输入的密码是自己想要输入的密码，可以增加"明文显示"功能。
邮箱注册成功后，自动发送验证邮件，但在APP端不提供验证功能，让用户在方便的时候去web端验证。
用文字描述表明：注册就表示同意注册协议，而不要使用勾选。毕竟，如果不勾选的话就无法注册，何必多次一举呢？万一用户不小心取消了勾选，还得重新进行勾选，徒增烦恼。
如果有第三方账号注册，一定要一起显示在同一界面。
注册最好做成H5页面，这样键盘呼出后就不再需要退出，而且用户也可以很方便地看到注册页面的所有内容和操作。
对于邮箱注册这一块，个人找到了一个觉得目前最好的注册设计：pocket。
手机号注册
用手机号注册是移动互联网盛行下开始流行的一种注册方式。在web时代，手机号很少被用来作为注册账号，更多是用来作为重要信息接收的途径（如支付宝绑定手机）。用手机号注册的优点非常明显：输入简单（11位数字），容易验证（手机接收验证码即可，验证码也是数字）；同时，手机号是非常私人的联系方式，对于企业营销来说是更为有用的信息，而且非常容易验证手机号的真实性。
同样，手机号注册也不是光有优点没有缺点。要求用户用手机号注册的不利之处在于：手机号是非常非常私密的个人信息或联系方式（尤其现在手机基本上成为了人们的第二器官），因此用户很注重手机号的保护。如果没有足够强有力的理由，让用户用手机号注册是很不容易的。如果强制要求，甚至会将用户挡在产品之外，让用户放弃对产品的使用。
在APP上用手机号注册应该怎么设计比较好呢？我的观点是：
如果你没有找到一个能够说服自己和身边绝大多数的理由（比如资金变动、重要信息提示），不要轻易要求用户用手机号注册，尤其不要要求用户只能用手机号注册。
如果你有足够的理由来要求用户用手机注册，那么，一旦使用手机注册，就排他地不再提供别的注册方式。
最好将手机注册的步骤逐一展示出来，而不是逐步展示，虽然大部分手机注册是这么做的。逐步展示容易让用户有心理负担，不知道接下来到底会出现什么，是不是还需要干很多活儿才能注册完成。
使用如下常用注册流程就不错，不要无故增加流程，手机号注册流程：输入手机号--获取验证码（60s）--填入验证码验证成功--设置密码。
不要求用户重新输入密码以验证前后两次密码是否正确（web端可以这样做）。为了让用户能够确认自己输入的密码是自己想要输入的密码，可以增加"明文显示"功能。
对于手机号注册这一块，个人认为可以参见美团的手机号注册，如下：
第三方账号注册
虽然在界面上，第三方账号注册往往被称为"第三方账号登录"，但其实用户第一次使用第三方账号登录也是在创建一个新的账号。因此，我将第三方账号注册也算成是一种注册类型。
第三方账号注册的好处是显而易见的：极致的简单和方便。但不利之处也非常明显：企业无法与用户之间产生任何连接，这对部分公司来说是完全无法接受的。
对于第三方账号注册，几条优化建议是：
第三方注册一般是和其他注册方式共存的。因此在设计上要注意分清主次。一般来说，第三方注册都是出于次要的位置。但也有部分APP将其作为主要注册方式，看需要。
第三方注册成功后，不再要求用别的方式注册，否则就是一个骗子，用户会很不爽。还不如不用第三方呢。
第三方注册成功后，如果还需要完善别的信息，则在需要这些信息时再要求用户填写，否则一个简单方便的注册就没有意义了。
多种注册类型的混合使用
仅用一种注册类型、两种注册类型混用甚至三种注册类型混用都在APP的设计中出现过。这里面其实没有真正意义上的好与坏，关键是看产品的需要。是否真的有必要这么做？这是需要产品经理考虑的一个核心问题。在这一点上，我只能说根据产品的不同形态和要求来做，没有定式。
关于注册的其他补充：
如果没有必要，不要多种注册方式共存（最常见的是邮箱、手机、第三方都用）。如果业务必须需要手机号，则仅提供手机注册就好。若业务不需要手机，邮箱就可以，则仅用邮箱就好。
页面设计上千万不要让键盘遮挡到任何内容，即使遮挡了，也要方便用户将其呼出（h5页面可以比较容易做到）。
步骤要清晰，不要让用户猜测接下来还有啥。
指令要明确：比如必须要填写昵称，则对昵称可以使用的字元一定要界定清楚。
不要玩个性。比如：大多数的密码都是18位以上的，你偏偏就只允许用户设置15位的密码。那么用户常用的密码用不了，就会忘记。
五、登录
说完注册，简单说几句登录。如果注册能够做好，登录自然也能够做好。但对于登录，个人还是要说几点：
将用户使用的最多的登录形式最大化地展现出来。
自定义键盘，适用不用的登录账号类型。
允许明文显示密码
要有忘记密码的选项。而且，根据登录形式的不同，找回密码的方式也要不同。
在APP上，用户一旦登录，一直保持登录状态，不要求用户重新登录。除非：
用户卸载后重新安装了app
用户自己登出了app
一个账户只能登录在唯一的设备上，已在别的设备上登录，在新的设备上打开必须要求登录。如微信。
同样，我们先来看看导航的定义。所谓的导航指的是：引导用户访问APP的栏目、菜单、分类等布局结构形式的总称。
也就是说，导航主要是引导用户，告诉用户怎么找到自己想要的信息或完成用户自己想要完成的任务。可见，导航在一个APP中的重要性是非常高的。导航设计的合理性关系着用户是否能够找到信息和完成任务。
那么，导航设计究竟应该如何做呢？这个说实话，不同的APP，导航设计既可能是相似的，也可能是完全不同的。因此，导航设计究竟应该如何做的答案只能是：根据APP的情况来定。
不过，虽然我们不能给出一个标准答案说：APP导航这样设计就可以了。但在众多的APP导航设计中，我们能够找到一些常见的设计模式，以此来作为一个参考，辅助我们的APP导航设计。
下面，我将就APP导航设计的常见模式进行一个总结。
首先，我将定义一个叫做原始导航的导航。原始导航是一个最最粗糙的导航，通过纯文字的链接入口来导航。如下图：
看到原始导航，是不是觉得弱爆了，怎么可能有这样的导航呢？所以，我把它定义为原始导航，然后在此基础上通过不断的演变来形成我们常见的导航模式。
一、标签导航（选项卡导航）
有了原始导航，你可能会说，原始导航这种入口的摆放方式太占空间了，就五个入口就占据了整个界面。有没有一种更加省空间的导航模式呢？当然有。
首先，我们将五个入口放到界面的下方，就会形成常见的底部标签导航。
通常，底部标签导航有3～4标签，一般不会超过5个，有更多的选项操作时可将最后一项设置为更多，将一些次要功能放置在更多里。这是一种非常常见的导航模式。如果你的应用需要用户频繁的在不同分页切换，可以采用这种导航。虽然它还是会占用一定的界面空间，但比起原始导航来说好多了。现在很多APP（包括iso和android）都在用这种模式。
当然，如果你在五个标签中，有一个标签是最重要或最频繁使用的，想要重点突出，可以使用下面变形的底部标签导航。
这种底部标签导航模式并不常见，但在一些APP中还是可以看到它的应用。比如微博的底部标签导航。
其次，我们将标签放到界面的上方，就会形成常见的顶部标签导航。
顶部标签导航在ios app中一般当作二级导航。在androidapp中，这种导航模式以前被用作一级导航，但自从google推出了"抽屉导航"作为一级导航后，顶部标签导航就被常用为二级导航了。
作为一个二级导航，顶部标签导航应用于多种情境下，可以固定数量，展示有限的几个标签。也可以扩大一定的数量，变成向左滑动展现更多标签。甚至可以像网易新闻那样，衍生出订阅功能。顶部标签导航也是一种非常常见的导航模式。
二、抽屉导航
说完标签导航，你可能会说，我是有六七个导航，但其中只有一个导航是主要的，别的虽然有用，但用户非常非常少用。这种情况下能不能只显示主要的内容，其它导航隐藏起来呢？这样还可以更近一步地节省页面空间。
当然可以。在这种情况下你可以使用抽屉导航。
抽屉导航是将菜单隐藏在当前页面后，点击导航入口即可像拉抽屉一样拉出菜单。这种导航的优点是：节省页面展示空间，让用户将更多的注意力聚焦到当前页面。比较适合于不那么需要频繁切换内容的应用，例如对设置、关于等内容的隐藏。缺点是：对于那些需要经常在不同导航间切换或者核心功能有一堆入口的app不适用。抽屉导航设计需要注意的是一定要提供菜单画出的过渡动画。
三：下拉导航
讲完抽屉导航后，还有另外一种类似的导航模式同样可以节省页面空间，并且隐藏次要入口，这就是下拉导航。
下拉导航，与抽屉式导航的目的相同，都是为了突出内容。一般位于产品顶部，通过点击呼出导航菜单。导航菜单以浮窗形式位于界面上层，可通过点击导航菜单以外的区域使其收起。下拉导航的菜单与界面的连贯性比抽屉式要好，容易让用户感知当前位置。但由于是位于屏幕上方，相对隐蔽而且不能结合手势操作，所以该菜单形式也不适合于频繁的切换功能使用。考虑到导航菜单的可用面积较小，所以一般采用列表的形式展示菜单内容。
下拉导航有一种比较常见的变式，就是下来菜单中展示两级甚至多级（一般就是两级，没见过更多的），很多人称其为超级菜单导航。如下：
这种导航模式说实话用得比较少。但最近在各种O2O形态的APP中有比较多的使用（可能跟分类级别多而且不好组织有关）。比如：美团、百度外卖等都有用超级菜单。
四、宫格导航
我在原始导航里设定了5个入口。可是，如果有7、8个甚至10多个入口呢？而且这些入口你也不好说到底哪个对用户是最重要的，重要性差不多，怎么办？OK，宫格导航可以解决这个问题。
宫格导航将主要入口全部聚合在页面，让用户做出选择。这样的组织方式虽然无法让用户第一时间看到内容或执行操作，用户的选择压力也比较大。但却能够让用户整体上了解APP提供的服务，从而选择自己所需要的那个服务。
目前来说，这种导航模式越来越少用在一级导航了。不过，作为二级导航，作为一系列工具入口的聚合，或作为内容列表的一种图形化呈现形式，还是存在在各种APP里。如：zakeer的核心页面就是宫格导航，但其与订阅功能结合，没有让所有宫格斗展示出了。各种手机界面打开后的app展示页面基本上都是宫格模式的。
由于受到卡片式设计的影响，宫格模式的变形也非常多。接下来简单说一下这些变形。
首先，可以将宫格的卡片变大，宫格与宫格时间不留空白，如下图：
是不是和锤子手机的宫格展示布局一样了？
上面这种展现方式所能展现的卡片数量有限。如果我们将其稍做调整，增加纵向滚动功能，就可以增加卡片数量的展现，可以说是无限的。如下图：
优酷安卓app里的"频道"模块采取的就是这种模式。
如果更进一步，是不是可以对上面这种无限的展示宫格进行分类呢？当然可以。然后我们就有了下面这种导航模式：
当然，每个分类下能够展示的数量可以更多，并不限于3个。
这时，如果我们想要在分类下，展示更多的内容，但又想多展示分类，怎么办？可以在以上的导航模式中再进一步变形，如图：
允许每行宫格横向滑动展示更多，这样就扩展了展示的数量，又不会减少分类数量的展示。
宫格导航还有没有别的变式呢？当然有。比如：
可以通过变化宫格导航中卡片的大小，来凸显宫格中内容的不同重要性。
可以将宫格导航和订阅功能结合，形成独特的订阅导航。
……
变化形式根据不同的需要很可能有很多种。一般来讲，常见的这些导航模式就够了。
五、列表导航
列表式APP导航是我们在APP设计种必不可少的一个信息承载模式。当然作为一个APP的导航也是非常方便的。这种导航模式从原始导航中很好转换，只要将列表左对齐，增加向右箭头表明是否还有下级即可。如图：
目前来看，列表导航通常用于二级页，由于它与宫格导航一样，不会默认展示任何实质内容，所以通常app不会在首页使用它。这种导航结构清晰，易于理解，冷静高效，能够帮助用户快速的定位去到对应的页面。
自然，如果你想要对列表进行分类也是可以的。这样逻辑上会更加清晰。如下：
如果说虽然可以分类，但实在不知道如何确定分类名称。把分类名称去掉也是可以的。只是用间距将每一组列表隔开也能起到梳理逻辑的作用。
对于列表导航来说，还有一种常见的变式：将列表下内容中的核心内容展示出来，常见的是核心数据展现。如下：
这种变式有时候也被成为仪表式导航，通过标题和核心数据来展现核心内容，同时作为导航使用。这种导航模式可以参见各种互联网金融APP中的产品列表。
六、轮播导航
如果我们将原始导航中的5个入口共处一个页面变成每个页面仅限一个入口可以吗？或者说，我们将宫格导航变成一宫格呢？会有一种新的导航模式吗？
按照上面的假设，我们会有一种常见的导航模式：轮播导航。如下：
当然，只有应用信息足够扁平，可以尝试轮播导航。轮播导航如果应用得当，能够给人耳目一新的体验。轮播导航能够最大程度的保证应用的页面简洁性，操作也是最方便的，只需要手指左右滑动。缺点也很明显：承载入口的数量有限，超过10个可能就优点多了。这种导航常见于查看图片，也经常与其他导航模式结合，作为banner广告呈现。
七、点聚导航
如果一个界面，因为内容或功能展示的需求，需要极端简化其入口，应该如何做？点聚导航是一种选择。
当层级框架比较复杂，几个并列的模块中都有用户频繁使用的核心内容，但有需要简化页面时，会考虑使用点聚式导航。点聚式导航将多个核心功能聚汇到主界面中显示，方便用户呼出使用。由于点聚式占用空间小，一般会融入一些动态的互动效果，让导航更具趣味性。很多图片拍摄及编辑、视频拍摄及编辑类APP会使用这类导航。
八、隐喻导航
如果原始导航中的五个入口，变成游戏界面中的五个关卡，只是简单地将其按照上下顺序列出来就会不太适用。游戏对导航的要求不仅要可用，更要和整个游戏的风格等匹配。因此，有了隐喻导航这种模式，用页面模仿应用的隐喻对象。这种导航主要用于游戏，但在帮助导航人们组织事物（如日记、书籍等），并对其进行分类的应用中也能看到。
九、关于导航的一些其它想法：
虽然每个导航模式有常见的用法，但并没有绝对的限定，要具体情况具体分析。比如顶部标签导航可以作为一级导航，但与抽屉导航结合的话，可能就会变成二级导航。
就目前的情况来看，很少有APP能够只用一种导航模式，至少需要两种。绝大多数的APP都在混合使用多种导航模式。很多APP甚至可能使用多大七八种导航模式，有的一个界面就可能用三到四种导航模式。
导航模式混合使用并不可怕，关键是要在设计上做好文章，确保用户能够获得良好的用户体验。
导航的具体设计方式多种多样，有只有文字的，有文字图标结合的，有图片文字结合的，有图片文字图标结合的、有只有图标的……具体的形式不在这里多谈。用什么样的形式取决于内容需要什么样的展现形式。
文中的导航模式只是一种参考，这些模式其实还有各种各样的变形。只要能够引导用户清晰明确地找到信息或完成任务的导航都是优秀的导航，并不一定非得使用某种导航。
私信我回复"666"，有惊喜哦
