今天給各位分享交互設(shè)計說明文檔模板的知識，其中也會對交互設(shè)計報告書進行解釋，如果能碰巧解決你現(xiàn)在面臨的問題，別忘了關(guān)注本站，現(xiàn)在開始吧！

本文目錄一覽：

• 1、項目的交互文檔怎么寫
• 2、交互說明怎么寫？
• 3、交互設(shè)計說明文檔內(nèi)容

項目的交互文檔怎么寫

1、交互文檔用來記錄在交互設(shè)計過程中的任何內(nèi)容，供團隊內(nèi)人員或者其他相關(guān)人員使用。

2、從長遠來看，交互文檔對整個團隊比較有好處。

一個好的交互文檔：團隊的新人通過文檔可以輕松接手。

1、設(shè)計系統(tǒng) (DS)的說明

設(shè)計團隊有一個很大的DS，實際使用時有些組件的用法和DS里寫的不太一樣。這時需要記錄下來到底怎么用、舉列、說明建議的用法和不建議的用法等，以便團隊所有設(shè)計師都能遵守。

還有整個UX pattern（模型）也可以記錄，放截圖和文字介紹，給新來的設(shè)計師或者相關(guān)人員查看。

2、記錄UX設(shè)計時做的決定

做復(fù)雜的新產(chǎn)品時，可以記錄整個設(shè)計過程。如PM給的設(shè)計要求、Tech的限制、research、設(shè)計上做決定的理由、最后的設(shè)計圖等。

方便團隊外成員了解設(shè)計的理由，防止忘記，方便回看歷史設(shè)計決策并做優(yōu)化迭代。

3、記錄UI里面的所有文字

亞馬遜特有的記錄所有文案的部分。不建議把UI里面的文字只放到Figma里面，可在UX Documentation建一個表格，放一些截圖并把各種UI文字放在截圖下面，這樣方便程序員們改文字，也方便UX writer查看所有設(shè)計師的作品里面用的文字是否有一致性。（有的團隊有UX writer）。

1、使用獨立文檔，可以用Word文檔等，不建議放在figma或sketch，給相關(guān)人員看的越簡單越好

2、根據(jù)團隊人員和其他相關(guān)人員的反饋，不斷改善交互文檔

3、亞馬遜的交互文檔模板如下文

1、項目時間年月

2、項目概述

3、商業(yè)需求或相關(guān)文檔的鏈接

1、該項目解決了核心用戶的什么問題

2、用戶對于一定要到網(wǎng)頁端支付感到很煩，因為這樣……

3、用戶的需求舉證

產(chǎn)品戰(zhàn)略：XXX

產(chǎn)品范圍：如下圖

產(chǎn)品經(jīng)理：John Smith / john.smith@

開發(fā)主管：Jane Doe / Jane.doe@

軟件開發(fā)工程師：Jack Li / jack.li@

1、相關(guān)調(diào)研的鏈接

2、相關(guān)調(diào)研的要點，例如：90%的用戶有5個或者更多的銀行賬戶；收款人的平均數(shù)量是16位

對比圖【方案1圖】【方案2圖】

1、開發(fā)建議修改……因為……

2、設(shè)計團隊建議新增……因為……

3、……的限制……

【圖】

1、設(shè)計原則

2、版本迭代的反饋/限制： 相關(guān)人員對版本迭代的反饋或一些限制因素

【圖】

1、相關(guān)人員評審和反饋記錄地址XXX

2、交接文件地址XXX

3、設(shè)計系統(tǒng)更新記錄

最終版反饋

1、設(shè)計團隊評審一致通過方案的日期：2022-02-22，無異議

2、技術(shù)團隊評審日期：2022-02-22，關(guān)于XXX有疑問，無其他異議

用戶驗收記錄，例如：沒有用戶測試的預(yù)算，在測試版中跟蹤用戶數(shù)據(jù)

【圖】

開發(fā)過程中的一些備注，例如：2022-02-22，開發(fā)提出XXXXX的方案

1、UX文檔：XXX

2、產(chǎn)品文檔：XXX

3、技術(shù)文檔：XXX

交互說明怎么寫？

所謂交互說明，簡單的理解就是對交互原型的解釋、強調(diào)或補充的說明文字。原型頁面往往無法展示全部的交互細節(jié)，即便完全做到了，團隊中的下游也不一定能夠全部get到。所以，一份足夠完整和詳細的交互說明文檔可以減少溝通成本及信息不對稱。

