這篇文章簡單總結了如何寫一份會表達的交互文檔，讓團隊中的上下游（產(chǎn)品、UI、開發(fā)、測試）溝通協(xié)作更加流暢。

關于交互設計文檔的文章不少，很多時候看了不一定能馬上提高一個境界，而需要我們不斷結合項目去實踐和總結積累。這里也是借鑒了一些設計書籍、行內(nèi)的設計分享以及結合自己做項目的親身經(jīng)歷進行總結。

一、 規(guī)范交互設計文檔的重要性

交互設計文檔，稱為DRD(Design Requirement Document)。

我們知道，做出一款產(chǎn)品需要團隊多人協(xié)作，也要歷經(jīng)多次版本迭代。交互設計師在實際工作中，除了需求分析，輸出交互稿之外，也要配合視覺、開發(fā)，甚至測試的工作。

此外因項目的節(jié)奏和進度不同，難免輸出的交互文檔有精細程度之差。所以輸出一份專業(yè)規(guī)范而表達清晰的交互設計文檔會尤為重要。

設計規(guī)范解決了什么問題？

二、交互設計文檔的書寫思路

1. 目錄

2. 封面

文檔封面包含版本信息、參與人員等信息。

3. 文檔說明

寫交互文檔是為了能夠很好地進行上下游協(xié)作，所以需要將文檔表達清楚。文檔說明包括項目背景、更新日志、設計進度、評審記錄等。以便讓項目組人員能夠知曉設計的“歷史進程”，提高溝通的效率。

3.1 項目背景

3.2 更新日志

版本迭代過程中，有時候會遇到人力資源調(diào)配（人員流動或者項目調(diào)配），如果能及時地記錄更新日志并且傳達到位，大家的合作會順暢很多。

4. 需求分析

根據(jù)PRD（產(chǎn)品需求文檔）進行需求的梳理，包括用戶調(diào)研、需求拆解、競品分析、用戶體驗地圖等等（根據(jù)具體不同項目進行安排）。

5. 頁面交互

關于頁面交互原型文檔的書寫思路，常見的有任務流程圖、頁面流程圖、信息架構。需要具體結合項目場景呈現(xiàn)。

5.1 任務流程

在設計之前我們首先要梳理任務流程圖，一般是主流程＋子流程的結構方式，繪制的軟件有Sketch,Axure或者其他第三方軟件。

5.2 信息架構

信息架構圖按照功能－頁面－模塊－元素繪制，幫助我們梳理功能、涉及的信息點，防止漏項。

團隊中協(xié)作之時，也便于做設計任務分工。

5.3 交互原型

通常來說，交互原型頁面由原型頁面＋交互說明組成，我們盡量用一個頁面說明清楚一個事情，盡量避免看文檔的同事困惑，節(jié)省不必要的查找時間，尤其是核心的頁面需要附上具體的流程說明。

本案例是公司的app項目，“分析”頁面中，tab標簽包含“總、月、周、日”，可以自由切換，方便開發(fā)能夠第一眼看到關聯(lián)的流程頁面。

5.4 交互說明

雖然很多產(chǎn)品、開發(fā)人員不愿意讀太多文字，相比之下更愿意看直觀的線框圖。但交互說明也不可省略，這是為了讓大家能夠更好地理解界面的操作行為和邏輯。

那么交互說明包含什么呢？

1. 內(nèi)容：范圍值、極限值；
2. 狀態(tài)：默認狀態(tài)、異常狀態(tài)、特殊狀態(tài)說明；
3. 操作：常見操作、特殊操作、誤操作、手勢操作等等；
4. 反饋：操作后的提示、跳轉(zhuǎn)、動畫等。

本案例中除了描述頁面內(nèi)容，也包含了默認、特殊狀態(tài)的說明，以及操作行為等。

tips：

1. 盡量用真實而符合邏輯的數(shù)據(jù)；
2. 不要忽略特殊狀態(tài)；
3. 清晰簡潔；
4. 交互說明更新時及時告知大家……

交互設計規(guī)范：

交互組件庫：

結合實際項目場景，制作交互設計規(guī)范和建立交互組件庫，并且不斷調(diào)整以適用項目需要，可以大大地提高工作效率。

三、總結

俗話說，好的設計需要有好的表達。誠然，交互設計文檔作為設計師的重要產(chǎn)出物之一，應該是對上下游協(xié)作有益的，能作為評估和參考。

當拿到產(chǎn)品的需求文檔時，應該學會從商業(yè)、技術、用戶的角度多方面思考和分析，擁有“翻譯”成設計目標的能力。相比畫圖，設計的思考、決策過程更能體現(xiàn)自身的價值。

至于原型，行內(nèi)當前沒有統(tǒng)一的標準，很多規(guī)范需要基于項目的實際場景慢慢積累起來，本文中列舉的也是通常遇到的情況，僅作參考。

總而言之，團隊之間的溝通非常重要，與書寫交互文檔的目的同理。

本文由 @emily 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議