離開交互圈已經(jīng)有段時間了。但由于博客還在，還是能夠偶爾收到一些郵件，上周有位同學(xué)問我：我在求職，我看到很多招聘說明上需要交互設(shè)計師編寫界面交互設(shè)計文檔，請問界面交互設(shè)計文檔是什么文檔？怎么編寫呢？

這讓我想起來2009年自己在項目里也大力推行過交互說明文檔（在下文中，簡稱為DRD），格式倒沒什么限制，交互設(shè)計師自己寫到界面上也行，單獨文檔成文也行，總之就是讓交互設(shè)計師能夠?qū)⒔缑娉休d不了的信息通過文檔沉淀下來，降低項目里的溝通成本和風(fēng)險。今天整理電腦，翻出以前的PPT，分享之。

這將涉及到幾個問題：

一、什么是交互說明文檔（DRD）？

所謂DRD即是用來承載交互說明，并交付給前端、測試以及開發(fā)工程師參考的文檔。

在項目中，交互設(shè)計師的主要產(chǎn)出物可能依次是：site map，page flow，wireframes。有的大型項目前期，交互設(shè)計師有可能還會產(chǎn)出用戶需求分析文檔（與PD產(chǎn)出的市場需求文檔不一樣的是，URD更多側(cè)重于對目標(biāo)用戶的需求分析）。

DRD則很少有人專門撰寫。如果需要對交互設(shè)計進(jìn)行說明，聰明的交互設(shè)計師往往會直接標(biāo)注在線框圖里，或者在項目中不斷和前端工程師和開發(fā)工程師口口相傳，反復(fù)驗收，不斷迭代修改來確保所有的交互設(shè)計意圖最終得以呈現(xiàn)。

二、 為什么要寫？

DRD非項目必需環(huán)節(jié)，一般情況下也不會為交互設(shè)計師專門留出相應(yīng)的時間預(yù)估。沒有這份文檔，項目也會繼續(xù)，但是可能項目會為此承擔(dān)不必要的溝通成本和時間成本。嚴(yán)重的話，項目的質(zhì)量也會受到影響。所以寫與不寫，交互設(shè)計師需要做把握，時間被統(tǒng)一包含在“線框圖”環(huán)節(jié)內(nèi)——如果你要寫，請在評估時預(yù)留1-2天的時間。

那么，結(jié)合我過去的經(jīng)歷，談一下此文檔的必要性。

下圖是一個產(chǎn)品開發(fā)項目基本的流程。

敏捷開發(fā)意味著很多不同角色的流程需要并行操作。如果等到產(chǎn)品經(jīng)理的FRD已經(jīng)全部敲定，交互設(shè)計師再開始去畫線框圖，固然會減少溝通成本和返工風(fēng)險，但是同時意味著交互設(shè)計師的很多想法不被采納。如果產(chǎn)品經(jīng)理再強(qiáng)一些，他甚至?xí)�在FRD里連原始的DEMO也一并繪制出來了，功能性的需求和界面交互的需求有時無法區(qū)分太清楚——比如他會在FRD里直接要求每頁條目40條，超過40條即分頁。而交互設(shè)計師可能會認(rèn)為像蘑菇街那樣不斷裝載出足夠長的頁面會更親和……所以，我們希望是和產(chǎn)品經(jīng)理同時開始工作，在術(shù)業(yè)有專攻的時候相互補(bǔ)充。

同樣，開發(fā)工程師也希望及早介入需求，在FRD并未確認(rèn)的時候就了解需求，進(jìn)而將商業(yè)需求和功能需求轉(zhuǎn)化為開發(fā)工程師看得明白的開發(fā)需求清單（這個清單，大部分叫做UC，即USE CASE），當(dāng)這份清單由工程師需求分析師——在過去，這個角色被叫簡稱為RA，但是目前已經(jīng)取消此專門的職位，而是由開發(fā)工程師代表擔(dān)綱此環(huán)節(jié)工作，為了便于描述，在此文里，我仍然將做這件事情的人稱為RA——交付給具體的執(zhí)行工程師后，執(zhí)行工程師基本上可以當(dāng)作一條條的checklist開始高效工作，而不必再思考商業(yè)邏輯和需求。同樣，測試工程師也需要編寫具體的文檔去指導(dǎo)很多測試人員在開發(fā)后高效測試，這也是基于UC和FRD去撰寫的。

