Flowcharts 幫助你整理出好設計
花五分鐘讓你的 Flowcharts 更好讀，還精進你的 UX 設計邏輯力＆溝通力
前言
我在之前的文章「傳達使用者體驗的 Wireframe 技巧」裡，快速整理了三項有效傳達使用者體驗的 Wireframe 技巧：依需求模糊的程度決定 Wireframe 的重心、分析資訊打好體驗基礎，以及選擇最有效的呈現形式。但是其實設計師在開始進入 Wireframe 設計前，是需要先做好準備的。接下來的內容，就幫你整理了讓 Flowcharts 更好讀、更好用的心法，不只讓你辛辛苦苦寫出來的文件不會白費，還幫你更有系統性的整理設計流程。
重申：為什麼你需要畫 Flowcharts？
假設看過客戶寄來的設計需求，羅列各項初步構想的業務邏輯，但其中隱藏很多細節尚待你去梳理。問題來了，要怎麼準確抓出尚待討論的議題？要怎麼快速整理那些業務規則跟系統限制？這份需求又需要花多久的時間來進行設計？要出多少個頁面？
整理 Flowcharts（或者類似的 User flow/Task flow，想一步瞭解差異可看這篇文章） 就如同幫一本書整理目錄，讓你在進入畫面設計前先做個整體盤點。好的盤點可以幫你釐清思緒、整理問題、節省設計時間，還可以幫你應付 PM 或 Lead 快速擬訂合理的交付時間。你還可以因應不同類型的設計需求，將 Flowcharts 與 Sitemap 或其他資訊架構圖合併一起研究。
一句話講完畫 Flowchart 的基本技巧
Flowcharts 的特色在於納入了系統判斷條件，針對使用者的 input （輸入條件）會因為不同狀況產出不同 output（回饋）的情況來描述。
畫 Flowcharts 最重要的就是運用鑽石型的「條件判斷式」來幫你整理比較複雜的互動。一個頁面進入條件判斷後，最多可以有三種不同的結果（通常為兩個結果：是/否，但也會有例外狀況）。你可以從決定 Flowcharts 的起點開始，進一步構思流程中會發生哪些狀況，以及最後使用者會抵達哪些結果畫面。
三個進階技巧讓 Flowchart 幫你產出好設計
01 注意流程方向性
你的整體流程會向右方還是向下方延伸？請選一個。一個好懂的流程，即使他再複雜，大迴圈之中又有好幾個小迴圈，也都要釐清主流程及次流程的分別，讓人一眼看懂主幹及支線，才能快速抓到使用者的主要目的，也就是能完成任務的最短路徑。
我推薦保持主要流程在一個向右延伸的路徑上，讓支線向上或向下發展。一路走到底就是任務成功，中途 drop 掉就是任務失敗，或者進入特定情境甚至另一個流程。這樣的寫法可以讓你的 Flowchart 保持在非常乾淨的狀態，讓你能夠快速看出哪些頁面要營造流暢的體驗，哪些頁面要處理使用者的情緒或疑問，甚至幫你判斷隱藏的斷點，順便設計系統性的回饋提示或頁面。
假設你不幸地遇到需求比較複雜的情況，「確保主要流程的方向性」就可以幫你快速整理出好讀易懂的 Flowcharts。以金融業為例，如果使用者目的都是申辦相同的產品，但要讓卡友走 A 流程、本行存戶走 B 流程，就有可能會有兩段主要流程。你可能要確保在這兩個主要流程中：
- 你的溝通方式(Tone and manner)都是一致的
- 是否會有類似的系統判斷點或存點
- 有哪些頁面可以共用
在 Flowcharts 裡列出兩個主要的流程，再梳理支線流程，就可以快速幫上你的忙。當然，如果遇到某些狀況，讓你覺得要保持流程在一條線上有點困難。記住，你的最終目的，是要能夠在複雜的流程圖中一眼看出主線任務，其他寫法都可自由發揮。
02 將複雜流程結構化
延續第一點「注意流程方向性」之後，你可以做的第二件事就是把 Flowcharts 結構化。我常遇到的狀況是，一份 Flowcharts 所涵括的內容太多且複雜，如果不結構化，要找到特定頁面就很麻煩。尤其產出的是結合 Wireframe 及 Flowchart 特性的 Wireflow，那問題就大了。沒有結構化的 Wireflow 或 Flowcharts 很容易把人繞暈，迷失在頁面裡。
要怎麼做結構化呢？通常一份文件中，不論是 APP 還是 Web，都會用固定的寬度來做設計，所以我推薦用向右延伸的方式來繪製的 Flow，並去控制每個頁面/判斷式的間距，將同一個步驟的不同狀態/相關頁面歸為同一個群組，並以清晰的步驟名稱來作為此段落的標題。用這個方法，你的 Flowcharts 就會有好幾個清楚的段落，更容易尋找關鍵畫面。
更進階的做法還有加入資訊架構的概念，你可以延伸出好幾個上下層級，以樹狀結構向右整理。比如說會員登入流程、忘記密碼流程、查詢帳號流程都在同一份文件裡，讓他們起點都在會員登入頁，你就可以向下依序分為三列向右延伸的主要流程。
除此之外，你還可以運用 Service Blueprints 的泳道概念，整理可能會在不同接觸點/人員完成的步驟。這個整理方式幫你釐清頁面會接觸到哪些系統、區分哪些步驟會在線下或後台完成，不僅提供你更多設計脈絡，還可以順帶更了解服務及系統的運作方式，對於 UI/UX 設計新手來說是很好的練習。
03 簡化判斷式
最後也是最重要的，經過了這麼多系統性的邏輯整理，就算是 UI/UX 設計師也會遇到盲點！所以一定要回頭再檢視所有的邏輯判斷式，有沒有哪幾個判斷點其實是可以合併的？盡量去幫使用者找捷徑。
舉個例子，使用者點選活動網頁的「參加抽獎」按鈕前往抽獎，抽獎之前，使用者要滿足已註冊 App 帳號，且已加 Line 官方帳號的條件，兩者都有完成才能夠參加抽獎。這個流程看起來像是有兩個判斷式，來判斷帳號是否註冊、是否加 Line，但其實兩個判斷會同時進行，讓既沒有註冊且沒有加 Line 帳號的使用者，可以一次看到兩個條件的提醒。
如果有很多判斷式會在進入目標頁面前發生，就應該思考這些判斷式的先後關係，有沒有可能同時判斷多個條件。
用 Flowcharts 整理你的系統性 Mindset
最後提點一下，Flowcharts 不是一個要被發表的成果，他只是一個溝通的媒介。我還是新手的時候，也曾認真跟 PM 及開發人員們對著 Flowcharts 講解流程，結果發現大家看了都沒感覺，等到看畫面時大家才開始認真討論。仔細想想也是人之常情，除了畫圖的設計師，團隊其他人很難看著 Flowcharts 就跟畫面連結起來。
所以設計師其實不需要解釋 Flowchart，應該說 Flowchart 是幫設計師更貼近開發者思考的工具，是設計師理解系統邏輯，而從使用者角度繪製的理想架構，真正的開發文件工程師們還是會自己來寫。
我自己的經驗是，用 Wireframe 或 Wireflow 跟團隊討論，可以讓團隊比較有情境、有脈絡，但設計師自己腦袋裡一定要先有大概的 Flowcharts 輪廓，這樣 Wireframe 才不會變得太過冗長、找不出系統性邏輯。而如果設計師有空把 Flowcharts 維護並時時更新，請附在 Wireframe 的前面當作目錄，讓團隊成員可以隨時參照檢閱。
結語
希望根據個人工作經驗所整理的一些 Flowcharts 小技巧跟概念，可以提供你一些有趣的觀點，甚至幫助你的設計更上一層樓。如果對於寫出更有效溝通的 Wireframe 有一點興趣，你還可以看看這一系列的上一篇文章「傳達使用者體驗的 Wireframe 技巧」，那我們下次再見囉！
