先让使用者独立完成一次预约，不先问页面好不好看

手机预约页面是否合适，可以让一位使用者完成一项明确任务：替指定学员选择某家门店的一场课程，并在提交后说出自己约了什么。观察她在哪里犹豫、点错了什么、是否需要员工解释，比直接询问界面漂亮不漂亮更能发现问题。任务要包含地点、场次和上课对象，不能只测试能否点到提交按钮。

检查前由机构核对本次测试的有效安排。若工作人员自己都不清楚该场课程在哪里、哪些人可以申请，页面测试容易把业务说明缺口当作设计问题。可以先准备一份已确认的信息清单，再让使用者从页面寻找并复述，比较页面实际传达的内容与机构原本准备提供的内容。

同一个页面可能被本人约课的学员、替孩子办理的家长和手机操作不熟练的人使用。安排测试时分别观察他们的查找方式，不假定所有人都认识机构内部简称。工作人员在旁边不断提示，会掩盖信息是否清楚；先记录使用者自然完成的步骤，再针对卡住的地方询问她当时怎样理解。

测试记录可以简单写出任务、使用设备、卡住的步骤和原话。页面完成时间可以提供过程信息，却不能只据此判定体验好坏。有人操作快但约错学员，有人花时间阅读却准确完成，结果不同。检查的第一目标是选择与确认是否正确，再讨论哪些步骤可以减少不必要的操作。

地点要能辨认到实际门店，不能只剩一个简称

连锁舞蹈机构的门店名称可能相近，手机页面应让人知道当前正在看哪家门店。门店名称、地址和课程地点是否一致，最好在使用者作选择时能够核对。宣传图片中的环境不一定就是本次上课地点，不能让用户靠图片判断自己应去哪一家，也不宜把必要地点信息只藏在另一页介绍里。

用户切换门店后，观察课程列表、所选场次和确认信息有没有让人辨认当前范围。若旧选择仍被保留，需要说明它属于哪家门店，避免用户以为切换之后已经自动改到新地点。检查时让使用者先选一场，再切换门店返回确认，通常比只打开首页更容易发现关联信息的混淆。

个别课程使用不同教室或临时地点时，页面说明应与机构当前安排对应。仍在核对的地点不要显示成已经确定，也不能由用户自行猜测。页面不能提供全部说明时，应让人找到可以询问的入口，并明确自己当前选择是否已经成立，不把缺少地点的问题推给提交以后再解释。

路线说明可以作为辅助，但不应替代实际地址与到场安排。学员从不同方向到店，无法只靠附近某个商场辨认入口。检查时让使用者说出到哪里集合、是否还有需要确认的地点问题；如果她只能复述门店简称，就继续看具体说明哪里难以找到。

课程、日期与场次，需要在选择过程中一直可辨认

课程列表里的名称、日期、开始时间和必要的参加条件，应当帮助用户辨认这一次具体安排。只展示周几，跨周查看时可能看不出实际日期；只显示课程名字，重复场次又可能难以区分。选择之后的确认内容应能将这些信息放在一起核对，避免要求使用者记住前一页细节。

课程级别或班型的说明，应来自机构已经确认的课程安排。页面不根据历史记录替学员作身体能力判断，也不让一个等级名称代替所有参加条件。用户对是否适合本次课程有疑问时，应能找到相应咨询方式，再由有职责的人员解释；手机操作的便利不等于课程适合度已经得到确认。

列表中未开放、暂不可申请或需要人工确认的场次，使用者应能辨认当前能做什么。可以询问、可以提交申请与已经确认参加，含义不同。页面如果把所有状态都用同一个按钮呈现，用户就可能把提交信息理解为确定名额。测试中让她复述当前状态，看看页面有没有传达这种区别。

返回修改日期或场次时，观察原选择怎样变化。用户只是想查看另一天，不应在没有察觉的情况下改变已经选好的对象或门店。确认页再展示当前有效选择，让人有机会检查。涉及费用、参加条件或其他安排的变化，需依据实际业务规则说明，不以顺畅跳转掩盖重要差异。

替谁预约，要在提交前清楚看见

一位家长可能替不同孩子办理，也可能自己参加成人课程。页面中的登录人并不总是上课人。检查时让家长选择一个明确的代约对象，再观察列表、确认页和提交结果是否都能辨认该对象。把账户昵称放在顶部，不一定能够说明本次给谁预约，用户很可能以为它只是登录提示。

