起點課堂會員權益
職業(yè)體系課特權
線下行業(yè)大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識實踐總結：敏捷開發(fā)下的B端交互設計流程
紙上得來終覺淺，絕知此事要躬行。本文由實踐經驗總結而來。
交互設計師在這整個流程中，需要主動推動項目的進展，積極溝通，充分協(xié)作。在需求階段充分了解需求，設計階段不斷與產品經理（需求方）及相關人員（視覺、開發(fā)等）溝通，開發(fā)階段積極傳遞設計目標及效果，有變更及時通知。盡量保證整個團隊的信息同步，才有可能高品質地實現(xiàn)敏捷開發(fā)。
1.需求理解
多問為什么，充分理解需求，發(fā)現(xiàn)不合理處及時溝通
a.多問為什么——驗證需求真?zhèn)渭皟r值
由于B端產品的需求通常來源于產品經理或銷售訪談客戶或用戶時獲取，交互很少有機會參與，所以需求多由產品經理向交互傳遞。而在這傳遞的過程中，往往夾雜著一些表面需求或個體需求，或是產品經理自己也不太明確的需求，因此，“多問為什么”則顯得至關重要。一是避免大方向錯誤導致的返工，二是有助于深入了解需求背景。
為什么需要這個功能？這個需求基于怎樣的場景？需求的來源及數(shù)量是怎樣？當前想解決的最主要的問題是什么？預計以后的方向是什么？當前問題和以后方向沖突嗎？等等，當解決了這一系列問題，即驗證完需求的真?zhèn)渭皟r值后，便可展開下一步了。
b.充分理解需求——挖掘深層需求
B端產品涉及到繁雜的業(yè)務，做設計時，對于業(yè)務邏輯的要求非常高；在設計前充分理解需求，理清本階段的設計目標，有助于設計階段能更全面地看待問題，而不是針對一小點一小點的設計，同時避免因理解誤差導致的方案不理想。
實際工作過程中，產品經理提供需求時常常是不完整的，只簡單闡述背景和這樣做的原因，而一些隱含的更深層次的（或說更原始的）背景原因和條件，則需要交互設計師不斷去思考、不斷與需求方溝通才得知。如果沒有充分理解需求，僅僅知道用戶的操作步驟是由這到那，而不清楚他進行步驟的背景和原因，不僅會導致對需求有理解偏差，無法挖掘到深層次的需求，更別談做出最優(yōu)解的設計了。
c.發(fā)現(xiàn)不合理處及時溝通
在整個需求傳遞的過程中，產品經理提出的需求不一定是原始需求，有些則是經過加工或推測得來。當發(fā)現(xiàn)需求有不合理的地方時，應及時向相關人員詢問溝通。不要等到設計時，才發(fā)現(xiàn)一大堆由“假問題”引發(fā)出來的“真問題”。當然，如果這階段交互發(fā)現(xiàn)了什么好的/可改進的需求點，也可以提出與產品經理討論。
有的時候，產品經理通常會以“ 市場就是這樣的 ”/ “這個地方不需要你理解”等等理由來回避一些可能有缺陷的需求，這個時候仍然不要放棄，要繼續(xù)了解原因，最大化地避免前期失誤導致的后期更大工作量的浪費。
2.需求分析
理清設計目標，梳理業(yè)務流程，對信息進行合理分類
a.理清設計目標——支撐你整個設計的最重要的元素
從基于場景的需求中，分析用戶最本質的需求是什么，結合現(xiàn)有資源，再總結我們這個版本的設計目標。
例如，需求是“可視化業(yè)務之間的訪問情況（可視化風險）”，那么分析用戶心理后，本質需求應該是“能夠及時發(fā)現(xiàn)異常訪問，及時處理”，但結合現(xiàn)有資源，在處理安全問題上仍有陷缺，故最后得出我們的設計目標就是“幫助用戶及時發(fā)現(xiàn)發(fā)現(xiàn)安全問題，并營造安全感”。
b.梳理業(yè)務流程——流程設計
梳理業(yè)務流程時，代入同理心，分析用戶為什么要進行這個任務，有哪些觸點可以促使他進行這個任務，任務進行中可能會經過哪些步驟。設計流程時，先設計主線，再設計支線，使邏輯完整，標出需要設計的頁面（畫草圖，防止后續(xù)畫原型時頁面缺失）。
在畫流程圖時，僅寫對象到觸點，到各任務步驟，再到任務結束點 ; 而不要將解決方案（具體交互形式）放入流程中，例如，“用戶拖動子對象到母對象中”是含有解決方案的，應改為“用戶添加子對象到母對象內”，至于“添加”這一行為，究竟是用“鼠標點擊拖動”還是“點擊添加按鈕選擇對象”，又或者是“選擇子對象，再選擇母對象，自動移動”等等，這些應該在草圖設計中呈現(xiàn)，而不是在流程中敘述，防止在頁面設計時被拘束。
c.對信息進行合理分類——信息架構設計
B端產品往往信息繁多，架構復雜。所以對信息進行合理分類，設計一個好的信息架構十分重要。其中最重要的一點是——遵循合理的一致的規(guī)范，而這個規(guī)范也一定是圍繞著我們的設計目標來的，我們最想讓用戶關注到什么，最想產品能解決什么問題。一是方便用戶理解產品，在第一眼時就能對產品有簡單的認知；二是方便后續(xù)有新功能加入時，仍能遵循原來的規(guī)范。
先根據(jù)流程整理出，完成所有任務需要的信息（并進行優(yōu)先級劃分），再根據(jù)遵循合理的規(guī)范分類組合（最好在信息架構中標明出）。
例如，我們的設計目標是“幫助用戶及時發(fā)現(xiàn)發(fā)現(xiàn)xx問題，高效解決問題”，那么我們分類的規(guī)范則可分為“發(fā)現(xiàn)問題”“分析問題”“處理問題”“預防問題”幾個維度來對信息進行分類。
3.原型設計
先畫草圖再畫原型，為最終版本設計，始終圍繞設計目標做設計，每個設計都應有出處，版本迭代時要注意和之前版本的融合
a.先畫草圖再畫原型
根據(jù)流程圖中標記需要出的頁面，畫完草圖就可以和內部或產品經理討論整體思路了。既能快速表達想法，提高效率，也能在方案有偏差時，不至于因為沉沒成本高而不愿舍棄。當草圖得到認可后，那么之后原型的大框架基本上就沒什么問題了，這樣即使原型有什么被質疑的地方，也很好縮小范圍，知道要改什么具體的地方。
b.為最終版本設計
有的時候，可能因為時間的原因，有些方案就只能實現(xiàn)一半，而一半的效果又往往不是當前時間、資源下的最優(yōu)解。于是，有些交互便會為當前情況下，做出中間版本的設計。（沒錯，就是之前的我）可實際上，這樣的設計，并沒有給未來帶來任何好處，反而會徒添之后開發(fā)修改的任務量。
正確做法是: 只為最終版本設計，如果開發(fā)時間不夠，那么標明目前版本的優(yōu)先級，有些開發(fā)難度高且價值不大的，則放在下一版本實現(xiàn)。
c.始終圍繞設計目標做設計
設計師進行原型設計時，通常會陷入一個誤區(qū): 做著做著，就忘了當初為什么這樣做，然后深陷細節(jié)，忘記當初的設計目標。實際上，并不需要做這么多。時時反思自己的設計是不是圍繞設計目標，可以防止自己做很多不必要的設計。
d.每個設計都應有出處
要理解為什么要有這些步驟，理解后臺邏輯究竟能不能實現(xiàn)，不能想當然地做設計。理解了這些步驟的來源，來能更好地結合用戶心理做更符合用戶心智、更高效的設計; 理解了后臺邏輯，才不會做出邏輯上極難實現(xiàn)的設計。
例如，“后臺驗證用戶手機號”，是應該在“用戶點擊獲取驗證碼”時驗證還是在“輸入驗證碼點擊確定”后驗證呢？從體驗角度上，“點擊獲取驗證碼”基本上就能確認用戶已成功輸入了自己的手機號，理應這時驗證會節(jié)省幾個步驟，用戶體驗會更高效自然一點; 但是如果再多了解一些后臺邏輯的話，可能就會發(fā)現(xiàn)這還存在著很多問題了。
e.版本迭代時注意和之前版本融合
一個產品是一個整體，版本迭代有新增模塊時，要考慮這個模塊與之前的其他模塊有什么聯(lián)系（做好信息架構，也可提前幫助解決這個問題）; 之前產品的慣有交互形式是怎樣的; 相同類型的功能有什么聯(lián)系，能不能整合; 有哪些地方是需要和之前產品保持一致的，等等。
4.多方評審
最終評審前分階段找相關人員進行評審，陳述方案時注意自上而下表達，明確會議主題，記好會議紀要
a.最終評審前，分階段找相關人員進行評審
在需求分析階段，找主對接的產品經理來確認自己產出的設計思路，整體流程等大方向有沒有什么問題; 在設計階段，也要保持和內部人員以及產品經理的溝通，確認主要的原型頁面，在接著細化細節(jié)，再與主對接的產品經理溝通。在這個過程中，還應積極向視覺、開發(fā)同步傳遞需求及設計理念。
這樣與相關人員經常保持溝通，信息同步，既可以減少自己因閉門造車而在最終評審時的大返工，又可以讓團隊人員提前了解提前做好準備，從而提升團隊效率。
b.陳述方案時注意自上而下表達
先講大場景，再講小分支。先簡單敘述下我們的產品目標和設計目標，再說我們主要解決了哪幾個場景下發(fā)生的問題。接著講流程，先主線任務，如有時間再講支線任務。講頁面之前，要先講頁面是怎么來的；講頁面時，不要細講里面的內容，要在具體的詳情頁面中對照著講，這樣參會人更容易理解。在詳述每個頁面的過程中，分別描述清楚what？why？how？幾點即可。
在闡述時有主次之分，重點或大的改變最開始講，有的內容則不需要細講，有人提出疑問或質疑時再詳細解釋。
c.明確會議主題
明確會議主題，是提高會議效率的首要指標。在會議前明確主題，盡量討論具象化（有初步想法后再開會），即最好有實際的圖表現(xiàn)出來，不然大家討論全憑腦袋空想，且就算達成一致大家想的還不一定一樣，這樣開會會非常浪費時間且沒有意義。
當遇到分歧或疑問時，如果是會議主題內的，能當場解決的當場解決，無法當場解決，先記錄下來，會下繼續(xù)討論。如果是會議主題外的，則做好記錄，會下與疑問提出人討論。另外，在會議中看交互稿時，參會人員很容易提出細節(jié)和視覺層面的問題，此時要講清楚這不是視覺稿，而是交互稿，主要是過內容和邏輯，不要糾結細節(jié)，具體風格、樣式等內容在視覺階段再提出。
d.記好會議紀要
現(xiàn)實中，一次性交付交互稿顯然是不可能的，再加上需求方不時的需求變動、各職責人員站在自己角度看待問題的差異，會議上難免會產生一些分歧，導致需要改稿。所以會議上需要記好詳細的會議紀要，以便對已確定的改動，交互設計師改稿后，與相關人員會下（或下次會議）再次確認；對提出的尚不明確的需求，會下及時與相關人員溝通，盡快確定。
另外，在會議上，產品經理“突發(fā)奇想”得出的新需求或要變動的需求，在未確認價值前，一定不要當場答應?？梢韵葘热葑鲈敿氂涗洠跁陆涍^仔細評估是否合理，價值多大，與提出人再次確定后，再決定是否要改。并且所有的需求還需要產品經理們協(xié)調一致后，再做決定；若產品經理內部遲遲未確定，那可交互先行，一是從交互角度判斷可不可行，可行的話先畫出草圖，出初步思路，再去找產品經理討論；二是占據(jù)主動性，更有話語權。
5.項目跟進
即使已經定稿交付開發(fā)，也會有很多或細節(jié)、或實現(xiàn)難度、或時間資源方面的問題，所以不能一交付完就萬事大吉了。畢竟最終的開發(fā)效果，根本性地決定著用戶體驗。實際項目中，經常有這樣的情況：開發(fā)遇到問題卻沒有詢問交互，而是自己用“自己的方式”解決。這顯然是最糟糕的情況，所以為了保證最終體驗，交互應主動進行項目跟進。
在這過程中，主動詢問相關人員有沒有遇到什么問題：交互文檔中有沒有什么沒看明白的地方或還未考慮到的地方；設計的實現(xiàn)難度；如果時間緊張，那么設計的優(yōu)先級是怎樣……
6.修改迭代
若設計需要有小的改動，則應先找相關人員討論，多方明確且達成一致后，再做變更，并在交互文檔中最好對應的變更紀要和具體說明。最后，將相關事項發(fā)郵件給所有項目成員。如有必要，則還需集中對相關人員再進行一次會上的講解說明。若改動較大，則放到下一版本。
作者：丸子圓，目前大四在讀，喜愛交互和心理學，歡迎前來交流指導。
本文由 @丸子圓 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載。
題圖來自PEXELS，基于CC0協(xié)議
很厲害，剛大四就總結的這么棒！我也是帶著手機號驗證的疑問來看的評論，哈哈，不錯的“埋點”。
我不太認同UI也要介紹入到產品需求里面。。。這和產品的功能不是交叉了嗎？之前的一個公司，就是這樣，產品與業(yè)務，及至 與研發(fā)都參與 了里面，UI，也要參與 ，還嫌不夠熱門，不夠亂嗎？
本來達成一個需求就是妥協(xié) 的結果，參與 的人越多，越難妥協(xié)。
很不錯了，大學尚未畢業(yè)就對于項目流程有這般的了解。很多東西不是一成不變的，企業(yè)也一直圍繞著利潤和風險展開，以這一目標為導向不斷在工作中思考總結，終會找到屬于你自己的項目流程 ?? 。
同學你好啊
常規(guī)規(guī)定動作套路吧。
這的確是常規(guī)套路，但套路不是被規(guī)定的，知道為什么，才能更好地運用。正如我在引言里說的“紙上得來終覺淺，絕知此事要躬行”，就是說的我的心路歷程，最開始的時候，做設計之后套用流程，而不知道為什么要做這些事，最后事情都做了卻是每個環(huán)節(jié)都脫節(jié)的，前期調研、設計目標之類的和最終原型幾乎沒有聯(lián)系。經過這次實習后，終于理解每個環(huán)節(jié)對下一環(huán)節(jié)的重要性，也能實際運用。于是，我便寫了這篇文章與大家共勉(?′?`?)
打錯字了，尷尬_(:_」∠)_ ……是做設計的時候…
流程是對的，關鍵在執(zhí)行，很多時候程序員會按自己的理解的來做，所以他們做完你應該第一個去測試，否則出來的東西基本完全走樣，還有你那個交互設計文檔是怎樣寫的是否可以截圖跟大家分享一下，我基本都是拿著原型跟程序口頭交流的。
在我看來獲取手機號選取方案一成本最低，我比較想知道其中存在的問題，希望能交流一下
我也很想聽聽您的見解，感覺我對這個的理解可能還不夠深入吧。您可以加我微信AiyouyouSuannai ，與您詳細探討一下
確實總結的很好，理清楚需求本質+目標導向設計在B端甚至整個產品設計中都是非常重要的步驟。另外每個設計都應有出處非常同意。點擊發(fā)送驗證碼那里驗證手機會有什么后臺邏輯影響還望說的更仔細一些。
同樣請教作者在后臺驗證時，點擊發(fā)送驗證碼和點擊確認兩種狀態(tài)方式后臺驗證邏輯的區(qū)別？
關于這個是因產品而異的。當時對于這個，我的理解是因為發(fā)送驗證碼時是調用的第三方接口，需要發(fā)送驗證碼、返回驗證碼和驗證碼時效數(shù)據(jù)等，然后如果再在這里添加一個核對用戶信息的話，會牽連到很多其他邏輯（例如發(fā)送流程限制、唯一性識別等來防止惡意攻擊），容易出bug。在以減少用戶受挫和安全的前提下，點擊確認會好一點
1、即使發(fā)送驗證碼時調用的是第三方接口，也可以同時再調用自己的接口來驗證手機號吧，方案一還是可以安全的實現(xiàn)的；
2、設計心理學里有一個很重要的原則是【反饋】，其中就包括反饋的及時性，如果是點擊確定驗證，明顯違反了及時性；
3、順便問下這個是要驗證手機號在后臺庫里是否存在么？如果是的話那在光標移除手機號輸入框時不就可以驗證了么？
4、關于“每個設計都應該有出處”我不是完全同意，對于懂些技術的PM或UI在進行產品設計時時常會陷入這么設計技術能不能實現(xiàn)的坑，這樣是不能設計好一個功能/產品的，因為會這樣可能會輕視用戶真正想要的是什么，及怎樣的交互是最自然的。不過不去了解背后的邏輯確實也不妥，這就是個博弈論，找到一個適合自己的那個黃金分割點才是最重要的。
感覺我好像舉了一個復雜又不太貼切的栗子，導致大家有很多誤解，我的鍋我的鍋【捂臉.png】
現(xiàn)在說說我對這個問題的看法吧，如有不對還望指正:
我先說下關于這個的背景: 這是一個用戶開通高權限功能時的確認（一驗證手機號是否是本人，二驗證該手機號是否在庫、是否曾經已開通過），而普通用戶開通這個高權限功能，即前面驗證都成功，那么就會對用戶進行扣費。
然后再來回答您的問題:
1.其實兩種方案都是技術上可實現(xiàn)的，只是需要因產品特性而定，對于剛剛的背景，由于直接和費用有關，所以需要特別謹慎。方案一相比之下，出bug的可能性會更高; 所以當時開發(fā)建議選用方案二。
2.這兩個方案都是和后臺邏輯有關，和前端沒什么太大關系。對于主流程來講，未開通的去開通，兩個方案所感受到的是一樣的;對于分支流程來講，如果手機號被提前開通過或者手機號不在庫等情況，方案一可提前告知用戶。關于你說的反饋，兩個方案是都會有反饋的，因為用戶點擊“獲取驗證碼”時，他的期待都是收到驗證碼;點擊確定的時候，才是驗證用戶信息（手機號），所以對于用戶來說，是有相同的期待和反饋的，只是方案一在分支流程中可能會更有效率。
3.是的，必須后臺驗證，前端驗證不了，你說的那種方案需要前端做驗證。
4.關于你說的這種現(xiàn)象我非常同意，感覺我“每個設計都應該有出處”這個標題可能有些讓人引起誤解了。主要是想說要了解業(yè)務背景和一些開發(fā)知識，知道為什么這么設計和為什么不能這么設計。舉另一個栗子可能更貼切一點，在PC端桌面，將一個應用入口（例如PS）鼠標拖動到桌面一個文件夾，這種做法很常見; 但是在web端，實現(xiàn)相同的操作卻很難。我個人認為，設計時最好不要有太多限制，但設計最終是需要考慮性價比的，如果實現(xiàn)難度和最終效益不成正比，這樣的設計也是不成功的。
總結思路很清晰，也很到位，實際與客戶溝通中的很多常見場景都有描述，學習了。
寫的真詳細，懇求指導，準備學習產品
過程很完整，厲害了~~好的交互的確不應該沉迷于設計細節(jié)，而需心系全局
寫得很棒，看到了最后歡迎前來交流指導，就想厚臉皮的來求個好友??
好啊好啊～我也很榮幸??我的微信號是AiyouyouSuannai 只是我最近在忙于找工作，所以可能不會及時回復，但是我真的是非常樂意的??
是否參與過B端產品實踐設計工作
我今年暑假有幸在深信服（專門做B端產品的一家公司）實習了3個月，完整負責過2個項目，在期間學到了很多，所以這也算是我的實踐中發(fā)現(xiàn)的問題以及解決方案的總結吧
大四。。。厲害惹
嘿嘿～多虧我暑假實習的時候跟了一個好師傅??學到了很多～
0歲端B產品經理，之前做B端saas軟件銷售的，最近感覺學習到不少，但感覺最大的落差就是想法和思路往往要多次更改，需要和團隊不斷妥協(xié)借鑒，同時對業(yè)務實際的學習也需要花大量時間研究，不過相反也能得到鍛煉，能從他人身上學到不少，技能是基礎，溝通與團隊協(xié)作才是最重要的，有效溝通協(xié)作，團隊間信任，才能高效產出實用的產品。
嗯嗯，非常同意，團隊間就是要共同學習共同進步