总结：遵循这些提示可以有效地评估一个网站的导航层级，并避免常见的设计错误。
在网站设计中，重复的信息类别和令人疑惑的命名是两种最常见的设计问题。幸运的是，有一些快速和有效的技术可以用来创建对用户有意义的类别和命名。
卡片分类法也许是最著名的技术了，向用户提供一组有代表性的内容项，让用户按照自己认为合适的方式分组并命名。卡片分类法在理解用户如何思考方面有着难以估量的价值，但是它不一定会产生你应该遵循的最合适的分类。比如说，卡片分类的参与者常常会创建一个通用的分类去放置那些放在其他地方都不合适的项目，这是可以理解的，但是如果你真的把一个“其他”类别放在菜单中，同样的这群用户却会像躲避瘟疫一样避免去点击它。（众所周知，网站访客一般会避免点击那些表意模糊的类别，因为他们非常合理地怀疑他们需要做很多工作去过滤其中的内容。）
为了得到最好的结果，在卡片分类之后应该做一个树形图测试来评估备选的菜单结构。
定义：树形图测试通过让用户在树形图中寻找在哪个位置能够完成给定的任务，以此评估一个层级分类结构，也就是一个树形图。
在卡片分类之后使用树形图测试会非常有用，因为：
- 它通过使用类似于可用性测试中的任务来观察一个层级结构在真实场景中的表现，从而对其进行评估；
- 它可以在开始设计页面布局或者导航菜单之前进行，因此可以对菜单类别和命名进行低成本的探索和调整。
要执行一场树形图测试，你不需要绘制任何线框图或者写任何内容。你只需要准备两种东西：树形图，即层级菜单，以及任务，即用于向研究参与者解释他们需要找些什么的说明文字。
定义树形图
你的树形图应该包含你的所有主要内容分类，以及它们的所有子分类。即使你只对树形图的某个特定部分的测试感兴趣，也不应该排除掉其他部分，因为这隐含了用户知道应该选择哪个部分的假设。比如说，如果你的网站有一个“产品”分类和一个“服务”分类，而你只选择测试“产品”树形图，你就无法发现你的用户是否理解这两个类别之间的区别。
你的树形图可能需要3个、4个甚至5个层级之深，取决于你最感兴趣的是层级结构的哪一部分。树形图应该包含到你想要测试的子分类的最低层级。每一个子分类都应该提供其包含的所有选项，以便观察到用户的真实行为。用户通常会通过与周围选项的比较来评估一个链接的标签名。比如说，对历史感兴趣的用户可能会尝试点击一个叫做“文化”的分类——除非同时有一个叫做“历史资源”的选项。
竞争性树形图测试：命名还是位置
如果你在考虑同个树形分类的不同命名，你可能想要测试不同的树形图以便比较这些名称的表现。这种测试用Userzoom的树形图测试工具就很容易做，可以把参与者随机分配到不同版本的树形图中，类似于真实网站中的A/B测试。如果你测试多个树形图，要避免在同一个会话中向同一个用户展示两个不同的树形图——用户在于第二个树形图交互时的行为会受到第一个的影响而产生偏差。
如果只是想要比较命名相同而位置不同的两个方案——比如说“土豆”应该放在“水果”还是“蔬菜”类别下，没有必要准备和测试一个单独的树形图。不需要对两种位置的树形图都进行测试，你可以只测试一个树形图然后比较有多少人点击了水果以及有多少人点击了蔬菜。（如果用户两个都点击了，也可以区分他们首先点击的是哪个类别。）
准备测试：工具和格式
你可以使用一个纸面原型（或者认可可点击的原型工具）进行树形图测试，但是一个专门为树形图测试而设计的工具将会极大地促进结果分析过程，值得一试。Userzoom和Treejack都是不错的工具。
在电子表格中准备好你的树形图，你可以方便地查看和编辑，然后将整个层级复制粘贴到你的树形图测试工具中。电子表格应该格式化，首页应该在第一列的第一个单元格，然后将较低的层级按列从左到右列出。确保每行都只展示一个类别，这样子你导入这个层级的时候才能被正确解析。
将你的层级粘贴到测试工具中之后，这些类别会被解析并用于自动生成一个可点击的菜单层级，在这个菜单层级中每一个类别都可以展开并展示相关的子类别。
上图是Treejack根据电子表格自动生成的可点击的菜单，包含了所有类别和子类别。
树形图测试任务
要求用户完成的任务跟树形图本身一样重要。首先你需要决定目标类别和命名。理想情况下应该包含指向以下目标的任务：
- 网站的关键目标和用户任务，比如寻找你们最重要的产品（首要的导航任务的成功率可以作为次要任务的对比基线，以及未来的测试中的参考值）。
- 潜在的问题区域，比如利益相关者或者卡片分类的参与者所倡议的新类别。
命名或者位置对比——同个分类的不同命名或位置。对于你写的每一个任务，都应该定义正确的回答是什么，也就是这个信息实际上位于树形图的哪个位置。这个信息让测试功能能够自动计算出每个任务的成功率。
任务措辞
每一个任务都应该通过要求用户找到某个类别包含的某个内容来测试一个类别。正如可用性测试中的任务，树形图测试任务的说明应该避免向用户提示正确答案。有时候可以通过描述一个场景和动机来避免这种暗示，但是仍然要注意用户不一定会认真读说明，如果要阅读一个冗长的故事他们可能会错过重要的细节。
举个栗子，要测试墨西哥州政府网站上的一个叫做“创业”的类别时，可能有以下几种不同的措辞：
- 寻找关于创业的信息。
- 你明年要搬到圣达菲，你到了之后想要通过开创一个副业提供草坪护理服务，以此增加自己的收入。寻找你可能需要遵循的条例。
- 你在考虑开创一个草坪护理服务。看看网站上是否有可以帮助你开启项目的资源。
第一种表述直接使用了“创业”这个词语，已经把答案呈现出来了；而第二种表述很长并且包含了一些无关的信息，用户没有认真看的话可能会误以为那是任务的重点。第三种表述能够同时避免提示答案和误导性的细节。
树形图测试的局限
树形图测试通常是作为一个远程的、非调节的研究。在招募到有代表性的用户之后，可以简单地向他们发送一个链接，然后测试工具就会引导用户使用自己的电脑完成任务。测试工具比人类更擅长关注用户具体点击了哪个类别。
但是，这种形式不能捕捉到用户行为的完整情境（比如用户在做一个任务时的评论）并且你无法根据用户的情况问问题。
为了最小化这种影响，可以在正式收集数据之前进行至少几个调节的预测试。在这些调节的测试中可以确保任务的措辞是可理解的，并且有机会发现在定量数据中很难发现的细微差别。比如，在一个最近的树形图测试中，我们发现在预测试中很多用户在前一半任务中都避开了一个特定的类别，因为它的命名太宽泛了，用户担心其中的内容太多。这个趋势在定量结果中无法观测到，因为任务的顺序会进行随机，但是当你能够亲眼看到用户在一个接着一个的任务中忽略了一个很明显的选项时，这件事情就很明显了。仅仅是这个洞见就使得预测试的一天值得花费。
你也可以通过在树形图测试之后添加一个简短的问卷，可以部分地弥补无法在测试之后询问问题的损失。比起要求用户回想他们觉得令人困惑的分类，向他们提供一个类别列表并让他们检查哪些比较难以理解，可能会更好一些。可以在最后添加一个开放性问题，让用户分享更多的评论和反馈，以发现从点击记录中无法明显看出的非预期的假设和误解。
结论
树形图测试专注于评估分类标签。这既是它的巨大优势，也是一个明显的弱点。因为用户交互的菜单完全没有视觉设计和内容，体验会与跟完整设计的交互明显不同。比如，一个多栏下拉菜单（mega menus）提供的浏览体验就会跟树形图测试中的很不一样，因为它会同事呈现多个子类别中的内容。
但是，即使是这些固有的缺陷也通常能够通过仔细的数据分析得以避免或弱化——比如，对于多栏下拉菜单来说，我们可以关注用户是否选择了正确的一级类别，而不是关注人物的成功率。
总之，这些局限都是为了能在设计过程的早期快速迭代和评估信息架构的关键结构调整而需要付出的小小代价。你可以测试一个全新的树形图，仅仅通过编辑你的电子表格——完全不需要设计或者编码。
翻译自：Tree Testing: Fast, Iterative Evaluation of Menu Labels and Categories
