移動應用開發過程中的迭代式原型設計

\

主要結論

\

• 移動應用原型建立過程中採用迭代式快速開發方法的重要性。 \
• 可以從對手身上學到什麼，如何從他們的失誤中獲益。 \
• 如何為你的應用定義USP，如何通過故事板（Storyboarding）、使用者場景和故事圖（Story-mapping）為自己挑選出最理想的使用者。 \
• 如何使用紙面原型匹配團隊的預期，並專注於共享的最終交付成果。 \
• 如何使用原型工具收集、管理和驗證需求，進而在無需進行太多文案工作的情況下讓產品解決方案具象化。

\

根據Yahoo Flurry提供的資料，消費者使用手機的時間中有超過90%用於各種應用。移動應用市場的增長速度和持續發展趨勢使得應用設計人員必須在移動應用開發工作中實施一種更迭代的方法。移動應用的開發過程與網站的開發大不相同，生命週期變化更頻繁，開發者需要在設計和使用者測試階段考慮不同的裝置種類、螢幕解析度，以及作業系統。傳統的網站開發方式以建立一個最終版本網站為目標，這種方式無法適應移動應用開發的需求，因而需要更敏捷的方法。\

毫無疑問，所有這些因素迫使開發者必須採用迭代式的快速開發過程。原型是這種敏捷方法中必不可少的，可以幫助開發者以更低的成本快速進行構建、測試、迭代、重新測試，以及重新構建的過程（當然也能讓利益相關者儘早參與到整個過程中）。UI設計的原型也是移動應用設計過程中一個重要的組成部分。\

本文將移動應用的開發過程分解為12個步驟，並介紹了迭代式原型建立工作在不同階段扮演的角色。\

第1步 – 定義應用的目標或USP

\

移動應用最終能否獲得成功，靈感很重要，但靈感必須歸納整理為最終成果所要包含的清晰明確的目標。在將應用投放市場的過程中，第一步需要提出並回答一些核心問題：應用的主要功能是什麼？主要是為了解決什麼問題？主要受益者或受眾是哪些人？\

為了探尋這些問題的答案，可以首先考慮一下如何能讓自己的應用變得更有“粘性” – 使用者在自己裝置上安裝你的應用，並與你的品牌隨時隨地建立聯絡的原因是什麼。應用為品牌忠誠度的促進提供了一個絕佳的機會，因此有必要在開發過程中針對最終成果為使用者定義USP（Unique selling proposition，獨特賣點）。例如Spotify的USP是讓使用者以合法方式隨時隨地欣賞數百萬歌曲。很可能在開發工作開始時，Spotify員工就確定了使用者直接面臨的問題或情況：有關非法或免費下載的顧慮，以及移動化生活方式的逐漸流行，他們的所有工作都以解決這些問題為主。\

為了制定強有力的USP，無疑需要對目標受眾進行妥善分析，因此在應用開發的這個階段，需要發現最理想的客戶以及他們的痛點/愉悅點。使用者群體劃分和調查問卷可以幫你為不同型別的使用者建立檔案，進而提煉出普適的移動應用首選項和行為。\

確定目標、USP以及目標受眾，即可幫助自己定義最小可行產品（Minimum viable product，MVP），以及在構建完整解決方案之前進行測試進而指導開發工作的產品功能骨架。\

第2步 – 與團隊一起在紙上建立線框

\

確定了目標以及自己的獨特之處之後，可以開始通過諸如Photoshop之類的工具設計介面。但如果需要團隊協作（哪怕孤軍奮戰），還需要退一步在紙面上建立線框（Wireframe），這樣如果隨後需要改動設計中的某些基礎元素，這一過程也會顯得更快捷和簡單。\

通過擬定粗略的紙面原型將重要功能和主要使用者流程實現具象化。雖然紙面原型通常主要用於規劃個別UI，但只要恰當使用也能幫你設計使用者操作流程和導航流程。此時可以一切從簡，只使用馬克筆和貼紙規劃自己的應用，但其實也有很多實用的工具和模板可以幫你更順利地完成紙面線框過程。網上有很多可供下載的移動裝置螢幕模板，配合鏤空的按鈕和圖示（也可以在網上下載）即可建立足以拿給潛在投資人看的紙面原型。如果打算針對某種特定作業系統進行大量開發，還可以考慮使用UI Stencils等金屬模板，這些工具可以幫你更便利地通過模板為iOS和Android建立線框。\

無論最終選擇哪些工具或方法，現階段需要讓每個團隊成員瞭解你的最終目標。做到這一點後，即可考慮用數字化的方式在原型工具中建立線框。\

第3步 – 研究競爭對手，從他們的錯誤中學習經驗

\

僅在2015年，每天平均就有1000款應用提交到Apple的應用商店，很有可能別人已經在試圖解決你正在嘗試解決的問題，或已經為使用者提供了類似功能。對於這些競爭對手無需過於警惕，但你可以從他們的成功和失敗中學習經驗。\