相信大多數(shù)的交互設(shè)計師們都有寫交互說明的經(jīng)歷。那么大家知道如何完成一份合格的交互說明文檔嗎?不妨從以下幾個角度了解下到底該怎么寫交互說明。

首先需要明確交互說明的讀者和在項目中的作用：

很明顯作為項目的 交互設(shè)計師 是交互說明的主要撰寫人和維護者。

在項目進程中，交互說明應(yīng)由設(shè)計師發(fā)起， 前端開發(fā)工程師 也會協(xié)助修訂細節(jié)。交互設(shè)計師更多的關(guān)注點在需求到原型的轉(zhuǎn)化，對于前后端能否實現(xiàn)并不是很確定。前端開發(fā)工程師對交互說明的的把關(guān)和疑問，能夠幫助設(shè)計師將設(shè)計思想轉(zhuǎn)為工程師能夠理解和實現(xiàn)的語言。這樣交互說明也能幫助前端開發(fā)工程師明確設(shè)計實際執(zhí)行方案。

寫交互說明文檔時，很多人都會疑惑，到底需要寫什么呢？我的意見是，站在下游的角度，視覺設(shè)計師和開發(fā)工程師在需要考慮的與頁面相關(guān)的邏輯和用戶操作相關(guān)的內(nèi)容基本都是需要在說明中體現(xiàn)出來。另外我們應(yīng)該盡量寫得詳細些，避免研發(fā)同事多次來討論或者直接按照自己的理解直接實現(xiàn)，這樣最終的驗收效果也會比較好。那么具體的該寫什么不該寫什么，這里也做了整理供參考。

用戶身份和系統(tǒng)功能頁面緊密相關(guān)。比如后臺系統(tǒng)常見的會區(qū)分管理員身份，普通管理員還是超級管理員。

表單校驗邏輯：是實時校驗還是觸發(fā)按鈕后做校驗，還是兩者結(jié)合，表達清楚邏輯并將相關(guān)的提示和反饋描述清楚。

根據(jù)項目內(nèi)容特性和業(yè)務(wù)將邏輯細節(jié)和交互細節(jié)表達清楚。比如app可能有鎖屏推送，項目是否有數(shù)據(jù)埋點。

