編輯導讀：當需要其他部門同事配合完成工作，項目需要跨團隊協作時，總是會遇到重重難題。如果沒有做好溝通，可能會影響后續項目進程。本文作者從自身經驗出發，梳理了B端項目中提高合作效率的幾個要點，希望對你有所幫助~

引言

是否遇到過開發做出來的東西與自己心里想要的完全不一樣？

自己辛苦設計的UI，被開發還原的體無完膚？

明明很多交互邏輯已經寫的很清楚了，開發還是會跑來問自己，手頭上的活總是被打斷？

這些問題，都可以理解為溝通出了問題，或者說團隊配合效率低下。站在公司角度而言，就是開發成本增加了，我們常說的創造價值，拋開資源的問題，無非就是省成本或提高效率。

下面我將從三個方面來聊聊如何提高合作效率，即產品、交互、UI。

一、產品

B端項目一般是由業務部門向IT部門提需求，IT部門接到需求經過分析后，解決這個需求。

所以前期就少不了與業務人員的頻繁溝通，并逐步敲定業務真正要的需求。

1. 與業務溝通

業務提交的需求文檔，這里我理解為業務需求文檔，主要是表達自己想要做的功能，其實格式真的不用限制，這里可以用到交互中的需求分析方法去細化業務真正想要的東西，并盡量分析出業務場景和實際操作用戶。

（1）字段表

首先要羅列出項目需要用到的所有字段。

這些字段從哪里來，例如是從上游系統遷入而來，還是本系統新建而來，或者兩者都有，在與業務溝通時就需要把這些問題搞得跟清楚，并與業務達成一致；同時也要搞清楚，這些字段將會去往哪里，以及在本系統中如何被使用。

字段屬性，包括字段名稱、字段類型、字段長度、字段取值舉例等，這些細節除了要跟業務確認，也需要和開發進行溝通。盡量提前準備好開發需要的細節點。

（2）權限

權限主要指用戶權限，首先要確定本系統存在的用戶，針對不同用戶，是否有權限控制，即不同的用戶，擁有的功能權限不一樣，常用的差不多就是查詢權限、編輯權限、系統管理權限等。用戶類型不多的情況下，這部分內容會相對簡單些。

（3）功能點

一些基礎的信息敲定后，后面的工作就是細化到具體的功能點上。

有的業務提交的需求文檔，會包含一部分原型圖，我們姑且可以先不管，先把功能點整理出來，并形成功能架構圖，與業務進行確認。

功能框架確定后，就可以開始編寫產品需求文檔了，如果后面有專業的交互流程，這個文檔只需要把具體的功能點講清楚即可。

不過對一些業務提出明確要求的點，我們需要透過表象看到本質，了解業務為什么要這個功能，具體要完成什么業務操作，即實際用戶在獨有的場景下完成的業務操作。

有時候業務是不懂實際的功能操作，把問題想復雜了；也有可能是把問題想簡單了，實際開發實現難度很大；還有可能就是表述有歧義，把一個簡單的功能描述復雜了。所以我們要跟業務確認這些問題點，搞清楚他真正想要的，即用戶心理模型。

產品需求文檔應該至少包含：字段表、權限、功能說明這三項。

2. 產品需求文檔

需求與業務確定后，就要著手編寫產品需求文檔了，即PRD。

PRD編寫好后，自己會先過一遍，主要是看流程是否全部走通，自己能不能形成閉環，有把握后再召開需求評審會。

我本次要說的重點就是需求評審通過后，開發表面上說看懂了，明白了，其實他心里想的還真不是自己心里想的那樣，即紙面需求與心里需求并沒有完全達成一致。

這個問題如果存在，必然會造成后期開發的成本增加和效率降低，就看這些不同點什么時候暴露出來了，越晚暴露損失越大。一個團隊中，開發肯定不止一人，若是很多人存在這個問題，后果真的不敢想象。

為了避免以上問題，我覺得需求評審通過后，需要進行需求反串講，具體的操作辦法就是：后面繼續花時間開會，讓開發來講解PRD，然后產品來聽，核對下大家心里想的是否一致；每個開發最終負責的模塊可能不一樣，可以重點講自己后面要開發的功能，然后產品去把握節奏，加入需要核對的公共部分。

有可能一開會，就能暴露出很多問題，產品也可以通過此方法掌握到團隊成員對需求的理解能力，便于以后需求評審時進行改進。

需求反串講結束后，開發才能真正開始去寫代碼，這個步驟很重要，最近負責的兩個項目，就是踩了很多類似的坑，雖然我一開始提過這個方法，但是團隊并不認可，說開發任務緊，其實后面開發不僅效率低，測試階段的返工率還挺高的，這樣其實就拉長了測試周期，在測試階段反復去修改開發理解不對的功能。

3. 功能測試管理

功能測試人員在拿到PRD后，就要開始編寫測試案例了，如果交互和UI分別負責交互驗收和UI驗收，則測試只需要負責功能驗收。

