启动

借着BQ用户体验大会的东风，我们UE部门也实际操作了一次流程完整，结构清楚，纬度立体的用户研究。

任务卡

任务卡要带着设计意图去完成，一是用户的体验流程应当完整，二是着重关注的细节要突出。另外，更重要的是任务卡要说清楚结果，不当对用户操作有所暗示（往往易犯）。

观察

• 让用户读任务卡并描述自己的操作。
• 别靠的太近。
• 多让用户找一会。
• 在最糟糕的情况下要提示用户执行下一个任务。

问卷

和任务卡一样，问卷也比较考验文字能力，当然更要细致的复盘，要清楚的表达意图不能引起歧义。另外用户对于“程度”的感觉并不敏感，最初使用的1-7分打分的方法恐怕不如用口语文字单选来的清楚直观。如：特别困难，比较困难，不困难也不简单，比较简单，特别简单。

访谈

不要被访谈提纲束缚了手脚，刚开始容易强行照着问题的顺序去走，往往会忽略了用户谈的内容，有时他们已经覆盖了部分你后续要提到的问题，有时他们要谈一个你没有列入其中却十分有用的问题。

访谈提纲是需要被内化的内容，因为大部分时候你都应当跟着用户或跳跃或深陷的思路去走，看看那里有什么需要的东西，同时又要保持清醒，一旦内容无益就要借机讲用户拉回到主流程的话题里去，这对于我来说在开始时有一丝丝困难（毕竟本人痛恨打断别人说话的行为），不过随着实践的增加，尤其时间控制的情况下要求谈话价值最大化就不得不做一些这样的行为。

带着设计意图去问，不只要知道哪里不对，更要知道用户接到一个任务是如何初始化的，如何思考，如何尝试的，反而他的意见有时并不和他的做饭一致。需要甄别。

另外：

• 记得模拟几遍，会发现提纲的疏漏并淡化它角色。
• 要有一个记录员，除了记录用户的问题主要要记录访谈者的错误和不当。

总结

常态化

受各种各样的用户的反馈所启发，我发现在在做设计两三年后，反而缺失的是当初的那份对于用户体验细致和小心，更多的关注的商业模式，闭环等等热炒的名词，即使在产品初期我们更关注某些价值层面的东西，通过精简的可用性测试（15分钟）和访谈（15分钟）也能发现初期绝大部分问题（Nelson早就说了5个测试用户就能发现80％的问题）。

此番过后，我决意手中的各个产品都要经过哪怕最减短的测试和访谈，必然会使产品有长足的进步。

遗憾

由于本次可用性测试的松散性，没有经过用户筛选的阶段，部分产品实施人员和主管人员并不关注易用性问题，在他们看来产品要培训、有说明书都学会的。

在显性问题尚未解决的前提下，眼动测试略显形式主义，因为在访谈和观察中可以粗放的了解用户对于任务的操作预期。另外在眼动结果的数据分析上方法准备并不充分。

另外在组织层面：

• 分组执行的好处在于明确职责，坏处是沟通成本过高，尤其是缺乏统筹的情况下。
• 方案可以讨论，决策并不需要讨论， 决策人应当明确。
• 对细节的讨论是必要的，但是和更聪明的人共事有助于减少对所有细节可能性的讨论，因为在执行层面遇到的问题需要人们有主动解决的能动性，此处需要明确主动性的范畴。