一款APP的交互文檔從撰寫到交付

來自專欄 UI設計師成長營11 人贊了文章

我第一份工作的設計總監是前百度設計師，34歲，一線設計12年；今年聊天說轉了產品總監，如今39歲還活躍在行業中……

我第二份工作的部門總監是前騰訊工程師，38歲，一線開發14年；2年前在Q群里跟我們說，他上山跟師傅修行養生，神隱了(;′??Д??`)……

設計總監哈爾濱的，開發總監青島的，和我們一樣都是北漂，無一線戶口，老家二三線城市，互聯網行業發展都很一般。

說起這個主要是和設計朋友們聊天，談到兩個事情：

①有人很焦慮，說中國互聯網30多歲後做不下去了，我不否認這殘酷現實o(╥﹏╥)o

行業精英只是少數人，我們終其一生也可能就是個普通設計師，把設計當成養家糊口的手藝，離開行業發達的城市甚至都沒有可用武之地。

但是我們這階段焦慮也是空有焦慮，沒什麼用。所以踏實的提升能力吧，到了30多歲的時候再考慮繼不繼續做下去。

②有人說小企業沒有牛人帶，想跳槽一沒拿的出手的作品，二怕沒跳槽的實力；

這種情況存在而且很多，多數中小企業就這樣，我們無力改變普遍行情。

所以我建議在職期間用盡一切辦法提升能力，不論自學或者網課；之後重設計公司的商業項目作為個人作品，年後趁早跳了吧。

最後說一句，我工作中遇到過很多設計師，套用現在比較俗套的句子就是：

設計行業，工作年限≠工作能力，天賦決定上限，努力決定下限。

所以不時刻學習提升能力，30多歲的我們也只是乾的時間比較久的美工而已。

閑話扯的有點多，下面來看乾貨部分吧。

Part 1 交互文檔的作用

這是理論性的東西，快速瀏覽下就可以了，沒什麼實質內容，但不寫還差點意思。

ㄟ( ▔, ▔ )ㄏ

交互文檔需要團隊人員都知曉，並根據需求反饋，時刻迭代，同步更新到每一個人。

說白了，這文檔必須每個人都熟悉，並且後邊更新後每個人手裡的都得跟著更新。

交互文檔在每個環節的作用：

· 把PM抽象的需求，變成具象的、可落地執行的設計方案；

· 和各級部門討論設計方案細節和可行性，並最終敲定需求、開始執行；

· 對UI：根據交互文檔設計效果圖，頁面布局、順序、頁面情感以及交互方 式等等；

· 對開發：嚴格根據交互文檔進行產品功能的設計和開發；

· 對測試：嚴格根據交互文檔設計測試用例，並Review方案進行反饋。

優秀的交互文檔的作用：

1.讓相關人員快速了解設計方案和制定工作計劃；

2.保證每個環節的用戶體驗一致；

3.開發完成後、作為產品驗收的檢驗依據。

同時也是體現交互設計師專業能力和個人價值的依據。

對設計師而言，製作原型的思考過程，絕對是最快提升邏輯能力、產品設計能力、分析能力以及提高產品認知度的過程；、

(當然前提是真的要思考著去做，不過腦子光畫線框圖的就當我沒說過吧……)

對團隊而言，低保真原型可以有效提升工作效率，規避風險和資源浪費。

無論是大到整個產品的交互文檔，還是小到某個功能的交互文檔，道理相同。

以上當然是理想狀態，但現實總是殘酷的。

我經歷過無視原型階段，拿需求文檔直接讓UI出效果圖；需求變更直接改效果圖，把UI設計師當牲口使喚；

也經歷過因方案沒有準確傳達到每個人，導致有人對方案誤解，開發中出現問題的；

第一種憑設計師個人很難改變公司的現狀，所以要麼走要麼扛；

第二種一定要儘力避免因溝通引起的低級錯誤。

Part 2 完整的交互文檔

不少人認為線框圖就是交互文檔，但它只算是「界面布局方案」，不算完整的「交互文檔」，因為「界面布局方案」PM、UI可以畫，甚至市場、運營也可以根據想法畫出來，

所以這個無法體現交互設計師的工作價值。

下面這份交互文檔的書寫習慣，來自我第一份工作的設計總監，他教導我的東西一直被我延用至今，受益匪淺。

首先看下交互文檔的Pages目錄，我會把涉及到模塊對應的內容解釋給大家：

①目錄

目錄就是交互文檔自身的信息架構,優秀的交互文檔需要結構清晰，命名準確的目錄。

很多人闡述交互方案時，其他人看到的目錄是「New Page01、新頁面03、功能02……」，結構和命名都很混亂，團隊成員憑什麼認同你的專業能力？

結構清晰，命名準確本身就是體現交互設計師專業能力的內容之一。

②交互文檔內容之一：產品封面

封面的內容：

項目或需求：項目名稱或者本次需求的名稱；

版本號：項目或需求隸屬的版本，用來進行版本歸檔，項目跟進、排期；

人員列表：項目相關人員都會位列其中，便於工作安排和交接。

產品封面顯示了項目的基本概況，是很好的介紹入口。

③交互文檔內容之一：修訂更新記錄

修訂更新記錄的作用：

· 讓UI、開發和測試等快速知曉項目需求以及更新內容，並迅速定位到對應位置；

· 作為需求的憑證，當有人對需求有異議時，拿出白紙黑字的記錄；

· 培養交互設計師時刻記錄的習慣，記錄的越詳細越好，以後會有很大幫助。

修訂更新記錄的書寫規則：

1.以天為單位倒序書寫，從項目立項開始記錄， 持續更新迭代；

2.每個需求點單獨列為一條記錄，不要一條記錄填寫多個功能點；

3.每條記錄添加鏈接到交互方案的對應頁面，便於其他人快速定位到相應位置。

這文章雖然叫「交互文檔的撰寫和交付」，但是交付之後交互設計師的工作可遠遠沒有結束。

交互設計師的工作就是不停的跟進需求變更和反饋，持續迭代優化交互文檔，而且無論何種更新，都要具體提現在我們的交互文檔中。

④交互文檔內容之一：需求分析 & 業務邏輯圖

這裡其實是來自於PM的需求文檔和業務邏輯圖，不是交互設計師的工作範圍。

這個模塊工作主要是PM來做的，放到這裡的原因有兩個：

①為了保持文檔的完整性；

②讓開發和測試能夠在同一份文檔里解熟悉業務需求和業務邏輯，方便他們工作，而不需要好幾個文檔來回查看了。

⑤交互文檔內容之一：信息架構圖

信息架構圖是根據PM的需求文檔、功能樹狀圖和業務邏輯圖提煉的產品功能模塊，這裡已經可以區分出產品功能的層級關係了。

信息架構圖的結構和產品交互方案的結構兩者是對應的。

從產品交互方案上就可以看出一個交互設計師的信息架構梳理能力是不是專業。

⑥交互文檔內容之一：流程設計圖

流程設計有多重要我就不贅述了，凡是做交互設計的都避不開的工作。

流程設計圖中的每一環節，是和我們交互方案中的頁面一一對應的。

把它放到文檔里來：

一是避免在製作交互方案的過程中，忽略遺漏掉某些頁面；

二是讓開發和測試快速理解產品每個任務的具體流程，來安排工作。

這裡注意一點：

有多個任務流程的時候，應該針對每一個任務單獨繪製該任務的流程設計圖。

⑦交互文檔內容之一：交互方案

交互方案就是我們整份交互文檔的重點：產品最終的可執行設計方案。

它會包含頁面邏輯關係、頁面布局、交互說明、迭代標示、動效說明、頁面情感說明等諸多要點；

它和前面提到過的信息架構圖，流程設計圖是相呼應的，設計它應該根據信息架構和流程設計來製作。

交互方案會在下一期詳細拓展，這裡僅作為本章示例來使用，不再過多展開。

交互方案的注意事項非常多，這裡展開的話會導致本章的內容過長了，而且我個人不喜歡看太長的文本。

⑧交互文檔內容之一：公用控制項庫

公用控制項庫的作用有兩個：

一是我們製作交互文檔的時候可以快速提取對應控制項，提高工作效率；

(目前線上平台已經提供了大量的可用控制項，但因為我們這裡使用的是本地化的製作工具，這個模塊還是要有的。)

二是團隊成員共同協作的時候，保持交互文檔的一致性；

每個團隊的公用控制項庫都不相同，需要各自的團隊根據自身產品特性去共同完善它，

這裡只放了一些示例模板，大家需要注意一下。

我們來總結下都有什麼：

①目錄

②文檔封面

③修訂更新記錄

④需求分析 & 業務邏輯圖 (來自PM)

⑤信息架構圖

⑥流程設計圖

⑦交互方案

⑧公用控制項庫

以上是一份完整的可以稱之為「交互文檔」而不是「界面布局方案」的文檔該有的內容，

除了第④項可能受限於PM的職業水平和素養，不能保證確確實實獲取到。

其他的內容都應該是作為交互設計師體現在交互文檔中的工作內容。

這一期我們談了一份完整的交互文檔應該包含的內容模塊；

其實也可以理解為使用本地化製作工具書寫交互文檔時，要體現哪些信息。

看過我以前文章的人也熟悉，我的文章大部分都是工作的方法，模式；很少涉及設計能力，理論體系之類的內容。

這麼寫的初衷是因為：

這類工作方法，不需要時間消化，看過之後立刻就可以根據自己的實際工作情況進行調整和套用，立刻就可以達到上手應用的程度。

而設計能力，理論體系這類抽象的東西，根據我個人的學習經歷，短時間內很難通過閱讀幾篇文章就得到質的提升，必須通過大量的實際工作經驗慢慢積累。

作者：精分青年鹵大濕

UI中國主頁：http://i.ui.cn/ucenter/126293.html

推薦閱讀：