功能測試以PRD為主，交互測試以交互文檔為主，UI測試則以UI文檔為主。

下面我會從交互和UI角度來闡述如何高效進行流程配合。

二、交互

我們知道產品經理輸出產品需求文檔，即PRD，而交互設計師輸出交互文檔，很多人會問到產品經理與交互設計師之間的區別是啥，我個人覺得產品是確定需求，框定范圍，而交互則是細化確定的需求，最終輸出指導開發的文檔，即交互文檔。

多年的項目和產品經驗，讓我知道上下游之間的溝通成本相當高，很多開發不理解時都是直接問，其實會浪費很多時間，我覺得可以將給開發看的文檔寫的詳細點，將所有的可能性都考慮到位，如果后期還是有開發問你，也可以補充你沒有考慮到的細節。

武漢這邊很少有專業的交互設計師，開發拿到手的估計就是PRD，壓根沒有專業的交互文檔，下面我要講解的是拿到PRD后，輸出最終的交互文檔的流程。不管是產品+交互的組合還是就產品一個人，也不管前面是否有詳細的PRD，最終輸出給UI、開發、測試的就是這份標準的交互文檔。

下面我將詳細講解下交互文檔如何編寫：

1. 交互文檔

（1）需求分析

不管有沒有PRD，交互進入項目后，需要先進行需求分析。

1）交互模型

有需求文檔可以先詳細分析下，沒有也無所謂，我們主要是對業務進行分析，并進行需求分解。

交互模型，即用戶，場景，目標。

分析用戶時，我們常用的方法是用戶畫像，也可以簡單羅列幾種關鍵用戶，例如：普通查詢用戶、業務類用戶、管理員用戶等。

場景主要是指用戶使用產品時所處的環境，有物理上的環境，也有軟件上的環境，例如：嘈雜的辦公室使用某產品、大屏手機上使用產品、叫不到出租車然后自己也不方便開車、外面下大雨然后自己也不想做飯等。

目標主要指用戶使用產品要完成的任務或目標，例如：快速找到要去的地方并且熟悉周圍環境、找到適合自己的旅游方案、成功并快速購買到火車票等。

B端產品一般都是提高操作效率的，這部分內容應該是比較明確的；C端產品估計需要做完整的用戶研究去挖掘有效信息。

2）流程圖

我之前接觸過的項目感覺都比較復雜，一般是對一些關鍵功能，輸出單任務的流程圖，我們現階段輸出的屬于任務流程。因為不同的用戶執行某項流程時，步驟可能會不一樣，所以需要根據用戶繪制不同的流程圖，這樣可以在分析階段深挖任務流程細節，對把控整個項目有很大的好處。

3）信息架構圖

前期羅列功能點時，會輸出功能架構圖，主要是對功能點用腦圖形式羅列。針對功能架構圖，對欄目進行規劃，輸出信息架構圖，就是最終產品的導航或菜單了。

（2）頁面原型

根據以上的分析，對應信息架構圖中的欄目，用Axure畫出所有單獨的頁面，輸出頁面原型，不過需要包含一些成功或失敗的頁面等。

對所有原型的跳轉，可以專門繪制頁面流程圖，將所有頁面連接起來，這部分內容根據需要來決定。

（3）交互說明

針對原型頁面，加上詳細的說明，換言之，那些開發同學經常問你的那些問題，都可以在這里補充了，下面我從5個方面來詳細說明下：

1）操作說明

人機交互時，對機器做出的指令，PC端主要是點擊，滑過等，移動端包含點擊、滑動、長按等，例如：導航菜單，是滑過展開還是點擊展開，需要對操作進行說明。

2）反饋效果

機器對人輸入后、點擊后和滑過等的反饋，例如光標顯示，樣式變化，彈窗出現，浮層出現，跳轉頁面等。

3）頁面跳轉

詳細說明所有可點擊，可觸發的功能，點擊后的去處，以及如何來到這個頁面。

4）邊界狀態

我們設計產品時總是會忽略掉一些特殊情況，我們將此類情況統稱為邊界狀態，由用戶操作、內容展示、系統運行產生。例如：下滑刷新后的效果，數據為空時的展示，系統錯誤時的提示，斷網時的提示等。開發同學就特別喜歡問這類操作，所以交互需要盡可能多的考慮細節。

5）公共說明

開發都是根據模塊開發的，你在其他地方寫的，開發同學不一定都看到了，所以要將一些公共部分的描述，單獨列一個欄目進行說明。分到任務后，開發同學會重點關注交互文檔中的公共說明以及自己對應模塊的頁面說明。

2. 交互評審

按以上步驟編寫好交互文檔后，就需要進行交互評審，為了避免前期方向錯誤，可以在畫完原型和寫好部分交互說明后，組織交互評審，先保證大的方向正確，詳細的交互說明可以在后續繼續完善。

交互評審通過后，就可以進行下一步，即UI設計。

3. 交互價值

