前言

當我在網(wǎng)上搜尋交互文檔規(guī)范時，可以搜到很多關(guān)于交互文檔的結(jié)構(gòu)搭建的文章，但始終沒有一份較為完整的案例 Demo 展示，主要是因為大多數(shù)商業(yè)項目的交互文檔是涉密的，無法進行分享。

相信大家和我一樣想要一睹交互文檔實戰(zhàn)案例的芳容，我本著在交互行業(yè)學(xué)習(xí)的精神，研究了飛書、釘釘、騰訊會議，構(gòu)建了這個《UEDART 云辦公 APP 交互案例》的虛擬項目，最終輸出在交互文檔中可以快速復(fù)用的框架與模塊。旨在通過符合實際的項目來進行交互文檔整體構(gòu)建的闡述，讓大家通過案例的瀏覽，更為切實的了解到交互文檔的細節(jié)，從中得到一些有效的幫助。

序幕

以下預(yù)覽的整個交互文檔全部由 Axure 制作完成

UEDART 云辦公 APP 交互案例預(yù)覽： https://vip.uedart.com/works/CloudOffice/Complete/index.html

關(guān)于整個云辦公 APP 項目的需求分析、設(shè)計思路、業(yè)務(wù)流程圖、頁面流程圖、原型圖制作內(nèi)容已經(jīng)在《UEDART 云辦公 APP 交互案例》文檔中體現(xiàn)了，本文就不再做過多贅述。接下來主要講一講，通過本次交互案例的展示，如何利用 Axure 快速構(gòu)建 DRD 交互文檔，為我們后續(xù)的工作提供更加有效的幫助。

通過本文的闡述再結(jié)合《UEDART 云辦公 APP 交互案例》，雙管齊下，能夠讓大家更好地了解到整個交互文檔框架與實戰(zhàn)交互案例的全貌，深入各個環(huán)節(jié)挖掘細節(jié)知識。這樣會比單獨從一個角度切入更為的直觀和有效。與此同時，大家可以初步了解到如何從項目實踐中抽離共通性，有意識地將共通性進行模塊化是提高效率的好方法。

希望本文能夠給大家傳播一些知識，也希望在和大家交流的過程中，我也能不斷地修正錯誤汲取新知識，和大家一起成長。

一、明確用戶對象

交互文檔給誰看，定義文檔的用戶對象很關(guān)鍵。

根據(jù)文檔的用戶對象不同，制作的方式與精細度也會有不同的要求。

本次制作的交互文檔主要是針對工作環(huán)節(jié)中，用于落地開發(fā)實現(xiàn)，輔助工作環(huán)節(jié)中的各個成員：產(chǎn)品經(jīng)理、視覺設(shè)計、開發(fā)人員以及測試人員，了解產(chǎn)品交互的功能與流程細節(jié)需求，便于開發(fā)對需求的理解與實現(xiàn)。

二、文檔制作場景化

2.1 我們產(chǎn)品設(shè)計中的5個常見場景

0-1 的產(chǎn)品設(shè)計：

完全 0-1 的產(chǎn)品，從頭梳理產(chǎn)品業(yè)務(wù)、場景與業(yè)務(wù)，對應(yīng)的業(yè)務(wù)與模塊需求特別多

全新業(yè)務(wù)線：

已有基礎(chǔ)流程與業(yè)務(wù)的沉淀，需要迭代全新業(yè)務(wù)線或大模塊，對應(yīng)的業(yè)務(wù)流程和功能

大版本迭代產(chǎn)品功能：

涉及多平臺、流程較多，對應(yīng)的迭代功能比較多

小版本迭代產(chǎn)品功能：

涉及流程少，迭代功能少，對應(yīng)的要求是快速響應(yīng)上線

2.2 如何讓整個文檔框架更為的靈活呢？

針對以上場景我將交互文檔框架拆分為：大、中、小三種形式，分別對應(yīng)產(chǎn)品設(shè)計的幾個常見場景

大型：0-1 的產(chǎn)品設(shè)計，迭代全新業(yè)務(wù)線

此會用 1 個完整的 UEDART 云辦公 APP 交互文檔案例來展示

UEDART 云辦公 APP 交互案例預(yù)覽： https://vip.uedart.com/works/CloudOffice/Complete/index.html

中型：大版本迭代產(chǎn)品功能

此大體結(jié)構(gòu)和“大型”差別不大，主要是刪減了一些基礎(chǔ)信息的內(nèi)容，流程和子業(yè)務(wù)的數(shù)量上的差異性

交互說明框架（中型）預(yù)覽： https://vip.uedart.com/works/CloudOffice/mid/index.html

小型：小版本迭代產(chǎn)品功能

