点石成金第8、9章

一个喜欢犁田，另一个喜欢放牛，但他们没有理由不能成为朋友。

我们建行网站的人都有一个共同点——我们也是web用户，而且我们似乎对网站上自己喜欢什么、不喜欢什么都有着强烈的感觉。由于这样主张的力量，还有人的天性 ，当我们处在一个web团队中时，事实证明很难保证不把这些感觉牵涉进来，投射到整个web用户身上。

在这种个人情绪的表面上，还有另外一个层次的问题：职位情绪。不同的职位对网站设计有着不同的看法，但是，当建立设计优先级时，他们在看法上的不同常常引发冲突和强烈的感觉。
这种艺术和商业持续矛盾的网络版对任何可用性问题的讨论增加了另一个层次的复杂性——从市场文化那边下达的武断指示。

大部分web用户和我们一样，还有另一个隐藏得更深的信仰：相信大部分web用户是弹性的，可以随意变化。一般人会想要找出所谓的普通用户来确定绝大部分用户的喜恶，但是，并没有什么普通用户，反而是这样的：

所有web用户都是独一无二的
所有web用户都是不一样的

对于大部分web设计问题业说，没有简单的正确的答案，良好的、一体化的设计能满足需求，也就是说，经过仔细考虑，实现和测试的设计就是好的。你必须使用团队的集体技巧、经验、创造性和判断力来建立一些版本，然后仔细观察人们对它的看法和用法。

为什么我们没有早一点这么做？在网站的第一次可用性测试过程中，每个人都会这么说。

有的时候，可用性测试能平息这种争论，但通常它所起的主要作用是证明他们正在争论的问题根本没有那么重要。

1. 焦点小组和可用性测试是有区别的 ：

• 在焦点小组中，组员会抽象地确定你的目标受众想要什么，需要什么，喜欢什么的时候可能会很有用，通过焦点小组可以快速得到部分用户的意见和感觉，但它们不适合用来了解网站的运行情况以及怎样改进网站
• 在可用性测试中，会看到人们真正的使用情形 ，并通过观察用户的行为 ，检测到哪些让用户混淆和倍感挫折的地方 ，并修复它们

2. 关于测试的几个事实

• 如果想建立一个优秀的网站，一定要测试，找出它是否动作正常，这是唯一方式
• 测试一个用户比不做测试好一倍。哪怕用错误的用户做一次最糟糕的测试，也会让你看到一些重要的地方来改善网站
• 在项目中，早点测试一位用户好过最后测试50位用户。早点做一次简单的测试，在你还有时间用上你的测试所得的时间，总是比以后 进行一次复杂 的测试更有价值 。web开发，很容易开始，但修改起来就不那么容易了，所以任何在开始时就有助于防止 你犯错误 的方法都很划算。

可用性测试的基本理念：如果你想知道某个东西是否容易使用，那么在一些人试图使用的时候观察他们，记下他们在哪里遇到问题。

3. 关于DIY可用性测试：更加简单、便宜的可用性测试

微信图片_20170831201321.jpg

4. 关于测试周期
   每个web开发团队应该每个月安排一个上午进行一次可用性测试，原因：

• 这样保持测试简单，所以你们能坚持进行。
• 这样能满足你们的需要。
• 这样就不需要决定什么时候测试。
• 这样人们更可能参与进来。

5. 关于测试用户数量
   每轮测试的理想用户数量应该是3个，原因：

• 这类测试的目的不是为了证明任何东西。DIY测试是一种 定性的方法，它的目的是通过发现和修复可用性问题来改进正在建行的东西。
• 你不用发现所有的问题。一个半天的测试，就能让你发现 太多的问题，一个月都修复不完，因此，要把注意力集中在首先修复最严重的问题上。

6. 关于测试参与者的选择
   如果能请到非常接近目标用户的参与 者来进行可用性测试，也很好。推荐另一种方式：宽松招募，曲线上升。——去寻找能反映你目标群体的测试用户，但是别因此裹足不前。

如果使用你们的网站需要了解一些特定的专业知识 ，那么你需要招募一些了解这些知识的人。

可以 使用一些并不是目标用户的测试参与者，原因：

• 设计 出的网站只有你的目标群体才能使用，这通常并不是一个好主意。在很多 情况 下，不管怎样，你需要满足卖家也同样需要满足新手。
• 在内心深处，我们都 是初学 者。
• 专家通常不会介意 对初学 者来说很清楚的界面。

7. 关于测试过程
   一个典型 的一个小时测试应该包括以下部分：

• 欢迎部分
• 提问部分
• 主页“观光”
• 任务测试
• 问题探查
• 结束部分

8. 关于在测试中会遇到的几个问题

• 用户不清楚概念
• 他们找不到自己要找的字眼
• 内容太多了。在这种情况下，需要（1）减少页面上的整体干扰；（2）把他们需要看到的内容设置 得更加醒目，让它们在可视层次结构中更加突出

9. 关于总结舍：决定修改哪些问题

最严重的问题最先修改

决定方法：

• 收集一份问题列表，每个人说出最严重的3个问题，必须 是观察到的问题
• 选择10个最严重的问题。
• 问题评级
• 建立一份排序列表

决定时的建议：

• 对那些够得着的果子，建立 另一份清单
• 抵制添加的冲动
• 不要太看重人们对新功能 的要求
• 忽略 皮划艇的问题

10. 其他两种测试方法

• 远程测试
• 无人主持的远程测试