紙上得來終覺淺，絕知此事要躬行。本文由實踐經驗總結而來。

[[211653]]

交互設計師在這整個流程中，需要主動推動項目的進展，積極溝通，充分協作。在需求階段充分了解需求，設計階段不斷與產品經理(需求方)及相關人員(視覺、開發等)溝通，開發階段積極傳遞設計目標及效果，有變更及時通知。盡量保證整個團隊的信息同步，才有可能高品質地實現敏捷開發。

1.需求理解

多問為什么，充分理解需求，發現不合理處及時溝通

a.多問為什么——驗證需求真偽及價值

由于B端產品的需求通常來源于產品經理或銷售訪談客戶或用戶時獲取，交互很少有機會參與，所以需求多由產品經理向交互傳遞。而在這傳遞的過程中，往往夾雜著一些表面需求或個體需求，或是產品經理自己也不太明確的需求，因此，“多問為什么”則顯得至關重要。一是避免大方向錯誤導致的返工，二是有助于深入了解需求背景。

為什么需要這個功能?這個需求基于怎樣的場景?需求的來源及數量是怎樣?當前想解決的最主要的問題是什么?預計以后的方向是什么?當前問題和以后方向沖突嗎?等等，當解決了這一系列問題，即驗證完需求的真偽及價值后，便可展開下一步了。

b.充分理解需求——挖掘深層需求

B端產品涉及到繁雜的業務，做設計時，對于業務邏輯的要求非常高;在設計前充分理解需求，理清本階段的設計目標，有助于設計階段能更全面地看待問題，而不是針對一小點一小點的設計，同時避免因理解誤差導致的方案不理想。

實際工作過程中，產品經理提供需求時常常是不完整的，只簡單闡述背景和這樣做的原因，而一些隱含的更深層次的(或說更原始的)背景原因和條件，則需要交互設計師不斷去思考、不斷與需求方溝通才得知。如果沒有充分理解需求，僅僅知道用戶的操作步驟是由這到那，而不清楚他進行步驟的背景和原因，不僅會導致對需求有理解偏差，無法挖掘到深層次的需求，更別談做出最優解的設計了。

c.發現不合理處及時溝通

在整個需求傳遞的過程中，產品經理提出的需求不一定是原始需求，有些則是經過加工或推測得來。當發現需求有不合理的地方時，應及時向相關人員詢問溝通。不要等到設計時，才發現一大堆由“假問題”引發出來的“真問題”。當然，如果這階段交互發現了什么好的/可改進的需求點，也可以提出與產品經理討論。

有的時候，產品經理通常會以“ 市場就是這樣的 ”/ “這個地方不需要你理解”等等理由來回避一些可能有缺陷的需求，這個時候仍然不要放棄，要繼續了解原因，最大化地避免前期失誤導致的后期更大工作量的浪費。

2.需求分析

理清設計目標，梳理業務流程，對信息進行合理分類

a.理清設計目標——支撐你整個設計的最重要的元素

從基于場景的需求中，分析用戶最本質的需求是什么，結合現有資源，再總結我們這個版本的設計目標。

例如，需求是“可視化業務之間的訪問情況(可視化風險)”，那么分析用戶心理后，本質需求應該是“能夠及時發現異常訪問，及時處理”，但結合現有資源，在處理安全問題上仍有陷缺，故最后得出我們的設計目標就是“幫助用戶及時發現發現安全問題，并營造安全感”。

b.梳理業務流程——流程設計

梳理業務流程時，代入同理心，分析用戶為什么要進行這個任務，有哪些觸點可以促使他進行這個任務，任務進行中可能會經過哪些步驟。設計流程時，先設計主線，再設計支線，使邏輯完整，標出需要設計的頁面(畫草圖，防止后續畫原型時頁面缺失)。

