二. 為什么要寫(xiě)？

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

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

下圖是一個(gè)產(chǎn)品開(kāi)發(fā)項(xiàng)目基本的流程。

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

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

開(kāi)發(fā)部門(mén)的需求分析師：

• 每次變動(dòng)都很痛苦，設(shè)計(jì)變了之后，我就要跟著改UC，改截圖，有時(shí)候UED改了還忘了通知我們，導(dǎo)致UC有問(wèn)題……
• 頁(yè)面交互的需求容易漏掉，因?yàn)閁C里面不可能寫(xiě)太多交互方面的東西。
• 希望UED能夠在提交HTML DEMO給RA時(shí)，能同時(shí)給出一份頁(yè)面元素描述文檔，需要介紹html demo中的文案、鏈接以及相關(guān)的圖片尺寸或顯示字符個(gè)數(shù)?，F(xiàn)在RA在這方面花費(fèi)的時(shí)間比較多，經(jīng)常要和UED去確認(rèn)這些內(nèi)容。

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

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

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

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

• DRD做為參考手冊(cè)，一定程度上避免不吻合的問(wèn)題發(fā)生。
• 即使有問(wèn)題發(fā)生，也可以作為界面驗(yàn)收時(shí)的Checklist。將“我對(duì)A說(shuō)，我對(duì)B說(shuō)，A對(duì)B說(shuō)”，轉(zhuǎn)變?yōu)椤癆和B共同參考同一份文檔”，減少溝通成本及信息不對(duì)稱(chēng)。
• 全程影響用戶(hù)體驗(yàn)（一直到測(cè)試，都需要參照設(shè)計(jì)文檔）。

可是以下問(wèn)題都可以通過(guò)一份DRD來(lái)解決嗎？

三. 寫(xiě)什么不寫(xiě)什么？

要明確文檔的定位，從寫(xiě)什么與不寫(xiě)什么開(kāi)始，劃清DRD以及FRD的邊界。

不寫(xiě)視覺(jué)規(guī)范規(guī)格標(biāo)注

這些說(shuō)明與功能實(shí)現(xiàn)沒(méi)有太大關(guān)系，主要是為前端做HTML的時(shí)候參考的。一般視覺(jué)設(shè)計(jì)師會(huì)在PSD里標(biāo)注清楚。如圖：

不寫(xiě)功能實(shí)現(xiàn)邏輯。

如下圖所示，作為DRD，你有必要傳達(dá)清楚Browse by category區(qū)域的設(shè)計(jì)：鏈接的可點(diǎn)擊性，鏈接的指向，字符與條目的數(shù)量限制等，但是具體二級(jí)類(lèi)目排列是按產(chǎn)品數(shù)目排還是按字母排，還是人工運(yùn)營(yíng)，是FRD要解決的任務(wù)。

那么文檔寫(xiě)什么呢？

交互細(xì)節(jié)說(shuō)明

相信我，我很不愿意寫(xiě)這些東西。我喜歡在會(huì)議室向各位涉眾演示我的線(xiàn)框圖，我會(huì)研究用axure制作各種動(dòng)態(tài)效果，達(dá)到它足夠逼真呈現(xiàn)各種聯(lián)動(dòng)——比如當(dāng)你選擇了下拉菜單中的某項(xiàng)時(shí)，頁(yè)面上其他區(qū)域也發(fā)生相應(yīng)的變化。可是，Axure不是全能的。即使能夠表達(dá)出來(lái)，線(xiàn)框圖交付出去，也不能確保其他人都能夠一一進(jìn)行點(diǎn)擊嘗試。所以只能在會(huì)議室反復(fù)講解，在事后再三檢查并敦促修改。

但是當(dāng)我嘗試用下圖對(duì)這塊小小且復(fù)雜的區(qū)域進(jìn)行詳細(xì)說(shuō)明后，事情變得簡(jiǎn)單多了。所以我用節(jié)省的時(shí)間去寫(xiě)了這份PPT.

五. 如何寫(xiě)DRD?

選擇最有效率的工具。

我的經(jīng)驗(yàn)是這個(gè)工具最好能夠提供清晰的目錄導(dǎo)航結(jié)構(gòu)，而且易標(biāo)注。word確實(shí)是個(gè)寫(xiě)文檔的好工具，不管你信不信，反正我是信了。