本文的作者Stephanie Troeth可謂一個使用者體驗策略專家，在此文中，作者介紹了一種非常新穎的使用者體驗工具，也可以說是一種方法。這種方法結合了座標軸和矩陣圖，彌補了使用者角色、使用者旅程、心理模型等常見使用者建模方法的不足，並通過一款APP設計帶讀者感受了一番其中的獨到之處。這種方法簡單易上手，非常適合小團隊敏捷開發，同樣也適用于大團隊成員間、利益關係者間的交流，降低溝通成本。
原文連結：
HTTP://uxdesign.smashingmagazine.com/2013/03/12/design-multifaceted-user
在做設計的時候時刻都要以使用者為中心是一件很棘手的事。我們不僅要清楚的知道誰是我們的使用者，而且要快速把對使用者的瞭解轉換成一個設計良好的產品。這通常並不容易做到。
目前，我們使用的的使用者體驗工具傾向于把重點放在「誰」是我們的使用者上。我認為這是從傳統行銷和市場研究中沿用下來的方法。在幾年前，我偶然發現了一種不同的方法，而且這種方法的有效性已經在我的專案中得到證實。在構建價值主張和描述我們對使用者行為作出的假設時，這種方法也是非常方便的。而我喜歡它的最重要一點是它能幫我完成產品優先設計決策。
因此，首先讓我說一下目前的工具集不完善的地方，然後我會帶你一起看一個使用了這種新方法的案例。看完這邊文章你應該做好準備自己嘗試一下這種方法。
我們是多面的（We Are Multifaceted）
站在使用者的角度設身處地的想一下。一個朋友推薦你加入Facebook的一個組，而且這個組的主題是你們兩個都很喜歡的。如果是那種像我一樣害羞的人，你或許會潛水一段時間，當你熟悉了這個組的動態以後，慢慢的你就有勇氣發表評論和分享連接。
再設想一下，你偶然在博客上看到一篇你很感興趣的帖子，那裡已經有了別人的回復，但你不能苟同他的觀點——我敢打賭，如果你恰好被解雇了，你一定會立刻反駁，而不是先花點時間看看之前的評論。你仍然是同一個人，但你對一件事的反應會取決於那是什麼事，以及那時候發生了什麼事，這是很正常的。
對設計師而言這意味著什麼？對我來說，這意味著我的交付物對「誰是我們的使用者」規定的過於詳細。更深入的瞭解使用者所處的多種情境（不同環境會產生不同的行為和決策）也許我們會做得更好。
總之，目前看來我們使用的工具（tools）大部分把人本身作為關注的重點，而不是預測使用者可能的反應。但是我們忽視的這一點，恰恰是作為設計師應該進行有效設計的地方。
人物角色（personas），使用者旅程（user journeys）,心理模型（mental models）？
人物角色，是基於合理的的研究方法創建出來的，內容提煉自幾個有代表性的使用者形象。人物角色有很多優點，特別是在確定誰是我們的使用者時，它可以在眾多利益相關者之間建立起共同語言。
使用者旅程（user journeys）和體驗地圖（experience maps）能夠揭示使用者在使用應用（application）和網站時潛在的路徑。它們對理解使用者流（flows）、把使用者需求需求向功能轉化很有説明。
上述兩種工具以及由它們衍生出來的工具，都對使用者做了深度思考。使用者路程可以描述使用者具體可能做什麼，但沒能說明使用者為什麼會這樣決策。通過人物角色，你可以一定程度上獲得使用者的背景情境和活動資訊，但你要的資訊只需包括當前設計能用到的就夠了，很顯然人物角色給的遠超你所需。
考慮一下，在你的典型設計流程中實際上包含了哪些內容。在任何階段，你的設計都需要滿足不同的活動流（activity flows）。作為設計師，讓我們崩潰的是我們不得不把一系列複雜的使用者行為轉化成可量化的功能集，而且要切實的適應于產品管理計畫。
應用人物角色和使用者旅程來研究和描述這些複雜的使用者行為並且保證整個過程的輕便性是一件非常困難的事。
上述提到的三種工具中，最接近我們所使用方法的是心理模型，它可以説明你概括出使用者的意圖和任務。然而，使用的心理模型通常並不能直觀的展示不同的場景的內容。
目前為止問題仍然存在：當使用者的行為和動機在一定範圍內變化時，我們如何做才能保證產品定位和介面設計都能符合使用者的決策模式（decision patterns）？
使用者群組建模（modelling user groups）
終於，偶然一個機會在一個客座演講中我聽到了一直在尋找的解決方法，演講者是David Rollert，是我的朋友兼同事，一個經驗豐富的設計師。
那天，大衛通過展示一系列使用者體驗工具吸引住了在場所有智慧設計工程專業的學生，那些工具中包含了一種創建使用者群組（groups of users）的方法。他以一個交友網站為例，展示了如何定義使用者群組的關鍵維度（dimensions）。（圖1人群維度、圖2喜好維度）這一步和我們平常創建使用者角色時使用的方法沒有區別。經過大衛的許可，下面引用了他幻燈片中的圖片。
接下來一步我們開始探索模式（patterns）的。大衛把上面的其中兩個維度結合在一起並且舉例展示了一組3×3矩陣圖，從中可以看出使用者的即時目標和使用者想要扮演的角色之間的關係。為了填滿矩陣中的空格，大衛問了這樣一個問題：「每個群組的需求是什麼？」
在Russ Unger 和Carolyn Chandler 所寫的《A Project Guide to UX Design》 (第6章，第90頁)中提到過類似的使用者建模方法，但只有寥寥數語。文中除了強調「真實使用者研究」（real user research）的必要性之外，其他的和我們通常的做法一樣——根據「使用者是誰」而不是「使用者想要什麼」或「什麼驅使他們」來創建使用者群組。
我覺得這是很有趣的事。如果我們不問「這些使用者是誰？」而是換一種方式問會怎樣？例如，「這個群組的使用者想要做什麼？」，「他們需要知道什麼？」在接下來的幾個專案中，我開始在工作中採用這一方法。而且結果已經證明在很多時候這種方法是非常有效的。
在繼續深入之前，我想指出，這種方法並不是最終的交付物。這種草稿不能拿來給客戶或產品經理簽收。這只是一種方法，用在工作坊中以及和利益相關者的討論中十分有效。
探索對使用者作出的假設
「使用者」已經成為一個負載詞（loaded word）。我們總是把自己的信念、詮釋、和情感一股腦附加在「使用者」和他們的需求上。在幾個團隊待過之後，我開始意識到一個普遍存在的問題：並不是所有的利益相關者和團隊成員對「使用者」一詞的理解都是一樣的。這就是為什麼在內部擁有一套使用者角色集合可以很好地解決語言溝通上的問題。
然而，使用者角色的問題在於它只是把單個特定的使用者場景展現出來，在研究一系列連續的使用者場景時，它並不是最好的工具。
矩陣圖的方法透過不同場景的視角，説明我們研究已知的、未知的使用者行為和動機。我已經用這種方法做了下面的事：
創建關鍵受眾角色
理解或驗證價值主張
確定優先研究的領域和產品功能——確定我們已知的資訊和缺乏的資料
找出哪些功能是非常重要的
它的本質是一個用來理解使用者模式的結構化頭腦風暴工具。它最好的地方在於可以很容易的「解壓」（unpack）那些不同利益相關者對使用者做出的假設。
第一步：畫出矩陣圖
我已經在多次與顧客以及工作坊參與者的交流中用到這種思考方法，對我來說3×3矩陣是最有效的。可能是因為它可以給我提供足夠多的樣本，而且不會過於精確——因此可以避免出現分析麻痹症。
第二步：確定重要的座標軸
接下來需要確定我們設計的系統中可以包含哪些不同的使用者（矩陣格子中所代表的不同使用者群）。
我們看一個為跑步者設計的潛在社交應用。本地跑步的使用者可以發佈跑步路線，遊客可以通過應用找到這條路線。
我們可以假想一下虛擬競爭因素。一個跑步的使用者在之前某個時間發了一條跑步時間的資訊，你看到後想在同樣的路線上打破他的記錄。亦或是當你到達一個新城市後想找個路線小跑一下領略這個城市的風光。試想一下我們需要滿足使用者的哪種行為屬性才能能吸引使用者使用這個應用？
我傾向于選擇「反對」（opposing）屬性。你可能不同意我的觀點，然後列出如下屬性和對應的使用者場景。
探索（explorative）
「我想通過跑步找一種感受這座城市的新途徑。」
競爭（competitive）
「我想和別人賽跑或者我想自我超越。」
頻繁（frequent）
「我經常跑步，每週幾次甚至每天一次。」
偶爾（occasional）
「我每週跑一次，或者更少。」
你的座標軸可能會是這樣：
感興趣（curious） ↔ 在使用（engaged）
社交（social） ↔ 個人（individual）
探索（explorative） ↔ 競爭（competitive）
頻繁（frequent） ↔ 偶爾（occasional）
遊客（visitor） ↔ 本地人（local）
對於正在從事的專案，你可能知道一點當前的使用者的資訊，也可能什麼都不知道。和我們一起為這款社交應用出點子的團隊屬於一個運動鞋公司，而且全部由跑步運動員組成，他們經常往來于在各地參加馬拉松比賽。這個團隊在之前做過一些研究，並且獲得一些從新手到高級跑者各個級別人群的相關資訊，同時也對使用過他們曾開發過的一款web應用的人群有些見解。
在你用此方法做練習的時候，要謹記哪些是你已知曉的使用者資訊，哪些是你假定的。從上面列出的座標軸中選擇兩條你最感興趣的，或者你認為值得深入探討的。如果你剛接觸這種方法，可能在抉擇上有點麻煩；這時最好的做法是立刻選擇兩條，看看會發生什麼。如果這個方向行不通，那就換一個座標，繼續嘗試。
第三步：確定關鍵問題
我把這個步驟比作「神奇的8球」（「magic 8 ball」）。通常我會這樣開始問問題，「這些使用者可能想要做什麼？」或者更簡單的問題，如「他們想要什麼？」第二個問題包含了使用者想要什麼和他們可能想做什麼兩點。你也可以這樣問：「使用者會感覺如何？」作為強化練習。當你想問題的時候，把想到的隨手記錄下來，後面會用得到。在這個例子中，我們的問題是「他們可以做什麼？」或者從使用者的角度，「用這個軟體，我可以做什麼？」
第四步：把表格填寫完整
盡你最大的努力把矩陣填寫完整。如果你已經在研究中有了一些見解，你可以標記出哪些是你確定的以及哪些是你認為正確但沒有證據支援的。一般情況下，當你把第一個矩陣填完之後會弄明白下面兩件事：你已經知道關於使用者的哪些資訊？接下來需要做哪些方面的研究？
第五步：反覆運算
當你完成上面的矩陣之後，把它放在一邊，然後再畫一個表格。你可以做下面的一到兩件事：
1、 從你列出的問題中再選一個，如「這些使用者想從我們這裡得到什麼？」或，
2、 保持問題不變，把其中一個座標軸換成別的。
畫完表格之後從上往下填寫矩陣表格，切記這一步這是一個頭腦風暴的過程。快速記錄稍後可以完善的想法比浪費時間更重要，所以每次反覆運算都不要用太久。
當你已經竭盡所能完成本次反覆運算後，請重複以下步驟：再選一個問題，或換另一個座標軸。
這一步，你們的團隊成員最好在選擇問題和座標上觀點保持一致。
完善和重複。你會發現，在短短一個小時的時間內就能完成很多矩陣圖，即使剛開始的時候進度會很慢。
分析&主要觀點
完成上述工作之後就該著手尋找「模式」（patterns）了。我們看一下可能會出現的情況：
假設（assumption）VS.知識（knowledge）
牢記一件事——我不得不再次重複——當你和你的團隊把這些都寫下來的時候，你們有的僅僅是對一堆複雜假設的總結。當你在討論任何一個結論時，要清楚你們討論的只是一些不同程度的潛在事實（potential truth）。記住這些可以有效避免陷入過度討論細節的爭鬥中。
有了矩陣圖，是時候看一下哪個使用者群是我們已經比較瞭解的，以及我們有多少把握滿足他們的需求。很明顯，我們也能同時知道那類使用者是我們不熟悉的；我們是否已經對某類使用者做了相關研究；是否有案例研究可以支援我們在矩陣圖中寫出的答案。簡單概括就一句話，我們知道什麼，不知道什麼。
如果手頭上沒有證據可以支援我們記錄下來的使用者需求，那麼這就是我們需要去驗證的假設。假設是偉大的，因為它們能提供最完善的設計假說。利用這組矩陣圖，我們可以確定需要進行哪些使用者研究來驗證我們的假設。
共有因素（common factors）
你常常會發現這樣一個現象，有些問題在橫座標或縱座標中的每一格裡得出的答案是相似的。例如，在圖7中我們假設喜歡「探索」的使用者不管是當地人還是遊客，都對尋找新的跑步路線很感興趣，同樣所有喜歡「競爭」的使用者都對計時感興趣。這樣做沒有錯，只是當我們在測試這些需求的時候，我們會通過一定的參數限制來決定需要和哪類使用者進行溝通。當我們為這些場景而設計的時候，這些功能可能會代替原先的某些基礎功能出現在我們的應用中。
優先順序和相關性（priority and dependencies）
有時，當你為功能排優先順序的時候，畫矩陣圖的方法可以同時幫你理清相關性問題。在我們設計此應用的案例中，用這種方法很快讓問題變得清晰：那些會用有意義的方式標記路線的使用者通常是本地使用者——發生在路線被遊客使用之前。這就意味著我們的應用首先要吸引本地的跑步者，在任何場合都是，例如在功能設置時，在我們的溝通中，以及在我們行銷時。
核心價值主張（core value proposition）
「價值主張」就是一種用有趣的方式描述你向顧客承諾將會帶來的價值。當畫完幾組矩陣圖之後，你可以通過了戶需求和場景的範圍來判斷對你實際上向使用者承諾了什麼。
在我們上面舉得小例子中，我們僅僅用了不到一個小時間，就完成了好幾個矩陣圖的製作。當時有個團隊成員突然站起來激動地說：「我希望知道哪裡可以跑步！」似的這就是我們需要回答的問題。
我遞給她一支筆，她隨手在我們完成的最後一個矩陣圖的後面寫下了這句話（圖8）。之後我們明白了，要想讓這款應用獲得成功，不管使用者處於什麼樣的場景中，我們都必須回答這個問題——而這將是我們最原始的核心價值主張。至此，我們可以把精力放在設計背後的合理性上，而我們只需要通過一些自下而上的思想（bottom-up thinking）讓自己有一個明確的基本原則就行了。
再進一步
現在，我們手頭上已經有了一些矩陣圖，還有一些比較深刻的分析和見解。那接下來呢？
首先，和許多工作坊常用的工具一樣，這種方法也鼓勵結構化的頭腦風暴，整個實施的過程和得到的結果一樣重要，甚至有過之而無不足。就像我剛開始說的一樣，這套方法不會產出具有漂亮格式的交付物——而是，描述了我們實際上是如何考慮使用者的。按照上述步驟完成矩陣圖並且分析它們，你會發現在迎接後續的挑戰時你的思路會更清晰：
例如決定哪個使用者群需要進行更深入的使用者研究；從哪個使用者群中可以獲得人物角色、思維模型和使用者旅程的樣本以滿足更詳細的任務需求。
確定哪些功能是跨使用者群的，然後基於功能創建一個產品路線圖。從而你可以決定設計哪些功能可以放在一起設計和開發。
用這種矩陣圖的方法表達使用者需求有個讓心開心的副產品，你可以把他們分別描述成一個對應的使用者故事（user story），非常適合敏捷方法。再次以我們的應用為例，我們可以創建這樣一個使用者故事：作為一個當地跑步者，我想找一條新的跑步路線。然後你可以看看這個使用者故事是否是一個經過驗證的使用者需求。如果是的，那你就可以進如設計—開發流程了。
這種方法什麼時候用最好？
我已經成功使用這種方法作為和別人溝通的紐帶，當我教創業公司如何拉近他們和使用者群的距離以及告訴他們應該先開發哪些內容時，這種方法收效很好。它和一些方法不謀而合，例如Lean Startup，因為他為假說的產生提供了結構化的基礎。我還發現它可以用作説明設計決策的初步思維工具，也可以用作使用者研究過程中的整合工具。
毫無疑問，在你研究這個方法時，你可能會發現他的其他用處，或者也可能覺得他對你沒用。你可能會說這是一種適合所有工作的最好的工具，但最好的工具往往是能讓工作快速、簡單完成的工具。
在這種情況下，我有個非常簡單的方法讓我們可以方便的思考使用者行為和動機的範圍——時刻牢記他們所處的情境。
（微博UDC原創博文，轉載請注明出處
特別注意：本站所有轉載文章言論不代表本站觀點，本站所提供的攝影照片，插畫，設計作品，如需使用，請與原作者聯繫，文章轉自alibuybuy