【UX工作坊】以角色扮演與親和圖卡片分類法體驗專案需求
現實專案中，有很多利害關係人作為一個需求方，常常拿著別的產品介面要你照做，我們可以如何應對呢？
五月份我舉辦了兩次UX工作坊，起源來自於媒體公司波波黛莉的邀請，這是一間年輕有活力的公司，本文記錄籌備工作坊的構思過程。
收到邀請詢問後，我跟波波黛莉的 UI 設計師、 PM 以及主管進行過兩次會議作需求討論，然後將工作坊要解決的問題定義為「協助非產品團隊的同事能了解更多產品開發知識，以增加需求討論的效率」。
工作坊目標：
1. 針對需求認知不同的情況增加辨識能力
2. 提昇產品開發流程的認知構思角色扮演工作坊活動
我在思考工作坊的大綱時，先思考如何讓外行人能夠理解「提需求是一個技能，沒有經驗的人提需求很容易歪掉」。
隨後我想到自己在大學時代投入了大把時間玩 TRPG 桌上型角色扮演遊戲的經驗，認為用角色扮演法來模擬專案情境，讓非產品團隊的人體驗看看軟體專案的進行過程，利害關係人提需求到底會如何歪掉，好像蠻有趣的。
根據這樣的構想，我很快的寫出了跑團腳本….呃不，工作坊腳本，並且定義這個角色扮演活動的重點是：
1. 上課成員分別扮演需求方與產品開發團隊互動。
2. 體驗自己親手寫下的需求，最後如何影響產品。
3. 體驗換位思考。構思需求工作坊活動
接下來我還需要一個活動，因為第一段活動讓參與者體驗了專案進行中提的需求影響有多大，第二段活動，我希望讓參與者學會辨別需求。
什麼是辨別需求呢？我採用的架構是下面這個需求價值描述的理論：
白話文來說，有效性問題就是「不處理會完蛋」，效率問題是「不處理會很麻煩」，滿意度問題是「不處理有人會不高興」。
決定了重點，跑團腳本….呃不，工作坊腳本也就很順利的寫完。
但身為一個 UX 設計師，我們要有雛形驗證的精神，所以我就先找了六位朋友當白老鼠，驗證一下工作坊腳本的內容，並且根據現場的反應調整帶團…呃不，主持工作坊的節奏。
雛形驗證工作坊腳本找出改善目標
這個白老鼠工作坊（喂）進行的比我想像中順利，當然時間超時不少。
過程中每個人都笑到無力，扮演 PM 的朋友是沒有產品經驗的大四學生，他一面進行一面哭吼：「你們需求不能講明確一點嗎？這些真的要我決定嗎？」
負責扮演工程師的是我們家 UX 設計師筑云，她很殘酷的扮演了相當寫實的工程師一直吐槽 PM 給的需求：「你說要圓的？正圓還是橢圓？」
其他人扮演股東、行銷主管、業務主管、通路商，提出各種讓 PM 變臉的需求改動。第二輪產品釋出時，利害關係人們看到的甚至是修改到一半沒有頭的產品。
工程師跟PM用完了開發時間只好硬著頭皮跟利害關係人說明下個版本會更好，當然，又收到了更多的改動需求。（好寫實好想哭）
在場有專案經驗的人都安慰扮演PM的朋友：現實的專案更可怕。突然之間他似乎領悟到了什麼（喂）。
經過雛形驗證之後，我發現本來構思的破冰活動太浪費時間了，所以後來在波波黛莉進行工作坊時，進行了調整。
在波波黛莉進行調整過後的需求工作坊
整個過程有兩個主要活動，第一個體驗是角色扮演工作坊，讓大家體驗專案的利害關係人如何提出需求與影響產品，當然又是一個笑到崩壞一面進行的遊戲。
在活動前我們先進行了認知心理學理論知識的補充，說明人類要成功完成思考必須具備四個要素：
1. 環境資訊
2. 長期記憶中的事實型知識
3. 長期記憶中的程序型知識
4. 解決問題後預期的效益
劇情背景： 你加入一間新成立的網路新創公司，年輕的創辦人整天跑出去募資跟參加活動很少在公司裡，你們被招募進來後每個人手上都分別收到了創辦人的指示，希望打造一個偉大的產品。接著在角色扮演工作坊中，總共了三輪的開發流程，第一次產品跟利害關係人 demo 的時候是一片空白，扮演 PM 的 UI 設計師 Poppy 居然面不改色的跟所有人討論時間不足的問題。
最後成果發表時，五個利害關係人有三個支持產品可以發佈，Poppy 妳要不要考慮轉行當 PM 勒？
第二個活動是用親合圖（KJ法）來體驗需求的三個層級。我在這邊先提出了一個題目以及劇情背景，要求參與者針對目標寫下可能需要處理的問題。
以便條紙寫下為了達成目標所要解決的問題後，先請大家進行問題的分群，這個時候就會開始發現參與者的認知不同步，每個人對於問題的定義是有歧義的。
接著按照需求的層級，要求所有人動手進行分類。滿滿的便條紙一開始都放在「一定要解決、不解決會完蛋」的分類。
我在這個活動主持的階段，注意的是禁止參與者們討論需求，以及討論別人的分類方式，因為參與者中比較主動積極的人會影響別人的認知，進而形成社會性壓力，讓習慣順從的人覺得別人已經考慮清楚了，所以我只要同意就可以。
執行卡片分類的活動，有點像是頭腦風暴 Brainstorming ，重點在於產出越多想法越好，一但陷入討論就會停下來檢視自己想法，或者改變想法，或者不擅長遵守規則的參與者會不小心「檢討別人的想法」，進而壓抑想法的誕生，這是主持人需要制止的行為。
活動的重點在於列出想法後，仔細討論每一張需求。
其實參與者都能同意很多需求不應該放在「不解決會完蛋」。透過這個體驗讓大家感受認知落差、價值觀不同，是如何影響我們談論需求實現的優先順序。
活動之後我們針對真實的專案情境中，該如何辨別需求以及承諾交付的順序作了一些討論，當然，又超時啦。
這兩次舉辦工作坊的經驗很有趣，最主要的是我能用客觀的觀點檢視，如何引導缺少專案經驗的人進入狀況討論需求。
查看獸群之心的 UX 文章目錄
