只是记录一些对我个人有用的关键点，对于一个高效的执行脚本。（话说这是我08年起的一个草稿贴，汗颜）

1、清晰指出该次执行的探寻焦点。形式上可以是关键字，也可以是一连串的问题，前者适合于当执行者不大熟悉研究主题的情况，能快速的上手且准确执行，但容易遗漏关键字以外的关注点；

2、没有严格的执行顺序，但有清晰的场景定义。这点对刚入门的用户研究员尤其需要避免。看到很多脚本，由于研究员在设计时考虑到很多的“问题逻辑”，所以在脚本中设定了严格的执行顺序（例如先问什么，例如先做什么）。

这对于千变万化的用户思维，有时是弄巧成拙的，一方面是造成执行现场的冲突，更麻烦的另一方面会严重损坏用户数据的真实性。

但清晰的场景定义就不同，围绕着研究假设的各类用户场景来展开执行，简单的说就是控制的粒度变大了，只定义了要探寻哪些场景，而不限定各个场景中的顺序，只要用户场景足够自然，用户的想法就可以顺畅的天然的在咱们的实验中长起来。此外，我们在研究方案中预设的大部分逻辑，都源自产品的业务逻辑，或我们拍脑袋的，好一点的情况则有可能是我们推论的，这些都不是“从用户出发的思路”，显然容易出现“问啥知道啥”，也就是直接导致“研究结果都是已知的、经验的”这种悲剧结局。（往往一些初级产品人员做的所谓研究，基本属于此类，皆大欢喜，只要最终产品结果没出来）。最终的逻辑应该是基于数据整理，并加上对产品的理解所得，而不是让用户直接报告出来的。

3、时刻保证操作的灵活性。这很基础，而且最有发言权的应该是脚本执行人，简单的说就是，请在脚本正式投入使用之前，预先执行几次，校验此点。唯一要避免的问题就是别让执行人被脚本限制，这里包括主持人、记录员、观察员等角色。

当然，另外一个角度，如何让执行完后的数据整理更高效，也是可以在脚本设计上做点文章的，但那不是在设计脚本时要考虑的关键问题，就正如在设计界面时你不需要考虑界面的维护如何高效一样，但那些在考虑维护问题的兄弟如果给你提了需求，你可以在不妨碍设计目标的情况下轻松接受，支持别人工作。

就想到这么多了，作为2010年的第一篇，不宜口味太重，就到这里吧。