原型像真实网站，GOV.UK为什么仍说代码不能直接拿去上线

一个原型能在手机和桌面上显示页面，也能让用户体验交互，是否就可以把它的代码当作正式服务交付？GOV.UK的Making prototypes指南把这两件事明确分开。原型可以在外观和行为上接近真实网站，代码却不需要符合与正式生产代码相同的要求。逼真描述的是研究材料的表现，并没有自行完成上线质量判断。

指南先把原型放在设计探索中：在承诺构建服务之前，用它分享和测试不同方案，可以快速制作多个版本，再舍弃测试不佳的方向。这使原型具有一种可替换的身份。它承载当前准备讨论的想法，不是仅因已经投入制作，就被定义为后续必须保留的成品。

具体形式也与目的相连。原型可以是纸笔草图，也可以是像完整交互网站那样工作的代码。文中把草图与同事讨论基础想法联系起来，把代码原型与更真实的用户研究联系起来。因此，纸面表达不必因为缺少点击能力而被视为没有作用；代码形式也不能仅因为表现更丰富，就包办所有讨论目的。

代码原型的优势，原文放在交互情境里解释：它在移动与桌面环境中可以接近真实网站，使参与者较少被不真实的表现分散注意力，也让团队共同理解设计想法。同时，设计者会面对网页媒介的约束。这里谈的是一种研究材料能帮助呈现哪些条件，不是本篇已经测得某次研究更准确或更省时。

随后出现的代码边界十分重要。指南说，转入正式生产时，代码质量需要另行考虑，原型中采用的代码未必能继续使用，并直接提醒不要把原型代码简单复制到生产中。于是，“这个页面能用于讨论交互”与“这份实现适合正式运营”是两项不同描述。前一项成立，没有替后一项补足所需证据。

原型也不是只有alpha阶段才出现。该页让团队在alpha探索不同服务设计，并在beta和live继续用原型研究潜在的新功能或改进。正式服务已经存在，与另有一份探索材料，可以同时发生。因此，接到一份原型时，仅知道项目阶段，还不能确认这份文件究竟代表当前运营服务，还是尚在讨论的新想法。

本文依据首次发布于2016年10月18日的这份服务设计指南，只解释原型的用途和实现身份，没有建立网站、招募用户或执行部署。GOV.UK Prototype Kit也被原页限定为原型工具，不能由它的外观认定已经成为live服务。把拟讨论的交互与正式交付的代码分别说明，才不会让一份逼真的演示承担尚未完成的工作。