跳到主要内容

产品设计方法

今天介绍的这种产品测试方法,是由《Don’t Make Me Think》的作者Steve Krug先生提出、也是之前我在工作中尝试实践过的一种方法。相对于专业的实验室测试方法,个人觉得这种方法在我们日常工作中可能更高效、更有用。

言归正传,直入主题吧。

相信大家都听到过产品经理或者设计师对于可用性测试的抱怨或害怕,例如:

- “我们没有那多时间做测试啊!”

- “我们没有太多的经费预算。”

- “这方面我们不够专业,怎么做啊?”

- “我们没有可用性测试的用户体验室啊!”

- “用户体验室这两天被预订出去了,我们去哪儿做啊?”

Steve Krug先生提出的这种简易测试方法,正是为了解决诸如此类的问题,让每个产品经理、设计师都能够轻松的做测试、轻松的发现问题。

1. 简易测试方法和传统可用性测试的比较

我们先通过下面的这个表格来大致看一下这种简易测试方法和传统可用性测试的区别。

2. 简易测试方法对于被试人数的要求

传统可用性测试往往要求每一轮的被试都需要严格筛选,一轮测试需要6-10名的用户甚至更多。简易测试方法则强调多轮测试,在产品的不同阶段进行多轮测试,发现问题并迅速做出相应修改。

如下图所示,左边为传统可用性测试,在一轮测试里面,8名用户能够找到较多的可用性问题。但是往往正是这5个问题,使得测试人员不能够走得更深,从而发现更多的问题。右边部分为简易测试方法。一般一轮测试3个用户,的确在一轮测试下来,3个用户发现的问题往往没有传统测试8名用户那样多。但是简易测试会在改进第一轮的三个问题之后继续测试,这个时候测试人员能够更深入的了解更多的问题,因此可能2-3轮测试下来,找到的问题会比传统一次测试8名要多。

3. 简易测试方法的场地要求

很简单,一个会议室或者安静的办公室即可,无须有单向玻璃的观察室,无须带有声音监控的设备。测试人员和用户坐在一起,要求用户在电脑上完成产品相应的若干个任务,在完成任务的过程中,测试人员记录问题和用户的反馈。如果条件允许,还可以外接一个显示器,让团队的其他人员也能够看看用户的操作过程(如下图)。

4. 简易测试方法的操作流程

流程很简单,主要分为四个阶段:

1) 准备阶段

- 准备好需要测试的产品或demo:可以是纸质的草图原型,也可以是高保真的flash模拟产品的原型,也可以是即将发布的beta版本的产品;

- 准备好需要让用户完成的任务列表:考虑到各方面的成本,挑选一些有代表性的、关键的任务即可,无须面面俱到;

- 约好用户;

2) 介绍阶段

- 向用户介绍测试的目的;

- 告诉用户有任何问题、任何意译,随时可以询问;

3) 完成任务阶段

- 将准备好的任务列表让用户一一完成;

- 记录用户完成任务中的问题;

4) 结束阶段

- 完成所有任务之后,结束测试。

从上述流程我们可以看出,流程中最主要的就是准备阶段和完成任务阶段。需要把握的两个关键点是:

- 测试人员需要准备好测试所用的产品以及典型/关键任务列表;

- 现场让用户完成任务的时候测试人员记得记录用户出错或者有问题的地方;

在完成第一轮测试之后,产品相关人员可以根据用户的问题,马上改进产品设计,然后进行下一轮的测试。当让,如果产品相关人员觉得发现的问题已足够,可以在完成一轮的时候就结束测试。

原则:

\1. 我们测试的是产品可用性,不是使用者的个人能力

\2. 尽量不要打断用户的操作

\3. 尽量让用户独立完成

\4. 测试环境和场景任务应当尽量符合用户使用产品的真实环境

\5. 要让测试用户感觉到自己是被充分尊重的,尽量使其心情平和放松

其他:

\1. 每次用户测试前先要把测试用电脑的缓存和历史记录清除。

\2. 测试前一定要做预测试,把发现的问题记录下来,并在测试前把问题解决。

\3. 用户到体验室后,不要马上开始,先和用户聊聊天,拉拉家常。让他放松,告诉用户先休息几分钟,过会我们正式开始,再向您介绍本次测试的主题等等。考虑准备一些和用户的沟通的东西。

\4. 要和用户说明本次测试的产品、测试的目的、和测试大致的步骤以及可能花费的时间。

\5. 注意和用户沟通的语气,语速要慢。如果担心用户对自己表达的内容没有完全理解,可以说“我把我的意思表达清楚了吗” 和用户说话时要尽力看着用户,保持微笑。

\6. 过程中请尽量不要打断用户。

\7. 用户碰到问题情绪记得事先安抚用户。如“这个问题很多用户都碰到了”或“这个问题不是很重要,我们先放放。”

\8. 用户碰到问题时,可以提醒用户,不要代替用户操作,更不要说“您只要点一下这里就可以了”和不需要那样做等等,会让用户觉得他很无知。可以换种说话如:您可以试着这样操作看看

\9. 不要问用户“你为什么要这样做。。。”可以换钟方式如“我刚才看到您是这样操作的,能和我们说说你的理由”或“当时您是怎么想的”

\10. 如果用户操作的流程中并不是我们关注的流程,而用户由碰到了问题,这时候我们可以主动帮助用户。

\11. 当我们决定介入用户操作时,先询问用户是否需要帮助,用户现在想做什么,碰上什么问题。

\12. 引导员和观察记录员的电脑最好不让用户使用。

\13. 如果用户不是在关键任务上出现问题我们可以主动提供帮助,

\14. 如果在用户操作出现错误并遇见到他不能通过自身能力解决时应当主动帮助解决。

\15. 不要说“你有没有听懂”,要说“我有没有说明白”

\16. 当用户犯错误时要安慰他说“不只是您一个人有过这样的问题,很多用户也出现过类似的问题”

\17. 不要把体验问题归结到谁的身上,无需给用户解释原因,不要承诺什么,只需记下问题反馈给相关人员

\18. 不要问用户你为什么这样操作,要说“能告诉我你是怎么考虑的吗?”