這次剛好給公司新同學(xué)培訓(xùn)，梳理了撰寫交互文檔的思路，希望對新同學(xué)有一定幫助。

交互文檔是設(shè)計(jì)師的輸出物，首先需要明確文檔的用戶和目標(biāo)，交互文檔面向的受眾主要是下游同事，包括視覺、動(dòng)畫、開發(fā)、測試等，另外還有自己和PM；文檔的目標(biāo)就是讓下游同事清楚地知道是如何設(shè)計(jì)的，讓他們在進(jìn)行自己工作時(shí)有參考依據(jù)；另外文檔還應(yīng)該能讓自己理清思路，同時(shí)方便與PM討論。

明確了交互文檔的用戶和目標(biāo)后，我們來看看它應(yīng)該包括哪些內(nèi)容，具體內(nèi)容根據(jù)工作需要會(huì)有不同，這里就說說我自己在寫完整的交互文檔時(shí)會(huì)包括的內(nèi)容。

1.修改記錄

修改記錄是整個(gè)文檔的歷史，它讓每一步修改可追溯，便于各職位查看每次新增、修改或刪除的內(nèi)容，同時(shí)便于在工作交接時(shí)讓同事了解整個(gè)文檔的歷程。

一般修改記錄需要包括以下內(nèi)容，文檔版本、需求版本、修改內(nèi)容、修改界面（可鏈接到頁面） 、修改原因、修訂日期、修改人等。

注意事項(xiàng)：及時(shí)更新，保證內(nèi)容詳細(xì)、完整。

2.需求分析

需求分析是在進(jìn)行設(shè)計(jì)前的一個(gè)必要步驟，將它文檔化至少有如下兩點(diǎn)好處，讓自己理清思路，確保設(shè)計(jì)中的問題都思考清楚；評審時(shí)，讓大家對方案的推導(dǎo)過程有了解，更容易推動(dòng)方案，減少分歧 。

需求分析的方法有很多，但做需求分析的思路是一致的。

1. 首先應(yīng)該明確目標(biāo)，是新產(chǎn)品、新功能設(shè)計(jì)，還是改版或優(yōu)化，要達(dá)到怎樣的用戶目標(biāo)和商業(yè)目標(biāo)，不同的產(chǎn)品體量決定需求分析的體量，不同的目標(biāo)決定分析的側(cè)重點(diǎn)。
2. 著手獲取相關(guān)信息，包括需求細(xì)節(jié)、競品信息、用戶反饋、用戶數(shù)據(jù)等，較小的需求可能不需要這么多信息，根據(jù)不同的項(xiàng)目選擇需要的信息。
3. 最后就是分析，不同的項(xiàng)目會(huì)用到不同的方法，常見的方法有場景分析、體驗(yàn)地圖、任務(wù)分析、用戶決策過程分析、全生命周期分析等。這里就不詳細(xì)說明每種方法的使用，提供兩個(gè)例子供參考。

注意事項(xiàng)：

1. 大多數(shù)需求都是需要分析的，盡管它看起來很小，或很明確。
2. 不要為了做需求分析而做，要讓它指導(dǎo)設(shè)計(jì)。
3. 需求分析也是需要迭代的。

3.信息架構(gòu)

信息架構(gòu)是整個(gè)產(chǎn)品的骨架，對于新產(chǎn)品、新功能我們通常會(huì)梳理信息架構(gòu)，而且它也是相對穩(wěn)定的，除非大改版，一般不會(huì)動(dòng)到信息架構(gòu)。信息架構(gòu)圖可以幫助我們在前期梳理整個(gè)產(chǎn)品的結(jié)構(gòu)，后期按照大的架構(gòu)來迭代，同時(shí)讓信息更易理解與瀏覽。

既然信息架構(gòu)如此重要，我們應(yīng)該如何梳理信息架構(gòu)呢，筆者提供幾點(diǎn)思路：

