需求文檔200多頁、時間緊、變更頻繁，專業(yè)知識點還超多！如果是你接到這樣的一個復雜需求，你會如何展開工作？作者以實際工作中的這個具體項目為例，與我們一同探討如何應對復雜需求下的UX設計。歡迎閱讀~

上周給團隊做了一個15分鐘的小分享，以我們之前一個具體的B端項目為例，探討如何應對復雜需求下的UX設計。

由于這次的分享主題是由team內的小伙伴指定的，所以在分享的開始，我就問了一個問題：你們覺得這個項目復雜在哪里？

以前聽人大一個教授說，任何問題，都需要有一個定義域。后來聽舒祺老師講課的時候，也聽到一句話，叫做：defined before detented。

01 解決問題之前，先定義它

當你拿到一個你認為復雜的需求時，先確認對你而言，復雜的是什么很重要。以我分享的那個項目為實例，它的復雜性在于：

1. 我拿到手的需求是一份200多頁的技術要求文檔，是由甲方組織撰寫的國標文件，雖然實際描寫功能的只有10頁左右，但為了理解每個功能的具體細節(jié)，必須要翻看后面更偏技術的描述，比如接口結構、傳輸協(xié)議等等。而當時項目里也沒有產品經理的崗位幫助去梳理需求。這一條也是我當時分享時現(xiàn)場詢問小伙伴為什么覺得這個項目復雜時，所得到最多的答案。
2. 時間緊張，需求變更頻繁。中間一個版本又在這200多頁文檔里添加了詳細的后臺微服務及接口定義文檔，和最初我們自己后臺微服務框架和接口定義有許多不一致的地方。
3. B端項目本身的業(yè)務門檻和相關的專業(yè)知識點造成的壁壘。

02 這些復雜性，給UX設計帶來了什么困難？

有時候，我們很容易將現(xiàn)象和問題混淆起來，復雜和簡單只是事物的屬性，是這個世界的一部分，它并無好壞之分（詳見《馴服復雜，B端設計思考》）。

比如“200多頁的技術要求文檔，沒有專門的產品崗位去梳理需求”只是一個現(xiàn)象，并不是問題本身，需要定義的是你面臨的問題，而不是將現(xiàn)象和問題混為一談，因為同一個現(xiàn)象，可能對其他人造成的問題（也可能并不成為問題），和對你造成的問題是完全不一樣的。

在這個項目中，前面三點造成的問題主要有：

（一）兼顧大結構的同時，又要注意小的細節(jié)。

（二）同時期其他工作的干擾&后端接口文檔改動時自己的預判不足

（三）對業(yè)務的了解程度不夠可能造成設計后的界面交互并不那么滿足用戶體驗要求

（一）兼顧大結構的同時，又要注意小的細節(jié)。

我們知道，交互設計是要下沉到細節(jié)邏輯的，它流轉的不止是表層的界面跳轉，也關系到界面下的底層信息交互的邏輯運轉。

我之前寫過一篇文章，探討B(tài)端界面設計的復雜性從何而來（詳見《B端設計思考：以界面為觸點的信息流轉》）時也有聊到。

同時，B端系統(tǒng)需要交互的信息常常有很多（功能點多），也就意味著它需要許多許多彼此相關聯(lián)的界面來承載它們。

不過，面對項目當時的情景和目標，探討按鈕的擺放順序和表單字段是否冗余已經沒有任何意義，首先要確保的是主結構、主流程和關鍵界面的正確性。

好在這個項目之前，我已經做過一些相同業(yè)務領域的類似項目，所以在確認主結構和主流程上，我基本沒有浪費什么時間。

這塊的正確性和可擴展性，也保證了我在第二個現(xiàn)象：小需求變更頻繁的情況下，并不認為它有困擾到我，成為要專門解決的一個問題的原因。

在細節(jié)設計上面則更多的是保證它的無錯性而不是體驗性，比如遵循已有的平臺設計經驗，套用常規(guī)組件，在評審之前容忍許多細節(jié)處于非最優(yōu)設計的風險，然后依靠研發(fā)評審及開發(fā)和測試過程的反饋來不斷調整。

（二）同時期其他工作的干擾&后端接口文檔改動時自己的預判不足

單純的時間和工作任務沖突問題我認為還是比較好解決的，當時我同時期還有一些管理工作，所以我一方面從自己出發(fā)，盡量集中大塊時間來做這個項目的設計，并且提前將設計分批輸出&評審的時間計劃表同步了研發(fā)。另外一方面，我也小模塊地引入了其他兩位設計小伙伴的幫忙，加快了部分進度。

在這種情況下給出計劃并嚴格執(zhí)行我認為還是很重要的，這是一種確定感的給予，不僅能方便其他相關工作的安排，也能讓你在工作的過程中不會被打擾和追問。

第二個問題也是研發(fā)同事幫忙一起解決的，他們從接口文檔反推出可能新增或改動的界面功能給到我，我再結合他們的反饋去看滿滿技術語言的接口文檔，思考新增或改動的交互，的確快了不少。

當然，輸出也是分批分模塊和對應的前后端小伙伴確認的。

（三）對業(yè)務的了解程度不夠可能造成設計后的界面交互用戶體驗不佳

雖然這個問題我列上去了，但在做項目的時候并不是我的主要問題，第一個原因是之前項目鋪墊的業(yè)務知識已經讓我能夠確保主要邏輯和流程的正確性，第二個原因是項目當時的目標并不是實際投入使用，而是要去通過該系統(tǒng)所對標行業(yè)的一個資格考試。

這也再次說明了定義問題的重要性。

03 回顧這個項目

對于如何應對復雜需求的UX設計我認為有三個關鍵點值得一提：

1. 優(yōu)先保證主結構、主邏輯和關鍵幀

• 主要結構，指產品功能如何組織，它需要通過分類和層次性來體現(xiàn)。
• 主要邏輯，指用戶的思路如何流轉在幾個主要功能上面的，它需要通過界面的用戶流和邏輯流來體現(xiàn)。
• 關鍵幀，主結構和主邏輯的具體體現(xiàn)，是其中關鍵觸點的具化界面。

2. 確定你面臨的問題，而不是將現(xiàn)象和問題混為一談。

這也是我們上面一直在澄清的，每一個現(xiàn)象要定義它給你造成的具體問題上，defined before detented。

3. 最終，解決問題的本質，還是你以往經驗和能力的積累。

在做這個項目的過程中，如果我沒有之前的業(yè)務積累，我也沒辦法在面臨B端項目本身的業(yè)務門檻壁壘時，認為它所造成的問題不是那么主要，不會影響我的主邏輯和主流程。也沒有辦法在確保大結構放棄小細節(jié)時依然能夠保證細節(jié)的出錯概率在所有人可以容忍的范圍內。更沒辦法在面對第三個問題時輕輕放下，認為它影響不了大局。

另一方面，如果我的經驗和能力更好一些，在應對這些問題時就會更為輕松，也不會發(fā)生前面提到預判不足造成的措手不及。

總結一下

1. 復雜所造成的問題是什么？defined before detented。
2. 以一個B端項目為例：我的三個問題（兩頭兼顧、其他工作和預判不足、用戶體驗不佳）和主要的解決方法。
3. 三個關鍵，關于如何應對復雜需求下的UX設計。