小鱼|可用性测试你不知道的Buff( 四 )

文章插图
在小型可用性测试中，也有脚本、简易的暖场、用户定义、测试目标、测试任务、测试原型、测试参与者、测试观察、思考总结，更多的也是发生在功能上线之前的推敲阶段，它比较适合设计师在自测阶段后的验证以及多版本Battle，帮助你Pick一套更加合适的方案。
但是整个过程相对正式可用性测试会更加简单易行，其中价值观念与目的都是一致的，都是以用户价值与用户目标来驱动（使用动机）使用产品，并且观察用户的使用过程以获取有效的反馈来改进或决策。
不过呢，脚本会更加简易一些，原型材料也不用那样精细，主要能表达功能作用与信息流程为主，其中测试者更多的是寻求那些关心我们产品或有需求的用户，另外也不会准备那些知情书、协议、录制设备、测试指标啥的，更多的是寻求熟人或哪些有意向的用户快速进行测试并观察，这样不仅时间成本都节省了，难度降低了，也能拿到一定的有效测评结果。
基本上主要的实践步骤就这五点，还有一些布置会穿插在其中，后面代入案例讲解一下。

文章插图
2. 案例代入讲解便于直观的了解和感受小型可用性测试，这里代入一个老案例讲解一下，关于案例背景这里简单交代一下。
（1）背景
平台服务于游戏相关的订单交易、互动娱乐，本次测试的内容是新的游戏订单定制服务，通过推出一批专供用户定制游戏服务的客服来完成沟通与定制下单，其价值在于帮助用户快速了解平台游戏服务以及快速定制服务并完成下单转化，以沟通的方式减少用户下单的操作流程与门槛。
（2）任务流程
设计服务入口与流量分发->用户选择心仪的小鱼（专供客服的代称）->进入小鱼的会话界面->沟通需求目标->小鱼制定用户专属服务订单->用户支付确认->转到订单流程
为了加快讲解和体现测试的价值与方法，这里就不跑全套流程了，就以小鱼入口的设计与流量分发来代入讲解，测试前提是聊天会话界面中已经集成了“小鱼”所受理的主要游戏业务介绍，以及快速下单的入口。
当然一般都是在用户向“小鱼”倾述目标需求后，由“小鱼”进行服务定制，并向用户发起订单等待用户确认支付，之后便是等待订单完成到验收评价，平台转交佣金。
（3）首先定义用户与目标
在这个测试任务开展前一定要知道开展目的是什么，然后就是这个过程中你的功能或产品是为什么样的人服务，能为他们带来什么样的价值，也就是前面一直提到的价值与目标驱动用户的概念。
为此你可以建立一个简易的用户原型来定义用户的特征属性，使得目标群体再具体一些。
然后将小鱼的服务价值写出来，让参与者能够快速知道小鱼功能有什么用：

文章插图

文章插图
（4）创建适用于目标的测试任务
对于测试任务的创建，应该是围绕目标的。
根据流程的多少或复杂程度，可以划分为多个阶段，这样具有阶段性会更好控制测试节奏或分段进行，然后就是将多个任务按照流程顺序或是操作难度排序，目的是使得任务流程正确或是用户接受起来更容易。

文章插图
当你把任务清单罗列出来后还不算完，这套清单你可以放在脚本里，但是当你描述给用户时，你应该代入对方视角去描述并且带有目标性，所以还需要进行一次调整后应用：