面对多平台的可用性测试需要注意的内容

摘要: 手机、PC、网页、平板一个产品拥有多个终端/平台的情况已经非常普遍,面临大版本时更是所有平台要同期发布,并且各个平台之间的连贯体验也越来越重要,单平台的可用性测试已经

手机、PC、网页、平板……一个产品拥有多个终端/平台的情况已经非常普遍,面临大版本时更是所有平台要同期发布,并且各个平台之间的连贯体验也越来越重要,单平台的可用性测试已经渐渐不能满足当前的需求,这里就跟大家探讨下面对多平台的可用性测试需要注意的内容。

  (以下故事纯属为了奠定全文喜剧色彩和夸张手法,和真实产品没有半毛钱关系。)

  用户研究员老王最近遇到了一件烦心事,TA负责的某产品过俩月要发个大版本,瞅了眼项目经理发的周报,六个平台还要同步发!(领导再也不担心老王的工作不饱和了)看来各平台的可用性测试跑不掉了,老王掐指一算:

  我们这个狂霸酷拽的产品共有6个平台;

  这个新版本共有3个新特性和5个基本特性需要测试;

  各平台是分开研发的,所以每个特性完成的时间点不一样;

  那么项目进度表有可能是以下这样丧尽天良的:(以下表格纯属虚构)

  所以:

  等单一平台的所有特性开发完成后按平台测试是来不及的!

  等单一特性在所有平台开发完成后按特性测试也是不可能的!

  这可把老王愁坏了,硕果仅存的几缕头发也要被薅(hao一声)光了。

  老王不用怕!小天使偷偷告诉你一个秘诀——

  已经翻了白眼的稍安勿躁,这样放荡不羁的前提条件是:

  1. 平台多;

  2. 发布时间集中;

  3. 特性在不同平台同质性高。

  至于好处则是:

  1. 减少可用性测试的次数;

  2. 增加验证解决方案的轮数;

  3. 预测并避免同类问题在不同平台重复出现。

  那么具体执行与常规的可用性测试有什么不同呢:

  接需求前切记保持底线

  首先给大家讲个小故事:

  其实只是多问一句的事儿:

  上面提到的这种情况也不是不可能发生,接需求前记得保持自己的底线:

  不能在当前版本落地的缓一缓(下个版本还是未知数,也许整个特性都会被干掉,那么这次的测试就是白费功夫)

  没有明显变化或改进的等一等(如果这个版本只是修复了上个版本的一些细节内容,而大的交互流程和图标体系没有变化,并且和上个版本测试出来的可用性问题无关,那么建议不要接,或者利用其他平台测试的资源顺便测试。)

  对界面完全没有影响的就算了(有时会和其他产品甚至是硬件合作,如果我们无法影响到其中的界面那么就算有问题也没法改,这种情况不如不做)

  保证一个主平台的基本特性不测漏,其他合理补充

  虽说这奥义是哪里做完测哪里,但是也不能胡来对吧。

  通常来说会放到可用性测试里去测试的特性有这么4种:

  在多平台的可用性测试中,首先要选定一个主平台,保证该平台所有的基本特性不测漏,对于其他平台,有全新特性做完的平台优先测,其次是有改进后特性的,但一次测试不要超过3个平台。这样是为了让新特性有更多的试错验证机会。

  重场景、轻任务,同平台放一起,跨平台看场景

  场景,是对角色如何使用基于软件的产品达到自己目标的简明描述。任务,在我看来更像是对特性的包装,而这些都需要在“场景”这个大剧本下才可执行。

  实际测试时我通常会让用户明白TA是谁(通常就是TA本人)现在在哪里(比如家里)要干什么(把手机里的照片存到电脑上),然后看TA如何操作就好。至于TA是不是按照理想的任务顺序来操作其实并不重要,重点是TA的目的(或者说是我们设定的目标)是否达到。如果没有达到目标,观察TA是在哪些环节出了问题导致失败即可。

  至于用户通过捷径跳过设定的任务直接达成目标(或者说没有测到需要测试的特性)的情况,可以在用户达到目标后再邀请TA通过其他方式尝试。

  另外值得注意的是,虽然让用户自然地操作很好,但是当平台较多的时候很可能出现手忙脚乱的情况,所以为了用户方便还是尽量要把同平台的任务编排到一起,需要跨平台的话(比如在电脑上下载了电子书传到手机上看)那就把它放在使用电脑的任务和使用手机的任务之间作为过渡,如下图示意。

  疯狂鞭笞小伙伴修改问题,反复验证解决方案

  测出了好多可用性问题怎么办?催着改啊!改完才能在下一轮验证解决方案对不对啊!iOS的特性A这轮出错了,下轮Android就能测改过以后的特性A啦!还有问题?那继续改啊!之后还有iPad那轮呐!(见下图)

  这里需要重申一下最前面提到的一个大前提——特性在不同平台同质性高。也就是说当特性A在iOS和Android的界面基本类似的情况下为了节约时间可以用另一个平台来验证这个平台的问题,当然最好还是能在原平台进行验证啦。

  把报告写给要看的人,及时跟踪落地结果

  报告出来以后要让同事能看懂并且立即消化对吧,所以给不同角色看报告大概是这样的:

  给老板看核心问题和主要结论;

  给产品经理看问题的严重性,提供需求优先级的参考;

  给设计师看具体问题发生的原因,这样设计师就可以去思考更好的解决方案,而不是粗暴地通过增加功能特性的方式来解决;

  给开发看哪些问题是属于bug,可以立即修复;

  另外,不同平台的负责人可能是不同的,所以最好把同一个平台的内容聚合到一起呈现。

  最后来说说自己维护一个可用性问题追踪表(如下图示意)的好:

  从跟踪情况看哪些问题是历史遗留并且还没有解决的,再发生类似问题就多跟相关同事聊一聊;

  从特性名称看哪些任务总是完成得很差,哪些是改了以后越来越差,嗯,还是要找同事聊一聊;

  从其中一个平台的问题也可以预估其他平台在做类似任务的时候可能出错的地方;

  方便统计自己的落地率,总结一下经验教训;

  最最好用的一点是——别人问起某平台某版本的问题时你可以瞬间把同版本不同平台/不同版本该平台的所有问题全截给TA看,如果顺便能把其他平台的同样问题或者该平台的历史遗留问题一并解决就太棒了。

  唔 说了这么多不知道对大家有用么~