所以，開發(fā)需求分析是個很重要的環(huán)節(jié)。那RA是如何來完成需求分析工作的呢？

1、前期介入，對PD進(jìn)行開發(fā)需求評估支持；

2、參與每次的FRD評審會；

3、詳細(xì)審閱FRD文檔并不斷與PD確認(rèn)。

對于做這件事情的人來說，足夠詳盡的FRD是非常重要的。所以一份FRD雖然是PD產(chǎn)出，但是很多實施細(xì)節(jié)則是由開發(fā)工程師不斷溝通評估并確認(rèn)下來的。而設(shè)計需求的傳遞，卻存在很多問題。除了線框圖，沒有“詳盡的說明性的文檔”告訴他們。比如：

一方面，交互設(shè)計師對產(chǎn)品經(jīng)理說：這塊由我們來考慮，你的文檔不必包含設(shè)計上的說明，這隨時會調(diào)整的。

另一方面，線框圖的評審有時會讓RA參與，有時卻沒有叫他們。即使叫上了他們，他們也會發(fā)現(xiàn)交互設(shè)計的需求變化要比FRD變化快。另外，他們會認(rèn)為UC不必寫太多關(guān)于交互設(shè)計的需求。

在某個大型項目結(jié)束后，作為交互設(shè)計師，我進(jìn)行了一些調(diào)研，聽聽這相關(guān)人員是怎么表述問題的：

開發(fā)部門的需求分析師：

1、每次變動都很痛苦，設(shè)計變了之后，我就要跟著改UC，改截圖，有時候UED改了還忘了通知我們，導(dǎo)致UC有問題……

2、頁面交互的需求容易漏掉，因為UC里面不可能寫太多交互方面的東西。

3、希望UED能夠在提交HTML DEMO給RA時，能同時給出一份頁面元素描述文檔，需要介紹html demo中的文案、鏈接以及相關(guān)的圖片尺寸或顯示字符個數(shù)�，F(xiàn)在RA在這方面花費的時間比較多，經(jīng)常要和UED去確認(rèn)這些內(nèi)容。

產(chǎn)品經(jīng)理：

前期RA和PD溝通過程中，有很多交互點點不能夠明確，比如“默認(rèn)顯示多少屬性值”，“標(biāo)題顯示多少字符”等。在以往的需求和項目中，對待這些問題我們都是想到一點補(bǔ)一點的到FRD文檔或者郵件中去。既增加了溝通成本又會存在遺漏細(xì)節(jié)的風(fēng)險。PD為了可控性的需求，往往會“越俎代庖”，直接在FRD注明這種需求（對于交互設(shè)計師來講，卻又導(dǎo)致沒有發(fā)揮余地）

走訪了一些交互設(shè)計師后，他們也存在如何清晰無遺漏將交互設(shè)計需求傳遞下去的困惑：

交互認(rèn)為很平常的設(shè)計需求，如果不表達(dá)出來，還是容易被前端和開發(fā)忽略掉。我經(jīng)歷的一個項目，前端從頭到尾更換了三個人，每次我都要重復(fù)去講解下設(shè)計需求，講得口干舌燥。而且做好后，還需要去驗收。

DRD做為參考手冊，一定程度上避免不吻合的問題發(fā)生。

即使有問題發(fā)生，也可以作為界面驗收時的Checklist。將“我對A說，我對B說，A對B說”，轉(zhuǎn)變?yōu)?ldquo;A和B共同參考同一份文檔”，減少溝通成本及信息不對稱。

全程影響用戶體驗（一直到測試，都需要參照設(shè)計文檔）。

可是以下問題都可以通過一份DRD來解決嗎？

標(biāo)簽： 用戶體驗 交互設(shè)計文檔 界面交互設(shè)計文檔 

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。