一個完整的 Case Study 架構
最近看了許多設計師的作品集，有趣的地方是大家對於如何呈現作品，無論在形式上或者內容架構上都不盡相同，有點一個作品集各自表述的味道。
對於 Product Designer 而言，如何說一個好的故事比起 Graphic Designer 是更困難，卻也更重要的關鍵。因為設計流程本身就是在反映 Product Designer 如何思考，以及依據怎麼樣的邏輯做出設計決策，同時也反映了設計師本身的溝通能力，而這些恰巧都是優秀的產品設計師所應該具備的條件。因此這篇文章我想聊聊，對我而言一個完整的 Case study 應該是怎麼樣的架構，以下是架構中所包含的部分。
- Summary
- Role & Responsibility
- Background / Challenges
- Business Objectives
- User Study / Competitive Analysis / Workshop
- Design Tryouts / Wireframes / Information Architecture
- Highlights
- Outcomes
- Takeaways
Summary
摘要，以簡潔的文字說明專案的目的以及你最終產出了什麼。有點類似於一般寫在論文最開頭的 Abstract，讓讀者能夠在短時間對於這個專案的內容有大致的概念。摘要難的地方在於需要寫得足夠精簡，否則便失去了摘要的目的，但又不能過於精簡而讓人有看沒有懂。好的摘要應該像一部電影預告片，將兩個半小時的片長濃縮在兩分鐘裡，讓人理解故事大綱的同時又能夠激起觀眾想要進電影院一睹為快的慾望。
Role & Responsibility
在專案中所擔任的角色以及職務概述。當一個專案有多個設計師的參與以及跨部門的協同合作時，透過清楚地描述你的 R&R 讓讀者了解你在團隊中的定位與價值，而不是把所有的功勞都攬到自己身上。畢竟獨角獸設計師往往是可遇不可求的，面試官當然也知道，若你把自己描述的無所不能卻在面試環節被看破手腳，對你的印象分數只會大打折扣。
Background / Challenges
專案的背景脈絡。通常一個專案之所以會被發起（Initiate）往往是因為組織在面臨某種挑戰而需要採取行動，進行改變。因此我認為在描述專案的背景故事時一併帶出所面臨的挑戰，是一個讓讀者更容易進入狀況的寫作方式。一般來說新專案發起的驅動力我會大致分為三種類型：
- Business-driven：為了因應市場的變化或者商業策略的調整所發起的專案，通常是以 Top-down 的形式出現，意即由公司內部的關鍵決策者所發起。通常在專案的規模上會比較大，也會牽涉到較多的利害關係人，因此在處理這種類型的專案時透過 workshop 的形式取得團隊成員的共識會是不錯的設計方法。
- Data-driven：透過分析產品數據進而發現有哪些能夠優化的機會點，以這種形式發起的專案通常在目標的設定上會比較明確且合理，並且在前期較容易形成假設去影響到設計策略，因此要特別注意前期的假設並不一定正確，還是要畫時間進行探索以驗證假設的真偽。
- Design-driven：通常是為了提升設計的一致性，或者設計系統的迭代。從設計觀點所發起的專案往往會比較難定義成功的量化指標，因此在執行這類型的專案時，為了不要流於單純介面設計的優化，跟開發團隊一起制定出更有效率的產品開發流程我認為是一個不錯的發力點。畢竟很多時候設計師所面對的用戶不僅僅只是產品的使用者，還有與你共同協作的工程師與產品經理們，透過綁定彼此的利益相關性，能夠讓設計師在推動專案時更有力道，也更容易制定出成功的量化指標。
Business Objectives
商業目標通常是由產品經理所負責制定，也是主要用於衡量專案在上線之後是否成功的量化指標。假如你的設計產出沒有與商業目標進行綁定，便會很難透過數據說明設計在專案中如何產生價值。我認為產品設計之所以有趣的地方在於能夠作為商業需求與用戶需求之間的橋樑，在提供好的用戶體驗的同時幫助企業達成商業目標。
在目標的制定上，不同的企業與產品都會有各自的框架（Framework），常見的像是 AARRR、Google HEART Framework、North Star Metric，等等。而設計師需要做的就是去了解你所負責的產品的商業模式（Business model），並將其帶入到你的工作流程當中，在發想設計方案的階段同時衡量用戶需求與商業目標，以幫助你做出更有品質的設計決策。
User Study / Competitive Analysis / Workshop
在探索階段，設計師可以根據專案的需求執行合適的設計活動。例如：當團隊成員對於用戶所面臨的問題尚未明確，或者已經有初步的假設但是想要進一步驗證時，透過問卷以及用戶訪談等形式來獲取洞察是不錯的方式。如果手上的產品在市場上處於追趕者的地位，需要加快腳步完善產品功能的話，做一個詳細的競品分析來盤點競爭者們的現況，並排定產品功能的優先級會是一個更有效率的做法。
在 Case study 中涵蓋這些探索階段時的設計活動，不僅能夠讓故事的脈絡更完整，也可以讓你在接下來展示設計交付物，例如：資訊架構圖、線框圖、mockups 時能夠有理有據地闡述你的設計策略，起到一個承先啟後的作用。
Design Tryouts / Wireframes / Information Architecture
在我看來，半成品所述說的故事往往會比最終結果要來的生動有趣。特別是當你能夠展示出你如何將用戶洞察轉化為設計策略，而根據這個設計策略你又如何發想出各種不同的設計變體（Variants），設計變體之間又是以怎麼樣的權衡取捨、加加減減，最終取得平衡得出你認為最優秀的解決方案。
這個過程中所體現的就是一位設計師的思考能力，它包含了對用戶需求的理解、對商業目標的理解、對技術可行性的理解，以及，對美的理解。因此不要吝於呈現你在概念發想初期的設計草圖、線框稿，展示你的設計迭代的過程就是展示你做為一位設計師所具備的思考與設計能力最好的手段。
Highlights
把專案裡的方方面面都鉅細靡遺地放到 Case study 裡是不切實際和懶惰的行為，因為不太會有人在意你的登入/註冊畫面，空白狀態頁面，等等枝微末節的設計，除非你確實在這些頁面上特別下過功夫，而讓它們值得被「強調」。比較好的做法是，挑出你認為在這個專案中三到五個亮點去做介紹，例如：Before/After 的比較、低保真到高保真的逐步優化過程、多個設計變體之間的橫向對比，等等。讓讀者能夠更容易理解你採用了怎麼樣的設計策略，來解決產品所面對的挑戰。
要怎麼篩選合適的亮點呢？最好是那些從前期調研中所發現的洞察而延伸出的設計方案，或者與滿足用戶需求密切相關的關鍵步驟，又或者對於商業目標有著顯著影響的設計優化。簡單描述這些設計亮點背後的思考邏輯、它將會如何影響用戶的行為與商業目標，以及存在怎麼樣的 trade-off。比起放上複雜到難以理解的流程圖和螢幕畫面小到什麼都看不清的 mockups，透過這種方式才會讓 Case study 有看點，進一步加深讀者對你的印象。
Outcomes
設計的價值該如何量化？我想這是每一位設計從業者都會有的疑問，設計是一門 Half science, half art 的學問，因此在某種程度上存在主觀的差異，你所欣賞的好設計或許與我不盡相同，為了讓各式各樣的設計能夠在相同的尺度上進行衡量，多數情況下與商業目標進行綁定我認為是一個合適的做法，畢竟正如同我前面所說的：「產品設計之所以有趣的地方在於能夠作為商業需求與用戶需求之間的橋樑，在提供好的用戶體驗的同時幫助企業達成商業目標。」沒辦法幫助企業達成商業目標的設計，我認為並不算是好的設計。因此在 Case study 中我會期待看到實際的產品數據佐證，新版本的設計如何影響用戶的行為，例如： Page views, session lengths, CTR，等等。並進一步影響商業目標，例如：Coversion rate, AOV, GMV，之類的指標。
當然，除了這些量化的產品數據指標以外，你也可以透過問卷以及調研的方式了解用戶對於設計改版前後的偏好，輔以 NPS（淨推薦指數）來作為設計價值的驗證。
關於這部分的話題我之前寫過一篇相關的文章，有興趣的話可以看看。
Takeaways
在完成這個專案之後對你而言最大的收穫是什麼？它可以是你設計能力上的提升、對於設計流程的反思、作為一位設計師心態上的變化，或者與其他同事之間協同合作的模式。Takeaways 就有點像是小時候經常寫的讀書心得報告，將專案上新的學習成果編織進你既有的知識體系當中，讓你在每經歷過一次專案之後都能夠確實有所成長，並且幫助你在面對類似的狀況時能夠及時做出反應。
通常如果 Case study 中沒有提到這個部分的話，面試官可能會問：「如果再讓你執行一次這個專案，你會有哪些不一樣的做法？有哪些需要改善的地方？」，其實這也是從另外一個面向去了解你的 Takeaways。
Appendix
以上只是我個人對於 Case study 寫作重點的整理，大家其實並不一定要照著這個架構去準備作品集，可以將其作為一個參考，並根據自己的專案特性以及需求，有彈性的做出調整。
另外我也整理了幾個我覺得很不錯的 Case studies 分享給各位，或許在架構上略有不同，但它們都有著同樣出色的敘事邏輯、恰到好處的圖文比例、具有啟發性的用戶洞察，以及緊扣著商業目標說了一個完整且引人入勝的故事，是幫助設計師在撰寫 Case study 時很好的學習範本。