时间: 2024-11-03 07:28:30

面对多平台的可用性测试需要注意的内容的相关文章

一大波平台来袭,可用性测试怎么破

手机.PC.网页.平板--一个产品拥有多个终端/平台的情况已经非常普遍,面临大版本时更是所有平台要同期发布,并且各个平台之间的连贯体验也越来越重要,单平台的可用性测试已经渐渐不能满足当前的需求,这里就跟大家探讨下面对多平台的可用性测试需要注意的内容. (以下故事纯属为了奠定全文喜剧色彩和夸张手法,和真实产品没有半毛钱关系.) 用户研究员老王最近遇到了一件烦心事,TA负责的某产品过俩月要发个大版本,瞅了眼项目经理发的周报,六个平台还要同步发!(领导再也不担心老王的工作不饱和了)看来各平台的可用性测

一个你绝对不知道的移动可用性测试

  在移动设备上进行可用性测试是大多用户体验设计团队既关注又头疼的部分,市面上的各种专业测试工具各有利弊,如何抉择是一道难题.性能好.对用户干扰少.录制质量高.能记录用户面部表情和手部操作.价格便宜等要素成为大家在选择工具与方法时重点关心的内容.本文作者Colman Walsh提供了一种讨巧的方式,能较好的解决测试中大部分问题.尽管不完美(无法记录用户与移动设备屏幕互动),依旧值得一试,有精力的同学可以结合Lookback(https://lookback.io),或许能捣鼓出一套更完善的解决方

用户体验设计:浅谈可用性测试中沟通的技巧

文章描述:如何快速解除用户防备?--浅谈可用性测试中沟通的技巧.   一般来说,在产品的设计和开发过程中,不同阶段会使用到不同的用户研究方法.比如,在产品正式发布之前,通常会进行可用性测试.可用性测试,是指让一群有代表性的用户尝试对产品进行典型操作,同时观察员和开发人员在一旁观察.聆听.记录.该产品可能是一个网站.软件,或其他任何产品,它可能已经做好,也可能尚未成型. 对于一个典型的可用行测试,我们可以:1. 通过观察用户在使用产品过程中出现的一些问题,发现产品的可用性问题2. 从测试参与者的表

可用性测试:表述清晰的功能

在产品开发完成后,可用性测试是我们必要的一个环节,而在测试之前,我们一般会对软件走查多遍,以熟习产品,并对可能遇到的问题在心里有一个大致的判断. 本文作者@Uprit 最近做了一个导航产品的可用性测试,主要过程是,让一些用户在主持人的陪同下完成一系列已设计好的典型任务,以此来发现软件中的一些可用性问题. 整个测试下来,发现了一件比较有意思的事情:有一个任务看起来比较复杂(群组导航),但一次完成率较高;同时有一个任务看起来简单(搜周边),但一次完成率却较低.这与测试之前的预期有点出入. 先来看看这

《可用性测试手册(第2版)》一1.2 导致可用性低下的原因

1.2 导致可用性低下的原因 究竟是什么原因导致许多高科技产品如此难用? 接下来,我们将研究这个主题,讨论这个现象存在的原因,并全面研究问题的对策.书中很多案例不仅仅涉及消费类硬件.软件.网站,还包括用户使用手册和内嵌的电子帮助文档以及错误提示信息.解决方法一并适用于乐器.移动手机.游戏操控台,等等,甚至类似超声波影像操作平台或数码相机的用户手册都是本书涉及的范围. 导致产品可用性低下的五大原因 对于当前从事产品研发的工作者,如工程师.用户界面设计师.技术协调员.培训专员.管理者等而言,导致产品

案例学习 – 关于VSCO Cam的可用性测试

Visual Supply公司出品的VSCO Cam是一款时尚并强大的移动端照片处理应用,无论在App Store还是Google Play都有着4.5星的优异战绩.VSCO有一大批忠实的用户群,而且他们的Grid(应用内置与在线的照片流)当中有着很多我所见过的最美的照片.在2014年5月,他们成功融得4000万美元的投资. 可用性测试的目标 通过6个基本任务识别出VSCO当中的可用性问题及痛点.其中的3个任务直接来源于App Store的小编所撰写的简述: Visual Supply公司的这款

我从可用性测试中学到的五件事

我喜欢做可用性测试. 没有比把假设放在用户面前来测试更有效的方法了.你不仅可以在开发环境之外看你的工作,还可以从用户那里得到很多创新的想法,因为他们每天都在用这个系统. 这件事你必须尽快安排,但是让人吃惊的是很多开发者并没有这样做.他们应该少花点时间开发,多花点时间和用户交流.也就是说,他们更应该走出去. 我还学会了如何获取更有效的反馈.如果专注于特定的模式,那么你可以提高自己发现隐藏观点的能力. 最好在环境上下文中进行测试 我第一次参与的几个可用性测试就是市场人员喜欢做的:主持人坐一边,另外五

用户调研和可用性测试:利用客户资源提高约访

文章描述:用户访谈成功约访三大秘籍. 做用户调研和可用性测试,招募到合适的用户,是有效用户研究的基础.因商业产品的特殊性,我们约访客户来源渠道也有一定的限制,且这些有限的客户也不是每一次预约都能成功.如何有效利用客户资源提高约访的成功率呢?总结了些经验供大家参考,希望在工作中有所帮助. 客户约访流程: 秘笈一 约访前的准备 1. 心态准备--在电话约访前调整好心态,不要害怕被拒绝而不敢打电话,可以想象是打给自己的朋友. 2. 话术准备--电话约访前进行充分的话术准备和练习(沟通时话术.被拒绝话术

产品提升作用非常好的工具:可用性测试

文章描述:开始一场可用性测试. 相信每个产品设计者都希望自己能够打造出非常棒,贴合用户的产品,而可用性测试是对产品提升作用非常好的工具,可以为产品提供很多非常有价值的内容,让你可以恰当的在产品与用户之间找到一个微妙的平衡. 可用性测试在专业互联网公司里是隶属于用户研究的职责,而且用户研究这个职位并非每个公司都会设置,如果你也像我一样渴望提升产品品质又没有用研帮忙,也没有这方面的领路人的同行们,怎么办?因此我写了这篇文章,不是因为我是一个用户研究,也不是我对可用性测试多精通. 前段时间恰好啃了一些