网易云阅读【iPhone2.0】 交互设计回顾

作者: 伊缘 分类: ||产品经理|| 发布时间: 2013-05-08 16:34

改版背景

iPhone版网易云阅读在1.5之前的每次改版,都是以增加功能为目标,快速迭代为手段。发布的大大小小的版本中,先后提供了离线下载、书籍阅读、书城等实用功能,满足了用户更多的阅读需求。但是一直沿用的信息架构,不再能满足新增加的功能和需求;并且在反复的迭代中,增加了不少想改却没有时间改的体验不足之处;再者,移动互联时代的到来,用户对移动体验的要求越来越高,网易云阅读却慢慢落后于这个时代的发展。所以,一次全面提升用户体验的改版迫在眉睫。

 

设计流程

 

一、收集需求(用研阶段):

1、简易的可用性测试

项目时间永远是紧张的,我们没有条件按照标准的可用性测试流程来实施,但一个简易的测试仍可以发现不少问题。在较早的一次可用性测试中,我们招募了公司内的7位同事作为被试者,测试时间进行了2天,设计任务和整理结果进行了1天左右,发现的主要问题有:

测试不仅可以发现问题,也能帮助我们在纠结的问题上做出选择,比如1.x的首页资讯源右上角有一个“i”,虽然碍眼,但考虑用户在首页会有查看源详情的需求,一直没去掉。而从测试结果中看出,当用户需要用到详情页的功能时,大多数选择点击进入源,而对“i”视而不见。由此,就可以有理有据地把他干掉了。

2.整理有效的用户反馈:

网易拥有较完善的用户反馈收集系统,并且每隔一段时间都会将反馈整理并发送至项目内人员,让所有参与者都能一直保持对用户的关注。以下是从大量反馈中整理出来 的设计类中较典型的问题。

3.项目内人员发现的问题整理:

 

1) 动态效果太少
动态效果不仅可以带给用户时尚和酷的感觉,在情感上产生共鸣,增强用户对网易品牌的认知度;而且在可用性方面,合适的动效可以使界面逻辑更清晰;再者,在现在的移动互联网的环境中,动效的地位越来越高,是用户体验不可或缺的一个环节。

2) 搜索功能隐藏太深
对于目标明确的用户,想要找资讯源或书时,需要多次点击,经历多个页面的加载。

3) 文案不统一
诸如“资讯”和“订阅”,“评价”和“评论”,“分享”和“转发”等。

4) 信息架构不合理
比如收藏在设置中,显然不合理(从可用性测试中也可得知)。并且目前架构扩展性不够,小小的屏幕上已经塞了很多入口,再增加功能没地方可放了,必须拓展屏幕外空间。

5) 重要元素视觉不够突出
比如首页的“资讯”和“书籍”是云阅读两大重要模块,而切换的TAB却不够明显,导致当默认为“资讯”时,书籍的曝光率很少。

4.竞品分析:

 

因为网易云阅读自身产品的特殊性:包括资讯和书籍两大模块,竞品也可以分为两大类。其中资讯类有:ZAKER,flipboard,鲜果联播,腾讯爱看等;书籍类有:多看阅读,QQ阅读,云中书城,iReader,字节社等。竞品分析是一个持续的过程,主要分析竞品的优势,用户为什么喜欢使用的原因,哪些可以学习。由于竞品数量多,没有形成完整的一套文档,所以我们的方法是在必要的时候,针对某一些大家都有的模块,进行纵向的深入的分析。以下是书籍正文中,功能优先级的竞品分析,通过分析可以给我们自己的设计提供参考,哪些功能是主要的,哪些是次要的。

从竞品分析中看出,返回-目录-书签-进度-亮度-夜间模式-字体大小,是最被重视的,而横屏阅读和阅读主题也是很多竞品都有的功能,我们未来必须考虑这两个功能的必要性。当然竞品分析不能作为设计的准则,否则肯定会成为一款毫无亮点的中庸的产品,它只能从某一个侧面给我们在做设计决策时提供某种参考。设计还是应该以目标用户和使用场景为导向。

二、确定体验设计目标:

在上面的结果中可以看出,用户碰到不爽,会直接建议我们“增加**功能”,或者“学一学腾讯”。但这些建议还不能够指导设计,作为设计师需要还原用户提出这些建议的场景,发现用户的痛点和本质需求,最终提炼出用户体验设计的目标,并以此作为设计的导向。所谓条条大路通罗马,同一个目标可以用多种不同的解决方案来实现,把目标明确出来,更有利于拓展设计思维。

三、方案PK

新项目流程中,用户研究之后应是梳理信息架构和绘制流程图的工作,但在改版项目中,架构和流程都较稳定,不会频繁修改。我们的办法是围绕用户体验设计目标,结合用户实际使用情景,提出多种解决方案。这个过程前期类似于“故事板”的方法,但时间有限并没有将故事纸面化。

有了解决方案后,再根据体验提升程度、实现成本、系统性能、运维支持等多方面来最终确定方案。

下面举两个例子说明我们确定设计方案的过程。

1.目标:让用户能够方便地找到已经订阅的资讯源和已添加的书籍

首先想到的是提供分组,我们也进行了很多的抽屉模型的尝试:

