[[142621]]

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

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

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

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

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

當我們談論移動應用設計的時候，我們通常所指的是應用在 Photoshop 或者 InVison 和 Pixate 這些原型設計平臺上面所呈現的形象，這些功能強大的視覺化工具可以展現出最終應用的外觀和感覺。

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

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

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

這點引出了一個相關的問題……

設計資源分配的矛盾

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

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

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

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

缺乏真實數據的設計

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

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

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

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

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

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