应用设计会如何损害应用开发

下一篇文章

谷歌研究发现插屏广告严重影响移动用户体验

编者按Anders Lassen 是 Fuse 的创始人兼首席行政官。Fuse 是一款面向设计师和开发者的本地应用工具套装。

移动应用现在已经变得十分普及,以至于技术圈的大部分人都认为开发应用是一个简单直接的过程。然而,当你揭开应用开发的帷幕时,你会看到一个充满预算超支,代码和素材的臃肿,以及开发进度延迟的艰苦历程。

上面提到的很多阻碍都是移动应用开发所独有的。现在的移动应用通常都会作为连接用户和公司之间的主要纽带。这就意味着移动应用设计涉及的人员数量是非常庞大的:设计师本身、产品团队、市场人员、产品经理,甚至包括最终为应用开发提供资金的用户(或风险资本)——他们当中很少有人能够大概了解真正的应用是如何在代码层面实现的。

这并不是说工程师是唯一能够理解应用开发过程的人——只是说大部分应用的策划阶段(也就是概念和设计)和制作应用所需的代码部署阶段(也就是开发)之间都存在严重的脱节。

应用开发过程的关键矛盾在于,负责部署最终代码的开发者和其他人之间在文化和技术上存在的差异。换句话说,技术圈的大多数人都是造成这个问题的一部分原因。下面我会向大家进一步解释这点。

执着于代码无法实现的视觉效果

当我们谈论移动应用设计的时候,我们通常所指的是应用在 Photoshop 或者 InVison 和 Pixate 这些原型设计平台上面所呈现的形象,这些功能强大的视觉化工具可以展现出最终应用的外观和感觉。

但是这些平台与应用的基础代码其实没有直接的联系,而且它们只能代表一个非常理想化的最终成品,但是这种想象是有可能无法实现的。(例如大量的动画,高度可动的 UI 在视觉上是很有吸引力的,但是这些元素也许会增加几个月的开发时间。)

然而,开发公司经常会将精美的视觉设计作为应用的核心参考对象。(这点和网页设计很不一样,后者的 HTML/CSS 最终代码通常可以进行实时的原型设计。)

我已经见过很多这样的情况:当你向客户展示原型设计的时候,他们就会对产品产生一个固定的印象,但是经过几个星期或几个月之后,当他们将最终成品和当初通过的设计进行比较的时候就会感到非常失望。

这点引出了一个相关的问题……

设计资源分配的矛盾

虽然原型设计可以确定应用的外观和功能,同时也是公司与客户和内部开发团队进行沟通的一个重要工具,但它实际上也属于开发流程当中(成本很高)的一部分,而且它跟最终产品之间没有直接的关系。

一旦应用已经完成了代码部署,原型设计就没有价值了,也就是说,大量的开发时间和预算都花在了一些最终会被丢弃的东西上面。另外,设计一些不会出现在最终应用里面的功能也是一种浪费资源的行为。

这种存在于原型和开发之间的脱节,意味着设计师可以轻易地想出一些动画、UI 概念和富媒体内容,但是它们几乎不可能通过代码实现。

在这样的情况之下,设计师的时间和精力就被完全浪费了。当发现应用出现问题之后,他们就需要进行新一轮的设计工作——在这个时候,原型的“终稿”往往已经通过了审批,应用也进入了开发阶段。

缺乏真实数据的设计

在原型设计的过程中,设计师总会挑选出一些数字、名称和图像,展示出用户输入内容在最终应用上的最佳效果。但是他们通常会忽略用户输入内容可以是多种多样和凌乱不堪的——其中部分内容可能会导致应用出现“走样”或者完全不可用的情况。(Dropbox 的乔什·帕克特(Josh Puckett)之前在 Medium 的一篇文章上生动地描述过这个问题 。)

不幸的是,数据和设计之间的冲突一般只能在应用公开测试阶段被发现,这已经是比较好的一种情况,更坏的情况(也是更常见的情况)是应用已经上架 App Store,用户真正开始使用它之后才发现这个问题。无论是哪一种情况,设计师和开发者通常都需要进行新一轮长时间的更新开发流程。

我们开发的是应用,而不是原型

为了应对这些难题,有人提出的一个解决方法是让设计师学习编程。但是我的看法跟 杰西·韦弗尔(Jesse Weaver)一样,我们都认为这种做法既不可行,也难以接受。我们真正需要的对应用整体有更好的理解——从它的编程基础到表面的 UI 和艺术素材,并充分考虑到它在不同平台上真正运行的情况。

我们还需要认识到应用开发并非一个线性的过程,它不像是把一个设计好的应用直接交给开发者那么简单。相反,设计师和开发者之间需要通力协作,在打造出引人入胜的外观之余,他们还要保证这个外观的每一步都能够被实现出来。

现在已经有越来越多的公司将应用作为自己的唯一产品,因此按照这种方式进行应用开发就显得更为重要了。

题图来自:FOXIE/SHUTTERSTOCK

翻译:关嘉伟(@consideRay

How App Design Can Hurt App Development

blog comments powered by Disqus