批准企业应用改版前，应该先测试什么？

新界面看起来不错。供应商演示了如何查找订单、修改订单并保存。现在，他们请你批准改版，好让开发继续推进。

答应之前，请一位实际会使用应用的人试着完成一项重要工作。告诉对方遇到的情况和需要达到的结果，然后观察过程。听演示的人可以跟着演示者走。处理客户请求的人则必须自己找到操作方法。

从重要工作开始

选择人们经常做的工作，或出错会带来麻烦的工作。如果某种例外情况会改变处理方式，也把它纳入测试。具体测试范围取决于你的应用和当前要做的决定。

下面是一个假设的例子。一位订单文员收到客户请求，要在发货前更改送货地址。文员需要找到正确的订单、改正地址，并确认修改是否生效。

准备几笔样例订单，使用虚构的客户资料。给文员一条可信的客户消息，并提供足够的信息来识别订单。原型若没有能力保护真实信息，就不要放入真实客户或业务资料。

然后请文员处理这项请求。不要告诉他们“打开订单，选择编辑，再按保存”。这些步骤会直接给出你想要了解的答案。

Marieke McCloskey 在她的2014 年 1 月 12 日任务情境指南中解释了这一区别：给人们有意义的背景和目标，但不要透露界面操作路径。

让可能的用户亲自试一试

请一位从事这类工作或很可能从事这类工作的人来试。如果订单文员负责更正订单，已经熟悉拟议界面的经理就不能代替他们。其他岗位如果会遇到不同的问题，也应纳入。

使用符合实际工作的条件。整天在办公桌前工作的文员可能主要用键盘。用手机查订单的人面对的屏幕和输入方式则不同。如果有人使用辅助技术，要按相关配置安排测试，并检查原型是否支持。

GOV.UK 关于主持式可用性测试的指南介绍了观察实际用户或可能用户尝试可信任务的做法。你可以把这个原则用于当前需要审查的具体工作，无须照搬整套政府研究项目。

观察文员看向哪里、何时犹豫、走错方向或漏看信息。听听他们认为发生了什么。如果你需要帮忙，记下何时帮了忙以及怎么帮的。有人在指引下完成任务，和独立完成任务所提供的信息不同。

“我喜欢这个布局”能说明一个人的偏好。“我以为地址已经保存了，但页面还在编辑模式”则指出了一个值得调查的具体问题。

现在假设订单已经发往配送环节

还是这个假设例子：客户提出请求时，普通的地址更正已经来不及了。文员能否看懂订单当前状态，并判断下一步该做什么？也许他们需要经理批准，或者必须联系配送部门。

先在业务中明确下一步应该是什么，再让当事人试着处理。如果原型支持，就把相关界面和选项纳入。观察结果是否清楚：文员知道地址有没有更改、是否需要其他人采取行动，以及能否给客户答复吗？

模拟的警告信息可以帮助判断文案是否容易理解，但无法证明实际应用会阻止未授权的更改，或确保消息送达配送部门。这些问题应留给真正能够验证它们的检查。

选择能回答问题的原型

草图可以帮助你讨论屏幕上应该有什么，以及拟议方案是否说得通。可点击原型可以让人查找订单、切换屏幕并理解确认信息，前提是这些部分已经制作出来。要告诉所有人哪些部分能用，哪些只是模拟效果。

如果你想了解文员能否找到更正入口，就让他们实际尝试这条路径。如果你要判断警告是否容易理解，就在它应该出现的情境中展示。问一个人觉得自己能不能用某个屏幕，得到的是他的预测；观察他实际尝试，才能看到他做了什么。

Katherine Alsop 在2014 年 8 月 27 日关于 GDS 使用原型的记录中，谈到了稳定的利益相关者演示与研究期间不断调整的原型之间的区别。她还指出，对正在运行的服务进行研究，能发现原型中没有的响应时间和错误处理问题。

这在批准工作时很重要。可点击的“已保存”提示可以帮助测试文员是否理解结果。要确认数据是否正确存储、重复请求是否得到安全处理，以及关联系统是否收到更改，则需要合适的实现检查。安全性、实际生效的权限控制和速度，也需要通过应用中相关的可运行部分来验证。

让人们使用自己平常的辅助技术配置，可以发现实际障碍。正如W3C 关于让用户参与无障碍评估的指南所说明的，这项工作应与依据无障碍标准进行的评估同时开展。完成这些任务并不能证明应用符合无障碍标准。如果原型不支持所需的配置，就记录这一限制，并安排适当的后续检查。

离开会议时，带着一个能说清理由的决定

趁记忆还新鲜，记下你观察到的情况。记录要实用：

• 谁试了什么：参与者的岗位、任务、设备和输入方式，以及原型支持了哪些部分。
• 发生了什么：参与者是否达到了预期结果、在哪些地方遇到困难，以及需要什么帮助。把观察到的情况和对原因的猜测分开记录。
• 要修改什么并重新测试：指出令人困惑的标签、缺少的信息或不清楚的下一步。修改后，让人重新尝试受影响的工作。
• 哪些问题仍需在可运行的应用中检查：记录未解决的问题、由谁检查以及何时检查。在这个例子中，可能要确认谁能批准发货后的更正，以及配送部门如何收到通知。

然后你就可以批准测试结果支持的设计方向；如果有人遇到困难，就要求修改；或者在拿到合适的证据前，暂缓某项决定。改版的不同部分可以分别采取这几种做法。批准订单界面，并不意味着也接受未经测试的配送系统集成。

如果你正在准备企业应用改版，我们的设计服务可以作为一次交流的起点，讨论谁会使用应用、他们需要完成什么，以及你希望获得哪些决策帮助。