Design Checkpoints: A Fast and Easy Technique for Evaluating Designs with Customers

Design Checkpoints：与客户评估设计的一个快速而简单的技术

 

Robert Barlow Busch, Quarry Integrated Communications交互设计实践总监, (加拿大)

 

曾经有想过写写把可用性测试简化运用到个人设计师/小团队的设计过程中去，但参加了UPA的这个workshop之后，我想不如就直接推荐Design Checkpoints吧！

就如演讲的标题，这是个快速而简单的评估设计的方法，容易做到也容易看到效果，最大的好处是设计开发的团队不论大小、处于哪个阶段(当然，别太晚了)，这个方法都是可以用到的。

 

What are design checkpoints?

 

首先，这不是一个可用性测试。对于设计师来说，和顾客的交流非常重要，但通常设计师不参加可用性测试，因为会趋向于保护自己的设计；而Checkpoints是设计师参与的，通常可以这样:

一位设计师，一位顾客，一个小时。当然，设计师可以不止一个，也可以一次分开访谈多位顾客，还可以请PM或者项目相关人员在旁观察。

这里的顾客(Customer)，解释成End User更为恰当。如果条件有限，也可以请同事代替，但最好他们能以普通用户的身份来参加评估。如果在开发过程中有多次的check points，每次邀请的人可以保留一些之前的访谈对象(注重最新的更改)和新的人选。

 

类似于飞机驾驶，航线途中可能不断需要调整方向，以免因为风向等的缘故偏离航线，Design Checkpoints的作用也想是设计过程中的参考和引导，做出最好最合适

的设计。

 

比较Design Checkpoints和可用性测试，

后者是正式的，前者相对来说非正式、访谈过程也比较轻松自由；

可用性测试的费用可能很昂贵，但Checkpoints耗费就很低；

Checkpoints相比之下可以更频繁地进行，8个月的开发周期中可能只做2-3次可用性测试，但Checkpoints可以两周就做一下；

可用性测试是任务性质的，而checkpoints是访谈/讨论性质的；

可用性测试的结果比较科学、文档记录，而Checkpoints的结果是经过归纳总结的。让我概括的话，可用性测试正规严肃，而Checkpoints更轻松并有很多机会讨论。

 

关于进行Checkpoints的地点，这自由很多，可能是任何一个可以谈话和观看设计的地方。会议室、可用性试验室、甚至利用远程技术(桌面共享之类的)

 

下面来谈谈三种Design Checkpoints:

 

Discovery Checkpoints

 

主要的作用是 Understand your customers.Test your assumptions.

可以说是初期使用的方法，我想需求定义的阶段比较合适。

 

可能用到的方法：

Getting to know you

用户使用产品的目标是什么？

访谈和观察

Task inventory

用户会怎样使用产品？

头脑风暴，角色扮演

Process mapping

用户会怎样执行关键任务？

角色扮演

Go shopping!

列出任务或者特性的列表，受访者会愿意“买”其中的哪一些？

Desgin the box

提供一个空盒子(真的空盒子或者画一个)，和受访者一起设计这盒子的样子、为什么是这样子？

 

这些方法中，印象较深的是Go shopping!模拟讨价还价的情境，在了解用户需求的同时也让他们参与了对于功能的权衡取舍。最重要的是，这种方法很轻松生动。

 

 

Exploration Checkpoints

 

作用在于Explore alternatives. Test different concepts. 个人觉得适合用在原形设计的初期。早一些犯错误，因为那时候的代价小，也可以从中学到不少。你可以拿着一个wireframe(线框图)就去做checkpoints了

 

可能用到的方法：

5-second test

给受访者看页面/屏幕仅5秒左右，然后问问他们记得些什么、哪些比较重要

Trial by fire

不要介绍或者引导，就让参与者独自面对界面，让你的设计帮助他明白

Be the director

让设计师来作用户，演示使用的过程，让受访者提供意见和反馈

Be the designer

鼓励受访者来设计他希望的原型

Be the instructor

“假设我没有用过这个产品”，请受访者来介绍一下怎么用(很适合来结束checkpoints)

 

记得在这个阶段，不要执著于一个想法，你可以准备两三种在这个过程中比较一下。关于评估的内容，可以zoom in，探讨一些小细节；也可以zoom out，讨论一些比较全局的问题。

 

 

Validation Checkpoints

 

为了Validate your decisions. Test the details.

你可能要去找那些明显的错误，但不必担心焦虑。当你看到它的时候，你会意识那是个需要解决的问题。

 

可用的方法：

Exploration checkpoints中的任何一种方法，详细的；比如5-seconds test, trial by fire, be the instructor

Task completion

类似于可用性测试

 

这次workshop里，我们就分组做了这样的尝试：设计一个影片租赁网站首页的wireframe，然后每次交换组员来做checkpoints。是Ami我执笔，集合了大家的idea在好大的纸上画，然后请交换过来的组员作为受访对象。

大家都没有忘记先来个5-seconds test，也询问了受访者感兴趣和关注的点、和希望有的内容等等，并随之做出调整。切实地尝试之后，也的确感受到了这种方法的作用，而且整个过程轻松愉快~

发现组内专业人士，因为工作关系，会比较喜欢多一些类似于可用性测试的尝试。但即使是专业人士，也别忘了不要因为一个受访者的意见就驳倒更改原先的设计，因为这只是参考意见，也只是个别的想法。(可用性测试的结果也是基于一定测试的人数的吧？)小小的workshop里就发生了这样的事：A组做来一个人说，我希望在xxx有xxx，于是我们组就有人坚持要改~而后的结果是B组的、C组的，都觉得xxx位置的xxx很多余。

 

 

最后的总结和提醒：

• 每间隔2周做一次checkpoints
• 每次征募2名参与者，1小时
• 在一个上午/下午连续做checkpoints
• 少花点时间准备，就用手边有的材料、不要为了评估而建立原型
• 尝试让设计师来做checkpoint
• 尽量让你的发现和结论简单些——通过email分发

篇幅有限，就写到这里啦，下次结合Ami的实践继续谈~

可惜还没有拿到一同参加的朋友所拍的照片~ DTE等我这篇文章等了很久了，我等那些照片也等得望眼欲穿啦~~

 

 

Ami的User Friendly 2006 专辑：
http://blog.sina.com.cn/u/1467134183#serial_5772b0e705000gz8