透過實作來快速成長！
深夜小報 陸號刊
前進 UI/UX 的敲門磚：如何打造具用戶思維的作品集
撰文
圖文設計 Daniel & 對於想進入 UI/UX 產業，或是想持續在該領域精進的設計師來說，整理作品集這件事，一直都是個有效檢視目前所學，回顧過往經驗的一個好方法。
曾在一次演講中聽 Frog Design 的創意副總監 - Genda Lin 說過，設計師們可以嘗試每半年就整理一次作品集，並藉由應徵上的試驗，來審視自己的設計能力，並同時趁這機會了解各個產業目前發展的方向，與他們所在意的技能又有哪些。
值得注意的是，這裡指的並不是為了作品集而做作品集。而是像 Genda Lin 所說：
作品集是一個結果，真實反應一個設計師在解決問題與創造時的思考與動手反應，最重要的學習不是把作品集完善，而是反過來調整未來工作的方法。
作品集除了可以很坦白地讓我們了解能力界限之外，也是獲取面試入場卷的必經之途。以面試官的角度來看，要從雪花紛飛般的求職信中，篩選出未來想一起共事的候選者，作品集本身勢必要有足以引人注目的特點，才能有機會從中脫穎而出。
那麼在整理作品集時，需要留意的地方會有哪些呢？
在《設計遊牧》的 Podcast 中，於美國新創 Modus 擔任 Design Lead 的 KC 就提到，她在審視應徵者的條件時，每一份作品集只會花 10 分鐘。
而《矽谷 UX Coach 幫你看設計作品集|作品集審查》一文中，於美國 Google 擔任 Sr. UX Design Manager 的 Nick，更也強調說一份好的作品集，應該要能夠在 100 秒內抓到面試官的心。
這時難題就來了，在這麼短的時間內，我們應該要如何整理作品集最適切的面貌，才能把握住這稍縱即逝的機會呢? 就讓我們繼續看下去。
文章目錄⊙ 如何組織作品集的結構
⊙ 來看看實際上作品集的樣貌吧
⊙ 找到對的問題並解決，才是作品集的關鍵
如何組織作品集的結構
一份作品的重點，在於清楚說明你在這個專案中面臨的問題是什麼，而你又是如何解決，來提出能滿足使用者需求的商業方案出來。
這是個端對端 (End to End) 的設計流程。先從釐清真正的問題是什麼開始，嘗試以不同的維度來切入，並從這連續不斷的探索過程中找出最有效的解決方法。整個過程最困難的地方，莫過於定義到底所謂的「真正的問題」究竟是什麼。
💡 找出值得我們捲起袖子解決的問題
在找出問題的過程中，可以運用 Google 所提出的敏捷式設計 (Design Sprint) 方法中的 HMW，來找出問題所在。
HMW 是 How Might We 的縮寫，代表的是「我們可以如何」來解決我們所認為的問題。這是一個問句式的寫法，主要目的是透過一句話的陳述，短而有力地定義問題與接下來要前進的目標是什麼。
例如，我們平時關心的或許是 ，「我們可以如何降低每次禮拜一上班時的憂鬱感呢？」(是有多麽不想上班XD) 這就是透過 HMW 的陳述，來導引出問題的方法。
HMW 定義出來的問題，是可以根據使用者訪談後得來的結果來加以調整的。因為我們很難能在第一次就找到根本性的問題，更多的是我們透過一次再一次地訪談，才能逐步梳理出問題的根源。
那麼 HMW 實際上可以如何用來找出問題呢？這裡舉個例子。
運用 HMW 釐清問題
這是之前在演講中聽到蠻精彩的案例-iCAN，該專案的開始，是設計師發現自閉症孩童多有著語言學習上的障礙，因此一開始定義的 HMW 問題是「如何幫助自閉症孩童有效地學習語言？」
然而在多次的使用者訪談後，卻了解到目前自閉症孩童學習語言的方式，其實是透過一張張手繪的單字圖卡來學習的。這也意味著，對於製作這些圖卡輔具的家庭來說，是個多麽大的心力負擔。因此 iCAN 再度調整了 HMW 的敘述，即「如何幫助家庭照顧者降低製作輔具的負擔？」
可以發現原本定義的問題有了一百八十度的轉變，目標使用者更也從自閉症孩童，轉變成照顧者。
這個過程，就如台科大唐玄輝教授所說的：
問題梳理的重點是獲得洞見，改變設計目標。
透過 HMW 的定位，可以讓我們清楚知道後續航行的方向，也才能有效找出那些真正需要滿足的需求。
想了解 iCAN 精彩的設計過程，可以點擊這裡 👇
🚀 明確闡述你所扮演的角色
找出核心問題後，接下來就是要在作品中提及自己在專案中扮演的角色為何。在商業專案中，其利害關係人往往涵蓋到各個部門。
因此如何在自己負責的環節中，清楚敘述是如何與各個部門推進專案的進行，如何在時程、技術與商業目標的框架下執行專案的目標，就能適切地展現出跨部門的合作能力，與跨領域解決問題的經歷。
而這也正是許多面試官在意的人格特質之一。
📙 故事化你的作品內容
這裡要展現的是具體執行上，我們是如何解決問題的能力。藉由 HMW 揭開故事的序幕，明確指出這個問題為何值得投入的原因。
在故事架構的組成上，可以運用 BloomReach 的 Director of Product & UX-Albert 所提出的四個組成作品的環節：「研究 (Research)」、「分析 (Analysis)」、「設計方案 (Design Scheme)」及「商業影響 (Business Impact)」，來構築出在我們設計過程中跌宕起伏的故事劇情。
研究(Research)
那麼具體上要如何應用呢？ 一樣以前述案例為例。iCAN 起初透過「研究」，找出關鍵的問題在於圖卡製作上的麻煩，而不是自閉症孩童如何學習語言這件事情上。
分析(Analysis)
接下來，透過進一步的「分析」了解到自閉症孩童在學習的過程中，要尋找特定的圖卡其實是一件很不方便的事。且孩童在學習這些字詞如何發音時，是需要照顧者不斷地重複唸這個字詞。如此所需要投入時間與心力，可說相當龐大、超乎旁人所想像的。
設計方案(Design Scheme)
針對這些痛點，iCAN 於「設計方案」中對於尋找不便的問題，設計出分類與搜尋的功能；而在於字詞如何發音的學習上，則開發出語音播放的操作。透過將痛點轉化出實際上可以執行的功能，如此也讓專案前後的發展能夠相互呼應，形成一個具有邏輯架構、又有鋪陳引導的好故事。
商業影響(Business Impact)
最後，作品本身的成熟度，來自於最後有達到哪些商業指標，而這些指標又是否有環扣到一開始設立的目標。iCAN 也因為明確解決了使用者的痛點，最後成功發展成一款協助自閉症孩童學習表達與認知的學習型軟體，在iOS 與 Android 上皆有代理商協助上市、銷售。
「商業影響」直接反應了這個專案，後續有達到哪些實際上的成效；一個具有影響力與商業效益的專案，是作品之所以成熟而能獲得認同的關鍵之一。
✨ 具思辨的個人觀點
作品中所呈現的內容，反應的是一個人的思考全貌。在專案執行的過程中，如何發現那些會影響成效的細節，如何獲得具有意義的洞察，再再展現出一個人在思考時的細膩程度。
以清晰而完整的邏輯，來將每一個努力投入過的專案，提煉出能讓人細細品味的故事，即是透過作品集來展現出具分析、思辨與執行能力的重要關鍵。
來看看實際上作品集的樣貌吧
提及這麼多作品集的整理脈絡與方法，想必大家一定會好奇實際上的作品集到底長怎樣呢？究竟該如何整理呈現，才算是一個符合標準、甚至超越期待的作品集呢？
在這裡就舉個過往負責過的專案，來看看作品是可以如何從「研究 (Research)」、「分析 (Analysis)」、「設計方案 (Design Scheme)」、「商業影響 (Business Impact)」各層面來做呈現，來完整敘述出整個解決問題的過程吧。
🔍 研究 (Research)
這裡舉的專案作品，來自於隨著公司的客戶日益增加，財務人員原本逐一向業務人員核對客戶資料再來建置帳務內容的方法，已然顯得不夠效率。
因此如何提升財務與業務之間的合作效率，便也成為專案的最大目標。
過往在工作分配上，是由財務負責所有客戶資料的建置與維護。但少了最瞭解客戶狀況的業務幫忙下，財務很難即時掌握客戶資料的變動，來回不斷的核對與修改，也讓雙方的溝通成本居高不下。
就專案初始所遇到的情況來說，可預想的最好解法，就是讓業務接管客戶的資料與維護，而財務則負責最後的資料的審核。因此用 HMW 來定義問題的話，就會是「如何建置具資料管理與審核功能的帳務系統？」
透過 HMW 定義核心問題
但在後續焦點團體的訪談下，卻也了解到客戶資料的建置，牽涉到客戶所使用的服務種類。且往往客戶不只使用一種服務，可能會多達十幾種之多，後續服務採購上也還可能衍伸出折扣、拆帳等需求。
因此如何針對這些多變的複雜狀況，設計出能讓財務與業務能隨時檢視、更新來確保資料正確性的方法，便也成為接下來需要思考的方向。HMW 的問題定義，更也轉以「如何有效提升財務與業務人員間的合作效率？」為主軸。
📌 分析 (Analysis)
由於公司所提供的服務，都是以雲端服務為主要的營業類型。在雲端服務的類別超過數十種的情況下，要以舊有人工方式逐一檢視四百多家客戶所採購的服務，是比較緩不濟急的方式。
減少重工的可能
在經過訪談、功能上的發想與討論下，了解到若我們能夠透過自動化處理方式，來處理這些比較偏向重複性的工作，那麼財務與業務便能更有時間來檢視客戶資料的正確性。自動化處理也能加快資料建置的速度。後續客戶服務上有任何變動，更也能透過系統提供更彈性的調整與即時資料的查詢。
那麼自動化處理主要是針對什麼呢？最主要的就是讓客戶的帳務資料與它所使用的服務來做綁定。例如，客戶一但確定要使用某項服務，業務建置好資料，財務審核沒問題後便按下「許可」按鈕；客戶這時便能使用服務，同時每個月也能拿到當初設定好的帳務資料。
將重心放在資料管理上
讓一個按下按鈕的動作，同時綁定了資料的正確性與否，以及服務是否開通這兩項功能，藉以節省額外不需要的重複操作，讓財務與業務能更專心管理與維護帳務系統。
資料管理之所以這麼重要，原因在於除了服務類型繁多導致資訊管理不易之外，要應對四百多間客戶的各種拆帳、費用折扣等需求，無形間也放大了資料管理本身的複雜度。
為此於接下來於設計方案中，我們便也開始針對各種可能遇到的問題，思考並設想出適宜的設計方案來加以解決。就讓我們繼續看下去 😃
✒️ 設計方案 (Design Solution)
首先，為能讓財務與業務在需要的時候，能快速了解每個客戶的狀況，為此在功能開發上，即構想出於客戶的資料管理頁面中，設計上了能代表客戶狀態的標籤 (Tags) 功能。
運用標籤來分類管理客戶群
透過標籤的分類，財務能快速知道有哪些客戶已經能正常使用服務，而又有哪些客戶是還沒審核過的，進而針對這些已分門別類好的客戶資料，來與業務做快速的確認與溝通。
同時，業務這邊也能根據財務在留言板 (Message Area) 上留下的註解，來了解有哪些資料是還有需要修正的地方，形成一個財務與業務雙向交流與方便合作的管道。
當我們運用了標籤，來分類管理各不同狀態的客戶群後，這時我們便再進一步思考，如何針對客戶可能使用多達十幾種的服務類型，來做更細部的資料管理。
這裡的資料管理，不只記錄著客戶目前使用著哪些服務，更也著重在如何讓後續出帳能更加地方便，且也要讓財務與業務能直觀地迅速查閱。
每一種服務代表著發票/請款單中的每一筆明細
由於每一種服務的費用可能都不一樣，因此要有效整理客戶所使用的服務數量與最後應付的帳務金額，最直觀的設計方法就是將服務記錄成每張發票/請款單中的每一筆明細。
所有明細加總起來即為該筆發票/請款單的金額
如此一來，要知道某個客戶所使用服務的數量，只要直接看發票/請款單的明細就能知道，同時更也能順便知道這個客戶的每月出帳金額是多少。
於系統設計上，即以財務與業務所習慣的 ServiceSet 為命名，來代表每個月所出帳的發票或請款單 (國外沒有發票)，而 SeviceSet 底下的 Service 則代表發票或請款單的明細。
如此劃分，也能方便客戶去做拆帳上的需求。例如，當客戶想要更了解旗下各部門的業績，便需要將所有使用的服務再細拆成以部門為單位來計算 (如此才能算得出各部門的成本)，這時我們運用 ServiceSet 即能輕鬆地根據部門去做拆帳上的需求。
此時，財務與業務更也能透過 ServiceSet 與 Service 的層級結構，來快速掌握目前客戶的帳務狀況與雲端服務使用上的情況。
以卡片式設計來整理發票/請款單與明細
以卡片式方式來管理 ServiceSet 資料 (發票/請款單)，優點在於卡片的方塊結構有著極佳的擴充性。即使客戶想拆帳拆到多達十多張，只要將卡片依序排列於頁面上，即能輕鬆地透過滑動來查找想要看的 ServiceSet 資料。
倘若想要進一步看 ServiceSet 裡的 Service 資料，只要點擊 ServiceSet 卡片來加以展開，就能看到同樣以一張張卡片來管理的 Service 資料 (明細)。
卡片式的層級結構，可以方便順應客戶的各種需求來做資料上的建構。如此即使公司所提供的服務持續增加，或是客戶有著各種拆帳與服務使用上的需求，都能透過卡片式設計來加以有效管理。
運用標籤頁來為客戶資料做細分
每個客戶所需要整理的資料，其實不只包含前述所說的 ServiceSet (發票/請款單) 與 Service (明細)，還包含合約與過期合約等各式資料。
由於我們沒辦法預期財務與業務每次進到客戶頁面時，會想要看到哪些資料。因此要針對這些有著不同屬性的資料進行分類，最有效的方法便是透過標籤頁 (Tab) 來為這些資料來分門歸檔。
標籤頁的好處在於，使用者一進到客戶頁面，可以自由選擇所欲查看的標籤頁；當要切換觀看另一個資料時，也能方便透過在頁面上方的標籤頁，隨時做點擊切換。
自動歸檔的 ServiceSet(Old) 標籤頁
除了前述所介紹到負責統整客戶所使用服務的 ServiceSet 標籤頁外，在客戶頁面中還有著 ServiceSet (Old) 的標籤頁。
ServiceSet (Old) 收集著所有合約到期後的 ServiceSet。系統會根據合約的到期日，自動將已到期的 ServiceSet 資料從 ServiceSet 標籤頁移自 ServiceSet (Old) 的標籤頁裡，同時也會將自動關閉客戶使用服務的權限。為財務與業務省下每次核對合約日期所需的龐大時間。
收錄過往所有發票/請款單的 Invoices 標籤頁
接著，於 Invoices 標籤頁中則統整著客戶每個月的發票/請款單資料。以表格形式記錄著過往每次的出帳，使用者只需透過月份去搜尋，即能快速回朔過往的出帳情況。
線上管理帳務檔案
若進一步點擊 Invoices 標籤頁中，表格裡的每一列 ServiceSet 列表，則能進到統整著該月份所出帳的發票/請款單內頁，財務與業務能於此上傳最新的帳務資料，以平台化的方式方便雙方能隨時根據客戶需求上的變動，來做檔案上的共同管理與更新。
🏢 商業影響 (Business Impact)
在以「如何有效提升財務與業務人員間的合作效率？」為核心理念下，我們設計了一連串從資料建置、審核到管理的系列流程。
為此也成功替財務與業務省下 60% 的溝通時間，降低財務來回核對資料的 30% 工作時間量，並將四百多位客戶導入進這次所設計的新平台中進行有效、即時的客戶管理。
💼 專案中所扮演的角色
在這專案中除了與各個利害關係人合作，以有效了解整個使用情境與脈絡之外，更重要的事，是與工程師合作來確認功能上的開發，除了是有吻合使用者的需求外，也需要確保是能夠在有限的時間內能夠開發完成的。
例如，財務發現業務在某些欄位中填寫的內容是有誤的，最好的方式是開發出能夠讓財務在該欄位中上標注的功能。如此業務就能迅速找到是在哪個 ServiceSet 的哪一個 Service 是需要調整的。
然後這部分對於後端來說，其實是個相當龐大的工程。考量時間有限下，便改以設計留言板 (Message Area) 讓財務能留下說明註解，而特定欄位的標注則列入後續版本更新時再進行開發。
整個過程中，最重要的是隨時與工程師核對並討論需求，以好在期限內設計出對於各個利害關係人都能接受，且也能滿足需求的折衷方案出來。
找到對的問題並解決，才是作品集的關鍵
從一開始所提及的作品集的設計結構，到實際上解決問題的流程來看，我們可以發現到整個過程，並沒有強調我們應該用多好看的設計手法，來設計我們的作品樣貌。
反而看重的是，我們是如何透過使用者研究，層層抽絲剝繭地發現問題的根源。這個問題梳理的過程，不僅要跟著公司的目標方向走，也要針對使用者所處的情境與需求，設想並設計出能解決問題的最佳解法，進而讓我們的設計能帶來具有意義與效益的商業影響。
釐清什麼才是對的問題並加以解決，這個過程並不容易。就讓我們持續學習，一起往更好的設計師來邁進吧! 💪
想進一步了解面試官是如何評估作品集的，可以參考以下文章 👇
