坑，坑，坑
＃这是个悲伤的故事——期望值令人叹气
——回顾文献确认试验方法
小规模的原型测试通常让用户进行某些简单的操作从而在两个版本中进行选择。虽然能进行测试的内容很少，但是也同样有着一定的前提。研究者最好意识到这些前提：如原型测试虽然看似测试用户偏好，但是测试的流程可能涉及到用户进行学习以及迁移学习经验的过程（比如识别版式，记认icon）。要解决这些问题，最好根据实际情况合理的安排参与者如何使用原型以及适当模仿类似研究的思路进行研究设计。
——样本缺陷与描述性统计
简单的原型测试的样本选取过程通常都是有缺陷的，通常都无法代表总体。这某种程度上是一个好消息，因为研究者就此不必进行某些复杂的推断性统计——因为违背了推断统计需要的前提（其实多半情况下人数都不够= = ）。
——原型本身的缺陷
既然作为原型而不是正式的软件、网页，所以必然有着很多局限性——比如原型只能模拟有限的效果和操作（axure不支持双击）；比如原型的制作需要一定时间；再如复杂的原型其实和代码一样可能有各种逻辑需要处理也需要慢慢debug。
——我们究竟需要什么
在研究之前，就应该清楚的意识到数据本身的意义，也应该尽可能思考更多的衡量角度。比如用户所需要时间少就能发现某个功能，那么这样意味着这是一种好设计吗？设计的好坏在很大程度上取决于某种整体性的需求（或者说是概率），数据的处理本身也必须根据这种需求以及情景量身订造。不讨论业务特性和业务需求只看简单的数据计算，最终得出的数据结果不能导向好的结果。
＃这是个麻烦的故事——原型制作到小规模测验
——无数被迭代掉的版本
进行正式的原型测试之前，通常会有无数个原型图以及好几个基于原型图的高保真版本。无论是正式上线的ab test还是原型测试，所能使用的测试原型数量都有限。这就意味着，如果在最初的原型方案就筛选掉更有潜力的版本或是最终高保真阶段的选择不当可能导致整个原型测试的努力都被浪费。同时，原型测试中所使用的版本，最好是确定在此后不会有太多变动的版本。如果该设计如果其后会因为先前没有充分考虑的因素（比如要处理某些消息和状态，再如一些常见的一场状况），那么必然导致最终版本的设计必须进行一定的修改。这些修改可能会让用户偏好该版本的原因烟消云散，原型测试的结果沦为鸡肋。
——原型制作需要与实验过程以及数据处理相耦合
原型测试既然是作为测试，那么必然需要一定的说明指导以及顺序和步骤。这些对用户的指引环节最好耦合在原型当中并且从构思制作用于用户测试的同时就要思考如何更好的引导用户。比如，如果需要用户进行abcde的操作，那么通过什么让用户知道下一个操作的内容是什么呢？以及这些操作指引应该放在何处，以及通过用何种方式更好的让用户专注的阅读指引内容呢？根据本次测试的经验，我们会用axure制作动态面板，在用户阅读操作指引时蒙住页面（减少用户因为长时间观察原型而累计的学习效果），用户只能手动点击某个按钮后才能继续进行操作（这样也方便记录用户实际操作的时间）。
每个研究中都有一些重要的变量，早日明确这些变量具体是什么有助于更好的设计测试，更有利于后期的数据处理。比如对于某些点击效果以及hover状态早日进行编码，那么日后整理数据就会更为方便。与此同时，尽可能想办法减少手动整理数据的时间也很重要，比如让用户填写电子版的问卷再如写个小程序处理axure的console log，都能减少研究者进行无意义手动纪录的时间。研究者有更多的时间处理数据而不是简单的录入，就有更多时间进行思考和尝试不同方法探索数据。手动纪录和梳理数据非常容易错漏并且导致研究者疲惫，所以最好前期通过某些方法洗清数据（比如写个小脚本简单处理数据），尽管这些方法大多会带来某些投入，但是这些投入长远而言是值得的。
——前期pre－test很重要
在做正式的原型测试之前，最好先做两次pre test。pre test有助于研究人员及早检查方案设计的疏漏以及熟悉流程步骤，甚至是培养互相配合的默契（这些都可能对研究过程造成偏差）。pre test的存在也是得到一些初步用户反馈的必要步骤，在更大规模的正式测试之前的pre test就能纠正可能存在的问题。如果是更为大型的研究，那么前期的pre test即便数量有限，也能很快的排除一些重要的问题，因为软件问题的数量本来就是随着参与测试的用户呈现某种某种对数增长的（前期随着参与测试的人数增加能发现很多问题，后期发现问题的数量则随着人数增长放缓）。
——或许需要教学关卡
无论是何种原型测试（除非正式上线使用），大多对于用户都是一种新鲜的体验。新鲜感本身可能会让用户花费更多时间进行学习和适应，导致研究者更难以衡量用户究竟是在理解操作步骤还是在观察和理解界面。这个时候，提供某种demo以及对应的说明指引（最好是一段小视频or gif）能帮助他们更好的适应测试环境，同时缓解紧张感，也能在真实测试中更自然的进行操作。当然，如果有更多的参与者或是有更宽松的时间，完全可以让用户反复试验操作从而替代教学关卡。
＃这是个蛋疼的故事——用number做统计
numbers是一个很轻巧简单的软件，也是一个不适合用来做统计的软件（某种程度上excel也差不多，但是excel虽然提供数据透视表，但是对于公式上方面的操作比numbers体验差很多）。虽然numbers对于公式方面的支持提供了相当多可视化的支持（比如其公式内容的展示非常美观也易于学习），但这货根本不是一个统计软件...如果只是做最简单的描述统计，numbers当然是一个好选择…而且用numbers可以生成很好看的图表，也能方便的进行图表的细节调整。处理数据而言，如果有钱那么最好上spss，没钱那么也可以尝试下python...(不推荐r因为r是一门很蛋疼的语言，而且python也有很多支持库了，scipy还有pandas都值得一用（虽然我写出来的代码运行速度堪忧就是了）)
＃小结：基于axure的超极简用户调研方式
虽然研究者可以通过很多努力，尽可能减少小样本原型测试中的问题...但是要解决问题需要研究团队中有熟悉研究的成员（从看文献到写代码再到画图），也要有试错机会一次次练习从而提高实施测验的技巧，降低某些前期准备的投入成本。毫无疑问，这其中有很多坑，但是小规模的用户测试依然有其意义——避免设计和产品团队身在此山中而做出太多理所当然的假设。
#书目推荐
如何做心理学实验
行为科学统计
评论
发表评论
"fire in the hole"