文章內容

網站設計：Web流程圖的繪畫指南

發布時間: 2012/9/13 15:08:34

在作者設計生涯開始的早期，就開始接觸流程圖。一個好的流程圖，可以用來理解需求、解析復雜的業務流程、同時也有助于交互設計。

　　為了使流程圖的價值最大化，文中著重分析了開始和結束標記、界面、對話框、決策點、條件分支、子流程、跳轉點、描述、系統行為等視覺詞匯。

　　前言

　　在我設計生涯的早期，我就開始繪制流程圖了。剛開始的時候，我所繪制的流程圖大都比較簡單，圖中的節點不多，邏輯也是直截了當的。因此，一直到我加入支付寶-中國最大的線上支付平臺，我才意識到復雜的流程圖的用處巨大。在支付寶，業務需求和流程之復雜、變化之迅速，使得理解它們本身已經是一件非常有挑戰性的工作。正是此時，我開始依靠流程圖來理解需求，并使用這一方法來做交互設計。漸漸地，流程圖顯現它的魅力：產品經理喜歡它，連工程師也用它來指導開發。

　　2008年秋天，我將自己的經驗總結為一篇題為《畫Web流程圖的一點心得》的文章，發表在自己的blog上。該文立即引起了廣泛的注意。各種推薦、轉載、討論和跟進的文章在線上線下都頻頻出現，甚至有人按照我在文章中提到的方法制作了一套流程圖模板。時至今日，這篇發表于四年前的文章仍然給我的個人主頁帶來不少流量。

　　然而，上述文章有一個比較嚴重的問題，使得其內容帶有誤導性：它并沒有使用用于“描述信息架構和交互設計”的《視覺詞匯表》。坦白講，寫作的時候我并沒有注意到有這樣一份廣為人知的詞匯表存在，而是創建了我自己的詞匯，并將其介紹給大眾。因此，文章的部分內容沒有遵循慣例，從DRY(Don’t Repeat Yourself，不要重復自己)的角度講這并不是很合適。該文發表一年后，我的確在另一篇文章中指出了這一問題，但遺憾地是這次沒能像上次一樣引起廣泛的注意。

　　此外，距離該文章發表已經有幾年過去了，我又積累了不少新的經驗和想法，希望分享給大家，特別是英文讀者們。

　　因此現在如你所見，我完成了英文版、帶有最新內容的《畫Web流程圖的一點心得》，并且提供了自制的配套模版下載。

　　內容概要

　　本文涵蓋了你應該了解的關于Web流程圖的最重要的幾條準則：

　　基本思路

　　視覺詞匯表

　　范例

　　建議和提示

　　工具和模版

　　1.基本思路

　　什么是流程圖?

　　流程圖，顧名思義，是用來描述某個系統在不同的情況下，如何應對用戶的狀態、決定和行為的圖。

　　流程圖能給你什么樣的幫助?

　　通常，對于任何希望創建流程的人來說，無論創建的是什么用的流程，流程圖都是很有用的。比如工廠可以用流程圖來告知其員工，當有人受傷后正確的急救流程是什么。當然除此以外，在本文中，我只會舉關于Web設計流程圖的例子。

　　對交互設計師和產品經理來說，流程圖是一個核心的工具。它可以幫你：

　　設計你產品的交互流程

　　確保的你的產品在任何時候都是友好的(甚至包括你原來根本未曾考慮過的故障發生時)

　　幫助你整合零散的線框圖

　　幫助你與不同背景的同事進行溝通：比如引導工程師開發

　　2.視覺詞匯

　　接下來的幾頁中，我將介紹視覺詞匯和它們的使用方式：

　　起點和終點

　　界面

　　對話框

　　決策點

　　條件分支

　　子流程

　　跳轉點

　　描述

　　系統行為

　　起點和終點

　　起點和終點是用來標識交互的開端和結束的地方，任何流程圖都必須有且只有一個起點和至少一個終點。

　　界面

　　界面元素被用來表現各種用戶界面，比如窗體或網頁。界面的編號可以用來做識別符，在協作過程中會非常有用。比如在開電話會議時，你可以用 “節點N”來表達你想指明的某個界面元素。

　　不僅如此，設計師也可以采用此規則為線框圖命名。比如“23.png” 線框圖與23號界面對應。這大大節省了文檔的閱讀者-比如工程師-找尋對應線框圖的時間。

　　對話框

　　隨著Web應用的問世，Web交互也從線性模式向基于狀態的模式轉換。局部頁面更新和單頁面內交互也越來越普遍，最常見的形式之一就是浮動消息，例如表單驗證錯誤后出現的錯誤提示。然而，做兩個幾乎相同的線框圖不僅沒必要，甚至很別扭。所以，對于這種由Javascript渲染出來的模態或非模態對話框，我特別創造了一種叫做“對話框”的新元素。

　　Note1：我的朋友曹曉剛(@caoxg)，一名資深技術人和企業家，用UML(Unified Modeling Language,統一建模語言)狀態機來描述Web應用中的狀態，以及這些狀態之間的轉換。我在想辦法將這個狀態機轉變成一個更簡單、更適合設計師的圖示。

