哈囉，朋友
我們在產品設計的早期階段，有一個相當重要的階段性工作，就是規劃服務的流程，描述使用者如何透過我們的產品服務達成目的，像這樣表達目的的流程圖，就是 User Flow。
然而我們在實務工作中會經常遇到幾種狀況，導致即使畫了服務流程圖也沒有人能夠理解，常見的問題包括：
- 顆粒度不均勻，有些步驟是細節的點擊操作行為，有些是整份表單
- 步驟內容不明確，有些步驟包含了抽象的判斷，例如描述使用者的內心戲
- 範圍模糊，有些步驟描述了服務外的行為，尤其是在服務遇到斷點或非同步流程時
- 觀點變動，有時候用系統的角度撰寫步驟，有時候用 A 使用者，有時候切換成後台營運
- 細節過度展開，同時描述所有的狀態變化、介面防呆條件，甚至連 API 流程都跑進來
- 充滿不確定性，寫了某個步驟，但不知道系統該如何實現（然後又不標註起來）
當我指導的設計師或客戶遇到以上狀況時，通常我會觀察到一個原因，就是「貪心」，貪心的想要試圖在一張流程圖裡面把所有在需求討論中聽到看到的東西都記錄進去，這是非常典型的為了手段而忘記目的。
那麼，什麼是服務流程圖的要溝通的目的呢？我認為本質上跟 RPG 遊戲的解任務是一樣的。
回想一下你在遊戲中遇到某個 NPC 交代你任務的時候，例如希望你送信給另一個城鎮的朋友，然後順便代給對方一束花。
你會得到該任務的完成條件，包含了：
- 一封信
- 一束花
- 交給指定的對象
在遊戲體驗的過程，這封信要遞送的對象所在城鎮可能是你從未去過的地方，因此你或許要進行野外探索，闖過一些擋住路線的怪物地盤。
然後為了獲得那一束花，你可能需要去找賣花的大嬸交談，然後發現她的丈夫之前出門的時候受傷中毒，要你代替花店老闆去野外尋找解毒藥材，兜兜轉轉你才解決花店老闆的問題，好不容易獲得要送的花。
最後你千里迢迢抵達了城鎮，卻發現這個城鎮遭遇怪物，你要送花的對象居然被抓走了（大驚）。
從遊戲攻略或劇情的角度來寫，篇幅可能有幾十個步驟，包含了解決各種問題需要的情報。
但如果從「送信任務」的角度來看，可能只有：
1. 獲得信件
2. 花店老闆取得花
3. 抵達目標城鎮
4. 交付給指定對象
相信你應該注意到了，最重要的描述是「實現目的的必要步驟」。
我知道，你會遇到很多人質問你「還有 OOXX 狀況你怎麼沒有考慮呢？」
但服務流程圖之所以是早期溝通用的圖表，重點就在於幫助我們「將大目標拆解為小目標」。
並且明確的定義每一個小目標具體該如何「交付」，才能推進到下一個小目標，最終串連起來完成整體目標。
如同上述的送信任務，抵達目標城鎮的這個步驟你可能有 N 種方式可以達成，你可以徒步前往、可以騎馬、可以坐傳送陣、可以用飛的等等，只要系統允許的方式都有可能幫助你完成此步驟所需的結果。
但那些移動的選擇，是系統中提供的「功能機制」，而不是使用者的需求目標。
我們在盤點產品的過程經常陷入功能優先、技術優先的討論情境，因此太快進入細節，而忘記為什麼使用者需要這些功能。
當我們先定義系統需要實現「讓使用者需要從 A 地點移動到 B 地點」，才能往下延伸討論相關的配套功能，例如角色本身可以移動（最基礎）、角色可以搭乘載具（組合功能）、角色可以透過指定傳送點前往其他可傳送地點（延伸服務）。
像這樣，團隊就能從服務流程圖中識別出需要打造什麼樣的功能機制，才能幫助使用者每一個任務步驟，最終實現目的。
總結一下：
- 畫爛的服務流程圖，通常是過於貪心，太早展開不必要的細節。
- 服務流程圖的溝通重點在於將大目標拆解為明確交付的小目標。
- 團隊根據服務流程圖的步驟任務，來打造相關功能機制，幫助使用者達成目的。
以上是我對於服務流程圖如何畫爛的觀察，分享給你。
如果你也曾經遇過這類糟糕的流程圖，歡迎與我分享你的經驗。
by Soking