如何做陌生專業領域的需求研究？賦能新手設計師/研究員的團隊知識管理
不論是初入職場的 UIUX 設計師，還是在學的大學生、研究生，都可能經歷過需要為「特定領域」設計數位產品的經驗，而這些領域從較易親近的Ｃ端消費性產品，到艱澀難懂的 B 端專業領域如金融產品，都須依靠設計師對該領域的理解，透過設計手段解決問題、創造新價值。
本文將以一個用戶體驗設計研究生的角度，分享設計團隊能夠如何透過桌面資料蒐集、訪談、資料分析以及資料管理，完成共耗時九個月的公共系統研究與設計，並在期末報告時和業主一起鼓掌慶祝結案 🎈
前情提要
2023 年臺灣科技大學 DITL 團隊受工研院委託為農業部設計「動物展演業者管理系統」，團隊由唐玄輝教授領導，本文作者是該專案的 PM，同時也是台科大設計所的碩士生。團隊成員前期研究共四人，後期設計與設計驗證共兩人，歷時共九個月完成需求研究與系統設計。專案進程如圖一所示，本次分享的內容主要是前期研究的部分，也就是「階段一：系統目標釐清」。
首先，動物展演是什麼？
就和專案剛開始的所有團隊成員一樣，你的腦海可能也正浮現這個問題。
動物展演在臺灣算是較晚被關注的領域，雖然我們小時候都有去動物園、水族館、親子農場的經歷，但一直到 2019 年才有正式的法令將動物展演業者定義為「動物供展示、表演或與人互動，及該動物飼養之場所。」並要求符合條件之業者應向當地主管機關申請「動物展演許可證」。所以台北動物園、Xpark 水族館、張美阿嬤農場都算是動物展演業者，且須申請動物展演許可證。
為什麼農業部需要建置動物展演業者管理系統？
近年來臺灣大眾對動物福利的意識抬頭，開始關注「被展演之動物的福利」，2020 年的 Xpark 爭議、2023 年的東非狒狒逃逸事件都引起了很大的社會輿論，要求政府提出管理業者的有效對策。因此當時的農委會希望能有一個系統整合各地動保處的動展業者資料，以向民眾公開每個業者的評鑑結果，讓民眾有權選擇並支持優良的動展業者。
換句話說，該專案不僅需要從零到一的建置一個全國系統，還是一般生活難以碰觸到的公共領域、動物保護領域，且該議題面臨著顯而易見的挑戰與衝突。對於當時的我們而言，像是要徒手翻過一堵看不見有多高的牆，即使前途未卜也只能硬著頭皮開始。
💥 設計團隊初入陌生專業領域的困境
在專案初期，我們做了桌面研究，也初步訪談業主了解需求與期待。然而作為一個外部團隊，在資訊蒐集上十分容易碰壁，要能真正的搞懂內部的業務是如何運作、利害關係人們的立場，需要付出相當的努力。
以下是我們在研究過程中曾遭遇過的困境：
- 較難判斷各方資訊的可靠性
由於團隊不具備該領域的常備知識，每一個從網路上蒐集的資料、每一段從訪談擷取的洞見都需要交叉比對，以確認其描述的對象為何、是基於怎樣的立場或背景，才能判斷是否須納入設計考量，大幅增加了研究困難。 - 較難取得專業領域受訪者的信任
此專案需要透過訪談政府單位的長官、動保處業務人員了解現況。然而對方不一定願意將最原始的動機、最重要的文件揭露給初次見面的「門外漢」，訪談品質端看主訪如何在過程中展現專業感以取得對方的信任。 - 沒有相關的數位產品可參考
沒有競品可參考是 B 端產品常見的困境，在此專案亦是。這更凸顯了做前期研究的重要性，「如果不搞懂，絕對設計不出好系統。」這句話在研究過程中一直存在我的腦海裡，也的確在後期設計時得到應證。
設計團隊如何跨越專業知識壁壘？
在不同專業領域裡，一定有不同的專業知識門檻需要克服。以此專案為例，最重要的就是要理解現行的動物展演法規和實際業務執行情形，而了解利害關係人互動，能夠幫助設計團隊判斷不同需求的急迫度，避免系統開發疊床架屋。此專案的專業知識壁壘面向與其影響如圖二所示。
第一步：不厭其煩的建立團隊知識庫
這邊指的「知識」包含所有為了專案所蒐集的資料，所以桌面研究、相關文件、訪談資料等都在此範圍內。
在初步了解專案背景後、與業者開會前，團隊最先能做的就是先確定「最基礎」、「最不可能變動」的知識，對於這個專案來說就是讀熟「動物展演業者管理辦法」。但當然不是在團隊裡開個法條讀書會逐條背誦內容，而是將生硬的法規內化成用戶體驗設計師看得懂的結構，並整理在團隊使用的知識管理工具 Confluence ，如圖二所示。
我們發現看似冗長且繁雜的法規經過梳理後，就能初步理解公部門管理動物展演業者的業務範圍，甚至能先透過對法規的理解初步繪製出動物展演許可證的申請流程如圖四，幫助團隊在後續的訪談中能夠和公部門的長官、執行人員快速對齊資訊如圖五，同時也建立團隊的專業感取得對方的信任。
💡 當時為了確保每一個團隊成員都有仔細讀過法規，有讓每個人嘗試將法規內提到的各種文件在流程圖中標記出來。這個做法不僅能推進研究進度，也能看出團隊成員在理解資訊、彙整資訊上的微小差異，對於初期建立團隊默契和基礎知識蠻有幫助的！
除此之外，在訪談過程中取得的公部門相關文件，也都會一併上傳到知識庫中，並標明文件來源、文件名稱、文件用途/項目、文件檔案，如圖六所示。再根據研究的進程特別標注需重點注意的事項，例如標注未來若需將紙本轉為數位系統，可能會有困難的項目，像是文件要求的紙本簽名是否可以用數位檔的形式取代，用於下次與業主開會時確認相應的對策。
雖然每次出差訪談完還要一張張掃描厚厚的文件們很累，但這份工真的很有幫助！尤其是到了後期要進行系統設計時，每個文件應該轉化成哪些資料欄位，不同縣市之間資料需求的差異為何，都必須仰賴這個資料庫作為設計的支撐，如圖七所示。
中央農業部雖然身為業主最了解整個動物展演業者管理的法規，但不一定了解各地方動保處的實際執行狀況，因此只能從一場場訪談中取得珍貴的資料作為參考，當利害關係人詢問為何某個地方要這樣設計時，也能馬上調出相關文件幫自己佐證。
第二步：由繁至精的三階段訪談資料整理
訪談作為此專案的重要資料獲取手段，除了需確保每次的訪談品質外，也要盡量讓每一個團隊成員都能充分吸收新知識。DITL 在學長姐們的傳承下，發展出一套非常紮實的訪談資料分析步驟，而在 2023 年的專案中，則沿襲這套方法並特別明確了三階段的產出與用途。
訪談資料分析三階段（如圖八）：
- 第一階段：Findings，從逐字稿歸納對應訪談目標的「新發現」
- 第二階段：Summary，將多項 Findings 彙整成容易吸收的文章
- 第三階段：Insights，總結呼應專案目標的核心訊息
在完成一段訪談後，主訪會根據記錄當下打的逐字稿，萃取重要資訊寫成 Findings，通常 90 分鐘的訪談會有約 40 項 Findings，再依據他們相關的主題分類彙整成 Summary，並在固定週會中與團隊分享、對齊資訊。最後的 Insights 是精煉此次訪談獲取的資訊撰寫的三項核心訊息，讓不是團隊成員的人如業主、上級，也能快速理解專案的進展。
分成三階段的好處是能夠確保團隊的人都知道最後精練的資訊「是從哪裡來的」，並且能夠很快地找到當初撰寫的人或是對應的證據。這件事對於後期在拆解複雜問題時很有幫助，例如在討論利害關係人圖怎麼繪製時，可能當下大家都只記得某個單位的立場，忘記背後的原因，就能反向檢索 Insights > Summary > Findings > 訪談逐字稿，去確認當時會下這個結論的脈絡。
每一階段的訪談資料彙整在 Confluence 的呈現方式如圖九。
當一個專案的資料量隨著研究進程越來越大的時候，可能某個團隊成員只要缺席一次訪談就很難跟上其他人對專案的認知，造成討論的時候少一顆大腦、少一種觀點，因此讓所有資訊脈絡透明、易取得，是讓後續的設計工作事半功倍的關鍵。
第三步：結合自身專業傳達觀點
經過一輪又一輪的訪談，此時團隊成員已大致摸透了動物展演業務的執行現況與相關法規，最後我們還是要回到「設計師」這個身份，去設想如何透過設計方案解決業主現階段遇到的問題。此時就需要借助團隊成員的大腦，一起集思廣益嘗試用不同觀點描繪這個議題，最終的目的是要幫助釐清問題、找到設計切入點。
在這個專案中我們有用到的資訊視覺化工具包含服務設計領域常用的「利害關係人圖」、「服務藍圖」（如圖十），也有用戶體驗領域常用的「資訊架構表」、「Flow Chart」。這些工具要畫出來不難，但如何應用設計師對該領域專業知識的了解，去產出一個精準、帶有獨特觀點的圖表，就是一個很有挑戰性的任務。
當時團隊在討論時很常遇到的困難就是 — 所以我們要先解決哪些問題？
每個利害關係人抱有各種不同的期待，同時現況也存在各種不同的問題，再加上業主有自身想達成的目標，當時的我們就像無頭蒼蠅一樣，不知道解決哪些問題可以滿足哪些期待，而滿足哪些期待又能達成業主的目標。因此就需要團隊透過手上現有的資料去釐清不同問題、期待、目標之間的關係，以更好的判斷身為設計團隊，能夠從哪邊著手介入。
因此當時我希望能透過在團隊內辦一個小型的線上工作坊釐清這些問題。在開始前，先把討論需要的步驟在共編白板工具 Figjam 上寫出來，包含從發想所需的資料到最終預期的產出，並邀請團隊成員一同思考，把關係模糊的資料一步步連結起來，並在最終擬定下一步需與業主報告和討論的內容。當時線上參與討論的成員共四人，最後也成功在兩個小時內釐清了方向。當時討論的畫面如圖十一。
透過在專案裡進行一次次這種討論，我們能夠很快的對焦彼此對該專案的認知，也能結合每個團隊成員自身的優勢總結出更好的洞察或更好的產出。例如有成員在思考上很謹慎，會把大家拉回來處理有思考謬誤的地方；或有成員雖然不常發言但把研究資料記得很清楚，能夠適時補充資訊。雖然團隊裡通常都會有一個最了解所有狀況的人，但人本身就會有各種認知上的偏見和思考漏洞，因此若只靠一個人去總結所有資訊是很危險的，才需要借助團隊中不同觀點的力量去平衡，以產出一個「盡量客觀且接近事實」的結論。
💡 小結
透過紮實的研究過程以及團隊成員的共同努力，我們在第一階段的產出是一份 50 頁的報告，清楚說明了團隊透過訪談發現的問題、各利害關係人互動發生斷點的地方以及團隊預期如何透過設計解決、效益為何。這份報告不僅得到了業主的認可，也在初期幫團隊打下了很好的基礎，能夠更有效率的完成系統設計、驗證、迭代，並且盡量將主要的資源都花在最關鍵的頁面上。
總結此次專案的經驗，以下幾點是如果我認為很有價值的學習，能夠在日後幫助我面對各種陌生的專業領域：
- 準備 排版乾淨、易用的知識管理工具（如 Notion, Confluence）
- 養成 總結資訊、分享資訊的好習慣，確保資訊好查詢、易取得
- 了解 團隊內各種知識、資訊的產出脈絡，確保能找到作證資料
- 設定 清晰的會議架構，確保團隊成員的大腦都能參與產出
✨ 致謝
最後我想感謝在此專案中帶領我們的 唐玄輝 教授，在專案過程中引導我們思考，在過急的時候幫我們踩煞車，在遇到困難時鼓勵我們向前進。也謝謝一起努力到專案最後的夥伴 淇墉，很開心能在這個專案裡一起學習！
專案成員
指導 | 唐玄輝 教授
PM | 吳子誼
研究員 | 李淇墉、李佳芸（前期）、 Mable（前期）
聯絡資訊
吳子誼 Wolsey Wu
Sabulaka1010@gmail.com