使用者沒你想像的這麼單純
現今在產品開發中使用者中心設計（User-Centered Design）越來越被重視。大家在產品設計時遇到不確定的選擇，總會說上一句「那讓使用者來決定吧！」，然後展開了如火如荼的使用者調查，然而使用者調查並不是萬靈丹，只單單依賴使用者中心設計反而會造成一些問題。原因是你所想的使用者並沒有麼單純。很多時候你的產品的使用者他們是好幾種不同類型的族群所混和出來的一大群使用者，更甚至還有其他相關參與者。
不單純的使用者們
在我們進行產品設計時，會規劃出人物誌( Persona )，描寫目標使用者的詳細樣貌，建構出目標使用者的模樣與細節。但事實上並不是每一個專案裡的使用者，都是唯一一種樣貌，比如說當我們要設計一個互動學習環境時，其中所牽涉到的角色有學生、老師還有教材設計者。這幾個族群雖然都參與到我們的產品裡，但彼此間的目標需求存在差異，甚至會有衝突的目標。比如說老師希望學生可以學習抽象思考，而非單單學會解決固定的問題；可是學生覺得利用真實世界舉例的問題比較有趣。在這樣的情況下，我們會很難從中整理出最終的主要角色，以及發展出適合的場景( Scenario )。
更甚至還有其他特殊的情況，會讓我們的使用者樣貌更為混亂。
有一群神祕的角色們存在於我們的使用族群之外，但是會重重影響我們的使用者。UCD告訴我們要專注在我們的使用者身上，去了解他們在想什麼、怎麼工作、怎麼生活，但是很有趣地在我們很少關注的使用者以外的角色中，存在著一群會『重重影響使用者的角色』。
然而那些角色是我們不得不去考慮的。
比如說前陣子Howlin前輩分享在臉書的工作心得，就有類似的想法：
persona的設計對消費型商品比較需要，對於B2B或者流程軟體、生產力工具，persona並不是按照年齡或文化背景畫分的，而是按照初階、進階、超級使用者畫分，這問題很有意思，因為我馬上就碰到了。
今天對流程軟體，做UI presentation的時候，老總就針對不同主管的立場提出質疑，因為不同高度有不同的操作行為，同時還有政策考量的問題，有些介面我做得太”friendl”y了，中層主管為了方便，當然希望表單越容易簽越好，我的設計就是以他們為中心，但對於高階主管來說，會希望中階主管一張張看過表單，謹慎簽核，也許實際上管不到，但介面上，不該引導使用者做出「政治不正確的行為」
購買者，未必是使用者，讓我想到兒童的網路看門員軟體=.=
在這裡所介紹重重影響使用者的角色，是指決定是否給使用者使用產品的實際決策者，他們掌握我們產品的生殺大權。但是他們的目標或許與真實的使用者不一樣，比如說前輩提到色情守門員。（我想情慾蠢動的少年們都會自己為自己的需求找到出路的XDD）
像這種例子層出不窮，像是平板醫療軟體－－幫助醫師整合醫療資訊的APP，實際的使用者醫師們並沒有決策權，實際擁有決策權的院長、董事們卻會有其他不同於醫師需求的考量，所以當我們只去了解醫生卻沒有顧慮到決策人的想法時，可能會造成產品的銷售問題。
當用的人與買的人不一樣的時候，如果我們乖乖地只為目標使用者設計產品，就像玩遊戲時，專注在眼前的魔王上，把自己技能裝備搭配成專門剋眼前魔王的組合，在好不容易攻略魔王時，發現剛剛打倒的竟然只是小魔王，真正的最終大BOSS：設計產品我們時所忽略的角色，等到我們筋疲力盡時再重重地賞了我們一巴掌。
『啪~~』
畫成表格以後你會發現打BOSS策略錯誤跟產品開發失敗有多麼像：
| 攻略魔王 | 產品開發 |
|---|---|
| 研究魔王弱點 | 使用者調查 |
| 搭配技能裝備 | 產品開發 |
| 打倒小魔王 | 產品測試完成 |
| 大魔王出現 | 決策者出現 |
| 重重打擊冒險者 | 打槍已經完成的產品 |
| GG | |
總結以上，對於產品設計我們應該不只專注在使用者，而是要擴大到所有可能參與的角色，我稱之為利益相關人( Stakeholder )。
現實的困境
但是文章一開始所提到使用者們彼此的目標常常會發生衝突，當我們加入使用者以外的權益相關者，會讓衝突變為更激烈，在這種「公說公有理，婆說婆有理」的情況下，所謂「資源有限，慾望無窮」，我們勢必無法滿足全部的需求，那我們要怎麼有所取捨呢？
很不幸地我們目前並沒有適合的設計框架可以幫我們解決這種問題，設計師常常是根據專案發展以及需求，發展出一次性的方法。每次遇到問題隨機應變提出解決方法來調整產品發展，通常判斷的方法都是以設計師的直覺或是誰是權益者中影響力最大的角色來決定產品方向。這樣並不是一個好方法，我們應該建立可以重複利用及較為科學的原則幫助我們解決需求衝突。
幾個有用的設計原則
今年 CHI’ 13 中有一篇論文 Why Interactive Learning Environments Can Have It All: Resolving Design Conflicts Between Competing Goals. 剛好嘗試解決這樣的問題。他們專注在設計互動學習環境( interactive learning environment )上所遇到的目標衝突，比如說像是設計教育遊戲、線上學習系統等等，所遇到的不同權益者的衝突。
他們提出了三個原則，幫助設計師解決目標衝突的問題：
建立目標位階（ Forming a Goal Hierarchy ）
藉由建立目標的優先等級，來決定開發目標。 實際操作的步驟如下：
第一步我們必須找出衝突在哪裡
一開始可以利用親和圖法（affinity diagrams）來幫助我們整理需求目標。藉由把所有需求目標寫在便利貼上，慢慢去整理聚合把便利貼分類成幾個大集合，再根據集合中的便利貼特性為集合命名一個大目標，比如說在論文中他們整理出五個目標：
- 目標1. 穩健的專業知識而且可以應用到新的問題
- 目標2. 標準考試中的好表現
- 目標3. 方便管理教學進行
- 目標4. 讓學生獲得信心不斷挑戰問題（self efficacy）
- 目標5. 有趣且具娛樂性
然後再列出為了達到每個目標所必須達成的小目標，比如說為了滿足「標準考試中的好表現」會有小目標：解決類似題目的能力、提供延伸練習的機會；「有趣且具娛樂性」則是像遊戲般多彩的介面和花俏的元素。列出這些小目標以後，便開始檢視小目標和小目標之間有衝突，把這些衝突給標記起來。
第二步給目標需求打分數
發現衝突後我們要開始為衝突目標排優先順序，此時我們要建立判斷優先等級的標準。
我們可以藉由目標需求中找出大家覺得最重要的目標，所有設計都應該要滿足它。以其他目標有沒有為完成最重要目標為基準來判斷目標的重要性。此時我們可以利用相關權益者所組成焦點團體( focus group )幫忙找出最重要的目標。
比如說論文中他們藉由訪談他們挑出「穩健的專業知識」及「標準考試中的好表現」作為最重要的目標，而且他們發現老師十分在意學生學習的深度，所以「穩健的專業知識」優先於「標準考試中的好表現」。（目標1 > 目標2）
有了主要目標以後，我們可以利用他來判別其他目標有沒有滿足主要目標來評分， 比如說論文中的例子：
| 目標 | 效果 | 得分 |
|---|---|---|
| 目標四：讓學生獲得信心不斷挑戰問題 | 簡單的題目可以增加娛樂性（＋目標5） 簡單但有一定程度的問題可以增加學習效果（＋目標1） 太簡單的問題對學生深入學習內容沒有幫助（－目標1） 學生在遇到比較困難的情況下會對課堂管理有正向的影響（+目標3） |
0.5(目標5的得分) + 1-1+0.5(目標3的得分) |
（目標請參考此章節一開始的例子）
「讓學生獲得信心不斷挑戰問題」這個目標的小目標有「用較具體的說明來讓學生理解」，這點會造成課程簡單。根據目標會造成的效果是否滿足其他目標來算出他得分，比如說他可以增加學習效果滿足了主要目標，可以獲得了一分；但是太簡單的問題對學生深入學習內容沒有幫助會違背主要目標，所以扣一分。至於滿足了非主要目標則在積分貢獻上打個折扣，比如簡單的題目可以增加娛樂性滿足了目標5，所以加上 0.5 ×目標5的得分 ；而學生學習遇到比較少困難時，對教學的管理也有正向的幫助，所以加上 0.5 ×目標3的得分。
至於目標3 與 5 的分數也會經由類似的過程算出，最後再導回目標 4 的積分函式中。
藉由這個方法，我們可以建立起目標需求的優先積分，優先順序會從主要目標需求最高到積分最低的目標需求。以先前提的例子來說：假設算出來 目標 3 ＝ 2分、目標 4 ＝ 1 分、目標 5 ＝ 0分，我們可以優先等級如下：
目標1 > 目標2 > 目標3 > 目標 4 > 目標5
最後我們可以根據優先等級來決定衝突發生時，我們應該要優先滿足哪個需求。
參數實驗（ Parametric Experiments ）
並不是所有問題都適合目標位階法，有時候我們會需要更仔細地考慮選擇。這種時後，我們可以採用參數實驗，實際規劃對照組與應變組去比較兩者的結果，來決定怎麼選擇設計方案。
論文中他們運用在決定要給學生練習一整個完整複雜的問題( holistic )或是把問題拆解成好幾個步驟，讓學生有結構慢慢地完成問題( subgoaling )。以學習程式舉例來說，一般傳統課堂回家作業要求學生做出完整的翻牌配對遊戲就是提供完整複雜問題，如果是像codecademy把作業拆成小部分，先要求你完成建立卡牌功能、洗牌功能再來才是比對功能，讓學生一步步完成作業，則是讓學生有結構慢慢地完成問題。
在案例中他們實驗在課程50%、70%和100%比例使用 subgoaling 的題目，學生的學習成效如何。藉由前測後測來研究學生的學習情況，來決定要採取什麼方案。
交叉迭代研究（ Cross-Iteration Studies ）
不過由於不是所有實驗目標都可以控制變因，所以有些情況我們無法利用實驗來幫助我們解決設計衝突。這種時候我們可以採取把我們產品拿給使用者測試，獲取回饋快速修正再進行測試，不斷在兩個衝突間嘗試取得平衡，快速經歷過好幾個迭代調整出兩衝突間，使用者最適合的搭配方案。
在案例中他們應用在解決到底要給學生敘述長且複雜但是有完整背景故事的問題還是提供簡單易用的系統，依照原先的目標位階來決定，他們提供了有完整背景故事的例子給學生，不過學生抱怨要讀很多字、老師覺得系統使用起來並沒有為教學帶來幫助。於是他們決定把完整背景故事給移除，但是後來發現學生沒有真實世界的例子以後，學生對抽象思考感到困難，學生覺得學習起來非常的挫折。經過再次修正，他們決定使用圖像例子取代冗長的故事敘述，比如說在分數教學中，利用圓餅圖取代原先對比薩例子中冗長敘述。在這次修正以後，學生的反應非常好。
緊貼著使用者
簡單地說，設計師應該要貼近相關權益者，快速開發修正並獲取回饋，反覆進行修正回饋，去找出衝突間的平衡點。
結論
當我們設計產品的時候，往往把所有注意力放在使用者身上，事實上我們應該關注所有與產品有相關的角色，也就是利益相關人( stakeholder )身上。以免當我們辛苦開發設計完產品後，卻遭到不被採納的結果。另外相關權益者包含許多不同的角色，每種角色都有著不同的需求目標，而這些需求很有可能是彼此衝突的，在資源有限、慾望無窮的情況下我們不可能同時滿足所有人的需求，我們得在衝突中做出取捨。
這裡我介紹了三個可以依賴的設計原則來幫助我們，在設計衝突中有程序地做出選擇來最大滿足相關權益者們的需求。這三個原則分別是：
- 建立目標位階（ Forming a Goal Hierarchy ）
- 參數實驗（ Parametric Experiments ）
- 交叉迭代研究（ Cross-Iteration Studies ）
希望藉有這篇文章可以讓各位設計師可以快速完成充滿衝突的專案，另外也感謝各位持續在設計領域研究的研究者們。
參考資料
Top image via Sebastian Arbelaez Fuentes, CC License.
“Affinity diagram” image via Sean Munson, CC License.
