編輯導(dǎo)讀：當(dāng)需要其他部門同事配合完成工作，項(xiàng)目需要跨團(tuán)隊(duì)協(xié)作時(shí)，總是會(huì)遇到重重難題。如果沒(méi)有做好溝通，可能會(huì)影響后續(xù)項(xiàng)目進(jìn)程。本文作者從自身經(jīng)驗(yàn)出發(fā)，梳理了B端項(xiàng)目中提高合作效率的幾個(gè)要點(diǎn)，希望對(duì)你有所幫助~

引言

是否遇到過(guò)開(kāi)發(fā)做出來(lái)的東西與自己心里想要的完全不一樣？

自己辛苦設(shè)計(jì)的UI，被開(kāi)發(fā)還原的體無(wú)完膚？

明明很多交互邏輯已經(jīng)寫的很清楚了，開(kāi)發(fā)還是會(huì)跑來(lái)問(wèn)自己，手頭上的活總是被打斷？

這些問(wèn)題，都可以理解為溝通出了問(wèn)題，或者說(shuō)團(tuán)隊(duì)配合效率低下。站在公司角度而言，就是開(kāi)發(fā)成本增加了，我們常說(shuō)的創(chuàng)造價(jià)值，拋開(kāi)資源的問(wèn)題，無(wú)非就是省成本或提高效率。

下面我將從三個(gè)方面來(lái)聊聊如何提高合作效率，即產(chǎn)品、交互、UI。

一、產(chǎn)品

B端項(xiàng)目一般是由業(yè)務(wù)部門向IT部門提需求，IT部門接到需求經(jīng)過(guò)分析后，解決這個(gè)需求。

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

1. 與業(yè)務(wù)溝通

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

（1）字段表

首先要羅列出項(xiàng)目需要用到的所有字段。

這些字段從哪里來(lái)，例如是從上游系統(tǒng)遷入而來(lái)，還是本系統(tǒng)新建而來(lái)，或者兩者都有，在與業(yè)務(wù)溝通時(shí)就需要把這些問(wèn)題搞得跟清楚，并與業(yè)務(wù)達(dá)成一致；同時(shí)也要搞清楚，這些字段將會(huì)去往哪里，以及在本系統(tǒng)中如何被使用。

字段屬性，包括字段名稱、字段類型、字段長(zhǎng)度、字段取值舉例等，這些細(xì)節(jié)除了要跟業(yè)務(wù)確認(rèn)，也需要和開(kāi)發(fā)進(jìn)行溝通。盡量提前準(zhǔn)備好開(kāi)發(fā)需要的細(xì)節(jié)點(diǎn)。

（2）權(quán)限

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

（3）功能點(diǎn)

一些基礎(chǔ)的信息敲定后，后面的工作就是細(xì)化到具體的功能點(diǎn)上。

有的業(yè)務(wù)提交的需求文檔，會(huì)包含一部分原型圖，我們姑且可以先不管，先把功能點(diǎn)整理出來(lái)，并形成功能架構(gòu)圖，與業(yè)務(wù)進(jìn)行確認(rèn)。

功能框架確定后，就可以開(kāi)始編寫產(chǎn)品需求文檔了，如果后面有專業(yè)的交互流程，這個(gè)文檔只需要把具體的功能點(diǎn)講清楚即可。

不過(guò)對(duì)一些業(yè)務(wù)提出明確要求的點(diǎn)，我們需要透過(guò)表象看到本質(zhì)，了解業(yè)務(wù)為什么要這個(gè)功能，具體要完成什么業(yè)務(wù)操作，即實(shí)際用戶在獨(dú)有的場(chǎng)景下完成的業(yè)務(wù)操作。

有時(shí)候業(yè)務(wù)是不懂實(shí)際的功能操作，把問(wèn)題想復(fù)雜了；也有可能是把問(wèn)題想簡(jiǎn)單了，實(shí)際開(kāi)發(fā)實(shí)現(xiàn)難度很大；還有可能就是表述有歧義，把一個(gè)簡(jiǎn)單的功能描述復(fù)雜了。所以我們要跟業(yè)務(wù)確認(rèn)這些問(wèn)題點(diǎn)，搞清楚他真正想要的，即用戶心理模型。

產(chǎn)品需求文檔應(yīng)該至少包含：字段表、權(quán)限、功能說(shuō)明這三項(xiàng)。

2. 產(chǎn)品需求文檔

需求與業(yè)務(wù)確定后，就要著手編寫產(chǎn)品需求文檔了，即PRD。

