想了解 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 看看高手們的作品找靈感吧。在這階段牽涉的東西非常廣泛,不止是視覺,連聲音、震動等等都可包含在內。隻字片語無法完整表達,有機會我再寫新的心得文章(又在挖坑了)。

延伸閱讀:Photoshop技巧

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

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

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

comments powered by Disqus