首次使用的人，会按页面文字理解接下来发生什么
医美顾客从一个入口进入预约页面，首先需要知道选的是哪家门店、本次希望咨询什么，以及提交之后怎样得到答复。工作人员熟悉后台，很容易主动补充解释，让一次测试看起来十分顺畅。评估首次体验时，应让不熟悉页面的人按文字独立完成任务，观察他如何理解选择和结果，再与前台实际收到的请求比较。
测试前准备专门资料和明确任务，例如询问某门店一个可选择时间，并提出一项一般接待问题。任务写明目标，少规定每一步点击位置。测试者自己寻找入口、选择并提交，观察员记录卡住的位置和当时的理解。有人求助时先记录问题，再提供必要帮助，帮助之后完成的结果与独立完成分开说明。
顾客端与前台端可以安排两位不同测试者。前一位提交后，后一位只依据现有记录查找本次请求，说明当前能确认什么以及下一步找谁。这样能看到页面选择怎样进入接待工作，而不只验证一个按钮有没有反应。界面评估的终点，是前台能依据请求继续回应。
门店和本次意向，选完以后还要看得到
从特定门店分享的入口进入时，页面可能带着某个默认选择。测试者应能辨认当前门店，必要时返回改选，并看清地址或其他区别。多个名称相近的门店，单靠列表文字可能难以区分；测试记录注明在哪里犹豫，再决定是否补充识别信息，而不是默认顾客了解每家分店简称。
咨询或服务意向应采用顾客可以理解的名称，并说明本次填写用途。测试时先让首次使用者读选项，再用自己的话说出选中后正在申请什么。顾客将一般咨询读成已经决定接受具体服务，就查看是名称、补充文字还是页面位置引起误解。选项名称与前台采用的介绍可以核对后调整，再请新的测试者复述。
输入示例可以展示该字段要表达的信息类型，例如一般接待问题如何写明想了解的事项。示例帮助理解用途，不预先替顾客选择项目。测试者读完后自行输入，再说明哪些内容来自自己、哪些只是参考提示。若他直接照抄示例却无法解释本次意向，就查提示是否过于具体或与字段标签混在一起。
测试者改选门店之后，原来的意向和时段怎样处理，值得完整走一次。看选择是否保持、需要重新选择的地方是否清楚、提交前是否还显示旧门店信息。最后到前台查本次请求，比较两端对象。问题发生在回退或改选路径，只有顺着路径测试才能发现，首页静态检查很难看出。
提交前可以集中展示门店、本次意向与时间选择，提供回到相应步骤的办法。让测试者修改一个选项，再说出当前保留了哪家门店、哪项意向和哪个时间。返回之后他若只能凭记忆回答，就检查当前选择是否缺少明确标识；再次进入确认页后再比一遍，让页面上的当前选择支持实际纠正。
空状态也要测试：没选、没填与暂无时间分别看
空状态可以分为尚未选择、必需信息待补充和当前没有可选择时间。三种情况需要不同提示。尚未选择时帮助人找到下一步；缺少信息时指明哪项待填；暂无时间时说明当前可用的联系或查询路径。一个通用出错提示，很难让顾客判断自己应改输入还是向前台询问。
测试可以故意留一个字段未填，观察错误提示出现在哪里，测试者能否指出它关联哪个字段。如果提示集中放在页面顶部，而字段在下方，就观察他怎样找到需要补充的位置。提示出现在输入框旁边时，也检查文字是否因手机屏幕较窄而换行或被遮住，记录实际看到的内容。
手机键盘打开后，可以让测试者继续阅读字段说明、查看下一项和尝试提交。键盘可能遮住下方提示或按钮，测试者也可能不知道怎样收起它。记录卡住的具体位置，再关闭键盘重新看页面，区分问题来自提示本身还是当前显示区域。短页面与需要滚动的长页面分别走一次，不替测试者提前移动到正确位置。
纠错之后，让测试者说明现在还需要处理哪项输入，并再次提交。观察页面是否停在可理解的位置，已有联系信息和问题说明是否保留。若返回顶部或清空其他内容，测试者可能以为整个申请要重新开始；可以针对这种实际行为调整提示和路径，再用同样的缺项任务检验是否容易继续。
没有合适时间时，测试者能否返回其他日期、联系门店或明确知道当前申请方式，也要走到实际结果。可选时段的含义由门店安排决定，是提交希望到店的选择，还是已经获得明确接待安排，页面文字应让人分辨。测试结果可以请顾客端说出自己的理解，再由前台核对实际状态。
长问题或特殊格式输入，可以使用专门文本观察页面能否完整保存并让前台读到。信息被截断时，前台可能只收到开头而缺少关键问题。检查看最后形成的请求内容，比仅看输入框当时容纳多少文字更有意义，也有助于决定接待说明适合放在哪里。
回退与再次提交，沿着原请求查实际结果
顾客提交之后返回修改，有时从浏览器返回，有时点击页面的修改入口。两条路径可以分别测试，观察目前编辑的是原请求还是新的申请。前台查到几条内容，各自采用哪个选择，再与顾客当前结果页比较。结果明确之后，门店才能解释顾客怎样修改最适合当前页面。
网络无响应时，测试者可能再次点击提交。可以在测试资料中观察按钮提示、当前结果和后台请求数量，发现问题后记录发生条件。测试重点是重复操作怎样影响实际请求，不凭页面看起来成功就认为一定只提交过一次。前台处理重复内容的办法也应清楚，方便顾客来询问时查回这次实际发生的操作。
结果页可以单独安排阅读任务：让测试者说出刚提交的门店和意向、当前时间是否已经确定、接下来等什么答复，以及关闭页面后从哪里再次查看。观察员先听完整回答，再与页面文字和后台结果比较。某句话让人以为可以立即到店，就定位这句话出现在哪里、是否缺少下一步信息，调整后再请另一位首次使用者阅读。
评估预约页面时，用测试任务核对门店、意向、时间、回退和前台接收，并记录入口、版本及日期。企雀的预约管理介绍仅供核对公开范围；未说明能力不推定支持，须在拟用版本演示。页面提示与前台信息，应按本店流程复核。测试结果注明使用版本并由岗位复核留档。
假设测试者提交后发现门店选错，又回到上一步改选。前台分别查询原条件和新条件，查看本次是否生成多份请求，再向测试者解释当前哪份用于后续联系。这个短任务能够同时检查回退提示、提交行为和前台查找路径，问题也能定位到具体一段操作。
代约时，联系人和实际到店人要容易区分
有人替家人预约，填写的联系方式属于代约人，实际到店的是另一位对象。页面可以让测试者说明各自身份和本次联系安排，前台查看后能够辨认该联系谁、接待谁。字段名称采用联系人或到店对象等具体词语，避免一个姓名栏让双方自行猜测应该填谁。
代约测试可以让提交者在结果页分别指出联系人和到店人，再由前台读出同一请求中的两类对象。信息不一致就回查字段名称和提交摘要。这样检查的是页面能否表达角色区别，实际沟通安排由本次经办人员确认。
关闭页面之后，还能否找回本次结果
提交结果页阅读完成后，让测试者关闭页面，从最初入口重新寻找本次请求。观察他想到使用哪个入口，能否辨认这次对象与意向，重新打开后读到什么状态。若页面没有再次查询方式，就检查能否找到当前可用的联系入口，并请测试者说明应该向前台提供什么信息。测试任务走到再次取得答复，不只停在结果页关闭。
再次查看时，可以请测试者复述页面上的当前状态、下一步是否仍等回复，以及此前填写的问题在哪里。后台人员仅用于查明同一请求实际呈现什么，不替测试者补充页面没有说清的内容。页面与后台存在差异，就把两边显示和采用的入口一起留下，定位需要修正的提示或查询路径。
电话变更可以作为一条简短复查路径：用测试资料提出修改，再回到结果页观察当前显示是否容易理解。前台提供已经核对的当前结果，比较顾客读到的内容是否一致。若原选择仍出现在摘要里，就请测试者指出哪项现在有效，检查当前状态提示是否足以帮助辨认。
测试结束后，按选择、空状态、重提、代约和电话变更分别记录问题及实际结果。优先处理会使对象选错、请求查不回或双方理解不同的环节，调整后复测相应路径。任务、设备与参与者条件尽量一致，验证结论落到哪项操作已经改善，不拿一次测试直接承诺转化或经营效果。
