设计师可用性测试计划编撰

　　最近在进行面向设计师的可用性测试介绍，在涉及到测试计划这一部分时，布置了一个简单的作业：为TB新版收藏夹设计一个原型测试计划。从回收的结果看来，发现了一些比较典型的问题。在这里简单介绍一下方法和自己总结的几个注意点。

　　这是面向意欲执行可用性测试的设计师的简单方案，所以选择了比较精简易懂的介绍。

　　制定测试计划可以简单归纳为三步：

　　确定用户最关键的一点是明确产品的商业目标，它很大程度(尽管并不总是)决定了后续的特征提取。特征通常包括使用行为以及人口特征数据两个方面。未必总是需要考虑人口特征，取决于产品。实际上有多少互联网产品能够在人口特征方面明显差异化呢?

　　一个标准的可用性测试当然需要根据定义好的特征去找对应用户，但是对于设计师来说，这样操作的成本较高，很多产品实际上并不需要十分严格地选取用户也能得到有效反馈。

　　为了帮助设计师明晰用户群，我在课堂上设计了一个简单的3C练习让大家分组讨论然后互相参看答案并点评。这种方式对于激发讨论(要辅以时间控制)还是蛮有效果的，从Gamestorming这个网站得到的启发。

　　确定了用户群体后，可以根据上一个练习得出的用户挑战以及结合产品本身待检验的设计决策等，转化成访谈问题、测试任务和观察要点。

　　测试任务，或情景任务(俗称指导语)是比较关键的一部分。不同的说法可能引导不同的行为，关键还是看任务本身的测试点是什么。上图所举例的四句话，没有绝对好坏对错之分，取决于你想通过任务发现什么问题。

　　后续通过回收设计师们的作业(描述收藏夹测试用户的特征;以及为其中一个用户群设计两个测试任务/访谈问题/观察点)，发现了一些共同的问题，所以总结了几个点。每个点辅以一些反例。

　　数据可操作性是指，需要考虑数据是否可以通过BI取到。

　　热身访谈和回溯问题是不一样的，回溯问题主要针对任务完成情况的提问。而热身访谈则用于了解现状、习惯等，这对于辅助分析用户为何作出某些行为有重要的参考意义。

　　其实，设计任务以及指导语可以说是最具挑战的环节。

　　任务本身必须具有逻辑性，比如上图举例为什么是反例?因为用户大可以不走我们希望TA走的行为路径来完成这个任务，这就达不到检验问题点的目的了。

　　另外，任务还需要考虑情景是否充分，过于干巴巴的指导语很难让用户进入状况。同时，还要考虑用户的性别等。如果是女性用户，让其购买足球就未必合适了。

　　再次，任务还需要考虑原型制作成本。比如一个逻辑性和情境性都很强的任务，却需要设计师花很大功夫做出相应的原型，也是不可取的。

　　对于刚刚接触可用性测试的人来说，事前在计划书里把观察点罗列仔细会更好哦。作为观察点，自然是能够被观察到的才算。所以尽量避免一些需要主观判断的内容，比如是否喜欢、是否意识/察觉/到……

　　最后，关于探询问题(访谈时/回溯时)，也有一些需要注意的点。常见问题包括问一些有偏向性的问题，或者非要要求用户在方案甲乙之间作出选择。当然，我们可以去问“你更喜欢哪个版本?”，但其实更应关注的是为什么喜欢/不喜欢而不是最终的选择。

　　此外，那些预测性的提问，比如“你觉得你会用吗?”“你觉得你会买吗?”，对于用户的回答要持谨慎态度。

　　作者：Helicopter

　　文章来源：piglili.blogbus.com/logs/127376255.html