交互設(shè)計(jì)文檔..docx

1、一. 什么是交互說(shuō)明文檔（DRD ）？所謂 DRD 即是用來(lái)承載交互說(shuō)明，并交付給前端、測(cè)試以及開(kāi)發(fā)工程師參考的文檔。在項(xiàng)目中，交互設(shè)計(jì)師的主要產(chǎn)出物可能依次是：site map ，page flow，wireframes。有的大型項(xiàng)目前期，交互設(shè)計(jì)師有可能還會(huì)產(chǎn)出用戶(hù)需求分析文檔（與 PD 產(chǎn)出的市場(chǎng)需求文檔不一樣的是，URD 更多側(cè)重于對(duì)目標(biāo)用戶(hù)的需求分析）。DRD 則很少有人專(zhuān)門(mén)撰寫(xiě)。 如果需要對(duì)交互設(shè)計(jì)進(jìn)行說(shuō)明，聰明的交互設(shè)計(jì)師往往會(huì)直接標(biāo)注在線框圖里，或者在項(xiàng)目中不斷和前端工程師和開(kāi)發(fā)工程師口口相傳， 反復(fù)驗(yàn)收，不斷迭代修改來(lái)確保所有的交互設(shè)計(jì)意圖最終得以呈現(xiàn)。二. 為什么要寫(xiě)？DR

2、D 非項(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)重的話，項(xiàng)目的質(zhì)量也會(huì)受到影響。所以寫(xiě)與不寫(xiě)，交互設(shè)計(jì)師需要做把握，時(shí)間被統(tǒng)一包含在“線框圖”環(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à)線框圖，固然會(huì)減少溝通成本和返工風(fēng)險(xiǎn)， 但是同時(shí)意味著交互設(shè)計(jì)師的很多想法不被采納。 如果產(chǎn)品經(jīng)理再?gòu)?qiáng)一些， 他甚至

3、會(huì)在 FRD 里連原始的 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ā)工程師代

4、表?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ā)需求分析是個(gè)很重要的環(huán)節(jié)。那RA 是如何來(lái)完成需求分析工作的呢？o前期介入，對(duì)PD 進(jìn)行開(kāi)發(fā)需求評(píng)估支持；o如何寫(xiě)一份交互說(shuō)明文檔參與每次的FRD 評(píng)審會(huì)；o詳細(xì)審閱 FRD 文檔并不斷與PD 確認(rèn)。對(duì)于做這件事情的人來(lái)說(shuō)，足夠詳盡的FRD 是非常重要的。所以一份FRD 雖然是 PD 產(chǎn)

5、出，但是很多實(shí)施細(xì)節(jié)則是由開(kāi)發(fā)工程師不斷溝通評(píng)估并確認(rèn)下來(lái)的。而設(shè)計(jì)需求的傳遞，卻存在很多問(wèn)題。除了線框圖，沒(méi)有“詳盡的說(shuō)明性的文檔”告訴他們。比如：一方面，交互設(shè)計(jì)師對(duì)產(chǎn)品經(jīng)理說(shuō)：這塊由我們來(lái)考慮，你的文檔不必包含設(shè)計(jì)上的說(shuō)明，這隨時(shí)會(huì)調(diào)整的。另一方面，線框圖的評(píng)審有時(shí)會(huì)讓RA 參與，有時(shí)卻沒(méi)有叫他們。即使叫上了他們，他們也會(huì)發(fā)現(xiàn)交互設(shè)計(jì)的需求變化要比FRD 變化快。另外，他們會(huì)認(rèn)為 UC 不必寫(xiě)太多關(guān)于交互設(shè)計(jì)的需求。在某個(gè)大型項(xiàng)目結(jié)束后，作為交互設(shè)計(jì)師，我進(jìn)行了一些調(diào)研，聽(tīng)聽(tīng)這相關(guān)人員是怎么表述問(wèn)題的：開(kāi)發(fā)部門(mén)的需求分析師：o每次變動(dòng)都很痛苦，設(shè)計(jì)變了之后，我就要跟著改UC ，改截圖，有

6、時(shí)候UED改了還忘了通知我們，導(dǎo)致UC 有問(wèn)題 o頁(yè)面交互的需求容易漏掉，因?yàn)閁C 里面不可能寫(xiě)太多交互方面的東西。o希望 UED 能夠在提交HTMLDEMO 給 RA 時(shí)，能同時(shí)給出一份頁(yè)面元素描述文檔，需要介紹htmldemo中的文案、鏈接以及相關(guān)的圖片尺寸或顯示字符個(gè)數(shù)?，F(xiàn)在 RA 在這方面花費(fèi)的時(shí)間比較多，經(jīng)常要和UED 去確認(rèn)這些內(nèi)容。產(chǎn)品經(jīng)理：o 前期 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)