可以安排一次容易混淆的测试：同一联系人关联两位学员，先为其中一位查看课程，再改为另一位。观察是否需要重新确认场次条件，之前的选择是否仍适用。文章不预设工具一定提供这种关联结构，机构要用实际方案检查代约关系怎样处理，缺少可行方式时由相应岗位协助确认。

上课对象信息不清楚时，应提供明确的核对路径，而不鼓励用户随便新建另一个名字完成提交。重复资料可能让前台找不到真正对应的人。若需要工作人员处理关系变更，告诉用户这一步目前处于什么状态、由谁承接，不把代约对象问题隐藏成普通网络错误。

页面测试还要看员工后台或接待资料能否辨认用户刚才选的是谁。手机上显示学员名字，不代表接待岗位看到的结果也一样。提交完成后，让另一位员工查找这条测试记录并说出参加对象，是检查信息有没有实际传到业务接待的一种具体办法。

提交以后，页面要告诉用户发生了什么

用户点提交之后，需要知道结果是已收到申请、等待某项确认，还是已经形成当前有效预约。可以用机构自己的状态名称，但解释要对应事实。加载动画消失或按钮变成灰色，不足以说明办理成功；使用者若无法判断，就可能重复点按、重新提交或转到聊天里再次登记。

重复提交的测试不只看是否出现两条记录，还要看用户如何得知现有结果。一次操作等待较久时，页面应该给出可理解的反馈和继续查找的方法。本文不宣称某项技术必然防止重复预约，而是要求机构通过实际测试核对当前处理方式，再决定需要补充哪段说明或人工承接。

提交结果最好能够让使用者复述门店、课程、日期时间、上课对象和当前状态。若仍需要其他岗位确认，也要知道接下来等什么、哪里可以查询。只有一句操作成功，却看不到成功的到底是哪一步，用户很难判断能否按计划出发，也容易把后续咨询当作新的预约再次提出。

未完成提交时，反馈应尽量指向可以处理的具体问题，例如哪项资料需要补充、哪一场需要重新确认或怎样联系负责岗位。不能让用户只看到失败两个字，再自己猜测是否已经占到名额。检查时观察修正之后原有选择有没有保留，以及重新提交是否产生了能够辨认的结果。

退出、返回和换设备，不应该让人找不到当前安排

完成提交之后，使用者可能退出页面、从聊天入口返回，或隔天再查看。安排这些测试步骤，观察是否能找到之前那次操作及其当前状态。报名当天能看到结果，不代表后续查询路径清楚；如果每次返回都只能重新选课，顾客可能把查看安排误操作成新一次申请。

入口名称要与用户想做的事对应。查看我的安排、继续确认或咨询修改，是不同任务，不必强迫用户重新走一次选课流程。具体采用什么页面结构由现有产品决定，检查时关注使用者能不能找到必要信息，不为了追求简洁而把所有后续动作集中到一个难以理解的按钮里。

用户发现选错日期或上课对象后，应能知道怎样修正、哪些部分需要工作人员确认，以及目前哪份安排有效。查看新场次不等于原场次已经取消，发出修改请求也不一定表示修改已经成立。页面说明与前台答复需要使用相同的状态，避免手机显示仍待处理，员工却口头说已经改好了。

用预约模块演示完整任务，而不是只点一遍首页

企雀舞蹈公开产品介绍包含预约模块。相关入口见舞蹈机构预约产品说明。机构可以带着选门店、辨认场次、确认代约对象和返回查询这组任务演示，核对目前方案能够怎样承接。公开说明只提供基础预约模块的信息，具体页面、代约关系和修正安排，需要通过实际操作确认。

演示结束后，让手机使用者复述她刚才的选择，再让接待人员查同一次测试记录，比较两边是否一致。若某些情况需要人工确认，就把相应入口与岗位交接一起测试。不能只凭页面按钮齐全就认为整个办理过程顺畅，也不由一个预约入口推断自动排课、教学推荐或其他课程能力。

改动页面之后，可以在相同任务与相近设备条件下重新观察，重点查看原来的误解有没有减少、是否出现新的选择错误。记录具体变化，如门店更容易辨认或提交后更容易找到状态，避免把一处视觉修改直接写成留存增长。页面检查最后应留下可继续执行的修正任务，让负责人员知道下一步需要调整哪一处信息或衔接。