魔琳人生-路漫漫其修远兮

接着上面的内容~~~

第八章 农场主和牧牛人应该是朋友—为什么WEB设计团队讨论可用性是在浪费时间，如何避免这种情况

只有他们自己设计的话，WEB团队在可用性问题的决策方面并不是那么成功。很多团队一直在花费大量的宝贵时间一次次地重复着同样的问题。
【作者在这一章的开头就给出了一段连环画，关于WEB设计的。呵呵，很形象。项目经理，设计师，市场专员，开发人员因为一个下拉框的问题来了一场“信仰大战”—因为这种讨论跟大部分的宗教和政治讨论有很多相同之处：它们由大量无法验证的个人信仰组成，大体上是为了在某些重要问题的最好做法上取得一致。而且，它们很少能让人改变他们原来的看法。】
除了浪费时间，这些争论也产生紧张气氛，破坏团队成员之间的关系，常常让团队无法做出关键的决定。
遗憾的是，有一些因素存在于大部分的WEB团队中，让这些辩论几乎无法避免。

“每个人都喜欢___”
我们这些建造网站的人都有一个共同点—我们也是WEB用户。而且，和所有WEB用户一样，我们对网站上自己喜欢什么，不喜欢什么有着强烈的感觉。
从个人角度来说，我们喜欢FLASH动画，因为它很好玩；我们也可能不喜欢它们，因为要花很长时间下载。我们喜欢每个页面左边的菜单；我们可能不喜欢它们，因为它们很枯燥乏味。我们真的喜欢有___的网站，或者，我们发现___真是让人觉得痛苦极了。
事实证明，当我们处在一个WEB团队中时，事实证明很难保证不把这些感觉牵涉进来。
结果往往就是一大堆人待在房间里，每个人都有自己的什么能让网站更好的主张。
而且，由于这些主张的力量还有人的天性。自然有一种把这些喜欢或不喜欢投射到整个Web用户身上的倾向，认为绝大多数Web用户喜欢我们所喜欢的。

农场主和牧牛人
在这种个人情绪的表面之上，还有另一个层次的问题：职位情绪。由于各自的职位不同，WEB团队的成员们对于好的网站设计由什么组成有着非常不同的看法。
以设计师和开发人员为例，设计师通常认为，大多数人喜欢视觉上看来有趣的网站，因为设计师们就喜欢这样的网站。实际上，他们之所以成为设计时，可能就是因为他们喜欢好的设计，他们发现这会让网站更有趣，也更容易理解。
而另一方面，开发人员认为人们喜欢功能多又酷的网站，因为他们喜欢这样的网站。
我无法确定在这样的场景中谁是农场主，谁是牧牛人，但是我确实知道，在机那里设计优先级时，他们在看法上的不同常常引发冲突和强烈的感觉。
同时，设计师和程序员发现他们在另一个更大的冲突面前是站在同一边的，这个冲突就是ArtKleiner描述的市场文化和工程文化。
当市场文化（上层管理、市场、业务拓展）关注于在网站上做出有助于吸引风险投资、用户、战略合作伙伴和赢利的承诺时，实现这些承诺的责任就落在设计师和程序员这样的工程文化人员身上。
这种艺术和商业持续矛盾的网络版对任何可用性问题的讨论增加了另一个层次的复杂性—这种复杂性常常体现为从市场文化那边下达的武断指示。

普通用户的神话
没有普通用户，大部分的Web用户是弹性的，可以随意变化。
事实上，我花了很多时间来观察人们对网络的使用，并且得到一个相反的结论：所有WEB用户都是独一无二的，所有的WEB使用都是不一样的。
对于大部分WEB设计问题来说，没有简单的“正确”答案，良好的，一体化的设计能满足需要，也就是说，经过仔细考虑，实现和测试的设计就是好的。
也并不是说不存在完全错误的方法，有些设计网页的方法的确是完全错误的，只是它们往往并不是设计团队通常讨论的问题。

对于信仰争论的解药
解药的关键是，不要问这样的问题“大部分人喜欢下拉框吗？”正确的问题应该是“在这个页面里，这样的上下文中，这个下拉框以及这些下拉框项目和措辞会让可能使用这个网站的大部分人产生一种良好的体验吗？”
而且，也只有一种方式来回答这种问；测试。你必须使用团队的集体技巧、经验、创造力和判断力来创建一些版本，然后仔细观察人们对它的看法和使用的方法。
争辩人们喜欢什么既浪费时间又消耗团队的精力，而通过测试将讨论对错转移到什么有效、什么无效上，更容易缓和争论，打破僵局。而且，测试会让我们看到用户的动机、理解、反应的不同，从而让我们不会再坚持认为用户的想法和我们的想法一样。

