離開交互圈已經(jīng)有段時間了千贯。但由于博客還在奶赠，還是能夠偶爾收到一些郵件近刘，上周有位同學問我：我在求職雳殊，我看到很多招聘說明上需要交互設計師編寫界面交互設計文檔橘沥，請問界面交互設計文檔是什么文檔？怎么編寫呢
這讓我想起來2009年自己在項目里也大力推行過交互說明文檔（在下文中夯秃，簡稱為DRD）座咆，格式倒沒什么限制，交互設計師自己寫到界面上也行仓洼，單獨文檔成文也行介陶，總之就是讓交互設計師能夠將界面承載不了的信息通過文檔沉淀下來，降低項目里的溝通成本和風險色建。今天整理電腦哺呜，翻出以前的PPT，分享之箕戳。
這將涉及到幾個問題：
一. 什么是交互說明文檔（DRD）某残？
所謂DRD即是用來承載交互說明，并交付給前端陵吸、測試以及開發(fā)工程師參考的文檔玻墅。
在項目中，交互設計師的主要產(chǎn)出物可能依次是：site map壮虫，page flow澳厢，wireframes。有的大型項目前期，交互設計師有可能還會產(chǎn)出用戶需求分析文檔（與PD產(chǎn)出的市場需求文檔不一樣的是剩拢，URD更多側重于對目標用戶的需求分析）线得。
DRD則很少有人專門撰寫。如果需要對交互設計進行說明裸扶，聰明的交互設計師往往會直接標注在線框圖里框都，或者在項目中不斷和前端工程師和開發(fā)工程師口口相傳，反復驗收呵晨，不斷迭代修改來確保所有的交互設計意圖最終得以呈現(xiàn)。
二. 為什么要寫熬尺？
DRD非項目必需環(huán)節(jié)摸屠，一般情況下也不會為交互設計師專門留出相應的時間預估。沒有這份文檔粱哼，項目也會繼續(xù)季二，但是可能項目會為此承擔不必要的溝通成本和時間成本。嚴重的話揭措，項目的質量也會受到影響胯舷。所以寫與不寫，交互設計師需要做把握绊含，時間被統(tǒng)一包含在“線框圖”環(huán)節(jié)內(nèi)——如果你要寫桑嘶，請在評估時預留1-2天的時間。
那么躬充，結合我過去的經(jīng)歷逃顶，談一下此文檔的必要性。
下圖是一個產(chǎn)品開發(fā)項目基本的流程充甚。
敏捷開發(fā)意味著很多不同角色的流程需要并行操作以政。如果等到產(chǎn)品經(jīng)理的FRD已經(jīng)全部敲定，交互設計師再開始去畫線框圖伴找，固然會減少溝通成本和返工風險盈蛮，但是同時意味著交互設計師的很多想法不被采納。如果產(chǎn)品經(jīng)理再強一些技矮，他甚至會在FRD里連原始的DEMO也一并繪制出來了抖誉，功能性的需求和界面交互的需求有時無法區(qū)分太清楚——比如他會在FRD里直接要求每頁條目40條，超過40條即分頁穆役。而交互設計師可能會認為像蘑菇街那樣不斷裝載出足夠長的頁面會更親和……所以寸五，我們希望是和產(chǎn)品經(jīng)理同時開始工作，在術業(yè)有專攻的時候相互補充耿币。
同樣梳杏，開發(fā)工程師也希望及早介入需求，在FRD并未確認的時候就了解需求，進而將商業(yè)需求和功能需求轉化為開發(fā)工程師看得明白的開發(fā)需求清單（這個清單十性，大部分叫做UC叛溢，即USE CASE）,當這份清單由工程師需求分析師——在過去，這個角色被叫簡稱為RA劲适，但是目前已經(jīng)取消此專門的職位楷掉，而是由開發(fā)工程師代表擔綱此環(huán)節(jié)工作，為了便于描述霞势，在此文里烹植，我仍然將做這件事情的人稱為RA——交付給具體的執(zhí)行工程師后，執(zhí)行工程師基本上可以當作一條條的checklist開始高效工作愕贡，而不必再思考商業(yè)邏輯和需求草雕。同樣，測試工程師也需要編寫具體的文檔去指導很多測試人員在開發(fā)后高效測試固以，這也是基于UC和FRD去撰寫的墩虹。
所以，開發(fā)需求分析是個很重要的環(huán)節(jié)憨琳。那RA是如何來完成需求分析工作的呢诫钓？
- 前期介入，對PD進行開發(fā)需求評估支持篙螟；
- 參與每次的FRD評審會菌湃；
- 詳細審閱FRD文檔并不斷與PD確認。
對于做這件事情的人來說闲擦，足夠詳盡的FRD是非常重要的慢味。所以一份FRD雖然是PD產(chǎn)出，但是很多實施細節(jié)則是由開發(fā)工程師不斷溝通評估并確認下來的墅冷。而設計需求的傳遞纯路，卻存在很多問題。除了線框圖寞忿，沒有“詳盡的說明性的文檔”告訴他們驰唬。比如：
一方面，交互設計師對產(chǎn)品經(jīng)理說：這塊由我們來考慮腔彰，你的文檔不必包含設計上的說明叫编，這隨時會調整的。
另一方面霹抛，線框圖的評審有時會讓RA參與搓逾，有時卻沒有叫他們。即使叫上了他們杯拐，他們也會發(fā)現(xiàn)交互設計的需求變化要比FRD變化快霞篡。另外世蔗，他們會認為UC不必寫太多關于交互設計的需求。
在某個大型項目結束后朗兵，作為交互設計師污淋，我進行了一些調研，聽聽這相關人員是怎么表述問題的：
開發(fā)部門的需求分析師：
- 每次變動都很痛苦余掖，設計變了之后寸爆，我就要跟著改UC，改截圖盐欺，有時候UED改了還忘了通知我們赁豆，導致UC有問題……
- 頁面交互的需求容易漏掉，因為UC里面不可能寫太多交互方面的東西找田。
- 希望UED能夠在提交HTML DEMO給RA時歌憨，能同時給出一份頁面元素描述文檔，需要介紹html demo中的文案墩衙、鏈接以及相關的圖片尺寸或顯示字符個數(shù)。現(xiàn)在RA在這方面花費的時間比較多甲抖，經(jīng)常要和UED去確認這些內(nèi)容漆改。
產(chǎn)品經(jīng)理：
- 前期RA和PD溝通過程中，有很多交互點點不能夠明確准谚，比如“默認顯示多少屬性值”挫剑，“標題顯示多少字符”等。在以往的需求和項目中柱衔，對待這些問題我們都是想到一點補一點的到FRD文檔或者郵件中去樊破。既增加了溝通成本又會存在遺漏細節(jié)的風險。PD為了可控性的需求唆铐，往往會“越俎代庖”哲戚，直接在FRD注明這種需求（對于交互設計師來講，卻又導致沒有發(fā)揮余地）
走訪了一些交互設計師后艾岂，他們也存在如何清晰無遺漏將交互設計需求傳遞下去的困惑：
交互認為很平常的設計需求顺少，如果不表達出來，還是容易被前端和開發(fā)忽略掉王浴。我經(jīng)歷的一個項目脆炎，前端從頭到尾更換了三個人，每次我都要重復去講解下設計需求氓辣，講得口干舌燥秒裕。而且做好后，還需要去驗收钞啸。
- DRD做為參考手冊几蜻，一定程度上避免不吻合的問題發(fā)生喇潘。
- 即使有問題發(fā)生，也可以作為界面驗收時的Checklist入蛆。將“我對A說响蓉，我對B說，A對B說”哨毁，轉變?yōu)椤癆和B共同參考同一份文檔”枫甲，減少溝通成本及信息不對稱。
- 全程影響用戶體驗（一直到測試扼褪，都需要參照設計文檔）想幻。
可是以下問題都可以通過一份DRD來解決嗎？
三. 寫什么不寫什么话浇？
要明確文檔的定位脏毯，從寫什么與不寫什么開始，劃清DRD以及FRD的邊界幔崖。
1.不寫視覺規(guī)范規(guī)格標注
這些說明與功能實現(xiàn)沒有太大關系食店，主要是為前端做HTML的時候參考的。一般視覺設計師會在PSD里標注清楚赏寇。如圖：
img6
2.不寫功能實現(xiàn)邏輯吉嫩。
如下圖所示，作為DRD嗅定，你有必要傳達清楚Browse by category區(qū)域的設計：鏈接的可點擊性自娩，鏈接的指向，字符與條目的數(shù)量限制等渠退，但是具體二級類目排列是按產(chǎn)品數(shù)目排還是按字母排忙迁，還是人工運營，是FRD要解決的任務碎乃。
img7
那么文檔寫什么呢姊扔？
舉例子說明下：
1. 字符限制
提高空間利用率，有時網(wǎng)頁上的動態(tài)文字需要從數(shù)據(jù)庫里提取部分然后截斷處理荠锭。比如下圖中的標題和描述旱眯。你的DRD需要傳達清楚：1，是否要做限制证九？2删豺，如果做限制的話，多少字出現(xiàn)截斷愧怜？截斷后是顯示為省略號還是不顯示呀页？這個漢語設計相對簡單，如果英文單詞的話拥坛，因為是按字符蓬蝶，每個字符的寬度不一致尘分，需要預估，另外還需要注明是整詞截斷還是詞間截斷丸氛。
img9
2. 鏈接具體化
很多網(wǎng)站都有對搜索結果的篩選設計（refine search）培愁，比如aliexpress搜索結果頁左側。這塊區(qū)域的交互事件是非常復雜的缓窜。
- 類目和屬性的不同如何處理
- 屬性以及每條屬性顯示的屬性值的條目是否有顯示上的限制定续？
- 選中后，被選中的屬性值是停留在原地禾锤，方便用戶記憶私股，還是放到統(tǒng)一的位置，方便用戶統(tǒng)一查看恩掷？其他未被選中的屬性值是否消失倡鲸？
img10
要確保這些你設想中的復雜的交互邏輯能夠被理解被呈現(xiàn)，除了一頁頁的線框圖黄娘，你有必要再三讓前端工程師和開發(fā)工程師了解并達成認知一致峭状。所以你需要將頁面上的關鍵鏈接事件標識清楚。它們有的指向無需刷新頁面的交互逼争，有的指向你安排的并非PD安排的某個中間頁面（page flow是交互設計師的職責）
img11
3. 交互細節(jié)說明
相信我宁炫，我很不愿意寫這些東西。我喜歡在會議室向各位涉眾演示我的線框圖氮凝，我會研究用axure制作各種動態(tài)效果，達到它足夠逼真呈現(xiàn)各種聯(lián)動——比如當你選擇了下拉菜單中的某項時望忆，頁面上其他區(qū)域也發(fā)生相應的變化罩阵。可是启摄，Axure不是全能的稿壁。即使能夠表達出來，線框圖交付出去歉备，也不能確保其他人都能夠一一進行點擊嘗試傅是。所以只能在會議室反復講解，在事后再三檢查并敦促修改蕾羊。
但是當我嘗試用下圖對這塊小小且復雜的區(qū)域進行詳細說明后喧笔，事情變得簡單多了。所以我用節(jié)省的時間去寫了這份PPT.
img12
又如龟再，你可以在這里說明任何你想要的效果书闸。你的受眾也只需要用10分鐘時間閱讀完畢，標注出與他工作相關的重點利凑，存檔并在遇到問題浆劲，找不到你人時隨時參考嫌术。
img13
5. 表單的校驗
這也是一項不怎么有創(chuàng)意的事情，但是你若不事先想清楚牌借，在項目過程中有點麻煩度气。寫文檔看似枯燥乏味，反過來想也是讓你自己再好好思量審核設計本身的關鍵步驟膨报。我曾經(jīng)自以為完善的交互設計方案就是在寫DRD的時候發(fā)現(xiàn)存在重大的紕漏磷籍，然后及時優(yōu)化的。
img14
6. 瀏覽器的兼容性要求
你們的產(chǎn)品兼容所有瀏覽器簡直是夢想丙躏，但是有時出于效率的要求择示，我們必須戰(zhàn)略性放棄某些瀏覽器，比如IE6.:D 晒旅。 這個決定誰來做栅盲？是前端工程師還是產(chǎn)品經(jīng)理？還是你——交互設計師废恋？我認為決定權在交互設計師這里谈秫，但是他必須和產(chǎn)品經(jīng)理達成一致，并與前端確認鱼鼓。你要求兼容的瀏覽器越多拟烫，標準越高，前端的工作量就會越大迄本，測試的工作量甚至也會翻倍硕淑。
img15
四. 什么時間交付呢咕别？
Heidi的建議：盡可能與你的線框圖同時交付褐墅，如果你先交付出線框圖，在撰寫DRD的時候艘希，極大可能會發(fā)現(xiàn)問題或產(chǎn)生優(yōu)化的想法公条。但是往往寫DRD至少需要1-2天的時間拇囊，你不可能讓所有下游等著你的工作。所以：
- 你可以交付出線框圖供視覺先開始靶橱。視覺設計往往會先做風格定位設計寥袭，這和交互細節(jié)關系不大。
- 先交付出已經(jīng)確定的線框圖給前端关霸，然后在1-2天DRD后传黄，若有改動，與前端當面一一確認并一起交付谒拴。
五. 如何寫DRD?
1. 選擇最有效率的工具尝江。
我的經(jīng)驗是這個工具最好能夠提供清晰的目錄導航結構，而且易標注英上。word確實是個寫文檔的好工具炭序，不管你信不信啤覆，反正我是信了。
2. 建立固定的目錄結構
下圖僅供參考惭聂。
具體里面的細節(jié)窗声，就不一一羅嗦了。
六. 重要的原則
準備寫DRD的朋友辜纲，請認識清楚此文檔真正要解決的問題是什么笨觅？如果是解決溝通偏差、需求遺漏耕腾、溝通成本高的問題见剩，你在項目里沒有出現(xiàn)過這種問題，各合作方也反饋良好扫俺，那么這個文檔就無需寫苍苞。如果是解決對設計需求進行存檔，便于后續(xù)人員改版時查看的問題狼纬，則又是另外一回事（經(jīng)驗證明羹呵，過去的DRD確實能夠在改版時起到一定的幫助，在我離開原項目很久后疗琉，新的設計師還找我要過相應項目的文檔冈欢，了解過去的設計邏輯）。
- 不是為了寫文檔而寫文檔（而是為了解決問題）
- 適合于項目盈简、合作方（大項目有大文檔凑耻，小需求有靈巧的解決方案）
- 工具不是問題（易傳播，易標注柠贤，成目錄即可）
- 模版不是問題拳话，大家看明白就可
- 完美的文檔無法取代面對面的溝通（評審會和討論不會因為文檔而減少）
- 需要在實踐中不斷改進
七. 誰來寫？
我建議由交互設計師發(fā)起种吸，但是由前端工程師進行修訂，再傳遞給開發(fā)工程師呀非。
有很多需求坚俗，交互設計師只要求實現(xiàn)即可，但是他可能并不在乎是前端實現(xiàn)還是后端實現(xiàn)岸裙。前端工程師對DRD進行把關和修訂猖败，能夠將設計語言轉化為工程師能夠看懂的語言，且能夠劃定與開發(fā)的實現(xiàn)邊界降允。
八. 與其他產(chǎn)出物的關系
項目中交付物對應不同的使用角色恩闻，如下圖所示：
但是有個問題是，雖然DRD的目標受眾有開發(fā)和測試剧董，但是讓開發(fā)工程師同時參考那么多文檔是不現(xiàn)實的幢尚，所以仍然是開發(fā)工程師的接口人破停，也就是事實上的RA需求分析作為需求整合傳遞的角色，將商業(yè)需求和設計需求尉剩，傳達給具體的執(zhí)行開發(fā)工程師與測試工程師：
【總結】
對于堅持撰寫DRD的我來說真慢，DRD的好處自己當然是明白的——在撰寫過程中重新梳理設計邏輯，優(yōu)化設計理茎；降低溝通成本等等黑界。
但是并非所有人都喜歡寫文檔或者都喜歡看文檔。
解決問題有多種方案皂林，DRD只是其中一個朗鸠。不過，當你因為設計需求傳遞過程中發(fā)生了問題础倍，或者你的需求被理解偏差烛占，或者你的需求被遺漏，或者你接手的項目改版著隆，因為要梳理過去的設計邏輯焦頭爛額時扰楼，你可以試試用DRD。如果使用過程中還是存在問題美浦，那么就想想是否還存在別的解決方案吧～
作者：Heidixie
版權歸作者所有弦赖，轉載請注明出處！
