重叠的信息类别和令人困惑的标签网站设计中两个最普遍的问题. 幸运的是，有快速有效的技术您可以用来创建对观众来说是有意义的类别和标签。
最著名的技术可能是卡片分类，其中向用户提供了一个具有代表性的内容项列表，用户可以根据自己的需要对这些内容项进行分组和标记。卡片分类对于理解用户的想法是非常有用的，但它并不一定会产生你应该遵循的精确分类方案。例如，卡片分类的参与者经常创建一个通用类别来存放一些似乎不适合放在其他地方的物品;这是可以理解的，但如果你在菜单中包含“其他内容”类别，同样的用户会像躲避瘟疫一样避开它。(众所周知，网站访问者不愿点击模糊的标签，因为他们很有理由怀疑，他们需要做很多工作来筛选内容。)
为了获得最佳结果，卡片排序之后应该进行树测试，以评估提议的菜单结构。
定义：A树试验通过让用户在树中找到可以完成特定任务的位置，评估层次类别结构或树。
树测试作为卡片分类的后续非常有用，因为它:
- 根据它在真实场景中的执行情况，使用类似于可用性测试的任务来评估层次结构;和
- 可以在设计页面布局或导航菜单之前进行良好，允许菜单类别和标签的廉价勘探和改进。
要执行树测试，不需要绘制任何线框或编写任何内容。你只需要准备两件事：第一件树，或层次菜单，以及的任务,或者解释参与者应该试图找到的指示。
定义树
您的树应该是所有主要内容类别的完整列表，以及所有子类别。即使您有兴趣仅对树的特定部分进行测试，除了其他部分是有风险的，因为它假设用户将知道要转到哪个部分。例如，如果您的网站有一个产品A.服务类别，你选择只测试产品树，你会错过寻找你的观众是否了解这两类之间的差异。
根据您最感兴趣的层次结构的哪个部分，您的树可能需要深入3,4甚至5级。将完整的深度包括到您要测试的最低级别的子类别。每个子类别都应在该区域中提供所有选项的完整列表，以便从用户引出现实行为。用户通常通过将其与附近的替代方案进行比较来评估链接标签。例如，对历史感兴趣的用户可能会尝试标记的类别培养-但如果还有其他选择的话历史资源。
竞争树测试：标签与位置
如果正在考虑为同一树类别使用不同的标签，则可能需要测试两个不同的树，以便比较术语的性能。这样的测试尤其容易进行Userzoom.'树测试工具，允许您随机将参与者随机分配给树的不同版本，以类似于的方式A / B测试在一个在线网站上。如果你测试多个树，避免在同一会话中向同一个用户显示两棵可选树——用户在与第二棵树交互时的行为会被第一棵树的体验所扭曲。
如果您只想比较不同，无需准备和测试单独的树地点对于标签-例如是否西红柿应置于水果或者蔬菜您可以测试一棵树并比较单击的用户数，而不是为每个位置测试两棵不同的树水果vs.点击多少蔬菜．（如果他们单击两者，你也能够讲述他们首先尝试的类别。）
准备测试:工具和格式
你可以使用纸上原型(或任何可点击的原型工具)进行树测试，但专门为树测试设计的服务将大大加快分析结果的过程，这是非常值得的。Userzoom.和tree都是进行树测试的好选择。
在电子表格中准备您的树，在那里您可以轻松地可视化和编辑它，然后简单地将整个层次结构复制并粘贴到树测试工具中。电子表格应在列A的顶部单元格中使用主页格式化，然后在左右列出列中列出的较低级别。确保仅列出每行的一个类别，以便导入层次结构时，您的级别将被正确解析。
将Shierarchy粘贴到测试工具中，分类已解析并用于自动创建可点击的菜单层次结构，其中可以扩展每个类别以显示相应的子类别。
树测试任务
您要求用户完成的任务与树本身一样重要。首先，您需要决定针对哪些类别和标签。理想情况下，您应该包括针对以下目标的任务：
- 关键网站目标和用户任务，如找到最重要的产品（主要导航任务中的成功率可以作为基准，以便您可以比较次要任务，以及未来测试的参考点。）
- 潜在的问题领域，例如在卡片分类中由利益相关者或参与者提出的新类别
标签或位置比较- 与相同类别的任何备用标签或位置。对于您编写的每个任务，您还应定义正确的答案，对应于该信息在树中的信息。此信息允许测试工具自动计算每个任务的成功率。
任务措辞
每个任务都应该测试一个类别标签，要求用户查找该类别中包含的内容。与可用性测试任务一样，树测试任务说明应避免使用泄露答案的术语．防止兴奋有时可以通过描述情景和动机来实现，而且还可以记住，如果他们在冗长的故事中被埋葬，用户可能无法仔细阅读指令。
作为一个例子，这里有一些不同的短语来评估开展业务新墨西哥州政府树上的类别（上面描绘）：
- 查找有关创业的信息。
- 明年你将搬到圣达菲，一旦你来到这里，你想通过开设一家提供草坪护理服务的副业来补充你的收入。了解您需要遵守哪些规定。
- 您正在考虑开设草坪护理服务。看看这个网站上有任何资源，可以帮助您开始进程。
第一个例子给出了答案通过使用确切的标签术语，开展业务; 而第二个很长，而且充满了无关的单词，如果用户快速扫描，很容易将其误认为是任务的重点。第三个选项避免了标签术语和误导性细节。
树测试的局限性
树测试通常作为远程测试执行，未修改学习。后招聘代表用户，你只需给他们发送一个研究链接，测试工具就会引导他们使用自己的电脑完成任务。在跟踪用户点击的具体类别方面，测试工具要比人类好得多。
但是，这种格式不能捕获用户行为的全部上下文(例如执行任务时所作的注释)，而且您不能问个性化的后续问题。
为尽量减少格式的影响，请至少进行几次调整试点会议在收集大量数据之前。在这些调节的会议中，你可以确保任务措辞是可理解的，也有机会捕捉到可能很难在定量数据中发现的细微差别。例如，在最近的树测试中，我们注意到许多用户在会话的前半部分避免使用某个类别，因为标签太宽了，他们担心内容会让人不知所措。由于任务顺序的随机化，这种趋势在定量结果中并不明显，但当你坐在每个会话中，看到一个又一个任务，用户忽略了一个明显的选择时，这种趋势就非常明显了。仅凭这一点就使飞行员测试的一天过得很好。
您还可以在树测试后加入一个简短的调查，部分弥补无法提出后续问题的不足。与其要求用户召回任何他们发现混淆的标签，不如向他们提供标签列表，并要求他们检查哪些标签难以理解。这个问题可以用一个开放式问题邀请用户分享任何进一步的评论和反馈，以引出可能在点击历史记录中不明显的意外假设或误解。
结论
树测试只专注于评估类别标签。这既是它的强大之处，也是它的一大弱点。因为与用户交互的菜单完全没有视觉样式和内容，所以与完整的设计交互的体验是截然不同的。例如，一个设计Mega菜单提供与在树测试中测试的浏览体验完全不同的浏览体验，因为它同时显示多个子类别的内容。
然而，即使是这些固有的限制，也可以通过仔细的数据分析来克服或最小化——例如，通过关注用户是否选择了正确的顶级类别，而不是关注具有超大菜单的站点的成功率。
总的来说，这些限制是一个小的代价，因为迅速能够迅速迭代和评估设计过程早期信息层次结构的主要结构变化。您可以通过编辑电子表格来创建一个全新的树来测试 - 绝对没有必需的设计或编码。
分享这篇文章：