　　Note2：如果你設計的不是Web應用(具體地說，不是那種看起來像桌面應用卻運行在瀏覽器上的)，我建議你不要依賴Javascript，甚至不要用它。具體的原因當然是題外話，我也就不在此詳細描述。如果你想要答案并了解我的“JapMag”設計語言，請訪問：http://dingyu.me/portfolios/dingyu-me。

　　決策點

　　決策點指用戶需要做出決策的地方，通常流程走到這，界面都在等待用戶做出下一步去哪的選擇。

　　如圖所示，通常我會讓正面的選擇(“Yes”)向下流動，而負面的選擇(“No”)指向右側。

　　這條規則能提供更佳的閱讀體驗，因為規則本身是很清楚且自然的(英文的寫法也是如此)。

　　這條規則還可以幫助設計師策劃流程圖：流程圖的主線居左，至上而下流動，而分支在右側，這樣整個流程圖結構就自然而然地從左到右、由上至下了。

　　注：實際上，我曾讀過美國前總統Geoge W.Bush的自傳“Decision Points”(中譯本為《抉擇時刻》)。因此，撰寫本頁總讓我想起這本書。

　　條件分支

　　條件分支看上去和決策點比較類似，但它們完成的是截然不同的功能：在決策點中，決策是由用戶明確做出的;而對于條件分支，則是由系統于后臺自動選擇合適的路徑。

　　子流程

　　子流程是相對獨立、在整個系統內都能夠被重用的流程。例如，你可以將一些相同的(會被頻繁使用的)任務-比如用戶驗證和接入網絡等-打包成子流程，然后將它們集成到更大或特定的流程圖中。

　　如果你的流程圖包含子流程，那么在別人問你要之前，你最好將相關的所有子流程圖也一并提交。

　　跳轉點

　　在有些高度復雜的情況中，我們需要用戶直接跳轉到另一條路徑，這時就需要跳轉點。

　　和之前所說的一樣，圓圈里的數字指向某個節點，這個節點便是該跳轉點將引向的節點。

　　顯然，跳轉點是某條路徑的終點。

　　描述

　　描述是節約溝通時間的一種便捷的方法。不過別理解錯誤，你仍需要以各種形式和你流程圖的讀者交流，只是描述因為能起到備忘和提示的作用，依照我的經驗，這的確會節省很多時間。

　　系統行為

　　系統行為是指系統完成的一系列后臺行為操作。例如，我們想要記錄用戶登錄失敗時的數據，就可以在流程圖中以 “收集錯誤日志”的系統行為來表示。

　　作為設計師或產品經理，我們雖然不需要將每種后臺操作都付之于圖，但我們還是有必要把那些和用戶體驗相關，或那些對我們重要的操作放進流程圖，此外還要寫入規范或文檔里，再次清晰地聲明，確保每個人都能領略其義。

　　元素總結

　　3.范例

　　登錄

　　下圖為一個簡易登錄流程圖，用來描述用戶登錄時系統如何反應：

　　安全檢查

　　以下流程圖展示如何使用系統行為和子流程這樣的元素。它來自于真實的項目，只是由于版權問題已被我稍稍修改。

　　其它真實范例

　　如你所見，不管業務邏輯多么復雜，流程圖都能用來描述系統是如何工作的。

　　4.建議和提示

　　基于調查結果，指引線框圖

　　用戶和他們的特點是指導繪制流程圖的首要因素。用戶調查能夠發現：用戶過去的體驗是什么?用戶的期望是什么?使用場景和環境是什么?這些問題在流程圖的設計中起關鍵作用。

　　同樣，流程圖對線框圖的制作也有指導作用。多數時候，一旦流程圖完工，線框圖的內容甚至布局已經基本確定了。當然了，這也正是流程圖的目的所在：連接線框圖。

　　Note：在流程圖之前我們會有如用例這樣的其它交付物。上圖并沒有涉及到這些內容，因為這并非本頁的重點。

　　使你的流程圖完整

　　制作流程圖最難的是，它必須囊括所有可能的情況，在我看來，這一點在應對復雜邏輯的商業需求時是很有挑戰性的。你將會遇到很多類似 “要是如何便會怎樣”的問題，并且有時候直到工程師告訴你，你才意識到自己之前欠缺考慮!所以，制作完整的流程圖不僅需要你了解用戶，還需要你懂業務邏輯，甚至要熟悉幕后的系統運作機制!

　　最好的辦法是和產品經理、工程師還有其他和商業需求有關的同事在工作中緊密協作。我見過不少交互設計師悶頭一人工作，然后在產品會議中遇到猛烈的挑戰。別再那樣了!相反，和項目相關的人合作，一起制作流程圖(以及其它交付物)，從不同角度排除不確定性，使它更完整全面(這樣也沒人會再挑戰你了，因為他們每個人也是參與制作的一份子)。

　　別忘記元數據