當我決定想以最容易理解的方式來寫一篇關於UX設計流程的文章時，我注意到了一個嚴重的問題——有的時候設計過程不符合一條單一的邏輯流線。 但是同一個工具怎麼會同時有用卻又難以理解呢？ 所以我閱讀了更多相關的內容，我開始慢慢理解。 在本文中，我將討論從“流程圖”到“使用者流”的許多不同型別的視覺化圖表之間的區別，也借這個機會淺談為什麼它會被這麼多人誤解。

開始之前，我想先說明“流”（flow)這個術語在文中用來表示具有某種順序或方向的圖表。 在文章中，我會解釋這些不同的圖表分別是什麼以及它們之間的區別，同時，也會提出如何更好地使用這些術語提出建議。 文章中的每個小節都是直接從教程或相關文章中篩選的，並且會加以說明（也都附上了源連結）。

 

主要流程

流程圖

1-“表示執行流程所需的步驟和決策順序的視覺表達。”

2-“表示工作流，流程或演算法的圖表型別。”

至少就其定義而言，流程圖是一種相對簡單的圖表。 當你想要表達一個完整的產品體驗或其中的某一部分的時候，流程圖是個很有用的工具。 流程圖通常是容易識別的，因為製作過程中，大家會普遍使用UML（統一建模語言）來繪製流程圖。其中橢圓形表示流程的開始和結束，菱形表示決策點（請參見下圖）。

帶有UML解釋的流程圖

 

除開UX之外，流程圖被廣泛運用在許多其他的領域。 所以，有時人們會使用一些花哨的術語，例如“業務邏輯流線圖”。 但是在我看來，術語的使用是為了強調流程圖本身的功能。 因此，如果你稱之為“使用者流程圖”，說明本圖是基於使用者角度的，而“業務流程圖”顯然專注於業務。除此之外，我認為應該儘量減少術語的使用。

 

流程圖示例

 

 

任務流

1 —“以流程圖的方式視覺化各個參與者的詳細步驟和中間的互動。”

2 —“視覺化使用者在執行特定任務時的流程。 當完成對應的任務對於大多數使用者來講會產生相同的執行流程時（比如共享一個公共入口點），任務流比使用者流（user flow)更合適。”

3 — “與使用者流相似。不同之處在於使用者流通常是單線性的，不會有多個分支或選項路徑”

4 — “針對所有的使用者完成同一個流程的特定操作。”

從定義中，我們可以看到任務流與使用者流是很相似的。 最大的區別似乎在於任務流所涵蓋的範圍通常很小且是單線性的。 任務流通常會假定使用者完成某個任務的方式不會產生變化和分歧（例如，註冊，登入，重置密碼）。

 

任務流 #1

 

到目前為止的內容看起來都是簡單明瞭的。

 

任務流 #2

 

線框流

1-“一種規範的設計格式，將線框圖與互動流程圖結合在一起的簡化佈局”

2-“螢幕流程的視覺表達，相關的線框組合按照它們在流程中會出現的順序排列。”

這是Nielsen＆Norman Group最近的一項發明，該發明實質上採用了向任務流中新增線框的想法，實現了有效記錄複雜應用程式的流程。 順便提一句，線框是低保真（即不是很詳細）原型。線框會使用佔位元件來填充頁面空白，而不是像高保真那樣直接製作出使用者在最終產品中實際看到的效果。 下圖會展示線框和線框流之間的區別。

 

線框（左）和線框流＃1（右）

但是，看上去“任務流程1”中包括線框，不是嗎？ 現在定義好像沒有上一節裡的簡單明瞭。 實際上，線框流（Wire Flows）的保真度實際上會有很大的不同，這也是為什麼有的時候線上框流當中會出現螢幕上的相對更詳細的介面設計。

線框流＃2（左）和線框流＃3（右）

 

 

使用者流

1-“使用者完成應用程式或網站中某個特定動作所需的一系列步驟”

2-“使用者在使用應用程式，網站或網站時可以遵循的實現某個特定動作過程的視覺化表達。”

3-“使用者完成特定任務所需採取的步驟（包括互動作用）的可視流程圖。”

加上這些定義，現在看起來好像變得更復雜了，現在想一想，任務流程的定義又是什麼……？ 因為這些定義似乎都是關於完成任務的工作流的。 但是實際的情況也許又有不同，比如這張圖片：

使用者流 #1

該圖顯然可以被稱為“任務流”，因為它顯然是符合我們對任務流的定義的。 但是，同時它也是一系列連續的線框……那這不是線框流嗎？

 

使用者流 #2

 