PRD編寫好后，自己會(huì)先過(guò)一遍，主要是看流程是否全部走通，自己能不能形成閉環(huán)，有把握后再召開(kāi)需求評(píng)審會(huì)。

我本次要說(shuō)的重點(diǎn)就是需求評(píng)審?fù)ㄟ^(guò)后，開(kāi)發(fā)表面上說(shuō)看懂了，明白了，其實(shí)他心里想的還真不是自己心里想的那樣，即紙面需求與心里需求并沒(méi)有完全達(dá)成一致。

這個(gè)問(wèn)題如果存在，必然會(huì)造成后期開(kāi)發(fā)的成本增加和效率降低，就看這些不同點(diǎn)什么時(shí)候暴露出來(lái)了，越晚暴露損失越大。一個(gè)團(tuán)隊(duì)中，開(kāi)發(fā)肯定不止一人，若是很多人存在這個(gè)問(wèn)題，后果真的不敢想象。

為了避免以上問(wèn)題，我覺(jué)得需求評(píng)審?fù)ㄟ^(guò)后，需要進(jìn)行需求反串講，具體的操作辦法就是：后面繼續(xù)花時(shí)間開(kāi)會(huì)，讓開(kāi)發(fā)來(lái)講解PRD，然后產(chǎn)品來(lái)聽(tīng)，核對(duì)下大家心里想的是否一致；每個(gè)開(kāi)發(fā)最終負(fù)責(zé)的模塊可能不一樣，可以重點(diǎn)講自己后面要開(kāi)發(fā)的功能，然后產(chǎn)品去把握節(jié)奏，加入需要核對(duì)的公共部分。

有可能一開(kāi)會(huì)，就能暴露出很多問(wèn)題，產(chǎn)品也可以通過(guò)此方法掌握到團(tuán)隊(duì)成員對(duì)需求的理解能力，便于以后需求評(píng)審時(shí)進(jìn)行改進(jìn)。

需求反串講結(jié)束后，開(kāi)發(fā)才能真正開(kāi)始去寫代碼，這個(gè)步驟很重要，最近負(fù)責(zé)的兩個(gè)項(xiàng)目，就是踩了很多類似的坑，雖然我一開(kāi)始提過(guò)這個(gè)方法，但是團(tuán)隊(duì)并不認(rèn)可，說(shuō)開(kāi)發(fā)任務(wù)緊，其實(shí)后面開(kāi)發(fā)不僅效率低，測(cè)試階段的返工率還挺高的，這樣其實(shí)就拉長(zhǎng)了測(cè)試周期，在測(cè)試階段反復(fù)去修改開(kāi)發(fā)理解不對(duì)的功能。

3. 功能測(cè)試管理

功能測(cè)試人員在拿到PRD后，就要開(kāi)始編寫測(cè)試案例了，如果交互和UI分別負(fù)責(zé)交互驗(yàn)收和UI驗(yàn)收，則測(cè)試只需要負(fù)責(zé)功能驗(yàn)收。

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

下面我會(huì)從交互和UI角度來(lái)闡述如何高效進(jìn)行流程配合。

二、交互

我們知道產(chǎn)品經(jīng)理輸出產(chǎn)品需求文檔，即PRD，而交互設(shè)計(jì)師輸出交互文檔，很多人會(huì)問(wèn)到產(chǎn)品經(jīng)理與交互設(shè)計(jì)師之間的區(qū)別是啥，我個(gè)人覺(jué)得產(chǎn)品是確定需求，框定范圍，而交互則是細(xì)化確定的需求，最終輸出指導(dǎo)開(kāi)發(fā)的文檔，即交互文檔。

多年的項(xiàng)目和產(chǎn)品經(jīng)驗(yàn)，讓我知道上下游之間的溝通成本相當(dāng)高，很多開(kāi)發(fā)不理解時(shí)都是直接問(wèn)，其實(shí)會(huì)浪費(fèi)很多時(shí)間，我覺(jué)得可以將給開(kāi)發(fā)看的文檔寫的詳細(xì)點(diǎn)，將所有的可能性都考慮到位，如果后期還是有開(kāi)發(fā)問(wèn)你，也可以補(bǔ)充你沒(méi)有考慮到的細(xì)節(jié)。

武漢這邊很少有專業(yè)的交互設(shè)計(jì)師，開(kāi)發(fā)拿到手的估計(jì)就是PRD，壓根沒(méi)有專業(yè)的交互文檔，下面我要講解的是拿到PRD后，輸出最終的交互文檔的流程。不管是產(chǎn)品+交互的組合還是就產(chǎn)品一個(gè)人，也不管前面是否有詳細(xì)的PRD，最終輸出給UI、開(kāi)發(fā)、測(cè)試的就是這份標(biāo)準(zhǔn)的交互文檔。

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