研究競爭對手可以讓自己在四個重要方面獲益：\

• 發現有誰正在從事和你一樣的事 \
• 從中獲得靈感 \
• 洞察技術需求和功能 \
• 在市場需求和盈利能力方面獲得榜樣

使用相關術語或關鍵字在應用商店和Google Play搜尋，深入瞭解相關應用和它們的條款。可以考慮將所有相關應用都記錄下來並仔細檢視客戶評價，同時還可以考慮通過各種線上論壇瞭解使用者在實際使用中的感受。\

如果某個現有應用包含一些你非常喜歡的功能，可以看看這些應用是否用到了開源控制元件。為此可檢視應用的致謝頁面，其中通常會列出應用中使用的開源元件，你也可以使用類似的元件開發出更出色的使用者體驗。開源“商店”Cocoa Controls提供了豐富的資源，你可以在這裡查詢競爭對手用到的開源控制元件。\

當然也可以通過詳盡的競品分析瞭解自己有關應用的絕妙創意是否已經被別人成功開發併發布出來。如果你的應用解決方案已經有類似成品，可以通過品牌認知度或感知度工具瞭解對方的表現，或通過免費工具掌握市場對競爭對手產品的品牌看法。\

如果無法確定自己的產品能為現有市場帶來什麼價值，或者無法制定穩妥的風險緩解策略，也許應該就此作罷轉向下一個移動開發專案。設計和開發過程中的所有細節都要記錄在案，就算專案在這一階段徹底終止也要這樣做，藉此可以通過學到的經驗教訓對自己的方法論進行持續的完善。\

第4步 – 故事圖和需求收集

\

確定目標和競爭對手後，可通過數字化或紙面記錄的方式將構思進一步完善。如果希望用模擬方式做到這一切，也許可以開始構建使用者故事，這些依然可以通過紙面方法進行，這是確保在將故事圖付諸實現前維持開放心態和創新精神的一種好辦法。\

儘管如此，通過傳統方式製作使用者故事圖的做法在某些情況下也會存在不足，尤其是涉及遠端團隊，或希望在整個設計過程中通過動態故事板保持實時和統一的情況下。如果決定通過數字化方式製作使用者故事，StoriesOnBoard和FeatureMap之類的工具提供了基於瀏覽器的解決方案，可以幫你將不同團隊聯絡在一起。\

雖然類似上文提到的故事板工具適合在很多專案中使用，但如果希望整體採用敏捷方法論，這些方式可能會妨礙到與報表有關的工作。此時你可能會希望改為使用互動式原型工具。在應用開發專案啟動時，可以通過Axure、InVision或Justinmind等數字化工具搭建基本原型的線框，這樣做可以幫助你拋磚引玉從利益相關者處獲得新的或更好的需求，並確保大家能對專案界限達成共識。\

這一階段中，基本線框可以讓為了解決第1步所確定的問題而開發的解決方案變得更形象，通過原型工具收集需求也可以免除擬定冗繁的需求文件需要付出的大量精力。\

第5步 – 定義使用者場景

\

藉助線框可確定應用能否按照你自己或客戶需要的方式工作，以及應用是否以使用者為中心。你可以通過原型工具建立和測試使用者場景，製作線框截圖以及需要由使用者執行的操作，藉此定義導航流程。可以在場景中將不同元件連結在一起，藉此為導航流程建立地圖。一旦開始通過線框建立保真度更高的原型，還可以將其轉換為功能流程。\

此時專案需求已得到進一步完善，可以向利益相關者演示整個工作流，並指出所有需要討論的領域。可以直接詢問利益相關者或客戶特定元素如何生效才能算作好的實踐，就好像“what-if”場景一樣通過討論整個流程發現隱性需求。你可以在原型工具中新增註解，這樣就算無法把所有利益相關者召集在一起，大家依然可以通過協作的方式繼續對需求進行完善。\

第6步 – 需求的更新

\

在這一階段你可能會發現，自己漏掉了某個螢幕截圖，某個導航流程走上了一條崎嶇的單行道，或者沒能充分滿足某個需求。在開始為應用編寫程式碼前，此時是發現所有此類問題的最佳時機。可以在原型工具中對需求進行定製，針對特定需求新增新的欄位。\

第7步 – 構建高保真度原型並引入利益相關者的意見

\

當需求經過全面修訂並達成共識後，還需要將靜態模型變為高保真度原型。可以為現有線框增加實際的動畫和過渡效果，藉此展示可以實現的互動並對前期假設的場景進行測試。\

在不實際編寫程式碼的情況下轉換為互動式原型，意味著後期在設計和開發團隊之間“詮釋”（理解、誤解）的空間會比較小。\

第8步 – 針對不同移動作業系統對原型進行使用者測試

\