目前有很多人看不到交互的價值，這里的交互并不是指交互設計師崗位，武漢這邊其實很少有專業的交互設計崗，但是并不影響交互的價值，交互流程有的是被產品經理掌握，有的是被UI設計師掌握，當然一些專業的公司或者比較認可交互能力的公司也會有專業的交互設計崗。下面我將詳細談談交互對B端項目的價值。

（1）用戶體驗五要素

先說點概念性的東西，在用戶體驗五要素中，交互的價值主要是：參與并協助完成戰略層和范圍層，獨立完成結構層和框架層，推動完成表現層。

（2）對項目而言

主要針對業務方和項目人員來展開。

1）對業務方

主要是提升業務價值，提高業務人員操作效率，降低認知成本。

業務人員在提出需求后，后期會參與功能測試驗證，系統如果操作起來麻煩，會增加業務方測試時間。

業務流程如果不好理解，在后期給業務方培訓時，也會增加培訓成本，一是培訓時業務方的疑問會很多，二是上線投產后，業務人員在使用時也會因為理解不透徹造成很多誤操作，影響操作效率，最終還是會反饋到使用滿意度上。

2）對需求分析師

需求分析階段，可以快速驗證需求合理性和可實現性。

另外可以協助需求分析師，對字段表、權限、功能點等進行梳理。

3）對UI設計師

可以精確定位設計目標，提高UI產出效率。

對那些有過交互經驗的UI設計師可能會好點，但是對那些沒有原型圖無法很好完成設計產出或者對產品的原型圖無法很好理解的設計師而言，無疑可以很大的幫助提高產出效率。

另外遇到疑問時，直接跟交互進行溝通，也更容易理解。

4）對前端開發工程師

看圖識規則，業務邏輯一目了然，減少溝通成本。

很多前端其實以前做過網頁設計或者UI設計的，對看圖操作有天然的依賴性，如果可以看懂交互意圖，也不會頻繁找產品或交互去解惑。

5）對后端開發工程師

協助梳理的功能架構、字段表、功能權限等，可以助力后端工作效率。

關于這個問題，專門找多個后端聊過，后端一般前期要建表，有詳細的字段表自然可以減少很多疑慮。

做項目時，也有一些后端問過我一些權限問題，例如：不同用戶，查詢條件的權限如何控制。

所以說詳細的功能權限說明也是有用的。

6）對功能測試工程師

看圖識測試點，方便編寫測試案例，后期正式測試時，也方便驗證實際操作，減少測試遺漏，提高測試效率。

（3）對團隊而言

為公司留下規范的后期可供查閱的詳細文檔，對新進人員熟悉系統有極大幫助。

記得剛來公司時，就是每天看PRD文檔，反復看了很多遍，其實還是很不理解。

后面是直接去測試環境實際操作，并反復對照PRD來研究，才逐步掌握業務規則，這個過程現在想想，還是覺得很難過的。

三、UI

從用戶體驗五要素而言，UI主要是獨立完成表現層。

1. 設計UI組件

UI設計師拿到交互文檔后，主要是跟上游的交互進行溝通，獲取已經確認的需求和交互細節，有疑問的地方可以直接跟交互同學溝通。

交互文檔中的原型是全量的頁面，UI設計的頁面就不需要全部設計了，一般是將幾個主要頁面進行設計，確定好風格和顏色，同樣的UI設計師也需要進行UI評審。為了避免大范圍的返工，可以先確定好風格和顏色，然后再對原型中出現的各種組件統一進行設計。

這里說明下，風格和顏色可以由業務、產品、交互共同來決定，UI負責引導；而UI組件可以由交互獨立來把關。

2. UI文檔

主要的頁面和UI組件設計完畢后，UI設計師需要輸出UI文檔了。目前有些公司是直接使用一些工具，即把所有的PSD全部導入工具中，可以自動生成所有的標注圖，另外切圖也可以用一些PS插件快速完成。

至于用什么方法可以根據團隊特點來靈活安排，核心就是把UI設計的意圖傳達給前端開發人員。UI文檔大致可以包含切圖、標注、操作說明。

我以前是用的傻瓜方式，手工用axure來編寫UI文檔，標注圖是用的插件來標注的，但是還是需要手工來操作，切圖是用的PS插件完成的，這個比較方便?，F在雖然有很多方便的工具可用，我覺得操作說明這塊最好還是用axure手動寫清楚點比較好。

3. UI還原度

為什么需要寫UI文檔，也是之前踩過的很多坑，口頭上溝通的東西，最后很難追責的，反反復復去驗證還原度，效率也是很低下的。

UI文檔可以將輸出物規范化、書面化，前端開發人員可以看到全局，后期追責也方便。

我記得最初使用UI文檔時，前端人員的還原度可以高達90%以上，UI測試時只需要稍微調整下就行了，總體感覺還是挺欣慰的。

總結

以上就是從產品、交互、UI三個方面聊的關于B端項目如何高效合作的問題。希望以后有機會也可以聊聊C端產品。

作者：D.cheerful，微信號：dcf8859，8年B端交互設計經驗。

本文由 @D.cheerful 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議