敏捷開發下的B端交互設計流程

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

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.修改迭代

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