1. 根據(jù)產(chǎn)品特征確定結(jié)構(gòu)類型，這個(gè)產(chǎn)品是適合層級結(jié)構(gòu)、自然結(jié)構(gòu)、線性結(jié)構(gòu)或者矩陣結(jié)構(gòu)，最常見的就是層級結(jié)構(gòu)，將信息一層層分解，直至用戶需要的信息。
2. 分類組合，將不同類型的功能分類，將相似的整合到一起。
3. 明確功能優(yōu)先級，根據(jù)其重要度、商業(yè)價(jià)值、使用頻率等排序，將重要功能抽提出來。
4. 構(gòu)建信息架構(gòu)，考慮可擴(kuò)展性。

注意事項(xiàng)：在有新功能、新方向時(shí)適時(shí)迭代。

4.流程圖

流程圖是梳理任務(wù)、操作流程的工具。它可以幫助我們梳理流程，避免遺漏、明確流程的主次；對照流程進(jìn)行頁面設(shè)計(jì)；向同事說明，一個(gè)任務(wù)是怎么完成的。

在畫流程圖時(shí)需要注意幾點(diǎn)：

1. 根據(jù)流程類型寫，將任務(wù)流程、操作流程、內(nèi)部算法流程區(qū)分開，不要混著寫，不然思路容易被打亂。
2. 分任務(wù)寫，不要將一個(gè)產(chǎn)品的所有流程寫在一個(gè)大流程里，這樣容易遺漏，不方便查看，而且流程太龐大也容易出錯(cuò)。
3. 區(qū)分主次流程\非必要流程，讓流程主次分明。
4. 盡量簡化流程圖，多種狀態(tài)指向同一結(jié)果可以合并。

5.頁面圖

頁面圖是詳細(xì)設(shè)計(jì)的主要內(nèi)容，包括頁面結(jié)構(gòu)、頁面圖、注釋、頁面流程。需要讓視覺、動(dòng)效、開發(fā)、測試的同學(xué)明白設(shè)計(jì)細(xì)節(jié) 。

1.頁面結(jié)構(gòu)

頁面結(jié)構(gòu)是整個(gè)文檔的框架，不同類型的產(chǎn)品有不同的文檔結(jié)構(gòu)，比如信息架構(gòu)型?、流程型?、面向不同角色型等。

2.頁面圖

頁面圖包括主界面、特殊狀態(tài)、反饋等。

主界面圖需表明：

• 布局關(guān)系
• 內(nèi)容主次
• 功能
• 操作

…..

特殊狀態(tài)包括:

• 中間狀態(tài)
• 網(wǎng)絡(luò)問題
• 加載
• 空狀態(tài)
• 不可用

…..

反饋包括：

• toast
• 頁面反饋
• 彈窗

…..

3.注釋

• 對界面的說明
• 對操作的說明
• 對視效、動(dòng)效要求的說明
• 需外界提供的信息備注
• 需求狀態(tài)說明

…..

4.頁面流程

流程中的頁面，為了方便說明可以用頁面流程來表達(dá)，把頁面的跳轉(zhuǎn)關(guān)系串聯(lián)起來。

注意事項(xiàng)：

1. 能用圖形不用文字
2. 盡量簡潔
3. 有主次

6.公共定義\廢棄頁面

將公共定義單獨(dú)拿出來寫，便于維護(hù)，不用每次變動(dòng)都修改每個(gè)界面。廢棄頁面單獨(dú)拿出了，便于追溯，讓下游同事知道改動(dòng)點(diǎn) 。

總結(jié)

寫文檔的過程也是設(shè)計(jì)思考的過程，一方面要確保設(shè)計(jì)思路沒有問題，另一方面要讓文檔可讀性高，以上是筆者的一點(diǎn)小總結(jié)。

作者：Jane ，1年交互設(shè)計(jì)師，歡迎指教交流。

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

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