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

主要結論

• 移動應用原型創建過程中采用迭代式快速開發方法的重要性。
• 可以從對手身上學到什么，如何從他們的失誤中獲益。
• 如何為你的應用定義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） 也許可以為你提供很多出乎意料的意見。

然后該干什么

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

 

來自：http://www.infoq.com/cn/articles/mobile-app-prototyping