1. 交互文檔

（1）需求分析

不管有沒(méi)有PRD，交互進(jìn)入項(xiàng)目后，需要先進(jìn)行需求分析。

1）交互模型

有需求文檔可以先詳細(xì)分析下，沒(méi)有也無(wú)所謂，我們主要是對(duì)業(yè)務(wù)進(jìn)行分析，并進(jìn)行需求分解。

交互模型，即用戶，場(chǎng)景，目標(biāo)。

分析用戶時(shí)，我們常用的方法是用戶畫像，也可以簡(jiǎn)單羅列幾種關(guān)鍵用戶，例如：普通查詢用戶、業(yè)務(wù)類用戶、管理員用戶等。

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

目標(biāo)主要指用戶使用產(chǎn)品要完成的任務(wù)或目標(biāo)，例如：快速找到要去的地方并且熟悉周圍環(huán)境、找到適合自己的旅游方案、成功并快速購(gòu)買到火車票等。

B端產(chǎn)品一般都是提高操作效率的，這部分內(nèi)容應(yīng)該是比較明確的；C端產(chǎn)品估計(jì)需要做完整的用戶研究去挖掘有效信息。

2）流程圖

我之前接觸過(guò)的項(xiàng)目感覺(jué)都比較復(fù)雜，一般是對(duì)一些關(guān)鍵功能，輸出單任務(wù)的流程圖，我們現(xiàn)階段輸出的屬于任務(wù)流程。因?yàn)椴煌挠脩魣?zhí)行某項(xiàng)流程時(shí)，步驟可能會(huì)不一樣，所以需要根據(jù)用戶繪制不同的流程圖，這樣可以在分析階段深挖任務(wù)流程細(xì)節(jié)，對(duì)把控整個(gè)項(xiàng)目有很大的好處。

3）信息架構(gòu)圖

前期羅列功能點(diǎn)時(shí)，會(huì)輸出功能架構(gòu)圖，主要是對(duì)功能點(diǎn)用腦圖形式羅列。針對(duì)功能架構(gòu)圖，對(duì)欄目進(jìn)行規(guī)劃，輸出信息架構(gòu)圖，就是最終產(chǎn)品的導(dǎo)航或菜單了。

（2）頁(yè)面原型

根據(jù)以上的分析，對(duì)應(yīng)信息架構(gòu)圖中的欄目，用Axure畫出所有單獨(dú)的頁(yè)面，輸出頁(yè)面原型，不過(guò)需要包含一些成功或失敗的頁(yè)面等。

對(duì)所有原型的跳轉(zhuǎn)，可以專門繪制頁(yè)面流程圖，將所有頁(yè)面連接起來(lái)，這部分內(nèi)容根據(jù)需要來(lái)決定。

（3）交互說(shuō)明

針對(duì)原型頁(yè)面，加上詳細(xì)的說(shuō)明，換言之，那些開(kāi)發(fā)同學(xué)經(jīng)常問(wèn)你的那些問(wèn)題，都可以在這里補(bǔ)充了，下面我從5個(gè)方面來(lái)詳細(xì)說(shuō)明下：

1）操作說(shuō)明

人機(jī)交互時(shí)，對(duì)機(jī)器做出的指令，PC端主要是點(diǎn)擊，滑過(guò)等，移動(dòng)端包含點(diǎn)擊、滑動(dòng)、長(zhǎng)按等，例如：導(dǎo)航菜單，是滑過(guò)展開(kāi)還是點(diǎn)擊展開(kāi)，需要對(duì)操作進(jìn)行說(shuō)明。

2）反饋效果

機(jī)器對(duì)人輸入后、點(diǎn)擊后和滑過(guò)等的反饋，例如光標(biāo)顯示，樣式變化，彈窗出現(xiàn)，浮層出現(xiàn)，跳轉(zhuǎn)頁(yè)面等。

3）頁(yè)面跳轉(zhuǎn)

詳細(xì)說(shuō)明所有可點(diǎn)擊，可觸發(fā)的功能，點(diǎn)擊后的去處，以及如何來(lái)到這個(gè)頁(yè)面。

4）邊界狀態(tài)

我們?cè)O(shè)計(jì)產(chǎn)品時(shí)總是會(huì)忽略掉一些特殊情況，我們將此類情況統(tǒng)稱為邊界狀態(tài)，由用戶操作、內(nèi)容展示、系統(tǒng)運(yùn)行產(chǎn)生。例如：下滑刷新后的效果，數(shù)據(jù)為空時(shí)的展示，系統(tǒng)錯(cuò)誤時(shí)的提示，斷網(wǎng)時(shí)的提示等。開(kāi)發(fā)同學(xué)就特別喜歡問(wèn)這類操作，所以交互需要盡可能多的考慮細(xì)節(jié)。

