前一向和两位同事（开发人员）去一些北京的中学做教师用户需求的现场调查研究（我们要开发的软件是面向几何老师的几何辅助教学工具），当时就有很多经验教训想总结出来。直到现在才开笔，想一想真有点惭愧，一些好的感触可能现在回忆不起来了。那就这样吧，经验教训混在一起说，来个“12345……”

1、只要你与用户接触，你就会有巨大的收获。

这是我第一次做用户研究，也是我第一次发现用户研究有多重要。在其中一个中学里，我们还没有说完自己的意图，老师们就非常热情地说出他们在操作一个同类竞争软件时遇到的一些问题（其中绝大多数问题都是交互问题，而不是功能上的需求问题），并在我们的要求下，做现场演示。想一想，如果开发人员只懂得通过访谈去了解用户的功能需求，用户真正的想要解决的交互问题必然就会被他们所忽略。其实，很多交互问题用户心理非常清楚，而且也很容易得到解决。比如，老师遇到了一个“给一个角标角号”的问题，用同类竞争软件来做，需要N个步骤才能实现，而且实现的方式比较隐蔽，更不符合老师的心理模型（Mental model）：老师希望通过软件先画出一个角，再画一笔就可以标上一个角号，而该软件的方式却恰恰相反，是先选择一个实现标角号功能的菜单项，然后画角的时候，这个角就有了角号。

2、要从多种角度多种方式去了解用户的目标。

开发人员往往容易从实现的角度去考虑用户的“目标”，就是说：他们会想当然地认为，用户有一个功能需求，用户的“目标”就是希望软件获得这个功能。这是一个简单化的思考用户目标的方法。在一所学校中，有位教师说他大部分时间都在使用黑板来画几何图。遇到这种情况，可能从软件需求分析的角度来说，就没得说了：教师都没啥需要的，还能提出什么功能上的需求？其实，用户不使用软件而使用传统的工具来进行教学，是不是因为传统的工具更容易达到他的目标。后来我才了解到，他有这样一种（我认为非常正确的）观点：几何教学最重要的不是（通过软件）把图画得多标准，而是通过画图/画辅助线的方法和过程让学生清楚地了解几何解题的过程，从而培养学生的几何思维。软件虽然画图标准，能整合资源，但黑板更能把画图/画辅助线的方法和过程体现得清清楚楚淋漓尽致。这时，我让他模拟教学，把在黑板上画图的过程为我们演示一遍。我们看到，这位教师真正的目标是：培养学生的几何思维和解题能力。那我们的软件是不是只有支持他的这种目标，他才可能心甘情愿地使用软件？显然是。这里，我们就换了一种角度来了解和思考用户的目标，这样我们在以后做软件的时候，就不会单单考虑所谓的软件功能是否能够提供给用户，而会考虑哪些功能是用户最需要的，哪些是用户不需要的，以什么样的交互方式提供给用户才是让用户最方便的。

3、抱着学生的心态与用户沟通。

尽管我在用户研究之前就与另外参加调研的开发人员强调过这一点——我们过去是学习的，因为我们没有用户的领域知识，所以要有当学生的心态——开发人员还是或多或少保持了他们惯有的沟通方式。什么惯有的沟通方式呢？（我不敢说这是所有的开发人员的沟通方式）就是：我这里有一个能实现**功能的软件，我认为他在**方面有很多优势，能够给你们很多帮助，我现在演示给你们看看，你们做做评价，看还有哪些功能需要加上去。呵呵，这种沟通方式是不是有点像推销？我们来调研，真的是希望听到用户的评价吗？（或许大部分开发人员会满意而归，因为用户出于礼貌往往会说出“不错”、“很好”的话来）。我们来到用户的现场，目标不是让用户说出他们喜欢什么功能不喜欢什么功能（用户做这些评价的时候迫于人际压力很难客观），而是要了解用户的情况：了解用户/用户的职业有什么样的特点，用户有什么样的目标和期待，用户完成他们的业务的过程是怎样的，用户在完成过程中遇到了哪些困难……这些问题，开发人员（即使是聪明绝顶的高手）会事先知道吗？有什么理由希望拿着自己的“强大”的软件去影响用户，并希望用户喜欢它？因此，到了用户跟前，我们就是学生，我们不能不懂装懂，我们需要虚心求教。

4、由一个人主持访谈活动。这也是我做这次用户研究的教训。本来商量好由我来主持访谈活动，其他人进行辅助性访谈。而到了现场，却没有努力组织好，结果造成多位访谈者发问，这样用户的访谈组织得不好，访谈就会不够深入，而且人多噪杂，给访谈记录也带来困难。

5、最好进行一对一的现场访谈和调查。这次用户研究，一所中学都有多名教师参与，在用户访谈的时候，一些有影响力老师会一口气说出很多，但我观察到，有的老师在旁边欲言又止，显然是有不同的一些观点和说法，迫于群体压力的时间上的不允许，不能即时说出来。我想，现场调查研究采取一对一的方式应该是最好的，一方面可以看到和听到不同用户的做法和说法，另一方面访谈和调查会更加深入。

6、合理安排调研的过程。这也是非常重要的一点。很多需求调研可能是先给用户看事先做好的软件/产品原型，然后让用户实际做一做，最后访谈。我认为这一过程值得改进。因为用户如果事先看到了我们要开发的软件，他们就会被引入到了我们的思路上来，无形地阻碍了用户在自然状态下的思想和观念，这样用户在后面的访谈中有很多可能内容会说的不够客观（就好像前面说的让用户做评价的后果）。其实我比较赞同这样一种步骤：

（1）说明来意，通过演示软件原型大概说明一下我们需要做的是什么样的软件，而不仔细说明软件的功能——最不应该说出来的是软件有哪些优势之类的。这个步骤的目的是让用户了解我们来调研的目标，并让用户对我们的软件有一个直观的印象——但不让用户有先入为主的印象。

（2）根据访谈提纲进行访谈，并在适当的时候要求用户演示同类竞争产品来说明用户自身在使用软件中遇到的问题，或让用户实际演示他/她在完成任务的过程等。通过这一步，我们已经收集到了所需要的绝大部分的信息。

（3）让用户实际操作我们的软件原型（就是原型的用户测试），在操作过程中，让用户出声思维，并说明原型中存在的功能需求和交互需求问题等。