2013-2-4 藍(lán)藍(lán)設(shè)計(jì)的小編
轉(zhuǎn)載藍(lán)藍(lán)設(shè)計(jì)( www.cqzjtgb.com )是一家專注而深入的設(shè)計(jì)機(jī)構(gòu) ，為期望卓越的國(guó)內(nèi)外企業(yè)提供有效的 BS界面設(shè)計(jì) 、 cs界面設(shè)計(jì) 、 ipad界面設(shè)計(jì) 、 包裝設(shè)計(jì) 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計(jì)、 網(wǎng)站建設(shè) 、平面設(shè)計(jì)服務(wù)
來源： http://heidixie.blog.sohu.com/207036464.html
如果您想訂閱本博客內(nèi)容，每天自動(dòng)發(fā)到您的郵箱中， 請(qǐng)點(diǎn)這里
離開交互圈已經(jīng)有段時(shí)間了。但由于博客還在，還是能夠偶爾收到一些郵件，上周有位同學(xué)問我：我在求職，我看到很多招聘說明上需要交互設(shè)計(jì)師編寫界面交互設(shè)計(jì)文檔 ，請(qǐng)問界面交互設(shè)計(jì)文檔是什么文檔？怎么編寫呢
這些說明與功能實(shí)現(xiàn)沒有太大關(guān)系，主要是為前端做HTML的時(shí)候參考的。一般視覺設(shè)計(jì)師會(huì)在PSD里標(biāo)注清楚。如圖：
2. 不寫功能實(shí)現(xiàn)邏輯。如下圖所示，作為DRD，你有必要傳達(dá)清楚Browse by category區(qū)域的設(shè)計(jì)：鏈接的可點(diǎn)擊性，鏈接的指向，字符與條目的數(shù)量限制等，但是具體二級(jí)類目排列是按產(chǎn)品數(shù)目排還是按字母排，還是人工運(yùn)營(yíng)，是FRD要解決的任務(wù)。
提高空間利用率，有時(shí)網(wǎng)頁(yè)上的動(dòng)態(tài)文字需要從數(shù)據(jù)庫(kù)里提取部分然后截?cái)嗵幚?。比如下圖中的標(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)唷?/div>
2. 鏈接具體化
很多網(wǎng)站都有對(duì)搜索結(jié)果的篩選設(shè)計(jì)（refine search），比如aliexpress搜索結(jié)果頁(yè)左側(cè)。這塊區(qū)域的交互事件是非常復(fù)雜的。
- 類目和屬性的不同如何處理
- 屬性以及每條屬性顯示的屬性值的條目是否有顯示上的限制？
- 選中后，被選中的屬性值是停留在原地，方便用戶記憶，還是放到統(tǒng)一的位置，方便用戶統(tǒng)一查看？其他未被選中的屬性值是否消失？
要確保這些你設(shè)想中的復(fù)雜的交互邏輯能夠被理解被呈現(xiàn)，除了一頁(yè)頁(yè)的線框圖，你有必要再三讓前端工程師和開發(fā)工程師了解并達(dá)成認(rèn)知一致。所以你需要將頁(yè)面上的關(guān)鍵鏈接事件標(biāo)識(shí)清楚。它們有的指向無(wú)需刷新頁(yè)面的交互，有的指向你安排的并非PD安排的某個(gè)中間頁(yè)面（page flow是交互設(shè)計(jì)師的職責(zé)）
3. 交互細(xì)節(jié)說明
相信我，我很不愿意寫這些東西。我喜歡在會(huì)議室向各位涉眾演示我的線框圖，我會(huì)研究用axure制作各種動(dòng)態(tài)效果，達(dá)到它足夠逼真呈現(xiàn)各種聯(lián)動(dòng)——比如當(dāng)你選擇了下拉菜單中的某項(xiàng)時(shí)，頁(yè)面上其他區(qū)域也發(fā)生相應(yīng)的變化?？墒牵珹xure不是全能的。即使能夠表達(dá)出來，線框圖交付出去，也不能確保其他人都能夠一一進(jìn)行點(diǎn)擊嘗試。所以只能在會(huì)議室反復(fù)講解，在事后再三檢查并敦促修改。
但是當(dāng)我嘗試用下圖對(duì)這塊小小且復(fù)雜的區(qū)域進(jìn)行詳細(xì)說明后，事情變得簡(jiǎn)單多了。所以我用節(jié)省的時(shí)間去寫了這份PPT.
又如，你可以在這里說明任何你想要的效果。你的受眾也只需要用10分鐘時(shí)間閱讀完畢，標(biāo)注出與他工作相關(guān)的重點(diǎn)，存檔并在遇到問題，找不到你人時(shí)隨時(shí)參考。5. 表單的校驗(yàn)這也是一項(xiàng)不怎么有創(chuàng)意的事情，但是你若不事先想清楚，在項(xiàng)目過程中有點(diǎn)麻煩。寫文檔看似枯燥乏味，反過來想也是讓你自己再好好思量審核設(shè)計(jì)本身的關(guān)鍵步驟。我曾經(jīng)自以為完善的交互設(shè)計(jì)方案就是在寫DRD的時(shí)候發(fā)現(xiàn)存在重大的紕漏，然后及時(shí)優(yōu)化的。6. 瀏覽器的兼容性要求你們的產(chǎn)品兼容所有瀏覽器簡(jiǎn)直是夢(mèng)想，但是有時(shí)出于效率的要求，我們必須戰(zhàn)略性放棄某些瀏覽器，比如IE6.:D 。 這個(gè)決定誰(shuí)來做？是前端工程師還是產(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í)交付，如果你先交付出線框圖，在撰寫DRD的時(shí)候，極大可能會(huì)發(fā)現(xiàn)問題或產(chǎn)生優(yōu)化的想法。但是往往寫DRD至少需要1-2天的時(shí)間，你不可能讓所有下游等著你的工作。所以：
- 你可以交付出線框圖供視覺先開始。視覺設(shè)計(jì)往往會(huì)先做風(fēng)格定位設(shè)計(jì)，這和交互細(xì)節(jié)關(guān)系不大。
- 先交付出已經(jīng)確定的線框圖給前端，然后在1-2天DRD后，若有改動(dòng)，與前端當(dāng)面一一確認(rèn)并一起交付。
五. 如何寫DRD?
1. 選擇最有效率的工具。我的經(jīng)驗(yàn)是這個(gè)工具最好能夠提供清晰的目錄導(dǎo)航結(jié)構(gòu)，而且易標(biāo)注。word確實(shí)是個(gè)寫文檔的好工具，不管你信不信，反正我是信了。2. 建立固定的目錄結(jié)構(gòu)下圖僅供參考。具體里面的細(xì)節(jié)，就不一一羅嗦了。
六. 重要的原則準(zhǔn)備寫DRD的朋友，請(qǐng)認(rèn)識(shí)清楚此文檔真正要解決的問題是什么？如果是解決溝通偏差、需求遺漏、溝通成本高的問題，你在項(xiàng)目里沒有出現(xiàn)過這種問題，各合作方也反饋良好，那么這個(gè)文檔就無(wú)需寫。如果是解決對(duì)設(shè)計(jì)需求進(jìn)行存檔，便于后續(xù)人員改版時(shí)查看的問題，則又是另外一回事（經(jīng)驗(yàn)證明，過去的DRD確實(shí)能夠在改版時(shí)起到一定的幫助，在我離開原項(xiàng)目很久后，新的設(shè)計(jì)師還找我要過相應(yīng)項(xiàng)目的文檔，了解過去的設(shè)計(jì)邏輯）。
- 不是為了寫文檔而寫文檔 （而是為了解決問題）
- 適合于項(xiàng)目、合作方 （大項(xiàng)目有大文檔，小需求有靈巧的解決方案）
- 工具不是問題 （易傳播，易標(biāo)注，成目錄即可）
- 模版不是問題，大家看明白就可
- 完美的文檔無(wú)法取代面對(duì)面的溝通 （評(píng)審會(huì)和討論不會(huì)因?yàn)槲臋n而減少）
- 需要在實(shí)踐中不斷改進(jìn)
七. 誰(shuí)來寫？我建議由交互設(shè)計(jì)師發(fā)起，但是由前端工程師進(jìn)行修訂，再傳遞給開發(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ǔ)言，且能夠劃定與開發(fā)的實(shí)現(xiàn)邊界。
八. 與其他產(chǎn)出物的關(guān)系
項(xiàng)目中交付物對(duì)應(yīng)不同的使用角色，如下圖所示：
但是有個(gè)問題是，雖然DRD的目標(biāo)受眾有開發(fā)和測(cè)試，但是讓開發(fā)工程師同時(shí)參考那么多文檔是不現(xiàn)實(shí)的，所以仍然是開發(fā)工程師的接口人，也就是事實(shí)上的RA需求分析作為需求整合傳遞的角色，將商業(yè)需求和設(shè)計(jì)需求，傳達(dá)給具體的執(zhí)行開發(fā)工程師與測(cè)試工程師：【總結(jié)】對(duì)于堅(jiān)持撰寫DRD的我來說，DRD的好處自己當(dāng)然是明白的——在撰寫過程中重新梳理設(shè)計(jì)邏輯，優(yōu)化設(shè)計(jì)；降低溝通成本等等。但是并非所有人都喜歡寫文檔或者都喜歡看文檔。解決問題有多種方案，DRD只是其中一個(gè)。不過，當(dāng)你因?yàn)樵O(shè)計(jì)需求傳遞過程中發(fā)生了問題，或者你的需求被理解偏差，或者你的需求被遺漏，或者你接手的項(xiàng)目改版，因?yàn)橐崂磉^去的設(shè)計(jì)邏輯焦頭爛額時(shí)，你可以試試用DRD。如果使用過程中還是存在問題，那么就想想是否還存在別的解決方案吧～
藍(lán)藍(lán)設(shè)計(jì)的小編 http://www.cqzjtgb.com
