我為何在團隊中引進「使用者故事」的框架
當時針對企業端需求進行開發的團隊（以下稱企業端團隊）才剛重組，常面臨討論發散的困境。即便有質性研究或量化數據的結果，卻因缺乏明確的收斂機制，導致開發方向的討論難以聚焦、會議冗長。甚至曾發生「初步設計完成後，才發現團隊對功能的想像有落差，導致設計全部重做」的情況。
為了解決這個問題，我導入了「使用者故事（User Story）」與「使用者故事對照（User Story Mapping）」的框架，讓跨職能團隊在設計或開發正式動工前，有明確的機制去對「我們要解決誰的、什麼問題？」與「具體的開發方向與範圍」達成共識。
導入後創造的團隊成效
判斷依據
以上是我主觀觀察到的變化，沒有經過嚴謹的質性或量化檢驗。最直接的依據是：我離開企業端團隊後，該團隊的 PO 仍決定沿用這套框架作為設計流程 —— 一套需要團隊全員投入數小時的流程，在推動者離開後仍被繼續使用。
我如何引導團隊定義「使用者故事」
引進使用者故事階層架構
分層的做法，起點是 C&C 之前，我在學習者端團隊帶過的一次不順利的工作坊。當時我對使用者故事的理解，還停留在「參照模板寫」：想寫得詳細，故事就變得太長；想寫得抽象一點，又無法表達這則故事對開發方向的意義。結果設計師與 PO 在向團隊說明使用者故事時，無法依專案的階段，對焦在該討論的內容上。
我花了一段時間才釐清原因：我還不夠了解使用者故事的本質。於是我參考網路上的資料，並讀了 Jeff Patton 的《使用者故事對照》，才理解使用者故事描述的是專案方向與使用者之間的關係，目的是定義專案的方向、範疇，乃至開發的細節與規格 —— 而不是照著模板，把想寫的東西寫出來。
回頭看，那次的問題正是用單一層級的使用者故事涵蓋所有專案脈絡時會遇到的困境：
- 為涵蓋所有脈絡而塞入過多內容，導致冗長失焦。
- 描述過於抽象，無法釐清具體的開發範圍。
- 描述過於具體，在專案前期就限縮了解法，扼殺了團隊共同發想的空間。
為此，我引進了將使用者故事分層的架構：每一層只鎖定該階段所需的共識，把更具體的決定留給下一層 —— 讓框架在各階段都保有彈性，跨職能團隊得以真正參與探索與定義的過程。
使用者故事階層架構表
| 階層與定義 | 目的 | 具體範例（以 設計可快速驗證的 AI 職能媒合 MVP，半數目標企業實際發布給員工為例） |
|---|---|---|
| Level 1：開發願景層級 高度抽象，作為團隊的長期開發目標。 | 基於質性與量化研究洞察，真實反映使用者痛點或需求，作為後續探索一系列解決方案的共通基礎。 | 人資想提升公司內部自主學習風氣，培育人才，因為內部人才成長，就可為企業帶來更大的商業收益。 |
| Level 2：開發方向層級 中度抽象，對應一個即將開發的獨立功能。 | 縮限一個即將開發功能的發想範圍。作為跨職能團隊討論時的發想原點，既能收斂發散的點子，又保留了探索多樣化解法的空間。 | 人資想把學習平台的學習內容與職能模型綁定，因為這樣可以大幅提升員工的學習動機。 |
| Level 3：開發細節層級 具體微觀，包含互動規格。經 PBR 會議收斂後，成為產品待辦項目（PBI），並定義其驗收標準（AC）。 | 對齊全體團隊對開發細節的共識，並作為後續排程與開發的依據。 | 人資想透過 CSV 批次上傳某一職級的職能模型描述，因為這樣能大幅節省手動建檔的時間。 └ 人資可閱讀「以 CSV 模板上傳職能模型」的方法說明 └ 人資可下載 CSV 模板 … 等細節 |
※C&C 為我擔任 Design Lead 的職能媒合功能專案，詳見設計可快速驗證的 AI 職能媒合 MVP，半數目標企業實際發布給員工
※ 本架構主要參考《使用者故事對照：User Story Mapping》一書，以及〈使用者故事對照（User Story Mapping）的三種用法〉一文；表中各階層的「目的」，則是我依當時產品團隊的狀況訂定的。
Level 1 & Level 2：淬鍊開發願景與方向
這兩層由 PO、UX Researcher 與我共同定義。參與者都熟悉設計思考與使用者故事的分層方式，因此不需要正式的引導流程，多半在幾輪討論中就能收斂。我們會刻意用不同的抽象程度與敘事方式寫出多個草稿，再組合、淬鍊出定義「開發願景」與「開發方向」的故事。
篩選草稿時，我們的判準是「具體程度」。每個階層的使用者故事各自需要不同的具體程度，而專案性質、時程等因素也會影響一則故事該寫到多具體。因此這個階段仰賴的是團隊在過往經驗上累積的判斷，而非一套固定的規則。
此圖中有兩則被淘汰的 Level 2 草稿。兩則都把手段（自動推薦、依職級設計路徑）寫得太過具體，會導致在專案前期就壓縮掉開發團隊發想的空間。
而最終採用的使用者故事雖然同樣提到了手段（與職能模型綁定），但沒有規定要怎麼綁定、綁定後要以什麼形式呈現給員工端 —— 開發團隊因此仍能依自身的資源與技術條件評估，發想出最貼合這則故事的功能。
Level 3：將願景轉化為開發規格
- ⓪ 判斷是否需要工作坊來對齊開發想像
一場工作坊要佔用團隊全員數小時，因此並非每個功能都值得。我在企業端團隊帶過約 10 場工作坊，要不要開，我會先看兩件事：
- 規模：如果功能的規模較小，例如只是某個頁面裡的一個區塊，或一兩則使用者故事就能定義清楚，就不進入工作坊的階段。
- 團隊的想像有沒有落差：我會在與團隊成員的定期 1on1 中，帶著 Level 1／Level 2 的故事與相關研究資料做事前說明，確認彼此對這個功能的想像，也聽取工程師在看過初期資料後，對開發難度的評估。當我察覺到一些不確定因素時（如：「某些地方的實踐方式我有點擔心」「我不確定另一位工程師會怎麼想」），就代表團隊之間確實存在需要當面收斂的落差 —— 這時我才會決定開這場工作坊。
- ①～③ 準備、引導與收斂
工作坊前，我會在 Miro 上備齊 Level 1／Level 2 的故事、目標受眾的人物誌與相關研究洞察。這一步很重要：只要使用者的脈絡、PO 對功能的想像，或工作坊本身的目標沒有被充分傳達，工作坊就產不出預期的結果。工作坊中，我帶領全體開發團隊梳理出功能的使用流程（骨幹），再往下發想對應的開發規格與互動細節；會後與 PO 整理便利貼，精煉成 Level 3 的使用者故事，進入 PBR 會議轉化為 PBI 並定義 AC。
以 C&C 為例，工程師在工作坊中對「直接用 AI 媒合課程」提出的精準度與成本疑慮，後來成為團隊以課程標籤作為中介的起點（詳見設計可快速驗證的 AI 職能媒合 MVP，半數目標企業實際發布給員工）。
後續與反思
作為 Design Lead，我有一段時期很常以個人的溝通去彌補團隊成員間的認知落差。在開始使用這套使用者故事框架後，我發現，找到一個適合團隊的協作方法更為重要 —— 一個人的時間跟能力有限，但一個好的協作方法可以發揮 1+1 大於 2 的功效。
我離開企業端團隊時，工作坊的產出、工作坊所需的各式 Template，以及 Notion 上對使用者故事與分層的定義，都已交接給該團隊的 PO 與設計師，但接手的設計師仍來詢問這套框架的用法。
這讓我的反思更加深刻 —— 即便找到一套能被團隊接納、重複使用的方法，但方法本身不一定能被正確使用，它需要實際被體驗過，才能真的被有效地執行。