移動設計和用戶體驗方法的關鍵要素

已發表: 2016-04-15

移動項目的生死取決於設計。 本專欄著眼於設計方法的重要性，並詳細介紹了英國製圖機構條例調查 (OS) 的數字設計過程。

雖然移動開發植根於從 Web 和軟件開發繼承的方法論——瀑布或敏捷； Scrum 和看板——對於您的移動項目的設計階段，沒有行業標準的方法論。

當您考慮到設計和用戶體驗 (UX) 對移動項目的成功有多麼重要時——公司和機構不得不開發自己的程序真是太瘋狂了……而且這些常常被證明是不夠的，這是可以理解的。

設計和用戶體驗階段是移動項目——或移動項目的新迭代——從偉大的想法轉變為開發人員可以開始工作的過程。

此過程中的步驟包括：

  • 項目的可視化——通常作為故事板畫在紙上。
  • 在目標受眾上進行測試，然後對其進行改進。
  • 獲得利益相關者的同意，然後對其進行改進。
  • 使用線框在紙上或數字上為項目提供結構、外觀和感覺以及用戶界面。
  • 再次測試，完善並獲得一致意見。
  • 創建原型——通常是數字的。

公司/機構可能會使用多種設計和用戶體驗技術和工具來實現這一目標——我們將在後續專欄中詳細研究其中的一些。

這些包括故事板、用戶旅程地圖、思維導圖、角色、線框、原型設計和最小可行產品。

瀑布或敏捷或兩者都不是？

軟件開發的傳統方法，通常稱為瀑布，是定義階段的線性過程：研究 -> 設計 -> 開發 -> 測試 -> 部署（或類似）。

雖然這使得設計只是開發過程中的一個階段，但優點是實際開發要等到設計完成並簽署後才能開始。

在 web 和特別是移動開發中，需要速度，需要同時處理項目的不同部分，定期進行測試並不斷增強和升級。

這導致了所謂的敏捷開發方法論的演變和廣泛採用，例如 Scrum 或看板，其中研究（包括可行性研究和受眾身份和需求）、設計、開發、測試和部署——在不同方面項目——可以同時進行。

以下是來自美國（新罕布什爾州）網頁設計機構 CommonPlaces 的瀑布和敏捷的最佳插圖之一。 然而，與許多機構一樣，該機構實際上混合使用了這兩種方法。

雖然敏捷性帶來了許多優勢，但設計過程可能會變得緊張、倉促、被忽視，或者如果外包，則會導致缺乏連續性和延誤。 這使得公司實施設計方法變得更加重要。 這不應該只是開發過程的一個子集，而應該是一種方法論。

定制 v 現成的設計方法

如前所述，沒有普遍接受的用於設計移動項目的方法，也沒有開發人員流程的等效方法，例如 Scrum 或看板。 但是許多公司和機構已經開發了自己的內部方法，有些已經與其他人分享這些方法。

其中之一是移動設計專家、設計機構 DesignCaffeine 的首席執行官 Greg Nudelman 稱之為 1 美元原型的精益 UX 方法。 該流程已用於 Intuit 應用程序、Wells Fargo、USAA 和 Oracle 的移動項目，並且是他的 UX 設計課程的基礎。

注意 1 美元不是書的價格，這是兩包便利貼的價格。 Nudelman 令人信服地認為，便簽是故事板和線框圖移動項目最重要的工具。 下圖顯示了 Nudelman 的一些學生使用這種方法繪製的移動項目。

我們將在未來的專欄中探討筆和紙以及便簽在數字設計過程中的價值。

實踐中的設計方法：條例測量圖

企業越來越普遍地使用具有代理背景的數字創意，因為這些創意帶有經過多年客戶工作磨練的設計方法。

英國的地圖服務機構條例調查公司聘請了英國先驅機構 We Love Mobile 的聯合創始人 Ben Scott-Robinson 來創建其內部機構來提供其數字產品和服務。

這是本·斯科特-羅賓遜（Ben Scott-Robinson），美國軍械測量局局長對 OS 數字項目設計過程的總結：

OS Agency 團隊在項目開始時進行設計衝刺。 我們從概述我們希望與客戶實現的情感參與的敘述開始，並將其作為開始完成用戶旅程的基礎。

以 OS Maps 為例，我們專注於創造一種稱為 Emotive Mapping 的體驗。 我們問：

  • 我們如何才能將人們對紙質地圖，特別是操作系統的情感共鳴帶入數字空間？
  • 我們如何才能製作出不僅功能強大，而且精心設計以提供積極情感參與的地圖？
  • 我們如何才能將人們從“位置”的概念帶入“地點”的概念？

這種關注是由現有客戶對傳統操作系統紙質地圖的參與以及對了解他們的直接環境的信念和信心推動的，而不僅僅是知道他們在哪裡。

從這裡開始，我們以相對標準的方式工作； 我們：

  1. 創建一個滿足敘述的潛在好處列表，並在受眾類型的代表中進行卡片分類。
  2. 利用這些好處，我們圍繞它們創建用戶旅程和故事板。 這些容易被騙。
  3. 再次測試受眾類型之間的旅程（始終根據圍繞敘事建立的標准進行測試），然後圍繞界面開始發散思維。
  4. 研究界麵類型，然後開始繪製界面。
  5. 從這些草圖中創建可點擊的原型，使用 Marvel 並使用遠程測試（例如 usertesting.com）來測試哪個有效。
  6. 開始在 Axure 中創建特定體驗的詳細原型（映射應用程序往往是多交互單屏體驗，需要非常複雜的工具）。
  7. 與開發人員一起驗證我們的設計是否可行！
  8. 再次進行遠程測試以消除乾擾； 然後使用受眾類型進行測試以獲得更詳細的反饋。
  9. 開始將體驗整合到產品中——再次使用 Axure——並開始簡化和調整交互。
  10. 然後視覺設計師參與進來，我們開始創建設計模式和全屏設計，這些都包含在原型中。 我們還研究了過渡和動畫的設計。
  11. 再次測試和測試，然後我們讓開發人員開始構建設計。
  12. 用戶體驗和視覺設計師被借調到開發團隊，在敏捷過程中與他們一起工作，參與規劃和支持問題，即時提供修訂，並處理邊緣案例。 OS 傾向於採用更多的看板方法而不是 Scrum，因為這更靈活，並且開發團隊的計劃開銷更少。

這是 ClickZ“適合移動設備的網絡 DNA”系列的第 16 部分。

___
安迪·法維爾