7、。 PD 為了可控性的需求，往往會(huì)“越俎代庖”，直接在 FRD 注明這種需求（對(duì)于交互設(shè)計(jì)師來(lái)講，卻又導(dǎo)致沒(méi)有發(fā)揮余地）走訪了一些交互設(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)收。o DRD 做為參考手冊(cè)，一定程度上避免不吻合的問(wèn)題發(fā)生。o即使有問(wèn)題發(fā)生，也可以作為界面驗(yàn)收時(shí)的Checklist 。將“我對(duì)A 說(shuō)，我對(duì) B說(shuō)， A 對(duì) B 說(shuō)”，轉(zhuǎn)變?yōu)椤?A 和 B 共同參考同一份文檔”，減少

8、溝通成本及信息不對(duì)稱(chēng)。o 全程影響用戶(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)，是解決的任務(wù)。FRD 要那

9、么文檔寫(xiě)什么呢？舉例子說(shuō)明下：字符限制提高空間利用率，有時(shí)網(wǎng)頁(yè)上的動(dòng)態(tài)文字需要從數(shù)據(jù)庫(kù)里提取部分然后截?cái)嗵幚怼１热缦聢D中的標(biāo)題和描述。你的DRD 需要傳達(dá)清楚： 1，是否要做限制？ 2 ，如果做限制的話，多少字出現(xiàn)截?cái)?？截?cái)嗪笫秋@示為省略號(hào)還是不顯示？這個(gè)漢語(yǔ)設(shè)計(jì)相對(duì)簡(jiǎn)單，如果英文單詞的話，因?yàn)槭前醋址?，每個(gè)字符的寬度不一致， 需要預(yù)估，另外還需要注明是整詞截?cái)噙€是詞間截?cái)唷ｆ溄泳唧w化很多網(wǎng)站都有對(duì)搜索結(jié)果的篩選設(shè)計(jì)（ refine search ），比如 aliexpress搜索結(jié)果頁(yè)左側(cè)。這塊區(qū)域的交互事件是非常復(fù)雜的。o 類(lèi)目和屬性的不同如何處理o 屬性以及每條屬性顯示的屬性值的條目是否

10、有顯示上的限制？o 選中后，被選中的屬性值是停留在原地，方便用戶(hù)記憶，還是放到統(tǒng)一的位置，方便用戶(hù)統(tǒng)一查看？其他未被選中的屬性值是否消失？要確保這些你設(shè)想中的復(fù)雜的交互邏輯能夠被理解被呈現(xiàn)，除了一頁(yè)頁(yè)的線框圖，你有必要再三讓前端工程師和開(kāi)發(fā)工程師了解并達(dá)成認(rèn)知一致。所以你需要將頁(yè)面上的關(guān)鍵鏈接事件標(biāo)識(shí)清楚。它們有的指向無(wú)需刷新頁(yè)面的交互，有的指向你安排的并非PD 安排的某個(gè)中間頁(yè)面（ page flow是交互設(shè)計(jì)師的職責(zé)）交互細(xì)節(jié)說(shuō)明相信我，我很不愿意寫(xiě)這些東西。我喜歡在會(huì)議室向各位涉眾演示我的線框圖，我會(huì)研究用 axure 制作各種動(dòng)態(tài)效果， 達(dá)到它足夠逼真呈現(xiàn)各種聯(lián)動(dòng)比如當(dāng)你選擇了下拉菜單

11、中的某項(xiàng)時(shí)，頁(yè)面上其他區(qū)域也發(fā)生相應(yīng)的變化?？墒?， Axure 不是全能的。即使能夠表達(dá)出來(lái)，線框圖交付出去，也不能確保其他人都能夠一一進(jìn)行點(diǎn)擊嘗試。所以只能在會(huì)議室反復(fù)講解，在事后再三檢查并敦促修改。但是當(dāng)我嘗試用下圖對(duì)這塊小小且復(fù)雜的區(qū)域進(jìn)行詳細(xì)說(shuō)明后，事情變得簡(jiǎn)單多了。所以我用節(jié)省的時(shí)間去寫(xiě)了這份PPT.又如，你可以在這里說(shuō)明任何你想要的效果。你的受眾也只需要用10分鐘時(shí)間閱讀完畢，標(biāo)注出與他工作相關(guān)的重點(diǎn)，存檔并在遇到問(wèn)題，找不到你人時(shí)隨時(shí)參考。表單的校驗(yàn)這也是一項(xiàng)不怎么有創(chuàng)意的事情，但是你若不事先想清楚，在項(xiàng)目過(guò)程中有點(diǎn)麻煩。 寫(xiě)文檔看似枯燥乏味， 反過(guò)來(lái)想也是讓你自己再好好思量審核