看了上面這個例子，定義的邊界變得模糊起來了。 例如，使用者流#2不僅具有線框，而且還具有類似於流程圖中的的UML元素，這與使用者流#1完全不同。 然後，還有一些情況，甚至都沒有使用UML或上述任何表達方式的例子，比如使用者流＃3中使用的相同節點形狀（在本例中為矩形）卻又是在傳達複雜的任務網路。

 

使用者流 #3

 

一次偶然我發了（與使用者流＃1同源）一個很好的示例，它具體地說明了如何區分流程圖的主要型別，如下圖所示：

使用者流 #4

 

唯一的問題是……要麼這張圖是錯誤的，要麼大家對於什麼是“線框流”或“使用者流”，是沒有達成共識的。 正如“線框流＃2”（出自“線框流”一詞的發明人）所定義的那樣，“線框流”會明確表示撥出下一個螢幕的互動。仔細看來，使用者流＃4似乎就是在明確這樣區別（當然，稍微更高的保真度也是區別之一）。

 

使用者流 #5

 

考慮到此類圖在現實世界中的多變性，可能更大的問題是，不同型別的流程圖都在“使用者流”這一標語下，被混合在一起了。

這個現狀帶來了一個問題：使用者流是否可以通過保真度，互動元素的明確和覆蓋範圍（即，所反應出產品範圍）來區分呢？或者使用者流是包括了多個可能性的選項，還是它應該僅僅是單線性任務（即任務流）呢？

 

根據我看到的絕大部分的內容，任務流與使用者流的區別在於任務流的的單線性和單選項性質。 與之形成反差的是，使用者流涉及使用場景中的自由選擇可能性。與單個預定路徑相比，使用者流提供了在更廣泛的操作可能性中選擇的自由。 但是呢，許多資料又說明了（或暗示）使用者流不必包含多個分支，包含分支僅作為一個可能性而已。 為了清楚起見，我寧願將任務流稱為“單任務流”，因為要是在使用中我們將所有的流程圖都稱為“使用者流”的話，使用這些術語就變得毫無意義。

 

考慮到這一點，使用者流＃5內的圖例對與術語“流”的使用，似乎是將它看成一條路徑（而不是指整個圖，與大多數人說到使用者流所指的內容不同）。 這個例子證明了我的觀點，也就是UX設計人員應該更加謹慎地使用術語，才能達到更高效的交流。 如果不謹慎的話，可能會出現幾個UX設計人員在使用同一術語討論時，所指代的物件是完全不同的（…這基本上就是我們的現狀）。

為了減少這種混亂，UX設計人員應嘗試使用有助於減少歧義的術語。 例如，在我看來，將使用者流#5中的實心線箭頭稱為“主使用者流程”意思會更加明確。而帶虛線的箭頭應稱為“備選使用者流程”。 基於同樣方式，我傾向於使用更具描述性的術語，例如“高保真互動圖”或“高保真UI流”，而不是統稱為“使用者流”。

 

使用術語“使用者流”的最佳方法是適當地對其定義上下文。 例如，說“登入使用者流”或“日曆元件使用的使用者流”是清晰明瞭的。 當然，許多UX設計師已經以這種方式使用這個術語了，但是我認為如果這種使用方式被廣泛認定成唯一方式的話，仍會是一個重大的改進。

 

最重要的一點

 

我認為業內的交付成果沒有問題，但是我確實相信術語“使用者流”（以及其他幾個類似的術語）的使用存在一些問題。 許多人都能對它做出更好的定義，但是似乎又只能通過與他人的定義產生分歧（各個定義相似但不同）或者進行對比才能做到這一點，這也恰恰證明了它是一個需要被澄清的術語。 出現這個現象的原因要麼是現有的定義無法很好地傳達資訊，或者是因為我們對它的含義目前尚未達成共識。

 

為這篇文章研究的過程使我開始懷疑使用術語這件事情到底有多麼重要 - 好像我應該對術語保一種工具的態度，而不應該對語言學過多糾結。 換句話說，我的目的是與其他人更好地合作，所以瞭解背後的概念遠比術語使用正確要重要許多，對嗎……？ 為了儘可能有效地進行交流，我傾向於選擇使用更簡明扼要的術語，讓每個人通過上下文都可以理解我們當時所言何物。例如“在4:30之前完成流程製作，我們 '4:45開會討論”）。

 

還是……這樣的處理方式導致了整個術語使用問題的發生呢？

如果你是UX設計師並且對這些術語的使用有自己的想法，歡迎你參與討論。

 

文末福利

 

最後給大家贈送摹客專業版啟用碼【cyrenecsdn】

領取即可全方位體驗這款強大的高保真設計利器，同時支援線上交付Sketch/PS/XD/Axure/Figma設計稿，還可以享受7*12小時線上客服支援

點選兌換啟用碼 或 複製連結領取  https://www.mockplus.cn/get-idoc?hmsr=cyrenecsdn