編輯導語：一個產品重要的一項就是用戶體驗，產品中的用戶體驗也能很大的影響產品的好壞；本文以用戶體驗五要素為主線，結合筆者自身工作經驗，對需求分析工作中可能會遇到的坑或需要注意的地方進行了描述。
沒有充分思考過的經歷只是經歷，不等於經驗。——俞軍《產品方法論》
我們所生產的產品更多的是為人服務，讓人可以從我們的產品中獲得更好的用戶體驗；但是To G類的產品常常被認為達到目的、可以獲得結果即可，容易忽略部分用戶體驗；那從完整的用戶體驗的角度審視需求分析，工作中會容易有哪些問題呢？
《用戶體驗要素——以用戶為中心的產品設計》這本書將產品分為功能型產品和信息型產品兩類，通過戰略層、範圍層、結構層、框架層、表現層五個層面闡述如何滿足用戶需求，這五個層面循序漸進，由抽象逐步具體。
該書具體內容在此不再詳述，感興趣的話可以看這本書或在網上查一下相關內容；我所常接觸的是功能型產品，下文也將以此類產品展開。
用戶體驗五要素
01 戰略層：產品目的和用戶需求
To G可以歸類為To B，To B相較於To C來說更重商業價值。這個商業價值是兩方面的，於自己公司和於客戶，即為戰略層所強調的產品目的和用戶需求。
想要確定用戶需求，首先要對用戶進行分類，這有助於我們了解用戶的需求及需求的優先級。
第一個角度：對於To G來說，一個系統通常有兩類用戶——買方和用方；買方大多數是領導，需求來源為政策、工作實際需要等，其目的一般是向上匯報或向下管理；用方則包括部分買方和實際用戶，其目的則包括向上匯報、向下監督和實際使用。
從這裡不難看出，買方提出的需求往往優先級較高（To G類客戶的話誰的最應該聽可以看我的另一篇文章http://www.woshipm.com/zhichang/4278371.html）。
另一個角度：用戶所在單位的信息化程度。從這個角度，用戶可以分為信息化程度高和低的兩類；信息化程度越高的用戶，越容易用系統語言描述清楚自己的需求；信息化程度越低的用戶，對於較為初級的信息化系統，接受程度也會很高。
從戰略層本身來說，它明確了產品目的和用戶目的，是產品第一個需要考慮的內容；從另一個角度來看，也說明了解決問題應該是以目的為導向的，需要首先明確做一件事的目的，剩下的才是如何做、如何高效地做。
俞軍老師的《產品方法論》中也提到了一個更為升華的概念——理性決策三要素，按重要性由高到低的依次是：理性的信念、理性的目標、理性的行動。
俞軍老師的「理性決策三要素」
02 範圍層：功能規格
用戶的問題決定了最終需求，需求決定了系統的建設範圍；功能來源於需求，需求有強弱，功能亦有先後。
對於我常做的政府類項目，往往通過招投標形式獲得，系統的建設範圍相對來說是明晰的；但是系統範圍下的功能是有優先級的，如何把控這個優先級將決定了用戶的滿意度和項目進度。
舉兩個例子，這兩個例子來源於同一個項目下的兩個子系統：
第一個子系統A是對全國特別重大自然災害的評估系統；從08年汶川地震以來，近12年中，僅有6次特別重大自然災害[注1]，從這個數據可以看出來，這個系統的使用頻率並不高，但是一旦使用便是緊急且重要。
與此同時，我們的團隊也在開發著常態化災害評估系統，例如地震損失評估系統，這類子系統使用頻率高，相對應的優先級也高；基於這樣的背景，按照現在的思路，A系統的需求分析應先滿足基本流程，保證基本業務流程暢通條件下的精準評估，但之前的更多工作內容放在了如何讓這個系統更為方便的目的上，導致了系統功能的部分冗餘。
例如為使得用戶可以在任一階段使用本系統（考慮到由線下辦公改為線上辦公的過渡期），在有前後流程關係的多個模塊下的多個頁面中保留了【新建災害事件】的入口；這也就需要在各個【新建災害事件】時對事件進行關聯控制，以保證同一事件的流程完整性；結果可想而知，在後期實際開發過程中對所有功能進行了優先級重排，只保留了一個【新建】入口。
第二個子系統B是面向全國鄉鎮、縣、市、省、部五級用戶的上報系統，需要以鄉鎮為單位對需國家補助對象進行逐級上報審核；這其中有一個很細小的功能，是通過選擇本級補助對象進而上報。用過ArcMap的同學應該都知道，在圖層屬性中可以單獨查看已選中對象。
當時我覺得這個功能很好用，一定很有用，就引借了進來，開發過程中也遇到了些困難，為此開發人員沒少找我麻煩；但在開發完成後的反覆測試過程中，實際上很少使用這個功能，往往都是全選上報了；返回來想想缺少這個功能，整個流程能夠走通嗎，答案是肯定的。
ArcMap查看所有記錄或僅查看所選的記錄功能：
ArcMap查看所有記錄或僅查看所選的記錄功能說明
在剛進入這個行業時，很多前輩告訴我，「我們的需求應該是按照最全的去做，至於開發能開發多少和我們就沒有關係了」。
我一直對這段話保持懷疑，因為：
一來有些基本功能往往客戶比較著急使用，如果我們不分優先級全部進行分析，分析完成後再傳遞需求給開發，必然會造成客戶需求的延遲滿足，這是一個很不好的體驗；二來雖然在招投標時項目範圍已然確定，但一個大項目往往持續一年甚至更久，政策、用戶的需求很可能會發生變更，如果從一開始就按瀑布式項目執行，則會造成大量人力成本的浪費；三來需求分析成果的完備性很大程度依賴於需求分析人員的工作經驗與能力，在分析過程中難免會有考慮不周到的地方，如果最開始做了全量，很有可能會因為中間的一點小問題而牽一髮動全身。從上面的任何一點來說，我都覺得需求也應該是PDCA不斷滾動完成的，通過再分析、開發、測試等工作過程不斷地驗證之前地想法，並沿著正確的方向繼續向前。
03 結構層：互動設計
通常一個系統是為多個人服務的，不是一個人，因此系統的流程及交互要符合業務流程及用戶習慣，不能只從上帝視角（前後都清楚）認為用戶是肯定知曉這個動作的目的；而要從「無知者」（對這個系統的流程甚至目的一無所知）角度思考拿到這個系統時，用戶是否能夠知曉或下意識地進行下一步動作。
舉兩個例子：
在開發專題地圖[注2]（例如中國大陸2020年地震點位分布圖）製作B/S端系統時，需要在創建一個製圖空間後讓用戶從本地導入地震點位的矢量數據等所需數據，再進行後續的製圖流程直至完成專題圖製作。
在實際設計時系統在用戶點擊【新建製圖空間】後打開本地文件夾，讓用戶選擇數據文件；乍一看沒什麼問題，但在忽略本段第一句話的情況，重新審視系統流程，是否會有疑問：為什麼忽然間就打開了本地文件夾，是要讓我保存新建的製圖空間還是要幹什麼呢？
如果修改流程——用戶點擊【新建製圖空間】後，系統彈出面板，用戶點擊【添加數據】按鈕後打開本地文件夾，讓用戶選擇數據文件——便可讓用戶明晰地知曉動作的目的，並符合日常的工作流程及習慣。
打開本地文件夾彈窗
專題圖製作中的數據添加流程
繼續上一個例子：在選擇數據文件時，用戶選擇了.doc文件，點擊確定後系統沒有任何反應；用戶又選擇了一個.jpg文件，確定添加後系統依然沒有反應，此刻用戶下了定論：這個系統不能用。
但實際上，並不是系統不能用，也不是系統出了bug，而是僅支持.xls/.xlsx/.txt/.zip/.rar格式的數據導入；但系統並沒有在任一過程中給出提示引導用戶進行正確操作，這就是上帝視角下的「用戶怎麼不知道？」
數據添加時的格式控制與異常處理
04 框架層：界面設計、信息設計
好的設計是可以給用戶提供好的引導且不會引起用戶歧義，同時對於一些功能的修改風險具有一定的可擴展性。
界面設計–提供給用戶做某些事的能力；信息設計–傳達什麼樣的想法給用戶。
例如在使用「中國大陸地震點位分布圖」專題圖模板完成專題地圖製作後，需要對製圖成果進行保存和共享。
因此有了如下原型設計：
製圖成果保存與共享彈窗
這個界面中提供了用戶保存成果的能力，但卻沒有告訴用戶：
是否所有項均需填寫（必填性說明）；有哪些項是系統可提供默認值，無需用戶每次都進行選擇或填寫（默認值）；有哪些項是系統自動填充的，無需用戶誤認為需再次點擊操作（例成圖時間）；有哪些項是想要引導用戶進行適當信息補充，以便用戶後期追尋的（例描述）。
界面設計優化後的彈窗
對於信息量較少的頁面，到這一步也可以了，但如果用戶所填信息較多，為使用戶可以更好地明確要填什麼，避免因為看到一堆必填項而煩躁的心理，可以對信息進行分組重排。
信息設計優化後的彈窗
05 表現層：視覺設計
視覺設計是產品設計的最後一個環節，但卻是用戶接受的第一個環節。
視覺設計可能承載了一個產品甚至是一家公司的理念，同時也向用戶傳達每一個頁面的重點或是常用功能，用以引導用戶更高效地達到目的。
換句話說，一個頁面中的按鈕也有主次之分，如何能將主次凸顯，是視覺設計的一大要點。
視覺設計優化後的彈窗
06 總結
一個產品的誕生並不一定會完整的走過這五要素，也不一定會完全按照既定順序走到表現層；但可以通過這五要素返回來審視一個產品，總結經驗。
注1：6次特別重大自然災害：
1）2008年5月12日汶川8.0級地震；
2）2010年4月14日青海玉樹7.1級地震；
3）2010年8月8日甘肅舟曲特大山洪泥石流災害；
4）2013年4月20日四川蘆山7.0級地震；
5）2014年8月3日雲南魯甸6.5級地震；
6）2015年4月25日尼泊爾8.1級地震。
注2：專題地圖（thematic map），又稱特種地圖，是在地理底圖上按照地圖主題的要求，突出並完善地表示與主題相關的一種或幾種要素，使地圖內容專題化、表達形式各異、用途專門化的地圖。
本文由 @嘻嘻 原創發布於人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基於 CC0 協議