maxOS

从原型到上线

产品

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

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

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

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

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

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

结果我们可以看到我们的网站大概的样子:
第一版基于 HTML 的快速原型

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

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

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

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

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

Aaron 创建的线框图

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

Aaron 在没有 UI 介入的第一版网站

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

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

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

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

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

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

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