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

維護修改歷史

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

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

記錄客觀限制

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

給設計稿編號

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

及時同步狀態

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