[[142621]]

移動應(yīng)用現(xiàn)在已經(jīng)變得十分普及，以至于技術(shù)圈的大部分人都認(rèn)為開發(fā)應(yīng)用是一個簡單直接的過程。然而，當(dāng)你揭開應(yīng)用開發(fā)的帷幕時，你會看到一個充滿預(yù)算超支，代碼和素材的臃腫，以及開發(fā)進(jìn)度延遲的艱苦歷程。

上面提到的很多阻礙都是移動應(yīng)用開發(fā)所獨有的?，F(xiàn)在的移動應(yīng)用通常都會作為連接用戶和公司之間的主要紐帶。這就意味著移動應(yīng)用設(shè)計涉及的人員數(shù)量是非常龐大的：設(shè)計師本身、產(chǎn)品團(tuán)隊、市場人員、產(chǎn)品經(jīng)理，甚至包括最終為應(yīng)用開發(fā)提供資金的用戶（或風(fēng)險資本）——他們當(dāng)中很少有人能夠大概了解真正的應(yīng)用是如何在代碼層面實現(xiàn)的。

這并不是說工程師是唯一能夠理解應(yīng)用開發(fā)過程的人——只是說大部分應(yīng)用的策劃階段（也就是概念和設(shè)計）和制作應(yīng)用所需的代碼部署階段（也就是開發(fā)）之間都存在嚴(yán)重的脫節(jié)。

應(yīng)用開發(fā)過程的關(guān)鍵矛盾在于，負(fù)責(zé)部署最終代碼的開發(fā)者和其他人之間在文化和技術(shù)上存在的差異。換句話說，技術(shù)圈的大多數(shù)人都是造成這個問題的一部分原因。下面我會向大家進(jìn)一步解釋這點。

執(zhí)著于代碼無法實現(xiàn)的視覺效果

當(dāng)我們談?wù)撘苿討?yīng)用設(shè)計的時候，我們通常所指的是應(yīng)用在 Photoshop 或者 InVison 和 Pixate 這些原型設(shè)計平臺上面所呈現(xiàn)的形象，這些功能強(qiáng)大的視覺化工具可以展現(xiàn)出最終應(yīng)用的外觀和感覺。

但是這些平臺與應(yīng)用的基礎(chǔ)代碼其實沒有直接的聯(lián)系，而且它們只能代表一個非常理想化的最終成品，但是這種想象是有可能無法實現(xiàn)的。（例如大量的動畫，高度可動的 UI 在視覺上是很有吸引力的，但是這些元素也許會增加幾個月的開發(fā)時間。）

然而，開發(fā)公司經(jīng)常會將精美的視覺設(shè)計作為應(yīng)用的核心參考對象。（這點和網(wǎng)頁設(shè)計很不一樣，后者的 HTML/CSS 最終代碼通?？梢赃M(jìn)行實時的原型設(shè)計。）

我已經(jīng)見過很多這樣的情況：當(dāng)你向客戶展示原型設(shè)計的時候，他們就會對產(chǎn)品產(chǎn)生一個固定的印象，但是經(jīng)過幾個星期或幾個月之后，當(dāng)他們將最終成品和當(dāng)初通過的設(shè)計進(jìn)行比較的時候就會感到非常失望。

這點引出了一個相關(guān)的問題……

設(shè)計資源分配的矛盾

雖然原型設(shè)計可以確定應(yīng)用的外觀和功能，同時也是公司與客戶和內(nèi)部開發(fā)團(tuán)隊進(jìn)行溝通的一個重要工具，但它實際上也屬于開發(fā)流程當(dāng)中（成本很高）的一部分，而且它跟最終產(chǎn)品之間沒有直接的關(guān)系。

一旦應(yīng)用已經(jīng)完成了代碼部署，原型設(shè)計就沒有價值了，也就是說，大量的開發(fā)時間和預(yù)算都花在了一些最終會被丟棄的東西上面。另外，設(shè)計一些不會出現(xiàn)在最終應(yīng)用里面的功能也是一種浪費資源的行為。

這種存在于原型和開發(fā)之間的脫節(jié)，意味著設(shè)計師可以輕易地想出一些動畫、UI 概念和富媒體內(nèi)容，但是它們幾乎不可能通過代碼實現(xiàn)。

在這樣的情況之下，設(shè)計師的時間和精力就被完全浪費了。當(dāng)發(fā)現(xiàn)應(yīng)用出現(xiàn)問題之后，他們就需要進(jìn)行新一輪的設(shè)計工作——在這個時候，原型的“終稿”往往已經(jīng)通過了審批，應(yīng)用也進(jìn)入了開發(fā)階段。

缺乏真實數(shù)據(jù)的設(shè)計

在原型設(shè)計的過程中，設(shè)計師總會挑選出一些數(shù)字、名稱和圖像，展示出用戶輸入內(nèi)容在最終應(yīng)用上的***效果。但是他們通常會忽略用戶輸入內(nèi)容可以是多種多樣和凌亂不堪的——其中部分內(nèi)容可能會導(dǎo)致應(yīng)用出現(xiàn)“走樣”或者完全不可用的情況。（Dropbox 的喬什·帕克特（Josh Puckett）之前在 Medium 的一篇文章上生動地描述過這個問題）

不幸的是，數(shù)據(jù)和設(shè)計之間的沖突一般只能在應(yīng)用公開測試階段被發(fā)現(xiàn)，這已經(jīng)是比較好的一種情況，更壞的情況（也是更常見的情況）是應(yīng)用已經(jīng)上架 App Store，用戶真正開始使用它之后才發(fā)現(xiàn)這個問題。無論是哪一種情況，設(shè)計師和開發(fā)者通常都需要進(jìn)行新一輪長時間的更新開發(fā)流程。

我們開發(fā)的是應(yīng)用，而不是原型

為了應(yīng)對這些難題，有人提出的一個解決方法是讓設(shè)計師學(xué)習(xí)編程。但是我的看法跟 杰西·韋弗爾（Jesse Weaver）一樣，我們都認(rèn)為這種做法既不可行，也難以接受。我們真正需要的對應(yīng)用整體有更好的理解——從它的編程基礎(chǔ)到表面的 UI 和藝術(shù)素材，并充分考慮到它在不同平臺上真正運行的情況。

我們還需要認(rèn)識到應(yīng)用開發(fā)并非一個線性的過程，它不像是把一個設(shè)計好的應(yīng)用直接交給開發(fā)者那么簡單。相反，設(shè)計師和開發(fā)者之間需要通力協(xié)作，在打造出引人入勝的外觀之余，他們還要保證這個外觀的每一步都能夠被實現(xiàn)出來。

現(xiàn)在已經(jīng)有越來越多的公司將應(yīng)用作為自己的唯一產(chǎn)品，因此按照這種方式進(jìn)行應(yīng)用開發(fā)就顯得更為重要了。