一份好的交互設(shè)計文檔，不僅僅是設(shè)計師本人專業(yè)思考、表達和品牌性的體現(xiàn)，還能幫助設(shè)計師更順暢地和上下游利益相關(guān)方溝通。今天這篇文章，主要想總結(jié)下自己之前在設(shè)計稿中做得不到位、常常偷懶忽略的細節(jié)，導(dǎo)致后續(xù)開發(fā)跟進過程中出現(xiàn)各種溝通確認時踩坑的情況。

維護修改歷史

在和業(yè)務(wù)方確認、內(nèi)部評審、可用性測試、開發(fā)評審等過程中，或多或少都會遇到設(shè)計方案需要調(diào)整的情況，而影響到最終方案確定的原因也是平衡多方訴求而得。而勤維護記錄每一次設(shè)計稿版本迭代的更新歷史(包括修改內(nèi)容和作出修改的原因)，雖然看似比較麻煩，但可以在后續(xù)開發(fā)過程中遇到種種對于設(shè)計細節(jié)的疑問挑戰(zhàn)時，幫我們迅速回想起當初作出設(shè)計決策的原因，給出充分合理的答案。

對于節(jié)奏很快，設(shè)計-開發(fā)迭代周期短的項目，這一點的作用可能并不突出。但如果是那種設(shè)計稿交付好幾個月才開始排期開發(fā)的項目(我最近踩到坑的就是這類)，當開發(fā)來找我們提出各種疑問挑戰(zhàn)的時候，可能我們早已淡忘了當初作出決定時的種種細節(jié)，而如果設(shè)計文檔里又沒有一份詳細的修改歷史記錄的話，就會需要耗費時間去重新溝通確認一遍以前討論決策過一次的方案，增加了更多時間成本。

記錄客觀限制

交互設(shè)計需要在用戶、業(yè)務(wù)與技術(shù)之間做好平衡，客觀的業(yè)務(wù)與技術(shù)限制也一直存在，這會使得我們的設(shè)計方案有時候看上去并不是那么完美合理。當我們因為客觀存在的限制而不得不在設(shè)計方案上作出折中時，不妨也將這些客觀限制條件一一整理記錄下來，既幫別人更好地理解我們這么設(shè)計的原因，也能幫自己在后續(xù)的同項目迭代中及時回避對同類限制條件考慮不周的情況。

給設(shè)計稿編號

當需要產(chǎn)出涉及多個界面的設(shè)計方案時，給每張圖進行編號標記(或類似交互文檔的頁碼)，并保證交互稿與視覺稿的編號一致。這樣在后續(xù)和視覺、前端、開發(fā)、測試溝通的過程中，可以通過編號迅速定位到疑問所在區(qū)域，而不需要花更多精力進行描述和查找;前端在參閱設(shè)計稿的時候，也能更方便地把交互和視覺方案對上號。

及時同步狀態(tài)

當設(shè)計方案發(fā)生變動后，即使是細節(jié)微調(diào)、或口頭確認得比較清楚，最好也還是及時同步更新最新的設(shè)計稿鏈接給項目組成員。否則的話，開發(fā)按照舊版本設(shè)計方案執(zhí)行，測試按照舊版本設(shè)計方案提BUG一類的烏龍狀況也更容易發(fā)生;與其等問題發(fā)生了再來想辦法補救，不如在更早的階段將其掐滅。