想了解 UI/UX，就一定要了解這張圖，這是 Jesse James Garrett 在 2000 年發表的使用者經驗元素一書中所提出：使用者的經驗可分成抽象到具體，也就是由策略、範圍、結構、骨架、表層所構成。圖片上有原作者的說明大家自己看吧。

這張圖是同一位作者提出的概念，同樣他也寫了很多說明，大家還是自己看吧。

這篇文的重點從這裡開始，我擅自把兩張圖合在一起比對，原始圖檔是分開的。合併後可以清楚看到每個階段包含的面向。以下是我自己的分析和筆記心得。

策略

使用者需求和開發的目的。

使用者需要什麼、建立這個 App/Web 的目標是什麼，這些都是整個專案最底層的根基，也是一切發源的基礎。基礎不穩越往上發展問題就會越多越大，所有炫又酷的介面、多到爆炸的功能通通比不上這個階段的重要程度。搞不清楚這個專案的目標是什麼就貿然開發…嫌錢多燙手可以捐給我，我好想去捷克看慕夏。這個階段主要活躍的角色會是 BD、PM、UI/UX。有時候 PM 和 BD 不那麼清楚要怎麼問才能從「出張嘴」的金主口中挖出開發所需要的情報，可以把這份工作交給 UI/UX，在這個階段加入 UI/UX 做訪談得到更多的資訊，能減少未來開發遇到問題的機率。

比如客戶說「我要能查詢美食餐廳、要有會員系統、能有社交功能」。這聽起來超龐大的對吧！但實際上客戶想要的搞不好就只是個列表、關鍵字查詢熱門餐廳資訊，帳號串接 FB 後能對餐廳按讚或按幹這樣而已，專案規模瞬間縮小很多。

延伸閱讀：使用者經驗藏寶圖：敘述故事、找出中心思想

範圍

找出需求與目的後以需求為基礎，整理出所有使用者可能會需要的資訊及功能，以愉快且有效的運用各種功能為出發點建構合理的互動模式與流程。

這個階段就是把抽象需求內容轉成可實行的功能，並訂定出 Spec。把所有需要的資訊、功能等全部列出，並歸納分類，以「策略」層決議的目標和需求為出發點，考慮各種操作方式。（再強調一次，同樣都是音樂播放器，列表型的和很炫型的就算功能大同小異，操作方式和介面設計還是會差很多。）

把所有可能會用上的功能、所有必需呈現的資訊、圖片等等全部用樹狀圖條列出來，方便 UI/UX 未來畫 UI Flow、方便 SA 制定 API ，也方便 RD 計算人日、PM 控管專案時程，好處多多。發現沒？這階段就是在做 Functional Map 啦！

延伸閱讀：初學者的 Functional Map

結構

把所有資訊整合起來，依使用者能直覺理解的方式組織成完整的概念。

既然「範圍」層在製作 Functional Map，那「結構」層就是在做 UI Flow 了，這個階段必需定義資訊、功能等要用什麼方式呈現。比如說 iPhone 上小張的美食照片只是預覽功能、需要「開大圖」，那大圖要怎麼個開法？點擊放大？只放大單張圖嗎？需不需要 Page Control ？還是在該頁把手機橫拿就會自動把圖片放大滿版？這階段訂定的 Flow 會左右介面的長相。

延伸閱讀：初學者的 UI Flow

骨架

結合介面設計、資訊設計、導覽設計三者將資訊做視覺化的呈現，協助使用者理解資訊。

畫 Wireframe 的時候到了。之前已寫過很多關於 Wireframe 的文章，就不多廢話。

延伸閱讀：什麼是 Wireframe ? 、為什麼要畫3次 Wireframe？

表層

以視覺與感覺為基礎，設計介面元素如文字、頁面的視覺圖像、導覽元件等。

簡單來說就是「最終這個 App/Web 要帶給人什麼感覺？」要注意的事項太多了，Guideline、UI Style、Graphic…上 Dribbble 看看高手們的作品找靈感吧。在這階段牽涉的東西非常廣泛，不止是視覺，連聲音、震動等等都可包含在內。隻字片語無法完整表達，有機會我再寫新的心得文章（又在挖坑了）。

圖片出處：http://www.sccc.premiumdw.com/web202/the-user-experience
書：http://www.jjg.net/elements

當你看到這行字，表示文章已大略看過，多少了解我想表達什麼。請捲到最上層重看一遍 Jesse James Garrett 提出的這 2 張圖。相信能夠更理解使用者經驗元素和實現方式。

題外話：有沒有發現什麼端倪了呢？當手上的理論和資料一筆筆分開來看都沒什麼感覺，整理分析後再合在一起就很有種「天下武功出少林」的感覺。說穿了天底下所有的事都有一定的軌跡可循，包含 UI/UX 。很多大師的理論資料看到後來都在講同一件事情，只是舉的例子、切入角度、實行的手法略有不同罷了。就跟無論什麼專案、拆分到最後就只是「需求」和「功能」一樣。