可用性测试任务怎么写？从研究问题到不暗示答案的场景

可用性测试任务应告诉参与者在什么情况下要达成什么目标，而不是告诉他点击哪个按钮。写任务前，先确定想观察的问题，再补齐必要的账号、数据和起点，最后为研究团队写下可观察的完成条件。参与者看到的是场景，研究团队保留的是观察与判断依据。

可以用Boardmix协作白板把研究问题、参与者任务和观察记录并排整理，避免产品、设计和研究人员各自理解一套题目。以下围绕一个城市活动报名网站，写出能直接调整使用的任务卡。

先问要验证什么，再决定让用户做什么

“测试筛选功能”不是充分的研究问题。你需要知道的是：用户能否找到符合时间和年龄条件的活动，在哪里判断条件，是否会误选。只有把疑问具体到行为，才能分清问题来自任务说明还是界面设计。

这些任务对应寻找、查信息和处理已有报名三种目标，不需要每个页面都出一道题。如果研究范围只是取消报名，就应集中验证第三项，而不是为了覆盖功能把全站操作排成一场考试。

NN/g的任务场景方法强调真实情境、可执行动作以及避免透露操作线索。这里的“真实”是符合目标用户的需要，不要求参与者真的付款或产生一笔真实订单。

一张任务卡，分成参与者版和研究版

下面假设测试对象是会为孩子安排周末活动的家长，网站已准备测试账号和活动数据。若实际用户不是这类人，就应更换场景，不能只把称呼替换成“用户”。

任务一：选一个周六上午可以参加的活动

这个周六上午，你想带一名8岁的孩子参加一场活动，中午12点前需要结束。请在网站上选一个适合你们的活动，找到后告诉我你为什么选它。暂时不用报名。

研究团队准备：从网站首页开始；测试数据中至少有一个符合年龄与时间条件的活动，也有时间相近但不符合条件的选项。使用明确日期替换“这个周六”，避免跨测试日期产生歧义。不给出“亲子”“筛选”等界面入口名称。

观察与结束条件：记录参与者怎样确定年龄和结束时间。选出同时符合条件的活动并说明依据，记为完成；仅觉得封面合适，尚未核对条件，不能等同完成。此任务允许选择不同的符合条件活动，适合探索查找行为。

任务二：确认在哪里集合

你已经报名了“周末植物观察”活动，出发前想确认到哪里与带队老师集合。请找出集合地点。

研究团队准备：提供已有报名的独立测试账号和固定起始页，不依赖参与者完成任务一。活动数据同时包含公园地址与园内集合点，以检查两种信息是否容易混淆；活动内容必须事先由研究团队核对。

观察与结束条件：记录参与者查看了哪个页面、引用了哪条信息。指出正确集合点才算完成；只找到公园门牌地址时继续观察，不立即提醒“还有具体集合点”。如果测试材料本身漏写了地点，应记为材料问题，不能算作用户操作失败。

任务三：处理一笔无法参加的报名

你之前报名了“城市建筑散步”，现在时间冲突，无法参加。请在网站上取消这笔报名，完成后告诉我你怎样确认已经处理好了。

研究团队准备：使用另一笔已确认且允许取消的测试报名，规定是否需要模拟退款，但不接入真实支付。每位参与者开始前重置记录，避免后一位面对上一位已经取消的状态。

观察与结束条件：看参与者是否定位到正确报名、理解取消后的结果并确认最终状态。按下取消按钮但未完成确认，或误取消其他报名，均应单独记录。把“正确报名变为已取消”作为完成标准，不能只凭参与者说“好了”判断成功。

题目写得越像操作教程，越难发现问题

避免暗示不等于回避正常用语。“取消报名”是用户能理解的目标，不必绕成“使参与关系不再继续”。真正需要去掉的是隐藏路径、按钮位置和只有产品团队才会用的术语。时间、年龄、活动名称等完成任务所必需的信息，则不能为了“少提示”而删掉。

先分清探索问题，还是比较成功率

上面的第一项允许参与者选择不同活动，能帮助研究人员了解他们如何查找和决策。若要比较两个版本的任务成功率或耗时，需要进一步统一情境、数据、起点和判断口径，不能让一组找热门活动、另一组找几乎没有结果的冷门活动，然后直接比较数字。

NN/g对定性与定量测试任务的区分指出，探索式任务与受控测量的要求不同。比如任务二可以固定同一活动、同一起点和唯一可核对的集合地点；任务三可以固定报名状态、取消条件和成功状态。统一的是要达成的结果与测试条件，不是强迫每个人沿着同一点击路径操作。

做探索研究时，发现题目不合适可以调整，但应记录题目版本及使用者。做版本对比时，正式测试中途改词会改变测试条件；需要先做预演，再决定正式口径。两类记录不要混在一起，计算一个看似整齐的完成率。

预演时先排除题目故障，正式测试时控制提示

找符合目标用户特征的人预演任务。不要急着看页面哪里不好用，先检查他是否理解情境、是否缺少必要信息、测试数据能否让任务完成，以及结束条件能否被研究人员一致判断。

例如，参与者不断追问“我家孩子几岁”，说明任务缺少条件；他沿着不相关入口查找，却能复述清楚目标，则更可能暴露信息架构问题。若报名记录已经被取消，重跑任务前应先修复测试数据。

正式测试中的提示也要留下记录。参与者问“我是不是要点我的活动”时，可以先请他按自己认为合适的方式继续；不能直接指向入口。若任务已经无法推进，研究员决定提供帮助，应记录帮助内容和时间点，并将“独立完成”与“得到帮助后完成”区分开。遇到系统故障或情境理解错误，则单列原因，不能全部归为界面问题。

用同一块白板连接任务、行为与修改决定

在Boardmix中，可以把画布分成三个区域：左侧放研究问题，中间按任务一、二、三摆放任务卡，右侧贴行为记录。每张记录保留参与者编号、任务编号、发生位置、实际行为、是否提示，以及需要进一步解释的疑问。不要把推测直接写成事实。

例如，“P03在报名详情两次返回列表，仍未找到取消入口”是待分析的行为记录；“用户讨厌复杂界面”则是没有足够依据的解释。用连线把行为接回对应任务，再讨论它支持哪项设计修改。若多个任务都卡在报名详情，可集中检查该页面，而不是分别修补三个表面问题。

完成观察后，再用可用性问题严重度分级整理影响和修复次序。任务设计解决“怎样获得可信观察”，严重度判断解决“发现问题之后先修什么”，两者各有用途。

准备下一轮测试时，可以在Boardmix写出第一张任务卡，先检查一句话：参与者能否知道要完成什么，同时仍需自己发现怎么完成。