小版本，時間緊，功能較少，于是這邊簡化為“頁面流”和原型圖展示

交互說明框架（小型）預(yù)覽： https://vip.uedart.com/works/CloudOffice/little/index.html

三、提煉交互文檔特性

結(jié)合用戶對象和使用場景，提煉交互文檔的幾個特性

• 易于閱讀：方便流程中的各個對象的閱讀與理解，方便瀏覽與閱讀
• 靈活應(yīng)用：適配于各個產(chǎn)品設(shè)計的場景，提升效率
• 調(diào)整修改：在產(chǎn)品開發(fā)進程中進行錯誤點的調(diào)整或需求變更的標記與注釋
• 版本迭代：要做好版本管理，方便更新迭代，不只是項目的迭代，整體交互文檔框架也需要不斷更新迭代使其更加符合我們實際的工作所需

為什么要提煉特性？

主要是讓制作有方向性，這一點很重要。

做一件事一定要明確為什么做，在項目之初已經(jīng)定義了本次項目的主要目的。在明確為什么做的基礎(chǔ)上，如何更有效地實現(xiàn)目標，方向性很重要，它為接下去的項目制作提供了關(guān)鍵著陸點，在一系列的發(fā)問與思考中不斷完善靠近最終目標。接下來的制作思路將基于此特性，進行制作方法的選型與整體交互文檔構(gòu)建的架構(gòu)。

四、制作思路

最初定義《UEDART 云辦公 APP 交互案例》的輸出為主，此案例按照大型的交互文檔框架進行打造，讓大家能夠了解到交互文檔的全流程制作的全過程。

4.1 制作準備與產(chǎn)出物

4.1.1. 制作方法論

我稱之為五環(huán)制作法：提煉原則，確定方法，統(tǒng)一規(guī)范、拆分模塊、提升效率。

• 原則：基于交互文檔的四個特性，易于閱讀、靈活應(yīng)用、調(diào)整修改、版本迭代。
• 方法：利用 Axure+oss 原型托管的方式來實現(xiàn)整體文檔的架構(gòu)與部署。方便不同制作場景下的應(yīng)用、各成員的瀏覽閱讀、修改調(diào)整、版本迭代控制。
• 規(guī)范：基于統(tǒng)一的規(guī)則，方便保持元素的一致性，提升文檔細節(jié)美觀度和閱讀感。
• 模塊：文檔內(nèi)部形成標準件模塊化、流程模塊化、頁面模塊化、組件模塊化，方便復(fù)用與管理。
• 效率：采用了原有已經(jīng)制作好的 PRD 框架+手機組件作為基礎(chǔ)素材，方便提升的制作效率，與此同時規(guī)范性與模塊化也為后續(xù)的制作帶來了高效率性。

4.1.2 項目準備

• 項目名稱：UEDART 云辦公 APP1.0
• 項目調(diào)研：了解競品、分析競品、競品結(jié)構(gòu)分析（主要針對飛書、釘釘）
• 項目安排：周期安排，利用業(yè)余晚上和周末的時間完成
• 制作工具：Axure9.0 版本、xmind8.0
• 項目啟動：2020 年 12 月 1 日啟動，
• 預(yù)計完成：2021 年 1 月 15 日
• 實際時間：2021 年 2 月 6 日

Tip：回溯項目整個的制作時間，2021 年 1 月穿插了很多其他事情，比之預(yù)期有所滯后，最終還算比較順利的在春節(jié)前完成了整個項目的制作與整理。

4.1.3 最終產(chǎn)出

• 腦圖：云辦公 APP、交互規(guī)則、非功能性需求
• 大型交互說明框架：UEDART 云辦公 APP 交互案例
• 中型交互說明框架：交互說明框架_中型
• 小型交互說明框架：交互說明框架_小型
• 原型元素：原型元素規(guī)范

4.2 文檔結(jié)構(gòu)

4.2.1 瀏覽框架結(jié)構(gòu)

• 標記 1：交互文檔標題，包含項目名稱+版本號
• 標記 2：主模塊頻道切換，可根據(jù)需要自定義和調(diào)整排序
• 標記 3：模塊內(nèi)，切換菜單，可根據(jù)需要自定義增加或減少
• 標記 4：子菜單內(nèi)容展示，可根據(jù)需要自定義內(nèi)容頁內(nèi)容

Tip：整體框架封裝好自適應(yīng)結(jié)構(gòu)，方便筆記本與 pc 電腦的閱讀感，同時封裝好切換點擊動效，整體瀏覽感就和平時瀏覽網(wǎng)站是一樣的效果，方便讀者閱讀。

4.2.2 交互文檔結(jié)構(gòu)

