实践中的应用程序原型设计：如何在使用代码之前测试想法

团队能做的最昂贵的事情就是将一个糟糕的想法变成构建良好的软件。工程成本高昂、速度缓慢且难以撤消。这正是为什么编码前的原型设计不再是一种奢侈，而已成为产品构建者的基本卫生习惯。

但知道应该进行原型设计和做好原型设计之间存在着一段距离。许多团队的原型设计都是错误的：他们在原型上花费了太多时间，追求他们不需要的保真度，或者以无法回答任何问题的方式进行测试。

本文是关于实践中的原型设计。不是关于使用哪种工具，而是关于如何思考原型，以便它实现其唯一的真正目的：快速且廉价地学习。

原型的目的是被扔掉

从改变心态开始。原型并不是产品的第一个版本。它是一种学习工具，而好的学习工具是一次性的。

当团队依附于原型时，当它“必须利用”所做的事情时，它就失去了发现这个想法是错误的自由。你害怕扔掉的原型已经达到了它的目的，因为它变成了一种承诺而不是一种实验。

中心论点是：原型的价值在于它回答的问题，而不是它产生的质量。一份扼杀坏主意的草案比没有人测试的漂亮原型更有价值。

实践中最常见的错误是使用错误的保真度级别。保真度是指原型与最终产品的相似程度，每个级别都解决不同的问题。

高效的团队从低位开始，只有当问题发生变化时才会向上移动。直接跳到高保真度是浪费时间对你还不知道有意义的东西进行原型设计的最常见方法。

实践中的原型设计是一个循环，而不是一个事件。通过减少创造和学习之间的时间来优化周期。

第一个优化是在原型设计之前定义问题。如果没有明确的问题“用户可以单独完成注册吗？”，您会生成不进行任何测试的漂亮屏幕。先提出问题，再制作原型。

第二种是与少数但真实的人进行测试。你不需要几十个。来自正确受众的少数用户揭示了大多数严重问题。与真实用户一起测试，而不是与队友一起测试，这就是验证与自欺欺人的区别，队友已经了解产品，并且永远不会陷入用户陷入困境的困境。

三是抵制过早抛光。过快地花一小时让原型变得漂亮，就相当于浪费了一个小时的学习时间。当方向已经得到验证时，就会进行抛光，这是以前从未有过的。

想象一个为应用程序设计注册流程的团队。在内部，似乎一清二楚，每个人都理解，每个人都认可。直接进行开发是一种诱惑。

相反，该团队建立了一个简单的可导航原型并要求五个人注册。三个人停在同一个地点，对于那些创造它的人来说，这个领域似乎是显而易见的，但对于那些从外面来的人来说却令人困惑。

这次学习花了一个下午的时间。如果它是在开发之后出现的，则需要花费数周的返工时间，并且真实用户会放弃注册而感到沮丧。这是原型设计在实践中所提供的完美示例：发现只有那些距离太近的人才能看到的显而易见的东西。

做好原型设计就成功了一半；良好的测试是另一半，这也是大多数人在实践中遇到困难的地方。执行不当的测试会产生错误的结论，给人一种验证的感觉，但没有提供真正的学习。

最常见的错误是引导用户。创建原型的人往往会解释，指出方法，说“现在点击这里”。一旦你这样做，测试就失去了价值，你正在衡量你的解释，而不是产品的清晰度。黄金法则是给出任务并闭嘴：“尝试注册”，然后只是观察，无论看到这个人被卡住有多痛苦。

第二个注意事项是将人所做的与所说的分开。用户是善良的，往往会给予好评，以免失望。行为诚实；口头意见，并不总是如此。当有人说“我觉得这很棒”但他们花了一分钟才找到按钮时，请相信这一分钟，而不是赞美。

第三是与正确的人一起测试正确的任务。要求队友使用原型几乎是没有用的，他们已经知道上下文，并且永远不会在真正用户感到困惑的地方感到困惑。寻找真正代表公众的人是值得付出努力的，即使需要更多的工作来招募。与错误的人进行测试比根本没有测试更糟糕，因为它会产生不必要的信心。

做好考试是一种自我控制的练习。你需要克制住捍卫自己创造的东西的冲动，并愿意默默地看到所有那些除了你之外对任何人来说你的明显想法都不明显的地方。

真诚的关怀是值得的。原型设计很强大，但它也有局限性，忽视它们会产生虚假的信心。原型测试在受控环境中进行，测试人员知道他们正在被观察。现实生活更加混乱。

有些行为只有在实际使用中、在压力下、在匆忙中、在分心时才会出现。连接性能差、重复使用造成的疲劳或罕见的边缘情况等问题很少在原型测试中显现出来。将经过验证的原型视为成功的保证，使该工具超出了其处理能力。

成熟度在于了解原型对什么做出响应以及不对什么做出响应。它减少而不是消除不确定性。盲目信任经过验证的原型的团队有时会发现自己在发布时感到惊讶，因为他们混淆了“它在测试中有效”和“它在世界上有效”。原型是第一个过滤器，而不是最后一个。

在实践中制作应用程序原型正在掌握一种简单的经济：用代码中犯错误的高成本来换取起草中犯错误的低成本。那些学会做到这一点的人可以减少浪费，做出更好的决策，并提供在实际存在之前就已经与现实有一定联系的产品。

好的原型并不是最漂亮的。它能够在尽可能短的时间内回答正确的问题，而且您不怕扔掉。

如果您的团队仍然先构建并稍后发现问题，则值得在下一个功能中颠倒顺序并衡量差异。这里还有其他关于发现和产品设计的文章继续这个话题。