从原型到上线

过去五年，我一直都是个自由设计师，从小公司的网站设计到当地活动的海报，我什么都做。创建 42Floors.com 并不仅是我第一次创业，也是我第一次和一群同龄企业家合作，而不是我的客户。

在我的很多项目中，我们都遵守严格的快速原型法。我们已开始的原型看上去挺真实的，然后我们和用户讨论，试着去理解我们到底要制作什么。然后，我们丢掉原型图，完全丢掉。然后从零开始重建。

快速原型对我们来说并不是独一无二的，我们在实践中很自豪的使用它。以下是我们建设移动网站的故事。

原来的 42Floors.com 移动版的体验简直不能更糟了，根本无法使用。

我和一个值得信任的 UX 设计伙伴 Leslie Chicoine 一起开发了移动网站的样式。几天后我们就完成了第一版的静态 HTML。静态的 HTML 能够让我们理解这其中的限制，我们能够感觉到实时的挑战，并且加快建设。有时候，在 PS 和 AI 里设计很容易被复杂的 UI 和图形所分心，以至于没有办法去思考真正的产品。

从 HTML 开始也使得我们可以使用真实的数据。在现实中，数据并不如设想的完美。有些数据很奇怪，可能会很长或者很短，甚至数据会丢失。使用 HTML 我们可以直接接入数据库，实时监听数据，然后把数据代入 HTML。如果没有办法拿到数据，就自己建一些临时的模拟数据。

结果我们可以看到我们的网站大概的样子：

我们没有使用任何线框图。没有花时间去进行头脑风暴。我手机了一些易于理解的目标，然后开始工作，把自己的最初的想法全都放进一个模型中。最终的结果就是这样的原型，它可以用在很多地方。很多元素并没有适配，而且有些功能还不能用，但我们还是拿着我们的移动产品在团队里寻求反馈。最终原型也进入了客户会议和董事会议。基本上没有人知道这些都是假的，接下来他们就给出许多实在的反馈。

在建立了第一个手机原型并收集反馈之后，我和开发组的 Aaron O’Connel 聊了会。虽然我也做过工程师，但是 Aaron 明显更专业。

我们从头到尾看了一遍我们的原型。包括不同的视图，讨论了一些我们的分歧，然后分享了我们收到的反馈。然后我和 Leslie 都感到松了一口气。我告诉 Aaron「你完全可以把这个原型推倒了重来。按照你们希望的方法来重新开发，使用你想要的框架来做。然后我们再来一起搞定 UI 的事情」

作为一个设计师，这不仅仅是放手，而是很难把之前努力工作的结果全部扔掉。每一次这么做的时候我都会犹豫，都会感到后悔。并不是说我很重视之前做的这些，只是想到还要重新面对之前的挑战让我有担忧。

但是设计的价值并不是代码或者线框图，这些都不重要。设计的价值在于我们可以成为什么。即时我们把之前的工作全都丢掉，也不算是浪费。这些主意通常还会再来。

一周之后，Aaron 搞清楚了他想要如何架构代码，然后根据一些线框图来帮助他建设网站。这个像框图跟我之前制作的原型很像。只不过我在想「你确定你不想用我之前写的 HTML？」但是我希望他能够自己把控整个进度。他肯定也是平衡了很多因素，而不仅仅是用户界面。

几周之后，Aaron 邀请我去测试网站，新的网站确实比我之前做的要好多了，反应更快速，而且更简单。与最终的产品已经很接近了。虽然有一些元素有些散乱，而且色彩也有问题，但是看起来依然是一个非常不粗的产品。

我花了几天的时间来和 Aaron 过 UI 元素，然后检查了一些 UI 里面的交互元素。一周之后，他就拿出了一个基本上可以上线的产品了。

最终的版本和我们一开始的原型很接近了，有一些不同是因为我们更改了一些 UI 然后通过一些复杂的方法检查了用户流程。

我们的快速原型过程就像是搭建了一个平台，我们可以通过这个平台来表达我对产品的愿景，对 Aaron 来说，这个平台也足够自由的去创建任何他想要去创建的东西。

虽然我可以直接跳过让他重建，转而让他来对原型做一些改进，但这样代码可能会不够效率和简洁。或者 Aaron 也可以一开始就加入来创建原型，而不需要设计参与，但这样做出的原型的布局可能并不符合 UI，这也会限制住他的能力。

这就是我们在 42Floors.com 做产品的流程。我们不会命令工程师去做什么，也不会让设计师做一些类似于魔法的效果。

原文：Fake It. Trash It. Build It.
作者：Ben Ehmke
翻译：Max Cheung