Nielson主要针对信息架构中的信息分类测试方法——卡片分类法，提出实际测试中可能经常出现的问题，并给出了较好的建议。所关注的问题在于：如何提高卡片分类测试的测试效果？卡片分类是信息分类可用性测试中较为理想的方法：让用户主导分类，具体做法是：用户按照自己的思路或直观感觉，把卡片归入已知的或由用户自己新建的类别里，以发现用户对于此类信息的心智模型，并检验事先假设是否直观合理，从而优化信息架构，提高信息浏览或检索的可用性。

Nielson写这篇文章的目的在于说明：卡片分类只是一种科学合理可用性测试方法，但要达到最佳的效果，操作时还需注意几点原则：

不要告诉用户完成任务所需要的具体操作名称； 例如：测试del.icio.us的导入书签功能。如果告诉用户：“你的常用浏览器中收藏了很多书签（bookmarks），你希望能在 del.icio.us中使用它们，现在把它们导入（import）进来。” 更有甚者：“使用导入书签（import bookmarks）命令导入你的浏览器本地收藏夹”。由于事先被告知了“import”和“bookmarks”这两个词，用户可能会直接在页面中扫 描，或者打开几个菜单，试图找到“import”和“bookmarks”字眼，然而这样就无法测试出“import”和“bookmarks”两个单词 的措辞是否合理，是否符合用户心智模型。可能对于一部分用户来说，更习惯用“favor sites”而不是“bookmarks”来表述收藏夹中的网站。所以最好使用类似下面的措辞：

“你的常用浏览器中一定有不少收藏，现在完成一些操作，让你在del.icio.us中也可以使用它们。”

这 样，喜欢“favor site”而对“bookmarks”不熟悉的用户可能就会想：“favor site” 在哪？……没有，那页面中出现的这个“bookmarks”是否就是我的“favor site”？此时，如果用户不喜欢尝试，或者不能迅速地把两个单词联系到一起，就有可能完不成任务，“bookmarks”可能就要换成其他什么 词，“import”也一样。正如Nielson所说：

“如果你告诉用户该用哪个，他们就永远不能以自然的方式使用软件。只会按照你告诉他们的去做; 而不是他们通常会怎么做。”

因此，测试的时候，不要告诉用户完成任务所需要的具体操作名称。给出这条原则是为了说明卡片分类测试常会遇到的一个问题：关键词匹配。Nielson通过一个case说明：如果对卡片上的关键词设定了某些过度明显的取向，可以大大增加用户分类成功的概率，但这样往往起不到较好的效果。例 如“番茄酱”、“番茄派”、“番茄汉堡”能够很容易地被分到“番茄”类中；而“番茄派”、“草莓派”、“香芋派”则轻易地被分到“派”里。到此有些设计者 就会说：“看，我成功了，因为用户们都分对了类！而且他们分得很快！” 而事实上，这样的分类没有任何挑战性，如果用户想都不想一打眼就能正确分类，那这种测试就没有意义了。“卡片分类不是设计用户界面，是一场关于知识的启发 式演习，用于发现的用户心智模型。” 一般情况下，当设计师对关键词难以取舍、模棱两可，或对专家词汇抱有疑虑的时候才找来用户进行卡片分类测试的。因此，为了优化关键词，我们希望用户能够 “略微驻足思考一下下，而不是简单地尽快完成任务”。当然思考也不能过长，以至无法完成任务。那怎样选择合适的关键词来提高卡片分类的测试效 果？Nielson给出了两点建议：

1. 使用同义词。 使用多组同义词替换测试，或交叉组合测试。如，测试一组同义的动词1，2，3，或同义的名词a，b，c，或在需要组合的时候测试“1+b”,“2+a”等等。多组同义词测试有利于发现用户心中最合适的分类名称。
2. 使用非并行结构。使用一组并行结构的词会人为降低分类难度，例如“购买商品”、“卖出商品”、“查询账单”，由于结构并列，没有干扰因素，使测试用户能够不假思索就正确分类，起不到卡片分类应有的效用。而“我要购买”、“卖出商品”、“账单查询”则拥有非并列结构，增加了一点难度，使得测试用户能够先思考一下具体意义，然后再理性地做出判断。

（对于第二点，起初我的理解与原文有较大偏差。事实上，易用性不是卡片分类测试的重点关注因素，人为降低一点易用性对理性和逻辑的分类是有帮助的，这是此篇文章的主旨。 在此感谢提出质疑的wendy同学，并向之前看过此篇博文的朋友表示歉意！）

总结：

• 做可用性测试只有保持中立的态度，使用中立的语言，才有可能发现更多潜在的问题；
• 卡片分类的主要任务是发现用户心智模型，在多组备选条目中找到最佳的表述，并找到正确的分类方式；不是单纯验证设计师分类的正确性，满足成就感。

结构 — structure，指页面之间信息的构成关系，是传承，细化，展开，追溯，交织等等。是p2p，page to page。重在强调每次action之前中后的信息变化关系，以及每“套”action之间的信息交互和对整体信息的影响，创造并维持用户思维逻辑上的体验流。

结构位于框架的下一层，结构的设计是需要早于框架的，但并不在着手框架之前就确定下来，而是需要测试，并且不断迭代。框架层发现的问题，有时并非一点trick就能摆平，可能需要调整结构才能得到真正解决。

眼动仪测试的多是框架之上，（包括框架和视觉）的好坏，鼠标点击热图体现的则侧重于结构的优劣，但框架和视觉往往也会对鼠标点击造成影响。 因此，在分析究竟是框架出了问题还是结构出了问题的时候，需要多方面考虑。

如果你精心设计了结构或是一个流程，并在页面上留了一个入口，但眼动仪显示它根本没有驱动用户的眼球，或是没有足够的吸引力，或是听到用户说：我想做什么什么，但却找不到它。而它确确实实就藏在某个被你玩躲猫猫的位置上，那这时基本可以定性为框架问题。剩下的，就是修改布局，大小，颜色，以便勾起用户产生交互动作的欲望。

如果用户告诉你：我迷路了，快带我出去。或，该死，我回不到刚才那里了。亦或是用户在一个大门前迟疑了很久，因为他根本不知道进去之后会出现什么，或不能完全确定是否与自己预想的一致。这时，可以说结构上的问题就出现了。即便是由于按钮上的文字表达不明而引起的歧义或是疑虑，那也是因为设计结构时，结点的信息传达没有考虑周全。布局和颜色的作用应该与语言表达的作用分开，因为注意到了并不等于就理解了。“注意到没”应该属于框架设计的考虑范畴，而“理解了没”应该归入结构设计的考虑范畴。