提供一個參考的目錄，可以進行適當?shù)恼{(diào)整作為項目交互原型的目錄：

相比較word等文本記錄工具比較推薦Axure，原因有三：

根據(jù)項目類型和情況確定具體合適的排版，基本可以按照從上到下從左到右的順序去排版。

以上都能理解和做到，已經(jīng)可以完成一份合格的交互說明文檔了。那么怎樣才算是一份不錯的交互說明的呢？

這里分享幾個注意點：

對接的下游有時候是同一部門或同一個同事，目錄保持基本的統(tǒng)一，可以降低下游的學習成本，另外也讓自己在寫說明時不必每次都去思考目錄的劃分。當然，針對不同的產(chǎn)品類型和產(chǎn)品特性需要去調(diào)整制訂目錄。

拒絕流水賬式說明，另外當描述文字過長，可能需要重新考慮是否是設(shè)計邏輯存在問題。那么如何讓說明文字盡可能的簡單呢？

原型設(shè)計的過程中，需要展示數(shù)據(jù)，對數(shù)據(jù)的模擬盡可能的真實，撰寫交互說明可以將場景還原更加貼近真實可能性。而且，真實符合邏輯的數(shù)據(jù)，研發(fā)也比較能更快理解頁面邏輯，所以也可以減少溝通成本。

原型頁面很多內(nèi)容是復(fù)用，那同樣的這些重復(fù)的內(nèi)容，按照常見的處理方法，就會重復(fù)寫很多次的交互說明（相信大家也會復(fù)制粘貼），但是這樣帶來2個問題，一是研發(fā)會不會懷疑前后的交互說明是否有區(qū)別，二是如果需要修改的話，需要對所有的相關(guān)頁面修改，維護的工作量就變大了很多。有2鐘解決方法：

每次更新都是一次改進的過程，添加新內(nèi)容的同時，保留舊的內(nèi)容，讓其他人也看到走過的彎路，讓他們知道每次修改都是深思熟慮后的決定。為什么要周知呢？下圖，是不是很直接地解釋清楚了：

另外，當我們在項目中寫交互說明寫多了就會發(fā)現(xiàn)，組件可以自己設(shè)計生成元件庫，調(diào)用元件庫就可以快捷使用，那么組件的交互說明也可以組件化進行歸類入庫，在需要的時候直接拿出來根據(jù)具體情況調(diào)整使用。附上，我整理出的交互說明組件庫的部分頁面供參考，大家可以根據(jù)自己的操作習慣和經(jīng)常接入的項目特點制作一套適合自己的交互說明模板庫：

通用交互說明：

頁面交互說明：

表文結(jié)合形式：

以上就是我在項目進行過程中發(fā)現(xiàn)的問題和個人思考的解決方案。但是，并非所有人都喜歡寫說明文檔或者看說明文檔。有必要的情況下，需要跟團隊成員強調(diào)交互說明的存在意義，推動大家去閱讀和反饋，這樣辛辛苦苦寫出來的說明才能對項目的發(fā)展起到真實的作用。另外在項目合作的過程中，除了做好自己的任務(wù)以外，要多站在項目的角度上去思考，要去考慮團隊中其他角色尤其是下游伙伴是否能夠較好及時地實現(xiàn)或完成相關(guān)任務(wù)，這樣思考后才去決定自己手下急需和應(yīng)該完成的任務(wù)項。

交互設(shè)計說明文檔內(nèi)容

完整的交互設(shè)計內(nèi)容：

一、設(shè)計背景

1、產(chǎn)品定位(目標用戶、競爭策略（差異化、控制成本））

2、具體設(shè)計內(nèi)容

3、設(shè)計目標

二、流程圖

1、業(yè)務(wù)流程圖（各角色的協(xié)作運行）

2、任務(wù)流程圖（用戶的操作流程，有：主任務(wù)流程、次任務(wù)流程）

3、頁面流程圖（在原型圖之前繪制、可便于整理頁面間的邏輯，包括頁面、行動點、連接線）

三、原型圖

信息架構(gòu)（頁面的內(nèi)容及排布、頁面之間的跳轉(zhuǎn)）

四、需求描述文檔

功能點、觸發(fā)條件（要窮盡異常的情況（情況1、情況2、情況3...））、結(jié)果描述、備注

五、其他元素

*網(wǎng)絡(luò)異常處理

1、整頁提示（插畫、說明、重連按鈕、小貼士）

2、預(yù)設(shè)圖、占位符提示（不增加操作負擔）

3、Toast/dialog提示（最好給出設(shè)置網(wǎng)絡(luò)的通道）

*臨時框（暫停主任務(wù)，關(guān)閉后回到主任務(wù)）

1、警告視圖（不易過多，比如訪問手機接口是獲取用戶許可）

2、Toast (1~1.5S,反饋信息但不中斷操作流程）

3、操作列表（將不常用的功能入口統(tǒng)一打包）

4、模態(tài)視圖（輸入頁面、用戶須知等）

標志說明：

頁面標題：

寫在每一頁的頂部。表明當前頁所述的功能是屬于哪個模塊的

對齊：

單個界面之中元素的對齊、界面和界面之間的對齊，頁面上任何東西都是應(yīng)該能找到對齊點的。注釋右對齊。

顏色：

使用黑白灰，避免使用黑色線條和黑底白字，灰色會顯得更精致。

用深淺不同的灰來表現(xiàn)層次和重點。

合理留白，避免界面過擠或過空。

熱區(qū)：

標明熱區(qū)的范圍。

緊密相連的熱區(qū)區(qū)分方法：

圖片：

使用圖片時，要注意和背景融合。

若暫沒有找到合適的圖標，寧可統(tǒng)一用占位符替代，輔以文字注釋。

若對圖片內(nèi)容或風格有想法，用各種形式在交互文檔中表現(xiàn)出來。

流程圖

主線和分支的走向要始終保持一致（是和否）。

善用輔助線

原型說明：

寫清楚各種異常情況的處理

多去考慮一下 交互文檔 閱讀者的體驗，可能就會想盡各種辦法來滿足他們。

交互設(shè)計說明文檔模板的介紹就聊到這里吧，感謝你花時間閱讀本站內(nèi)容，更多關(guān)于交互設(shè)計報告書、交互設(shè)計說明文檔模板的信息別忘了在本站進行查找喔。