傳達使用者體驗的 Wireframe 技巧

Published in

Flow話不完

8 min readJul 15, 2020

UX 工作上最常接觸到也最基本的就是 Wireframe 的撰寫，在不同情況下會需要運用文件來溝通，也會有需要留意的設計原則。筆者在設計顧問公司擔任 UX Designer 三年多，累積了一些專案經驗，最近聽到不同設計師在工作上有遇到一些疑問，因此想試著將自己的設計經驗文字化。

從 A-ha! 到產品，具體先看 Wireframe

雖然在不同組織分工的狀況會有所不同，但設計師通常是產品團隊的一份子，從設計師的角色來說，拿到設計需求（專案計畫）後就會進入設計流程。良好的執行這個流程，可以讓專案推進得很順利。我剛進入業界時，經常提醒自己要按照步驟釐清需求、執行設計，但是到了設計顧問公司之後，卻發現事情總是不按預期的來。

最困難的情況大概是，來自不同 Stakeholder 的想法都還在空中飄，我們要想辦法將這些訊息搜集起來，整理專案重點、使用者需求，甚至列出功能，將專案初步落地。尤其是業務規則越瑣碎，使用者旅程越複雜時，不確定因素越高。不管是太空泛的討論或太快進入設計細節的確認，都有可能造成一再重工的現象。

這時就恰好需要由設計師先行多想一步（讓設計發揮更大的效用），先用最有效率的方式產出 Wireframe，用每個人都看得懂的方式，確實的討論設計概念，有效的幫助專案進行。假設專案有做前期研究、使用者旅程或是測試，Wireframe 也是最能轉化各項洞察、呈現資訊架構、解釋流程的關鍵。

依需求模糊的程度決定 Wireframe 的重心

01 以關鍵畫面快速確認設計方向

在專案比較前期的階段，需求還很模糊，有可能就只收到寥寥數頁的簡報資料，這時問題都還沒定義下來，設計方向當然就還會有很多可能性，設計師必須憑藉競品分析及使用者洞察將體驗勾勒出來，整理出可能的設計方向。以 2018年經手過的報稅 App 概念提案為例，就針對新手與老鳥分別提出「年度回顧」及「按部就班」的兩種截然不同的概念。

這個階段的 Wireframe 不需要撰寫詳細的操作互動規則，只是要掌握影響使用體驗的「關鍵畫面」，跟大致上體驗的流程，以呈現清楚的設計方向為目標。這不代表設計可以草率或簡略，反而也需要藉由研究洞察，將需求轉化為清楚的資訊結構、白話的指示及標籤，讓使用者一看就知道整個服務/功能的好處是什麼，每一頁/每一屏的關鍵是哪些，要去哪裡完成自己想做的事。重點是，把自己最好的設計解法勾勒出來，拿出來跟同事、客戶及使用者討論，有時甚至會直接製作 Prototype 測試，最後以能夠決定一個設計方向/版本為目標。

02 以完整流程確認業務邏輯及系統限制

當要解決的問題已經足夠明確，剩下需要處理的就是所有能拿到的業務邏輯及系統限制。這時的 Wireframe 就會需要兼顧正負向流程、可能發生的所有狀態，以及描述所有操作互動的反饋，撰寫起來會花上更多時間去寫附註，也會花更多時間跟客戶及開發者往返確認修正細節。

這個階段 Wireframe 的正確性及全面性是相當重要的。設計師透過 Wireframe 確保使用者在遇到不熟悉（說難聽一點就是有點奇怪）的業務邏輯時，仍能夠順利地完成目標任務；而 PM 及工程師會就 Wireframe 為基礎再去分派工作、撰寫更多邏輯文件。順利的話，一個好的產品/功能就可以被開發出來了。

理解及分析資訊，打好體驗基礎

在專案剛開始的時候，設計師可能都還不了解自己要設計的內容，畢竟不管是金融、醫療或運輸業，每個領域所推出的產品，可能都有複雜的規範與設計。但是 UX 設計師就像是資訊的把關者，要幫使用者把看不懂的說明書轉換為懶人包，也要明確整理出使用者開啟產品/進入產品頁面時，會有哪些行為目的。Wireframe 如果沒有幫忙將資訊做基本的整理確認，那就會像地基沒有打穩一樣，進入 UI 設計之後就會產生大問題。

