树测试是把导航化成纯文字目录，让用户根据一个具体任务逐层寻找位置。它要回答的是“这个栏目名和层级能不能把人带到正确地方”。开始前准备一棵完整到目标层级的目录树、没有答案提示的任务，以及提前约定的正确终点；测试时记录第一次选了哪里、是否回退和最终停在哪里。
已经整理好帮助中心栏目后，可以在白板中整理导航树与查找记录，让产品、设计和客服共同确认要验证的疑点。白板用于准备和分析；面向参与者的材料应尽量只保留可逐层展开的文字目录，避免颜色、图标或正确路径标注提示答案。
分类方案已经有了，接下来验证用户能否找到
如果团队还不知道哪些内容应该放在一起，可以先做卡片分类。当候选栏目与名称已经形成，树测试才有可验证的对象。NN/g 的树测试方法也区分了这两类工作：前者帮助发现可能的分组，后者用任务评估既定层级的可寻性。
本次假设要调整一款团队协作产品的帮助中心。争议并不是导航栏用横向还是侧边形式，而是新管理员会去哪里找邀请同事的方法，以及用户会把删除文件的处理办法归到账号还是项目。下面的目录、任务和查找记录均为教学示例，不是真实用户研究数据。
参与者应具备任务所需的背景。例如，本例应招募曾参与团队协作、能够理解成员与项目区别的人；开票任务则需要有购买或费用处理经验的角色。把完全不了解业务的人混进来，再把所有找不到归因于栏目命名，会得到错误解释。
把导航写到能承载任务的终点
目录树可以先用缩进文本整理。保留目标分支旁边真实存在的相邻栏目，否则参与者可能靠排除法猜中。以下四个一级栏目下的末级条目，都代表帮助内容的可选择位置。
帮助中心
账号设置
登录与安全
重置密码
更换登录邮箱
团队管理
成员与权限
邀请成员
调整成员角色
项目使用
文件管理
恢复删除文件
转移文件归属
费用与票据
账单管理
下载付款凭证
申请发票给每个末级条目分配稳定的编号，例如邀请成员为 M01、恢复删除文件为 P01、申请发票为 B02。编号留在研究记录里，不展示给参与者。改名称以后仍能关联到同一条内容，不必靠文字猜哪一页是旧版的对应项。
注意工具怎样定义“选中终点”。有的树测试界面只允许选择末级项；如果你的真实网站在“文件管理”这个父栏目就有一篇概览，测试材料却不给它任何选择入口，用户的合理答案会被漏掉。要么补出代表概览的末级项，要么使用允许父节点作为答案的测试方式，并在开始前写清楚。
同一内容确实有两个入口时，可以预先接受两个终点。不能测试后才把大量错误终点改成“也算对”。如果参与者选中的地方按目前目录并不能提供所需内容，就先记录为未到达，再把“这个地方也应该有入口”留作设计假设。
任务描述用户的处境，不复述菜单名称
“请找到邀请成员”几乎把 M01 的答案交给了参与者。更好的任务提供目标与必要背景，让他自己决定从哪个类别进入。任务不需要写成长故事，也不要加入对路径无关的信息。
| 任务编号 | 展示给参与者的话 | 研究者预设终点 |
|---|---|---|
| T1 | 新同事入职了，你希望他能进入现有的协作空间一起工作。你会在哪里查操作方法？ | M01：邀请成员 |
| T2 | 你刚误删了项目中的一份文件，希望把它找回来。你会在哪里查看办法？ | P01：恢复删除文件 |
| T3 | 公司本月已付款，现在需要一张带公司抬头和税号的正式票据。你会在哪里查办理方法？ | B02：申请发票 |
T3 特意说明了票据用途和内容，因为“查付款记录”可能合理地指向下载付款凭证。若两位试读者对任务目标理解不同，应先改任务，而不是把其中一种理解判错。试读可以请不参与导航设计的同事完成，但正式研究仍需招募符合目标角色的人。
主持时可以统一说明：“请逐层查找你认为能够完成这件事的位置。可以返回，也可以说找不到。这是在检查目录，不是在考你。”不要补充“你再去团队那一栏看看”。如果参与者询问某个名称是什么意思，让他按自己的理解继续，并在结束后追问含义；当场解释会改变测试对象。
每个任务从收起的目录开始，记录完整走法
开始前用一个无关的练习任务，让参与者知道怎样展开、返回和提交答案。正式任务每次回到同一初始状态，不保留上一题展开的分支。任务顺序可以在参与者之间调整，减少先做某题带来的目录熟悉度影响。
主持式测试可把纯文字目录放进逐层可点击的原型，或由主持人按参与者选择展开纸面目录。应让参与者主导选择，而不是让主持人一边介绍一边带路。使用专门研究工具时，则先检查它是否准确记录返回、首个分支和最后答案。
记录至少包含匿名参与者编号、任务编号、树版本、首个一级栏目、完整路径、最终节点和是否放弃。若同时记录用时，约定起点是任务出现还是读完后开始，终点是点到节点还是确认提交；几种口径不能混在一张表里。主持人中途解释或设备卡顿，也要记为备注。
下面用 T1 的四条示例轨迹演示编码。箭头表示进入，回到上层也写出来，避免把绕路后的成功误看成一开始就找对。
| 记录 | 实际选择路径 | 编码 |
|---|---|---|
| S01 | 团队管理 → 成员与权限 → 邀请成员 | 直接成功 |
| S02 | 账号设置 → 登录与安全 → 返回根目录 → 团队管理 → 成员与权限 → 邀请成员 | 间接成功 |
| S03 | 项目使用 → 文件管理 → 转移文件归属 | 未到达正确终点 |
| S04 | 团队管理 → 成员与权限 → 邀请成员 | 直接成功 |
为这次研究约定：直接成功是未进入错误分支、未回退便确认正确终点；间接成功是经过探索或回退后确认正确终点。最终点错和放弃分别保留，便于区分“确信自己找到了”和“知道自己没找到”。这些编码定义要与所用工具一致；工具对 directness 的算法不同，就保留原始路径并注明差异。
把最终选对与一路找对分开看
上述四条示例中，最终成功是 3/4，直接成功是 2/4。这里仅用小样本演示两种计数的差别，不能把它当成真实帮助中心的成功率，也不能由此宣布新版提升了多少。
先按任务查看路径，再看总计。邀请同事的任务绕路，并不意味着整个目录失败；找回文件表现顺利，也不能抵消开票任务的持续误入。NN/g 对导航评估方法的说明强调将信息架构与界面表现分开判断。对本例而言，第一次进入账号设置提示了分类预期，而最终仍能找到说明用户可能依靠后续标签修正了方向。
小规模主持研究适合发现这种误解及其原因，不适合据几个参与者的百分比比较两个方案优劣。需要衡量整体表现或版本差异时，应按研究目标规划样本与统计分析，同时保留用户角色、招募条件和每题有效样本数。没有一个适用于所有产品的“达到某百分比就能上线”标准。
一次只改有证据支持的名称或归属
如果正式记录中反复出现 T1 先选账号设置，可以在完成任务后追问：“你在这里原本期待看到什么？”假如回答集中在“同事的账号也是账号”，团队可以提出两个候选：把“团队管理”改成“团队与成员”，或者在账号相关帮助中补充通往成员管理的入口。单凭一次误点，还不能判断是哪种改法有效。
把修改写成一条可追踪的记录：“T1 出现账号设置首选 → 假设团队管理未表达成员协作 → V2 只把一级名称改为团队与成员，其他位置不动 → 下一轮观察首选分支与回退情况。”这比一句“优化导航文案”更容易验证。若同时更名、移动层级和删减栏目，就很难知道变化来自哪里。
比较两棵候选树时，尽量让不同但条件可比的参与者分别看到一个版本，避免前一次任务教会后一次答案。小规模探索可以先验证任务是否清楚，再安排更正式的比较。重新测试时保留同一任务目标和终点定义，同时记录版本变化。
树测试结束后还要把选定结构放回真实界面：用户能否看到入口、窄屏展开是否清晰、搜索是否抢走注意力，都需要另行观察。交付一棵带版本号的目录、三类任务脚本和逐题修改依据，就能让后续界面设计有明确起点。更多研究与界面方法可在UI/UX 设计专题中衔接。
