做一個app很容易，做出來使用者下載了，開啟了用了/快速瀏覽了一次就不會再開啟了。作者針對這種情況，講述了幾點在創業團隊/專案中應該做的和應該避免的事情。
譯者注：
文章背景：關於瓦薩號（來自百度百科）
“瓦薩”號戰艦是現存最古老的戰艦殘骸之一，也是世界上第一批風帆炮艦和當時世界最大的炮艦。它在處女航中離岸10多分鐘就沉沒了，直到300多年後，它才被打撈上岸。
你的團隊努力工作，要搞一個牛逼的移動 APP，經過數月的努力，最後到了釋出。所有的人都處於精疲力竭又無比興奮的狀態。你的構想很棒，但是，這個 app 最終成為了你們永無止境的噩夢：許多有需求的使用者下載了 app，在用過一次後，他們就再也不會開啟了。
你的團隊幾個月的辛勤工作的都廢了。
你會想：『到底哪裡出錯了？』
你的應用程式變成了新趨勢的另一個受害者：現今41%的的應用程式只使用了一次就被拋棄了。這個趨勢和400年前瓦薩號戰艦的故事有些相似。瓦薩號由於基礎設計的問題，在他的處女航就沉沒了。
瓦薩號，在stockholm的博物館。 影象來源：Greg Nudelman
在這篇文章中，我們將探討如何從瓦薩號戰艦沉船的教訓中，幫助你的移動專案避免沉船。
一、建立一個清晰的、引人注目的構想
雖然瓦薩號最終失敗了，但這毫無疑問是一個偉大的作品。他的建造者們都不敢否認他的偉大。
所以，在討論專案中錯誤的因素之前，我們應該簡要的談談正確的因素：戰艦的建造者打造了一個關於皇家戰利品和驕傲的巨集偉的視覺外觀。即使在400年後，戰艦的視覺外觀也是吸引人的。美麗的手工藝製造，喜氣洋洋的描繪著神話雕像，令人聞風喪膽的武器，和戰艦的整體外觀。
放在今天，也是偉大的視覺景象。影象來源：Greg Nudelman
你正在設計和開發的移動應用程式之前，你必須清晰的知道你要做一個什麼應用，還有你的應用將會給使用者帶來什麼好處。
幸運的事，表達一個移動應用的構想時很簡單的。你可以在20至30分鐘內，僅僅用手畫標籤來建立一個應用基本使用情況的故事板。
有一個很好的例子，我的書《1美元原型》中的“英雄”的故事版：
“英雄”app故事版 from 《1美元原型》影象來源： Greg Nudelman
這個故事版展現了強大的使用者案例：一個人想提供資金給他自己選擇的颱風救災慈善機構。得到的好處清晰可見：這個人通過捐贈，得到做英雄的感覺，而災難的倖存者也會得到緊急的幫助，去開始重建他們的災後生活。
根據財富雜誌統計資料，大多數創業失敗的原因之一是，他們製造了一個沒有人想用的產品。要確保你的移動應用專案不會變成另外一個資料，一定要制定一個讓人興奮的構想。在做任何實質的設計和開發工作之前，花一些時間去製作你的構想的故事版。然後給你的潛在使用者貨和利益相關者看看，確保所有的關鍵人員的反應是熱情的。
你的構想必須是傳達一個明確的、令人信服的好處；否則，應用將不值得被開發。一旦你的構想到位，就到了設計和原型解決方案的時間了。
二、儘早測試，然後通知管理者
當瓦薩號的計劃首次向瑞典國王提出時，他已經造成了兩個致命的改變。一個是武裝了重24磅的大炮。第二個是為了讓戰艦快一些，把戰艦建造的很單薄。
很多人認為，如此相近的設計指導，意味著國王要親自監督施工。但事實並不是這樣的，國王只去碼頭看了一次。
事實上，第一次穩定性測試直到瓦薩號下水完全裝備後才進行。正如維基百科說的：開船時三十個人來回穿過上層甲板跑動，但是他們只進行了三次就被艦隊司令喊停了，因為他擔心會翻船。
儘管穩定性測試失敗了，但是現在開始更正修改還不算為時過晚。但是沒有人想給國王帶來壞訊息，他們都堅持說，這艘船馬上就要出海了。
最後，我們可以說，國王確實得到了他想要的，但是卻不是他需要的——一艘令人震驚世人的戰艦，卻出海一英里就沉沒了。
因反饋或改變而執行修改的建議性設計是沒有錯的。反饋和改變二者都是絕對必要的，他們是任何重大專案的一部分。這裡缺少的是早期的概念測試和及時反饋迴圈。
正如你的構想一樣，在每個設計和開發階段原型都需要充足的測試，將測試結果傳達給正確的人同樣重要。起關鍵作用的人需要成為解決方案的一部分，否則他們將成為問題的一部分。
作為一名設計師，你的工作是向管理人員提供及時反饋。儘早清晰的傳達所有產品問題的同時，問題也可以得到解決，以確保向著最好的設計邁進。
如何確保你的反饋得到執行？在這裡，一個簡易的可行的原型可以是非常有用的。
三、建立一個MVP:最簡易的可行的原型
2015年秋，在斯德哥摩爾的一個會議上，我進行了一次演講，趁這個機會我去參觀瓦薩號戰艦博物館。
在博物館裡，在打撈出來的瓦薩號旁，有一個1:10大小的原船模型，模型看起來是他喪命的那一天的樣子。這個模型，理想的精煉了原船的設計。任何人都可以看得出將船身造的更薄更高並且在船頂載入了沉重的大炮會損壞船的穩定性。
瓦薩號戰艦博物館裡的1：10瓦薩號模型 影象來源：Greg Nudelman
然而，這個1:10模型是在瓦薩號沉沒後製造的，是給我們總結出一個教訓的：建造一個你的移動應用產品的模型，儘早獲得可執行的反饋，並且在開發之前細化設計。
幸運的是，在今天，建造一個app的模型是很簡單的——你不需要木板，或者其他特殊的裝置或軟體。而且更好的是你的設計和你的原型可以是相同的。
你需要的是一包3＊5英寸的便利貼：
便籤移動應用原型影象來源：Greg Nudelman
例如，“英雄”app的最簡易的可行原型：
“英雄”app的最簡易的可行原型 影象來源：Greg Nudelman
有了這個簡單的原型，你可以快速簡單的測試和細化你的app的基本設計的各個方面：資訊架構、互動設計、等等，你甚至可以測試圖示和變化。
精益生產過程都是關於實驗的。通過建立簡易的可行的原型，建立實驗，並直接向潛在客戶進行測試，無論在內部和外部都可以顯出加快實驗的過程得到反饋。
從本質上來說，你將失敗轉化成了最便宜最有利的形式。
當你的app起動時，早期持續的原型使用者測試能減少任何致命的設計問題，大幅度增加了你成功的可能性。
四、早期的設計微調促使所有環節的差異
當瓦薩號災難很出名時，很多人不知道瓦薩號的姐妹戰艦，蘋果號戰艦。蘋果號的建造者提出了兩個重要的修改意見：在上層甲板安裝更輕的槍，船體加寬1米（僅是瓦薩號原始寬度的10%）。
這些簡單的微調造成了蘋果號與瓦薩號的差異：蘋果號成功的航行了30年。
為了確保你的專案的成功，每年都進行測試，並且計劃好在一開始就進行大量迭代，直到設計稍稍安定。花時間和精力去投入到一個高清晰畫素級完美的設計，從一開始就起到的是反作用。
相反，應該適當的保持專案的原型的保真度。設計（資訊架構，互動，複製）的關鍵基礎是使用快速廉價的簡易可行便籤原型進行測試。
例如“英雄”app，團隊提出了一種設計方案，進行了五次主頁設計迭代，都用的是“便籤”原型。
“英雄”app的5次迭代 影象來源：Greg Nudelman
只有當團隊完善了設計的關鍵要素，才投入額外的時間來建立高保真原型：
“英雄”app的視覺稿 影象來源：Greg Nudelman
根據專案階段適當保持原型的保真度，能幫助團隊快速行動，在設計早期解決大多數問題，能夠使他們在短短三週時間內確立最終設計。
我不知道你怎麼看，但這聽起來像用低廉的代價避免沉船——甚至瑞典國王都會批准的事情。
五、確保你的app順利航行
你現在看到的瓦薩號的歷史能幫助你避免一些主要的災難——如果你遵循一些簡單而深刻的UX準則。
在你開始之前，把你的構想轉化成故事板。花一些時間讓潛在使用者和利益相關者進行測試——確保他們和你一樣，對你的想法保持熱情。
當你的構想被批准了，就可以開始用低保真原型做使用者測試。在這一點上，持續的快速原型和使用者的反饋形成你的app設計過程的核心。
在過程中，別忘了團隊中管理人員和其他關鍵性人物雙向溝通的重要性。
確保所有關鍵人物都在你的反饋迴路中，確保團隊中的每一個人感覺他們的想法是從開始就被考慮的。最大限度減少了所有人都能堅持最後一分鐘不能充分測試或執行的變化。
記得要把你的原型的保真度和專案的階段相匹配。在你確定設計關鍵點之前不要花時間和精力在高保真原型上。相反的，儘可能長時間的使用低保真原型，迅速測試設計微調，並不斷的結合得出的觀點回到原型中。
精煉、快速的原型，再加上一個不斷反饋的迴圈，能幫助你的團隊工作順利，開發出一個不是隻有首航的app，而是多年以來成功航行，令競爭對手恐懼的app。