大結(jié)構(gòu)分為：基礎(chǔ)信息、交互說明、原型頁面、回收站四個模塊。

部分內(nèi)容展示：

更新日志：

產(chǎn)品介紹：

設(shè)計思路：

通用規(guī)則：

非功能性需求說明：

交互說明目錄：

頁面流程圖：

4.3 文檔規(guī)范與模塊化

4.3.1 原型元素規(guī)范

在整體文檔制作開始時，先制定好整個原型文檔的原型元素是一件很必要的事情，這為后續(xù)制作的規(guī)范統(tǒng)一性提供了堅實的基礎(chǔ)，基于統(tǒng)一的規(guī)則，方便保持元素的一致性，提升文檔細節(jié)美觀度和閱讀感。

這樣能夠保證后續(xù)組件與頁面的元素統(tǒng)一，保持一致性的原則。

主要定義了品牌色、自定義灰度色系、頭像尺寸、字號、4px 間距。

4.3.2 組件規(guī)范

我們在工作中經(jīng)常會用到一些固有的組件庫，比如 Ant 螞蟻出品的 axure 組件，很多同學(xué)可能就“拿來主義”直接應(yīng)用到自己的項目中，這確實也是一個比較容易也很省事的做法。

我個人比較習(xí)慣于把這些組件素材作為制作的基礎(chǔ)素材，在實際應(yīng)用中根據(jù)項目的業(yè)務(wù)所需，重塑組件。項目中的組件制作是一個循序漸進的過程，不能一蹴而就，在我們制作過程中，拆分出來的通用模塊，就可以封裝為一個組件樣式，方便下一個流程或頁面的復(fù)用。

本次制作中我應(yīng)用了 UEDART 出品的手機端組件作為基地素材，進而優(yōu)化成本次項目中的組件元素。

這套組件規(guī)范也是我參與制作的一個項目。

預(yù)覽地址： https://vip.uedart.com/demo/UEDART_003/index.html

4.3.3 模塊化思維

我們不止在制作文檔時需要模塊化這種思維，在設(shè)計產(chǎn)品與流程設(shè)計時也需要帶著這種思維，可以有效地將流程中公用的子業(yè)務(wù)流進行串聯(lián)，避免重復(fù)子流程與重復(fù)的開發(fā)工作。

4.4 調(diào)整與修改

4.4.1 文檔聯(lián)動調(diào)整

框架頁面名稱，采用函數(shù)制作，名稱自動按照頁面名稱展示。

交互說明目錄名稱：采用引用制作，名稱自動識別頁面名稱展示。

頁面流程的頁面與頁面名稱：頁面采用引用自動識別對應(yīng)原型展示，頁面名稱采用引用自動識別頁面名稱展。

通過以上幾個小應(yīng)用可以做到方便后續(xù)修改時，不需要做過多的重復(fù)命名工作，只需修改左側(cè)樹結(jié)構(gòu)的頁面名稱，所有相關(guān)頁面都會同步修改名稱，而且當我們需要在頁面名稱上備注此頁面（修改）時，在其他環(huán)節(jié)也會展示，相當方便。

不過在前面的制作時就要按方法執(zhí)行，避免后續(xù)為調(diào)整修改名稱，工作量大且容易忽略，導(dǎo)致名稱不對應(yīng)。

4.4.2 更新修改

當文檔進行修改或更新時要做哪些動作：

1、更新日志添加

按照修改時間、屬性、描述、修改人進行添加，當同一天更新比較多時（修改了需求），此時可以按照調(diào)整模塊拆分成多條來添加

2、添加目錄與頁面?zhèn)渥?

在交互說明對應(yīng)的流程目錄上添加更新備注，時間+更新

在頁面名稱后加上（新增）或（修改）

3、添加頁面流程標記

頁面流程中的標記，根據(jù)所做的修改部分進行標記

為了方便大家在頁面流程中的標記，我將標記修改進行了組件化：多頁面修改標記、注釋調(diào)整標記、單頁面局部標記、刪除隱藏標記

這邊我舉個例子，方便大家對標記實操的理解。當我修改了登錄頁面的一鍵登錄頁面和注釋描述時。

五、瀏覽閱讀

借助原型托管工具：這邊我采用了阿里云 oss 上傳。主要是考慮瀏覽速度的因素，藍湖大文檔的原型托管會卡。當然你也可以選擇 Axhub 或藍湖以及其他托管平臺都可以實現(xiàn)將 Axure 生成的 html 進行上傳。

文章來源：優(yōu)設(shè)   作者：時光若刻

藍藍設(shè)計( www.cqzjtgb.com )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標定制 、 用戶體驗 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)