第九章 一天10美分的可用性测试–让测试简单，这样你能进行充分的测试

有时候可用性测试能平息很多内部争论，但通常它的作用是证明正在争论的问题根本没有那么重要。人们经常想通过测试来决定哪种颜色的窗帘最好，却发现他们忘了在房间安上窗户。
可悲的是，这就是可用性测试完成的方式：太少了，太迟了，而且为了错误的理由。

跟我重复一遍：焦点小组不是可用性测试
可用性测试和焦点小组不同
焦点小组：一个小组（5到8人）围坐在桌子旁边，对展示给他们的想法和设计作出反应。这是一个小组过程，主要价值来自于参与人员彼此的反应。焦点小组是快速得到用户意见和感觉的一种不错的方法。
可用性测试：一次一个用户展示一些内容（不管是网站还是网站原型），并且要求说初：这是什么；试着用它完成一项典型的任务。
焦点小组在抽象地确定你的目标受众想要什么、需要什么、喜欢什么的时候会很有用。他们也可以测试出网站的理念是否有意义，价值主张是否吸引人。同时，它们在测试你的网站功能命名，发现用户对你的竞争对手看法等方面，也有很好的办法。
但这种方法不适合用来了解你的网站运行情况，以及怎样改进网站。
你能从焦点小组了解到的是你在设计网站之前就应该了解的。焦点小组是用在这个过程早期阶段的方法。

关于测试的几个事实：
如果想建立一个优秀的网站，一定要测试。为一个网站工作几个星期也会让你失去新鲜感。你了解得太多，测试会提醒你，不是每个人的想法都和你一样，知道你所知道的，和你用同样的方法使用网站。
测试更像邀请外地朋友来参观。不可避免地，当你和他们一起四处游玩时，你会看到平时不会注意到的一些情况，因为你对它们太熟悉了。同时，你也意识到很多你认为想当然的事情，对别人来说却并非如此。
测试一个用户比不做测试要好一倍。测试总会有效果的，哪怕对错误的用户做一次糟糕的测试，也会让你看到一些改善网站的重要方面。
在项目中，早点测试一位用户好过最后测试50位用户。早点做一次简单的测试，总比以后进行一次复杂的测试更有价值。毕竟开始更容易改变。
人们对招募用户代表的重要性估计过高。
测试的关键不是要证明什么或则反驳什么，而是了解你的判断力。
测试是一个迭代的过程。
没有什么比现场用户的反应更重要。

测试其实可以比你想象的简单。

应该测试多少用户
每轮三到四个，论述增加比一轮7到8个好。

宽松招募，曲线上升
关于可用性测试的最大秘密是，测试对象是谁并不重要。
换句话说，要寻找能反映你目标群体的测试用户，但是别因此裹足不前。
除非你的网站几乎只由某一类用户使用，而且找到这样的测试人员并不困难；使用你的网站需要专门的领域知识。
相反，你的测试用户和目标群体之间可以存在差别，理由如下：
实际上，我们都是初学者。
设计出的网站只有你的目标群体能使用，这通常并不是一个好主意。
专家通常不会介意对初学者来说不清楚的界面。

在哪里测试
安静的不受打扰的办公室。
由谁引导
耐心、公正、善于倾听的人。不要选择“非人类”和“办公室狂人”。
谁应该进行观察
整个团队的任何人员以及任何想要观察的人。
测试什么，什么时候测试
关键要在开发的各个阶段及早进行测试，还有经常测试。
甚至在你开始设计网站之前，就应该测试一下同类的网站。可以是实际的竞争对手，或者和你脑海中阻止方式或功能类似风格的网站。
你可以进行两种测试：
“理解”测试;就是让用户看到网站，然后看他们能否理解这个网站，理解网站的目标、价值主张、组织方式、运行方式等。
关键任务测试：让用户完成一些任务，然后观察他们是怎么做的。

立刻回顾测试结果
给问题分类和解决问题

常见的问题
用户不清楚概念
他们找不到自己要找的字眼：组织内容的分类不符合用户的习惯或则没有使用他们期望的名字。
内容太多了：有时候，用户就是找不到页面上的一个内容，这时候应该减少页面的整体干扰或者把重点内容设置得更醒目。

魔琳人生：www.linlife.com