如何運用User Story快速熟悉產品設計規劃
對初入產品開發團隊的設計師來說，首要挑戰可能是對產品內容的不熟悉和時程壓力。如何在短時間內釐清產品設計規劃，相信對初來乍到的設計新鮮人是十分重要的課題，本文章將以居家照顧服務app設計開發為例，分享如何運用使用者故事為產品功能開發導航；並藉由分享使用者故事，拉近團隊成員對設計規劃的共識。
文章內容
- 透過User Story認識你的產品使用者，和夥伴一同確認產品開發順序。
- 向團隊描述你的使用者故事，匯集共識來完成故事對照。
- 產品開發過程中，除了使用者故事之外，你必須特別注意的事情。剛加入團隊的新鮮人，如何跟上步調快速的開發團隊？
或許你曾有這樣的經驗：剛加入團隊時，產品已如火如荼進行開發，由於自己不是第一批規劃產品的人，也未曾協同蒐集相關資料，過程中你可能直接被賦予一個時間點必須完成幾項設計交付任務，儘管團隊夥伴提供各式資料與說明，但你心裡卻仍然沒什麼頭緒，就像不知如何開始的拼圖一樣，此時試著理解「設計規劃與使用者的關聯性」可能是你的首要任務。以下我將以居服app設計過程為例，分享我所了解的產品設計規劃之方法與流程
好像比較好讀?。
初期來說，設計師可將問題圍繞在5W1H的主題去釐清產品與使用者的關係：
- 這個產品要達成什麼目的？What
- 為什麼要用這個產品？ Why
- 這是給誰用的產品？ Who
- 在何時使用這個產品？ When
- 產品會在哪邊使用呢？Where
- 如何使用這個產品？How
5W1H是產品研究前期簡單卻十分有效分析，除了更有系統地了解產品外，也可充分作為完成使用者故事的訪綱依據。為了統整問題，我會再將5W1H概分為：
1. 使用者為何要透過這個產品達成這個目的(why/what)？
2.產品使用過程為何(how/who/when/where)？
其中第1項是訪談前需掌握的背景資料，第2項則為完成使用者故事的重要資料，亦即訪談聚焦的主題。
將訪談資料轉化為使用者故事
由於長照政策的資源挹注，服務紀錄與資料的完整性直接影響了核銷與機構評鑑的結果，數位化管理可說是必然的趨勢，因而將訪談對象聚焦在目前有使用居家照顧服務app(簡稱居服app)的照服員，希望瞭解居服員在照顧工作中如何操作競品app，拆解工作中的各項任務，並察覺使用痛點。
訪談後，我們可將龐雜的訪談內容，整理成各項工作任務排列成有系統的敘事流。整理原則為先將整個敘事過程拆分成數個摘要曾任務，按照時間由左至右排列敘事內容，並以這些任務摘要作為故事骨幹，將相關範疇的活動內容排列在該摘要任務之下，形成如下圖縱橫延伸的故事地圖。
完成故事地圖後是否對產品使用過程愈來愈清晰了呢？以上圖為例，可發現確實紀錄簽到退，是居服app最主要的功能；又和查看/調整服務項目關乎到該班工作項目，兩者都可歸為「核心任務」。而「瀏覽個案資料」、「撰寫服務內容」、「查看服務紀錄」和「聯繫主責督導」等任務，相對於能否正確簽到退，並不對居服工作造成直接影響，因此可歸類為「加值任務」。值得注意的是「加值任務」雖不直接影響工作進行，但卻是表現產品優勢的關鍵，特別在於絕大多數競品都具備必要功能時，我方產品優勢的差異性更應該謹慎規劃。
此外，針對居服工作遭遇到的問題，例如「無法執行任務」和「異常狀況」等狀況，都是會直接影響居服員或督導的工作問題，即便這些問題未必經常阻礙工作任務，但仍必須儘早設計出相應機制處理這類的問題。
檢視「核心任務」與「加值任務」來區分設計開發的輕重緩急
確認居服工作必要的「核心任務」和「加值任務」後，我們可再依優先順序將骨幹下的各個任務切階段，這邊要注意的是每個開發階段都必須以可完成每項摘要任務，以開發所產出的價值來定義每階段的最小可行產品。
在拆分開發階段時，我們可一邊對照PM規劃的功能需求開發表(如下圖)，查看故事地圖的拆分是否符合PM的開發規劃，由於UX設計師是蒐集使用者資訊的前線人員，是最瞭解使用者任務細節的人，當我們發現原本的開發規劃不符你的調查結果時，請善加與PM、設計師甚至是工程師夥伴溝通，說明訪談調查的資料和觀察，並即時討論設計規劃是否需要調整。
經由不斷溝通完成使用者故事對照
實務工作中我們或許無法像書本中那樣經常性地開使用者故事對照工作坊，但透過不斷對話了解彼此對使用者的認知，亦可以當作一種機動快速的「故事對照」，是確認設計規劃的最佳方式，有時甚至可以回頭確認更高層次的產品定位問題。而從居服app的開發順序對照故事地圖，可發現部分任務是使用者並不這麼重視，甚至沒有思考過的內容，例如「上傳證照」、「工作喜好設定」等人員檔案設定功能，以及個督、團督紀錄等訊息內容。經過團隊溝通後即可將此類任務向後搬移。經過開發表對照、調整後，我們可以完成如下的使用者故事地圖。
至此，我們可以大致釐清各開發功能在使用者故事中的位置與優先順序，但正如先前所說，第一層次的核心工作項目僅為完成工作任務的最小可行產品，我認為真正能展現產品價值的反而落在Low Priority區塊的待辦事項中。例如訪談中許多得知:僅模糊呈現基礎服務時數不能滿足居服員需求，他們很期待能透過app更清楚地了解自己的工作成果，若我們能設計出良好的服務紀錄檢視功能，將有機會成為相對優越的產品特色，圖表中灰色的代辦事項，可能真的是使用者故事中很雞肋的任務，但也藏有重要但競品較缺乏的機會點，「加值任務」會是在產品1.0後，更需要細心規劃的部分，而身為一個UX設計師，你需要考量的不只是使用者故事而已。
關注使用者故事之外，你該瞭解的事情還有很多。
回顧剛加入團隊時，其實對居服系統不甚熟悉，手邊的資料又多屬於較初期的研究，此時除了趕快尋求工作夥伴幫助建構背景知識外，使用者故事或許能幫助你瞭解從使用者到產品設計的規劃脈絡。但與此同時，你不該忽視收集資料間的顯著差異：例如當你從訪談中察覺到居服員權限差異足以產生截然不同的使用者故事，可能意味著居服機構多樣化的管理模式，此時團隊必須對目標客戶、產品定位與發展期待存有高度共識，否則易發生使用邏輯矛盾的設計規劃。
此外，在購買者、管理者與使用者經常不同的to b產品，早先理解不同利害關係人價值和立場，並納入開發考量也尤其重要。最後，隨時理解工程端的技術限制與生產能量也十分重要，工程師是產品能否順利落地進入市場的重要夥伴，產品設計規劃切phase時，請多花點時間與工程端討論，避免發生理想崇高但現實殘酷的問題。
總括而論，產品設計規劃是多重因素考量的結果，我們能藉由使用者故事對照，釐清產品近中遠程的發展目標，但仍需要納入其他重要影響因素綜合考量，盡量讓產品規劃的方方面面具一致性，方能在面對市場各種打臉前不自亂陣腳。