01 從手繪草圖開始

為什麼要從手繪開始？手繪最能夠即時記錄自己的想法。因為消化資訊的過程中會有大大小小的點子，最先畫出來的想法，就有可能是預期中最重要的亮點。手繪草圖也有個好處，就是可以先看到大致上的輪廓，而不會在那邊微調 1 px、2px，浪費時間。越快發現想法不對，就可以越快修改。

02 切分體驗目的，決定架構

想想使用者在產品裡試圖完成什麼事/目標。比如說購買保險產品，他怎麼開始瀏覽、比較產品內容，再進行試算，最後決定購買並收到購買明細。這個簡單的需求本身就包含了不同性質的資訊及互動。在不同階段裡，使用者在意的點可能不同。UX 設計師先分析了使用者的行為，再去決定產品的架構，就可以有效打理好設計基礎。

03 運用設計系統打造一致性

Wireframe 需反應使用者與產品互動的旅程，而不是單一畫面的資訊排版，在這個過程中，要確保產品有前後一致的互動方式。UX 設計師需要建立一套基本的設計系統，定義什麼情境下運用什麼元件，並運用在 Wireframe 之中。這件事情不難。如果是從無到有的產品，則可以參考現有的 design system，如 Material Design, Bootstrap Component 等等，再依產品特殊性質去變化；如果是長期維運的產品本身就會有一套慣用的設計系統，反而需要斟酌哪些時候要打破系統創造更好的體驗。

04 檢查使用者旅程，抓出漏洞

常常覺得設計師是不是麻煩製造者，看完需求後想想使用者旅程，就會發現很多疑點跟漏網之魚。但寫完 Wireframe 也一樣，需要從頭再審視一遍流程，最好再抓幾位同事幫忙測試。如果遇到邏輯複雜的情況，則是有可能意外讓使用者掉入洞裡。把每個狀態都想清楚了是 UX 設計師的基本功。

05 有些東西進 UI 再想就好了！

在畫 Wireframe 的時候，為了要清楚呈現資訊細節，UX 設計師對結構的掌握能力也要很強，清楚知道每一個 component 的表現意圖及用法，所以 Wireframe 呈現也會相當精細。但是資訊呈現就如同整體體驗的設計概念一樣，不一定只有一種呈現手法，加入視覺元素後能夠發揮的空間還是相當大，因此 UX 設計師在繪製 Wireframe 的時候必須理解，過度雕琢一個 icon 、按鈕，甚至是頁面區塊的呈現樣式(Style)，其實是不必要的，單看畫面能夠清楚傳達意涵即可。

選擇最有效的呈現形式

根據不同專案的性質及客戶需求，設計師可以與客戶協商交付 Wireframe 的形式。依結構化的程度分為 Wireflow、Wireframe 文件及 Prototype 三種。

01 Wireflow

我自己經驗上最常交付的樣式是一大張的 Wireflow，把頁面線框圖及 flowchart 都整理在一起，可以有效溝通複雜的互動行為，也可以一次看到所有情境，系統性的討論正負向流程，避免遺漏特定狀態。

02 Wireframe document

另一種比較公規的交付形式則是會有目次表，依內容及頁面結構分章節，依序交代網站/App 架構、User Flow 或 Flow Chart，以及分門別類的頁面線框圖說明，寫起來像一本手冊。這種 Wireframe 文件的優點是閱讀起來較符合一般文件閱讀的順序，要討論特定內容時相當方便。

03 Prototype

在頁面互動較單純的情況下，有時也會直接提供頁面線框圖的 Html 頁面（用設計稿快速製作的 Lo-fi Prototype）來快速確認頁面結構及文案。

結語

Wireframe是溝通用的工具，刪刪改改很常見。有時候需求丟過來就是模糊不清的，利用 Wireframe 協助客戶釐清需求，確認有哪些問題還沒搞清楚，就是他最重要的貢獻。本文整理了三項有效傳達使用者體驗的 Wireframe 技巧：依需求模糊的程度決定 Wireframe 的重心、分析資訊打好體驗基礎，以及選擇最有效的呈現形式，根據自身經驗總結而來，希望大家看完有收穫。如果有任何建議或疑問，也歡迎留言給我，讓我有機會改進，謝謝！