使用者測試是開發優秀移動應用的基礎，通過測試可以發現Bug並找出以往可能沒有注意到的多餘設計元素。使用者測試階段也是確保專案能在預算內完成的關鍵：對於針對基本UI概念已經寫好的程式碼進行更改，成本並不會很高，但對已經編寫好的功能進行大量改動會產生不菲的成本，如果整個應用都要改動，有時可能會讓成本翻倍。\

使用者測試可通過多種方式進行，選擇恰當的軟體組合可以確保整個過程的實現更為徹底。諸如Validately和Crazy Egg等使用者測試軟體可以幫你在無需自行搭建測試實驗室的情況下針對目標受眾和硬體進行測試，很多原型工具也能與此類軟體全面整合。通過將這些工具與自己的A/B測試或其他技術配合使用，即可針對不同作業系統對高保真度的原型進行測試，藉此可獲得大量的使用者反饋。\

然而也要注意，雖然針對原型進行早期測試是縮減成本的關鍵，但也絕對不能將實際程式碼和軟體的測試放到最後進行。取決於具體專案，你可能希望在這一階段暫時忘卻原型，讓開發者將你的創意用程式碼寫出來。使用者到底是如何與實際軟體互動的，沒有100%精確的替代方法可以不借助程式碼完全體現出來，對軟體程式碼進行迭代可以保證你能始終維持敏捷。\

第9步 – 驗證需求

\

在應用開發專案的這個階段，可以在開始寫程式碼前針對迭代原型核查最終的規則。對於依然在使用靜態需求的專案，可以進行全面的文件審閱；對於互動式原型，可將提議的解決方案分享給所有利益相關者，並根據他們在原型工具中留下的註解對原型進行迭代。\

第10步 – 讓開發者打好基礎

\

至此手頭已經有了一個清晰定義的應用，可以引入開發者讓他們為敏捷開發衝刺打好堅實的基礎。作為基礎，開發團隊需要設定API、伺服器、和儲存，通過需求和原型讓他們更好地瞭解從何處著手開始迭代。\

第11步 – 構建你自己的UI外殼和反饋週期

\

藉助從利益相關者和使用者測試中獲得的註解，開發者已經可以將原型的截圖和互動轉換為更高保真度的外殼。開發者可以選擇使用Kinvey等後端服務，並使用Adobe PhoneGap等SDK工具完善自己的前端。隨著後端的逐漸推進，此時專案的重點應轉向資料儲存和整合，以及伺服器端邏輯和版本控制。前端方面，此時可以將原型的螢幕截圖硬編碼至UI中。\

無論開發團隊使用何種技術，此時技術方面的首要目標是維持以使用者為中心的角度，並將之前獲得的使用者反饋納入考慮範圍。\

開發團隊的管理方面應該以敏捷為主要目標。為了保持敏捷，開發團隊應當對靈活性、快速的變更響應、迭代式方法，以及必要的使用者協作等工作劃分處輕重緩急。為了順利實現自己的想法，可以安排整個團隊進行Scrum衝刺，但也要注意Scrum有時候也會造成一些問題… 無論如何安排，迭代式開發和使用者體驗始終應該是整個過程的核心。\

第12步 – 使用者測試… 再一次

\

專案尾聲階段，移動應用的程式碼應該已經編寫完成並已能夠執行，其中不應該包含無用內容，UI元素也已進一步打磨完畢。但在歡呼慶祝前還要記得針對所有裝置和不同型別的使用者再進行一輪使用者測試。如果專案預算不足以支撐最終階段的使用者測試，還可以考慮其他方法：引入ATryBox等“使用者市場”，讓他們尋找合適的使用者群體並進行測試，或者也可以使用測試應用，例如Validately或Framer。\

如果希望通過使用者測試獲得更多創意，進行醉酒測試（Drunk testing）也許可以為你提供很多出乎意料的意見。\

然後該幹什麼

\

迭代式原型是移動應用開發過程中的“大殺器”。從以使用者和使用者故事為中心，到前端/後端工具以及最終的使用者測試，每個開發專案在最終實現和釋出之前都需要經歷一系列環節。雖然這些實踐可以幫助你安排自己的任務和預期，但沒有任何兩個移動開發專案是完全相同的：藉助不同的工具和方法論讓你的團隊實現積極主動的反應、協作和創新，最終即可獲得能滿足使用者需求，提供出色使用者體驗的應用。\

關於本文作者

\

Cassandra Naji是Justinmind的營銷內容編輯，這款營銷工具可供你為Web和移動應用建立原型，在無需編寫任何程式碼的情況下使得軟體解決方案具象化並對其進行測試。在轉型為科技愛好者之前，Cassandra曾在柬埔寨和臺灣地區擔任傳統媒體記者和通訊專家的職務。現在她居住在西班牙巴塞羅那。

\

作者：Cassandra Naji，閱讀英文原文：Iterative Prototyping in the Mobile App Development Process