紙上得來終覺淺，絕知此事要躬行。本文由實(shí)踐經(jīng)驗(yàn)總結(jié)而來。

[[211653]]

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

1.需求理解

多問為什么，充分理解需求，發(fā)現(xiàn)不合理處及時溝通

a.多問為什么——驗(yàn)證需求真?zhèn)渭皟r值

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

為什么需要這個功能?這個需求基于怎樣的場景?需求的來源及數(shù)量是怎樣?當(dāng)前想解決的最主要的問題是什么?預(yù)計(jì)以后的方向是什么?當(dāng)前問題和以后方向沖突嗎?等等，當(dāng)解決了這一系列問題，即驗(yàn)證完需求的真?zhèn)渭皟r值后，便可展開下一步了。

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

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

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

c.發(fā)現(xiàn)不合理處及時溝通

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

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

2.需求分析

理清設(shè)計(jì)目標(biāo)，梳理業(yè)務(wù)流程，對信息進(jìn)行合理分類

a.理清設(shè)計(jì)目標(biāo)——支撐你整個設(shè)計(jì)的最重要的元素

從基于場景的需求中，分析用戶最本質(zhì)的需求是什么，結(jié)合現(xiàn)有資源，再總結(jié)我們這個版本的設(shè)計(jì)目標(biāo)。

例如，需求是“可視化業(yè)務(wù)之間的訪問情況(可視化風(fēng)險)”，那么分析用戶心理后，本質(zhì)需求應(yīng)該是“能夠及時發(fā)現(xiàn)異常訪問，及時處理”，但結(jié)合現(xiàn)有資源，在處理安全問題上仍有陷缺，故最后得出我們的設(shè)計(jì)目標(biāo)就是“幫助用戶及時發(fā)現(xiàn)發(fā)現(xiàn)安全問題，并營造安全感”。

b.梳理業(yè)務(wù)流程——流程設(shè)計(jì)

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

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

c.對信息進(jìn)行合理分類——信息架構(gòu)設(shè)計(jì)

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

先根據(jù)流程整理出，完成所有任務(wù)需要的信息(并進(jìn)行優(yōu)先級劃分)，再根據(jù)遵循合理的規(guī)范分類組合(最好在信息架構(gòu)中標(biāo)明出)。

例如，我們的設(shè)計(jì)目標(biāo)是“幫助用戶及時發(fā)現(xiàn)發(fā)現(xiàn)xx問題，高效解決問題”，那么我們分類的規(guī)范則可分為“發(fā)現(xiàn)問題”“分析問題”“處理問題”“預(yù)防問題”幾個維度來對信息進(jìn)行分類。

3.原型設(shè)計(jì)

先畫草圖再畫原型，為最終版本設(shè)計(jì)，始終圍繞設(shè)計(jì)目標(biāo)做設(shè)計(jì)，每個設(shè)計(jì)都應(yīng)有出處，版本迭代時要注意和之前版本的融合

a.先畫草圖再畫原型

根據(jù)流程圖中標(biāo)記需要出的頁面，畫完草圖就可以和內(nèi)部或產(chǎn)品經(jīng)理討論整體思路了。既能快速表達(dá)想法，提高效率，也能在方案有偏差時，不至于因?yàn)槌翛]成本高而不愿舍棄。當(dāng)草圖得到認(rèn)可后，那么之后原型的大框架基本上就沒什么問題了，這樣即使原型有什么被質(zhì)疑的地方，也很好縮小范圍，知道要改什么具體的地方。

b.為最終版本設(shè)計(jì)

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

正確做法是: 只為最終版本設(shè)計(jì)，如果開發(fā)時間不夠，那么標(biāo)明目前版本的優(yōu)先級，有些開發(fā)難度高且價值不大的，則放在下一版本實(shí)現(xiàn)。

c.始終圍繞設(shè)計(jì)目標(biāo)做設(shè)計(jì)

設(shè)計(jì)師進(jìn)行原型設(shè)計(jì)時，通常會陷入一個誤區(qū): 做著做著，就忘了當(dāng)初為什么這樣做，然后深陷細(xì)節(jié)，忘記當(dāng)初的設(shè)計(jì)目標(biāo)。實(shí)際上，并不需要做這么多。時時反思自己的設(shè)計(jì)是不是圍繞設(shè)計(jì)目標(biāo)，可以防止自己做很多不必要的設(shè)計(jì)。

d.每個設(shè)計(jì)都應(yīng)有出處

要理解為什么要有這些步驟，理解后臺邏輯究竟能不能實(shí)現(xiàn)，不能想當(dāng)然地做設(shè)計(jì)。理解了這些步驟的來源，來能更好地結(jié)合用戶心理做更符合用戶心智、更高效的設(shè)計(jì); 理解了后臺邏輯，才不會做出邏輯上極難實(shí)現(xiàn)的設(shè)計(jì)。

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

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

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

4.多方評審

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

a.最終評審前，分階段找相關(guān)人員進(jìn)行評審

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

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

b.陳述方案時注意自上而下表達(dá)

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

在闡述時有主次之分，重點(diǎn)或大的改變最開始講，有的內(nèi)容則不需要細(xì)講，有人提出疑問或質(zhì)疑時再詳細(xì)解釋。

c.明確會議主題

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

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

d.記好會議紀(jì)要

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

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

5.項(xiàng)目跟進(jìn)

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

在這過程中，主動詢問相關(guān)人員有沒有遇到什么問題：交互文檔中有沒有什么沒看明白的地方或還未考慮到的地方;設(shè)計(jì)的實(shí)現(xiàn)難度;如果時間緊張，那么設(shè)計(jì)的優(yōu)先級是怎樣……

6.修改迭代

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