侧边抽屉式导航可能会降低你产品一半的用户参与度.pdfVIP

侧边抽屉式导航可能会降低你产品一半的用户参与度 设想你需要设计一个含有 多页面和模块 ，不能在一屏内显示完全的应用。你一定会首先想到去设 计一个底部或顶部的Tab导航。等一下 ，多出来的一排导航看上去有点碍眼 ？我们尝试下把他们收 到侧边栏里 ，或者叫安卓团队给它的名字“侧边抽屉导航”。 如果你们的应用的也是多视图的 ，在你们的团队里 ，以下话题一定常常引发激烈讨论 ： 是把导航选项都显示在屏幕上 ，让你们的用户可以清晰认知app结构 ，并避免多余操作才能发现 ； 还是使用侧导航让主屏的显示区域更大些。 目前 ，侧导航在安卓设备上比较流行 ，而iO S平台上使用的还不是很普遍。所以我们的讨论还要面 对一个问题 ：安卓和iO S应用是不是有一样的用户习惯 ，适用一样的导航模式 ？ 我想 ，在这里分享下我们的经验是很有价值的。 可用性 vs. 干净的设计 当第一次开始zeekbox项目 ，我们使用了顶部的t ab导航。我们的理由很简单“看不到的不记挂”。既 然你第一眼看不到这些入口 ，那么也 你也就不会知道它们在哪儿。 举个例子 ，上图左边的方案 ，如果你没有看到引导 ，你可能真的找不到导航在哪里。如果找到了 一次 ，你会在每次回来zeebox的时候都记得侧导航的入口吗 ？即使你记住了 ，每次切换栏目还是会 需要点击两次。 但从另外一个角度来说 ，没有那一排t ab导航 ，让设计看上去干净多了 ，把导航放进侧边抽屉里 ，让 主内容区域有了更大的空间余地。 侧边抽屉导航这种设计模式兴起于18个月前。 2013年九月左右Faceboo k使用了一种新的导航方式-也有可能是我在使用的Faceboo k app 作为A/B t est 的一个样本。当然了 ，既然Faceboo k都这么做了 ，那这种方案应该是好的吧 ，我这么想。 而后 ，友好而乐于提供指导的Goo le Play团队建议侧边栏抽屉式导航 （navi at io n drawers ）作为 一种新的导航方式适用于安卓应用。 所以6个月后 ，我们决定冒险尝试改为侧边栏导航。为了保证用户能清楚地发现侧导航 ，我们在应 用初次打开的时候 ，设置侧边栏是展开显示着的 ，像下图这样 ： 新版本刚发布的时候 ，我们的用户反馈很棒 （都是诸如“喜欢新的设计 ，全5分 ！”这样的反馈 ）但当 我们看到自己的数据 ，这真是个灾难 ！用户参与度降低了一半 ，就好像“看不到的不记挂”这句话真的 应验了。 让人惊讶的事实 在意识到结果的严重性之后 ，我们用两周时间出了一个版本恢复到了顶部Tab导航的模式。同时 ， 为了不让哪些喜欢新导航的用户失望 ，我们在设置里保留了侧导航的选项。 6个月后 ，zeebox经历了不少的改变 ，我们有了一个新的“我的T V ”页面 ，它的内容内容更丰富 ，包 括了订阅和广告 ，是对于用户来说很重要的一个页面。为了让更多的内容展现在这个页面里 ，我们 又想到了尝试侧导航。基于之前的经历 ，这一次 ，我们决定使用一种更聪明的办法 ，A/B t est 去 测试。 我最喜欢的A/B t est 工具和方法 我们使用Flint o来制作高保真的可点击原型 ，它让设计看起来像是一个真实的应用 ，并且 ，使用者可 以在很短是时间内就完成它。你在这里看见我们创建的Flint o原型 ：案例1、案例2-在iPho ne上可以 获得最佳的点击效果 ：在页面内任何区域点击 ，可以交互的热区就会显示出高亮提示 ，可以点击这 些热区 ，就像你使用一个真实的应用一样。 我们招募了喜欢看电视节目的用户 ，每周两次过来我们的工作室 ，测试不同的概念和我们设计的 原型。在一些情况下 ，我们可以通过小样本用户测试选择方案 ，就像上面提到的对于“我的T V ”页面 的原型测试。对于另一些情况 ，像验证侧边栏导航的使用效果 ，你需要观察大量用户的真实使用 记录。这时 ，我们需要使用A/B Test 。 对于移动应用的A/B Test ，我们使用Sw rve-在我看来最成熟的A/B Test 工具 ，它不但能提供Goal Seekin （当胜出方案明确的时候 ，A/B测试服务器可以自动切换所有用户到最佳选项 ），还能够 选择对不同用户提供不同的体验方案。 举个例子来说 ，如果你是一个Co mcast 源的订阅者 ，你没有发现我们应用中有对Xf init y远程控制的 功能 ，Sw rve会让zeebox弹一个窗告诉你相关信息。通过这种消息提醒机制的调整控制 ，A/B t est 每天都会趋向一种更合理的测试结果。 对于侧边栏使用效果的测试 ，我们采用了15/85方法 ，即针对