5）公共說(shuō)明

開(kāi)發(fā)都是根據(jù)模塊開(kāi)發(fā)的，你在其他地方寫的，開(kāi)發(fā)同學(xué)不一定都看到了，所以要將一些公共部分的描述，單獨(dú)列一個(gè)欄目進(jìn)行說(shuō)明。分到任務(wù)后，開(kāi)發(fā)同學(xué)會(huì)重點(diǎn)關(guān)注交互文檔中的公共說(shuō)明以及自己對(duì)應(yīng)模塊的頁(yè)面說(shuō)明。

2. 交互評(píng)審

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

交互評(píng)審?fù)ㄟ^(guò)后，就可以進(jìn)行下一步，即UI設(shè)計(jì)。

3. 交互價(jià)值

目前有很多人看不到交互的價(jià)值，這里的交互并不是指交互設(shè)計(jì)師崗位，武漢這邊其實(shí)很少有專業(yè)的交互設(shè)計(jì)崗，但是并不影響交互的價(jià)值，交互流程有的是被產(chǎn)品經(jīng)理掌握，有的是被UI設(shè)計(jì)師掌握，當(dāng)然一些專業(yè)的公司或者比較認(rèn)可交互能力的公司也會(huì)有專業(yè)的交互設(shè)計(jì)崗。下面我將詳細(xì)談?wù)劷换?duì)B端項(xiàng)目的價(jià)值。

（1）用戶體驗(yàn)五要素

先說(shuō)點(diǎn)概念性的東西，在用戶體驗(yàn)五要素中，交互的價(jià)值主要是：參與并協(xié)助完成戰(zhàn)略層和范圍層，獨(dú)立完成結(jié)構(gòu)層和框架層，推動(dòng)完成表現(xiàn)層。

（2）對(duì)項(xiàng)目而言

主要針對(duì)業(yè)務(wù)方和項(xiàng)目人員來(lái)展開(kāi)。

1）對(duì)業(yè)務(wù)方

主要是提升業(yè)務(wù)價(jià)值，提高業(yè)務(wù)人員操作效率，降低認(rèn)知成本。

業(yè)務(wù)人員在提出需求后，后期會(huì)參與功能測(cè)試驗(yàn)證，系統(tǒng)如果操作起來(lái)麻煩，會(huì)增加業(yè)務(wù)方測(cè)試時(shí)間。

