解讀交互稿模板:如何讓設計稿更規範化?

交互稿應該包含哪些內容？如何搭建一個合理的交互稿結構？

PS：本文適用於移動端，Axure軟體製作的文檔型交互稿。

• 交互稿應該包含哪些內容？
• 如何搭建一個合理的交互稿結構？
• 各個界面應該如何擺放？
• 清晰易讀的設計說明應該是怎樣的？

想必作為一個新人，很難完全弄清上面的問題。其實想要畫出一份合乎規範的交互稿並不難，只需找前輩的稿子參考一下就能習得十之六七。但由於設計稿大多涉及企業機密，有著較強的產權屬性，所以一般很難接觸到。

今天筆者將通過「解讀一份交互稿模板」的方式，解決上面的幾個問題。

1. 交互稿應該包含哪些內容？

交互稿是否只需包含設計方案即可？其實不然。交互稿兼具設計展示、上下遊協作、過程記錄、版本管理幾種作用，所以交互稿一般至少具有以下幾個部分的內容：

1. 封面：用於記錄版本號、人員、時間等信息；
2. 更新日誌：記錄了交互稿更新的信息，方便他人查看，同時也保障了規範性；
3. 設計過程：包含需求信息、設計資料記錄、設計過程記錄三方面信息，目的是讓自己的設計過程更加結構化，也方便以後回溯設計、總結設計；
4. 交互稿：交互稿的主體，內含流程圖、界面圖、設計說明等；
5. 廢紙簍：用於存放廢棄的頁面，以防後期用到；

2. 如何組織交互稿結構？

2.1. 交互稿結構依賴於產品信息架構

首先需要說明的是，「把所有界面放在一個畫布上的無結構式交互稿」一定是不對的，這是很多新人經常會犯的錯誤。因為這種做法無法適應大型稿件，而且開發同學在錯綜複雜的網狀設計稿中找信息，也是著實辛苦。

交互稿的結構，應該根據產品信息架構搭建。比如下圖是網易雲音樂「本地音樂」模塊的信息架構和交互稿目錄，由產品信息架構可以推導出交互稿目錄。可以發現這種一一對應的交互稿目錄結構，非常清晰易懂。

網易雲音樂「本地音樂」模塊

2.2. 交互稿結構原理

交互稿結構應當遵循「平臺–頁面–子頁面」這樣的原則（下圖，這裡說的頁面不是界面，而是指「一頁交互稿」）。每一個頁面中承載的對象有2種，一種是單界面，另一種是界面流程（後文解釋）。

交互稿結構原則

我們舉個例子，假設有一個「簡版的網易新聞」，那麼它的結構可能是下圖這樣的：

交互稿結構示例

什麼是「單界面」、「界面流程」？單界面相對容易理解，比如上圖中的「首頁」，就只需要在交互稿的這一頁中放置一張「首頁」的線框圖即可，也就是所謂的「單界面」。那麼界面流程是什麼呢？其實就是多個界面的串聯圖（如下圖所示）

界面流程

什麼情況下需要使用「流程界面」呢？所有APP都由界面組成，而界面上的元素可以歸為3類：內容、入口、功能。「界面流程」一般用來闡述一項「功能」。究其原因，功能與內容和入口都不同，功能一般需要「一連串操作」，比如登錄功能、搜索功能。此時我們再看上面的案例，就會很容易理解了。

3. 每一頁交互稿應該是怎樣的？

3.1. 每頁交互稿的內容

一般而言，每一頁交互稿應當具備以下幾項內容：

單頁交互稿示例

1. 頁面標題：建議使用「固定在瀏覽器頂部」功能讓頁面標題常駐；
2. 界面標題：方便交互稿中的互相索引，比如「回到界面B狀態」；
3. 界面：建議尺寸為360*640px，長頁面也可自行延伸高度；
4. 設計說明：邏輯關係、元素狀態、小微流程，都可以放在設計說明中；
5. 流程線：說明界面間邏輯關係，可使用軟體自帶流程線；
6. 連結：指向其他頁面，比如支線流程，開發同學閱讀起來會很方便；
7. 作者信息：這是設計師的落款，同時也方便他人聯繫設計師；

3.2. 網格系統的應用

確定了頁面內容後，內容的布局也很重要。布局不好就會顯得亂糟糟的，怎麼處理布局問題呢？筆者提供一個「網格系統」（下圖），可以讓設計稿很有「秩序感」。具體而言，在Axure的「布局-柵格與輔助線-網格設置」中設置間距為40px的網格（40px是常見界面尺寸320、360、640、1080…的公約數），然後儘量保證所有的元素貼齊網格即可。使用後你會發現自己的交互稿變得盡然有序，且美觀很多。

帶有網格系統的交互稿

網格的另外一個優點是可以很高效地對齊各個元素，如下面視頻所示：

藉助網格快速對齊元素

3.3. 每頁只展示一條流程

每個交互稿頁面應當最多承載一條「流程界面」，多出的流程可以新開子頁面。從而保障每一頁交互稿都是點狀或者線狀的，而不是網狀的，因為網狀的交互稿很難閱讀，閱讀者需要縱橫雙向滾動屏幕尋找信息（下圖是反例）。

網狀的界面結構很難閱讀

4. 清晰易讀的設計說明

設計說明是向開發同學傳遞設計信息的重要存在，如果設計說明位置雜亂、對應關係不好、可讀性差，很容易讓開發同學「不太想看」（很常見），最終造成設計還原度底，溝通成本增高等問題。

設計說明示例

一個較好的設計說明應當遵循以下幾點原則：

1. 位置統一：在筆者提供的交互稿模板中，所有設計說明均在界面下方；
2. 對應關係明確：須在界面上打標誌點（上圖綠點），與每一條設計說明一一對應；
3. 提供標題：標題可以大大提高開發同學的閱讀效率和視覺搜索效率；
4. 規整：多條設計說明的排布應當規整有序，使用上文中提到的網格可以很容易達到這一點；
5. 接近界面：因為設計說明是針對界面的解釋，所以不能離界面太遠，不然很難對著界面看說明。如果設計說明實在太多，可以採用動態面板的方式承載（交互稿模板附件中有示範）；

5. 最後幾個有用的提示

最後，補充幾點筆者認為很重要的提示：

1. 大部分開發同學都有一種「不想仔細看交互稿」的傾向，其中大部分原因是交互稿可讀性不好；
2. 交互稿是「工程圖紙」，不是「設計草圖」，所以信息交代得越詳細越好，越精確越好；
3. 每次更新交互稿，都應該在「更新日誌」裡寫明，並在頁面中也標誌出更新的地方。否則會給開發和QA同學帶去極大的麻煩；
4. 儘量不要頻繁更新交互稿，會給人一種「不專業」的印象，且會給自己養成壞習慣；
5. 字體使用PingFang SC-Regular和PingFang SC-Semibold，實測兼容性最好，要知道大部分開發同學都只有系統默認字體；

 

作者： 崇書慶/Seeking，UEDC互動設計師

本文來源於人人都是產品經理合作媒體@網易UEDC，作者@崇書慶

題圖來自 Pexels，基於 CC0 協議

收藏已收藏 | {{ postmeta.bookmark }} 點讚已贊 | {{ postmeta.postlike }}