12、設(shè)計(jì)本身的關(guān)鍵步驟。我曾經(jīng)自以為完善的交互設(shè)計(jì)方案就是在寫(xiě)DRD的時(shí)候發(fā)現(xiàn)存在重大的紕漏，然后及時(shí)優(yōu)化的。瀏覽器的兼容性要求你們的產(chǎn)品兼容所有瀏覽器簡(jiǎn)直是夢(mèng)想，但是有時(shí)出于效率的要求，我們必須戰(zhàn)略性放棄某些瀏覽器，比如IE6.:D 。 這個(gè)決定誰(shuí)來(lái)做？是前端工程師還是產(chǎn)品經(jīng)理？還是你交互設(shè)計(jì)師？我認(rèn)為決定權(quán)在交互設(shè)計(jì)師這里，但是他必須和產(chǎn)品經(jīng)理達(dá)成一致，并與前端確認(rèn)。你要求兼容的瀏覽器越多，標(biāo)準(zhǔn)越高，前端的工作量就會(huì)越大，測(cè)試的工作量甚至也會(huì)翻倍。四. 什么時(shí)間交付呢？Heidi 的建議：盡可能與你的線框圖同時(shí)交付，如果你先交付出線框圖，在撰寫(xiě) DRD 的時(shí)候，極大可能會(huì)發(fā)現(xiàn)問(wèn)題或產(chǎn)生優(yōu)化的想

13、法。但是往往寫(xiě)DRD 至少需要 1-2 天的時(shí)間，你不可能讓所有下游等著你的工作。所以：o 你可以交付出線框圖供視覺(jué)先開(kāi)始。視覺(jué)設(shè)計(jì)往往會(huì)先做風(fēng)格定位設(shè)計(jì)，這和交互細(xì)節(jié)關(guān)系不大。o先交付出已經(jīng)確定的線框圖給前端，然后在1-2 天 DRD 后，若有改動(dòng)，與前端當(dāng)面一一確認(rèn)并一起交付。五 . 如何寫(xiě) DRD?選擇最有效率的工具。我的經(jīng)驗(yàn)是這個(gè)工具最好能夠提供清晰的目錄導(dǎo)航結(jié)構(gòu)，而且易標(biāo)注。word確實(shí)是個(gè)寫(xiě)文檔的好工具，不管你信不信，反正我是信了。建立固定的目錄結(jié)構(gòu)下圖僅供參考。具體里面的細(xì)節(jié)，就不一一羅嗦了。六. 重要的原則準(zhǔn)備寫(xiě) DRD 的朋友，請(qǐng)認(rèn)識(shí)清楚此文檔真正要解決的問(wèn)題是什么？如果是解

14、決溝通偏差、需求遺漏、溝通成本高的問(wèn)題，你在項(xiàng)目里沒(méi)有出現(xiàn)過(guò)這種問(wèn)題，各合作方也反饋良好，那么這個(gè)文檔就無(wú)需寫(xiě)。如果是解決對(duì)設(shè)計(jì)需求進(jìn)行存檔，便于后續(xù)人員改版時(shí)查看的問(wèn)題，則又是另外一回事（經(jīng)驗(yàn)證明，過(guò)去的DRD 確實(shí)能夠在改版時(shí)起到一定的幫助，在我離開(kāi)原項(xiàng)目很久后，新的設(shè)計(jì)師還找我要過(guò)相應(yīng)項(xiàng)目的文檔，了解過(guò)去的設(shè)計(jì)邏輯）。o不是為了寫(xiě)文檔而寫(xiě)文檔（而是為了解決問(wèn)題）o適合于項(xiàng)目、合作方（大項(xiàng)目有大文檔，小需求有靈巧的解決方案）o工具不是問(wèn)題 （易傳播，易標(biāo)注，成目錄即可）o 模版不是問(wèn)題，大家看明白就可o完美的文檔無(wú)法取代面對(duì)面的溝通（評(píng)審會(huì)和討論不會(huì)因?yàn)槲臋n而減少）o 需要在實(shí)踐中不斷改進(jìn)七 . 誰(shuí)來(lái)寫(xiě)？我建議由交互設(shè)計(jì)師發(fā)起，但是由前端工程師進(jìn)行修訂，再傳遞給開(kāi)發(fā)工程師。有很多需求，交互設(shè)計(jì)師只要求實(shí)現(xiàn)即可，但是他可能并不在乎是前端實(shí)現(xiàn)還是后端實(shí)現(xiàn)。前端工程師對(duì)DRD 進(jìn)行把關(guān)和修訂，能夠?qū)⒃O(shè)計(jì)語(yǔ)言轉(zhuǎn)化為工程師能夠看懂的語(yǔ)言，且能夠劃定與開(kāi)發(fā)的實(shí)現(xiàn)邊界。八. 與其他產(chǎn)出物的關(guān)系項(xiàng)目中交付物對(duì)應(yīng)不同的使用角色，如下圖所示：但是有個(gè)問(wèn)題是，雖然DRD 的目標(biāo)受眾有開(kāi)發(fā)和測(cè)試，但是讓開(kāi)發(fā)工程師同時(shí)參考那么多文檔是不現(xiàn)實(shí)的，所以仍然是開(kāi)發(fā)工程師的接口人，也就是事實(shí)上的RA 需求分析作為需求整合傳遞的角色，將商業(yè)需求和設(shè)計(jì)需求，傳達(dá)給具體的執(zhí)行開(kāi)發(fā)工