業(yè)務(wù)流程如果不好理解，在后期給業(yè)務(wù)方培訓(xùn)時(shí)，也會(huì)增加培訓(xùn)成本，一是培訓(xùn)時(shí)業(yè)務(wù)方的疑問(wèn)會(huì)很多，二是上線投產(chǎn)后，業(yè)務(wù)人員在使用時(shí)也會(huì)因?yàn)槔斫獠煌笍卦斐珊芏嗾`操作，影響操作效率，最終還是會(huì)反饋到使用滿意度上。

2）對(duì)需求分析師

需求分析階段，可以快速驗(yàn)證需求合理性和可實(shí)現(xiàn)性。

另外可以協(xié)助需求分析師，對(duì)字段表、權(quán)限、功能點(diǎn)等進(jìn)行梳理。

3）對(duì)UI設(shè)計(jì)師

可以精確定位設(shè)計(jì)目標(biāo)，提高UI產(chǎn)出效率。

對(duì)那些有過(guò)交互經(jīng)驗(yàn)的UI設(shè)計(jì)師可能會(huì)好點(diǎn)，但是對(duì)那些沒(méi)有原型圖無(wú)法很好完成設(shè)計(jì)產(chǎn)出或者對(duì)產(chǎn)品的原型圖無(wú)法很好理解的設(shè)計(jì)師而言，無(wú)疑可以很大的幫助提高產(chǎn)出效率。

另外遇到疑問(wèn)時(shí)，直接跟交互進(jìn)行溝通，也更容易理解。

4）對(duì)前端開(kāi)發(fā)工程師

看圖識(shí)規(guī)則，業(yè)務(wù)邏輯一目了然，減少溝通成本。

很多前端其實(shí)以前做過(guò)網(wǎng)頁(yè)設(shè)計(jì)或者UI設(shè)計(jì)的，對(duì)看圖操作有天然的依賴性，如果可以看懂交互意圖，也不會(huì)頻繁找產(chǎn)品或交互去解惑。

5）對(duì)后端開(kāi)發(fā)工程師

協(xié)助梳理的功能架構(gòu)、字段表、功能權(quán)限等，可以助力后端工作效率。

關(guān)于這個(gè)問(wèn)題，專門找多個(gè)后端聊過(guò)，后端一般前期要建表，有詳細(xì)的字段表自然可以減少很多疑慮。

做項(xiàng)目時(shí)，也有一些后端問(wèn)過(guò)我一些權(quán)限問(wèn)題，例如：不同用戶，查詢條件的權(quán)限如何控制。

所以說(shuō)詳細(xì)的功能權(quán)限說(shuō)明也是有用的。

6）對(duì)功能測(cè)試工程師

看圖識(shí)測(cè)試點(diǎn)，方便編寫測(cè)試案例，后期正式測(cè)試時(shí)，也方便驗(yàn)證實(shí)際操作，減少測(cè)試遺漏，提高測(cè)試效率。

（3）對(duì)團(tuán)隊(duì)而言

為公司留下規(guī)范的后期可供查閱的詳細(xì)文檔，對(duì)新進(jìn)人員熟悉系統(tǒng)有極大幫助。

記得剛來(lái)公司時(shí)，就是每天看PRD文檔，反復(fù)看了很多遍，其實(shí)還是很不理解。

后面是直接去測(cè)試環(huán)境實(shí)際操作，并反復(fù)對(duì)照PRD來(lái)研究，才逐步掌握業(yè)務(wù)規(guī)則，這個(gè)過(guò)程現(xiàn)在想想，還是覺(jué)得很難過(guò)的。

三、UI

從用戶體驗(yàn)五要素而言，UI主要是獨(dú)立完成表現(xiàn)層。

1. 設(shè)計(jì)UI組件

UI設(shè)計(jì)師拿到交互文檔后，主要是跟上游的交互進(jìn)行溝通，獲取已經(jīng)確認(rèn)的需求和交互細(xì)節(jié)，有疑問(wèn)的地方可以直接跟交互同學(xué)溝通。

交互文檔中的原型是全量的頁(yè)面，UI設(shè)計(jì)的頁(yè)面就不需要全部設(shè)計(jì)了，一般是將幾個(gè)主要頁(yè)面進(jìn)行設(shè)計(jì)，確定好風(fēng)格和顏色，同樣的UI設(shè)計(jì)師也需要進(jìn)行UI評(píng)審。為了避免大范圍的返工，可以先確定好風(fēng)格和顏色，然后再對(duì)原型中出現(xiàn)的各種組件統(tǒng)一進(jìn)行設(shè)計(jì)。

這里說(shuō)明下，風(fēng)格和顏色可以由業(yè)務(wù)、產(chǎn)品、交互共同來(lái)決定，UI負(fù)責(zé)引導(dǎo)；而UI組件可以由交互獨(dú)立來(lái)把關(guān)。

2. UI文檔

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

至于用什么方法可以根據(jù)團(tuán)隊(duì)特點(diǎn)來(lái)靈活安排，核心就是把UI設(shè)計(jì)的意圖傳達(dá)給前端開(kāi)發(fā)人員。UI文檔大致可以包含切圖、標(biāo)注、操作說(shuō)明。

我以前是用的傻瓜方式，手工用axure來(lái)編寫UI文檔，標(biāo)注圖是用的插件來(lái)標(biāo)注的，但是還是需要手工來(lái)操作，切圖是用的PS插件完成的，這個(gè)比較方便。現(xiàn)在雖然有很多方便的工具可用，我覺(jué)得操作說(shuō)明這塊最好還是用axure手動(dòng)寫清楚點(diǎn)比較好。

3. UI還原度

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

UI文檔可以將輸出物規(guī)范化、書面化，前端開(kāi)發(fā)人員可以看到全局，后期追責(zé)也方便。

我記得最初使用UI文檔時(shí)，前端人員的還原度可以高達(dá)90%以上，UI測(cè)試時(shí)只需要稍微調(diào)整下就行了，總體感覺(jué)還是挺欣慰的。

總結(jié)

以上就是從產(chǎn)品、交互、UI三個(gè)方面聊的關(guān)于B端項(xiàng)目如何高效合作的問(wèn)題。希望以后有機(jī)會(huì)也可以聊聊C端產(chǎn)品。

作者：D.cheerful，微信號(hào)：dcf8859，8年B端交互設(shè)計(jì)經(jīng)驗(yàn)。

本文由 @D.cheerful 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來(lái)自Unsplash，基于CC0協(xié)議