但是尝试多种分组方案后,每种方案都存在较大的弊端,可能带来导航混乱、复杂度提高等不良后果。于是再分析用户的一般使用场景:用户想要找的一般是他常看的源或书,所以“按照使用频次来自动排序”和“便捷的搜索功能”也同样可以达到这个目标,因此最终放弃了分组功能,而只增加了搜索功能,不仅可以满足“使搜索资讯源和书籍更便捷”这个目标,也可以满足“方便找到已经订阅的资讯源和书”。

,

2.设计目标:优化手势操作,使阅读更高效和方便

方案1(原方案):在文章正文页左右滑动切换文章:

优点:在文章内切换文章很方便,符合老用户的习惯

方案2(改进方案):

优点:

  1. 对于较长的文章(如网易新闻),一般情况下用户会选择性地阅读,很少会连续阅读文章,所以右滑返回列表更有效。
  2. 对于较短的文章(如笑话之类),用户需要连续阅读,上下滑动切换仍可满足这个使用场景。
  3. 手势操作和动效隐喻对应,空间结构在正文页和列表页统一,更易于理解和记忆。

在讨论中,我们预见到会有很多老用户来抨击这个设计,因为改变了已养成的习惯,但我们相信:只要是正确的设计,越早改影响越小,越往后代价越大。

关于坚持和妥协:

设计方案的提出,免不了要面对各方挑战,设计者一味说服别人或者一味接受意见都不可取,如何坚持和妥协我觉得应该有如下原则:

  1. 讨论过程中各方人员根据自己的需求和想像,对方案提出挑战,这时设计师应该坚持,并从目标用户、使用场景、体验目标出发来解释如此设计的原因,当然如果设计者说不出那就说明方案确实不靠谱,经不起挑战。
  2. 开发人员凭借对系统的透彻了解,提出各种极端可能性和异常现象来否定方案,这时候设计师一定要坚持“为大多数用户设计”的原则,切不可为“可能性”而牺牲了大部分的体验。
  3. 开发从系统性能、实现成本、平台制约等方面提出意见,策划从优先级、资源配置提出意见,对于这类挑战我们需要适当妥协,因为我们的目标都是产品成功,如何利用有效的资源实现最多的体验目标,这是成熟的设计必须关注的。

四、交互细节

移动客户端的细节设计是对设计师基本功的考验,第一、客户端要考虑的case比web端要多很多,诸如屏幕尺寸、内存因素、网络状况、缓存和网络加载的区别、界面切换动效等等;第二、每一处细节也都体现着设计师对用户使用场景的思考。

下面也举两个例子。

一、首页搜索的结果中,对于已添加的内容,显示按钮“阅读”;而资讯中心已添加的内容,不显示“阅读”。

用户在使用首页搜索的一种场景如下:因为订阅了很多源,在首页翻页找不到,就使用搜索来快速定位。这种场景下提供给用户一个“阅读”按钮可以提高操作效率。

而在资讯中心时,用户是想要添加新源,如果也在列表上增加“阅读”按钮,一旦误点击,会跳转到首页再打开此源,无法返回,后果较严重。

同样的列表为何有不同的设计?因为即使样式差不多,使用场景却有很大差别。

二、在资讯正文的操作中增加“日间模式”和“夜间模式”的切换。

从系统逻辑上讲,日间和夜间的切换是全局的,所以放在全局的设置中更合理。但分析用户的使用场景,用户往往在专注于阅读文章时,才发现屏幕太亮而需要换到夜间模式。

五、开发跟进

一份完备的交互输出文档,是设计与开发有效沟通的必不可少的环节。但实际工作中,文档沟通总是有障碍,简单了,很多细节说不清,复杂了,设计者写得累死开发还不一定仔细看。所以,最有效的办法:坐到开发旁边,每天检查成果,有不符合规范的地方直接沟通并修改,省去繁冗的文档和邮件,可以大大提高效率。当然这种方法仅限于代码没有还原设计的情况,如果涉及设计变更,还是需要使用邮件等方法告知项目中其他相关人员。

再分享一个经验,将Axure导出的交互文档存放到服务器上,通过浏览器可打开地址直接浏览,当开发期间有设计变更时,开发者也可以看到最新的设计稿,不再需要通过邮件附件不断往返,降低沟通失误的机率。

存在的不足:

  1. 在前期数据支持不够。客户端产品不像web端产品容易埋点搜集数据,所以在数据方面我们存在很大的不足,希望以后的版本能有改进。
  2. 设计流程不够完善。虽然知道有很多用户研究、交互设计的方法,但由于专业能力、项目时间、资源等等原因,并没有很好的实施起来,很多设计决策主要还是靠想像和讨论,没有足够多地与用户接触。如此,产品可用性没有很好的保障,设计人员的专业影响力也得不到提高。希望以后流程能够越来越完善。
  3. 设计师对客户端技术和平台约束了解太少,导致沟通困难。在web端,设计师都被要求了解html和css、清楚前端后台的分工,可以减少很多沟通成本;在移动客户端领域也一样,做IOS平台设计的也有必要了解Xcode的基本知识,尽管他比html要难许多。总之,设计师要学习的还有很多。