在畫流程圖時，僅寫對象到觸點，到各任務步驟，再到任務結束點 ; 而不要將解決方案(具體交互形式)放入流程中，例如，“用戶拖動子對象到母對象中”是含有解決方案的，應改為“用戶添加子對象到母對象內”，至于“添加”這一行為，究竟是用“鼠標點擊拖動”還是“點擊添加按鈕選擇對象”，又或者是“選擇子對象，再選擇母對象，自動移動”等等，這些應該在草圖設計中呈現，而不是在流程中敘述，防止在頁面設計時被拘束。

c.對信息進行合理分類——信息架構設計

B端產品往往信息繁多，架構復雜。所以對信息進行合理分類，設計一個好的信息架構十分重要。其中最重要的一點是——遵循合理的一致的規范，而這個規范也一定是圍繞著我們的設計目標來的，我們最想讓用戶關注到什么，最想產品能解決什么問題。一是方便用戶理解產品，在第一眼時就能對產品有簡單的認知;二是方便后續有新功能加入時，仍能遵循原來的規范。

先根據流程整理出，完成所有任務需要的信息(并進行優先級劃分)，再根據遵循合理的規范分類組合(最好在信息架構中標明出)。

例如，我們的設計目標是“幫助用戶及時發現發現xx問題，高效解決問題”，那么我們分類的規范則可分為“發現問題”“分析問題”“處理問題”“預防問題”幾個維度來對信息進行分類。

3.原型設計

先畫草圖再畫原型，為最終版本設計，始終圍繞設計目標做設計，每個設計都應有出處，版本迭代時要注意和之前版本的融合

a.先畫草圖再畫原型

根據流程圖中標記需要出的頁面，畫完草圖就可以和內部或產品經理討論整體思路了。既能快速表達想法，提高效率，也能在方案有偏差時，不至于因為沉沒成本高而不愿舍棄。當草圖得到認可后，那么之后原型的大框架基本上就沒什么問題了，這樣即使原型有什么被質疑的地方，也很好縮小范圍，知道要改什么具體的地方。

b.為最終版本設計

有的時候，可能因為時間的原因，有些方案就只能實現一半，而一半的效果又往往不是當前時間、資源下的最優解。于是，有些交互便會為當前情況下，做出中間版本的設計。(沒錯，就是之前的我)可實際上，這樣的設計，并沒有給未來帶來任何好處，反而會徒添之后開發修改的任務量。

正確做法是: 只為最終版本設計，如果開發時間不夠，那么標明目前版本的優先級，有些開發難度高且價值不大的，則放在下一版本實現。

c.始終圍繞設計目標做設計

設計師進行原型設計時，通常會陷入一個誤區: 做著做著，就忘了當初為什么這樣做，然后深陷細節，忘記當初的設計目標。實際上，并不需要做這么多。時時反思自己的設計是不是圍繞設計目標，可以防止自己做很多不必要的設計。

d.每個設計都應有出處

要理解為什么要有這些步驟，理解后臺邏輯究竟能不能實現，不能想當然地做設計。理解了這些步驟的來源，來能更好地結合用戶心理做更符合用戶心智、更高效的設計; 理解了后臺邏輯，才不會做出邏輯上極難實現的設計。

例如，“后臺驗證用戶手機號”，是應該在“用戶點擊獲取驗證碼”時驗證還是在“輸入驗證碼點擊確定”后驗證呢?從體驗角度上，“點擊獲取驗證碼”基本上就能確認用戶已成功輸入了自己的手機號，理應這時驗證會節省幾個步驟，用戶體驗會更高效自然一點; 但是如果再多了解一些后臺邏輯的話，可能就會發現這還存在著很多問題了。

e.版本迭代時注意和之前版本融合

一個產品是一個整體，版本迭代有新增模塊時，要考慮這個模塊與之前的其他模塊有什么聯系(做好信息架構，也可提前幫助解決這個問題); 之前產品的慣有交互形式是怎樣的; 相同類型的功能有什么聯系，能不能整合; 有哪些地方是需要和之前產品保持一致的，等等。

4.多方評審

最終評審前分階段找相關人員進行評審，陳述方案時注意自上而下表達，明確會議主題，記好會議紀要

a.最終評審前，分階段找相關人員進行評審

在需求分析階段，找主對接的產品經理來確認自己產出的設計思路，整體流程等大方向有沒有什么問題; 在設計階段，也要保持和內部人員以及產品經理的溝通，確認主要的原型頁面，在接著細化細節，再與主對接的產品經理溝通。在這個過程中，還應積極向視覺、開發同步傳遞需求及設計理念。

這樣與相關人員經常保持溝通，信息同步，既可以減少自己因閉門造車而在最終評審時的大返工，又可以讓團隊人員提前了解提前做好準備，從而提升團隊效率。

b.陳述方案時注意自上而下表達

先講大場景，再講小分支。先簡單敘述下我們的產品目標和設計目標，再說我們主要解決了哪幾個場景下發生的問題。接著講流程，先主線任務，如有時間再講支線任務。講頁面之前，要先講頁面是怎么來的;講頁面時，不要細講里面的內容，要在具體的詳情頁面中對照著講，這樣參會人更容易理解。在詳述每個頁面的過程中，分別描述清楚what?why?how?幾點即可。

在闡述時有主次之分，重點或大的改變最開始講，有的內容則不需要細講，有人提出疑問或質疑時再詳細解釋。

c.明確會議主題

明確會議主題，是提高會議效率的首要指標。在會議前明確主題，盡量討論具象化(有初步想法后再開會)，即最好有實際的圖表現出來，不然大家討論全憑腦袋空想，且就算達成一致大家想的還不一定一樣，這樣開會會非常浪費時間且沒有意義。

當遇到分歧或疑問時，如果是會議主題內的，能當場解決的當場解決，無法當場解決，先記錄下來，會下繼續討論。如果是會議主題外的，則做好記錄，會下與疑問提出人討論。另外，在會議中看交互稿時，參會人員很容易提出細節和視覺層面的問題，此時要講清楚這不是視覺稿，而是交互稿，主要是過內容和邏輯，不要糾結細節，具體風格、樣式等內容在視覺階段再提出。

d.記好會議紀要

現實中，一次性交付交互稿顯然是不可能的，再加上需求方不時的需求變動、各職責人員站在自己角度看待問題的差異，會議上難免會產生一些分歧，導致需要改稿。所以會議上需要記好詳細的會議紀要，以便對已確定的改動，交互設計師改稿后，與相關人員會下(或下次會議)再次確認;對提出的尚不明確的需求，會下及時與相關人員溝通，盡快確定。

另外，在會議上，產品經理“突發奇想”得出的新需求或要變動的需求，在未確認價值前，一定不要當場答應。可以先將內容做詳細記錄，在會下經過仔細評估是否合理，價值多大，與提出人再次確定后，再決定是否要改。并且所有的需求還需要產品經理們協調一致后，再做決定;若產品經理內部遲遲未確定，那可交互先行，一是從交互角度判斷可不可行，可行的話先畫出草圖，出初步思路，再去找產品經理討論;二是占據主動性，更有話語權。

5.項目跟進

即使已經定稿交付開發，也會有很多或細節、或實現難度、或時間資源方面的問題，所以不能一交付完就萬事大吉了。畢竟最終的開發效果，根本性地決定著用戶體驗。實際項目中，經常有這樣的情況：開發遇到問題卻沒有詢問交互，而是自己用“自己的方式”解決。這顯然是最糟糕的情況，所以為了保證最終體驗，交互應主動進行項目跟進。

在這過程中，主動詢問相關人員有沒有遇到什么問題：交互文檔中有沒有什么沒看明白的地方或還未考慮到的地方;設計的實現難度;如果時間緊張，那么設計的優先級是怎樣……

6.修改迭代

若設計需要有小的改動，則應先找相關人員討論，多方明確且達成一致后，再做變更，并在交互文檔中最好對應的變更紀要和具體說明。最后，將相關事項發郵件給所有項目成員。如有必要，則還需集中對相關人員再進行一次會上的講解說明。若改動較大，則放到下一版本。