工具一：用途規格 Job Spec
「用途規格」是比較完整又複雜的語言工具，實務中較少用到。呼應前面「產生需求的過程」，用途理論學者 Clay Christensen 將用途界定為「顧客在特定情境中想獲得的進步」，用途一定和特定的情境脈絡有關，他進一步說：
用途「使得」顧客在特定「情境」中，能獲得「進展」。
A job enables the progress that an individual seeks in a given situation.
如果要記錄一個用途，他提出了「用途規格」這個語言結構，其實也是個「文件結構」：
- 顧客處在什麼「情境」中？
- 想達成什麼「進步」？想要的進步，有哪些功能面、社會面、情感面的用途？
- 有哪些進步的「阻礙」？有哪些焦慮和阻礙？
- 顧客勉強接受哪些「不完美的方案」？我們必須贏過哪些方案？
- 如何定義良好進步的「品質」？為了品質，顧客願做哪些「取捨」？
如果我們做完需求探索、用戶研究，可以按照以上五個問題，做成一份 1–3 頁的 A4 文件。因為這個結構相對完整、複雜、不夠簡潔，所以更適合以下情境：
- 當作「介紹用途理論」的工具
- 產品或研究團隊「交接、濃縮研究結果」的工具，先讓讀者看完較短的文字摘要，再進入各種 UX 工具、圖表、影音呈現的研究結果，加速讀者的理解速度
- 專案或產品啟動時，先提供更濃縮、更簡短的敘述，然後提供前項摘要的連結，給「想進一步了解顧客需求」的隊友參考
工具二：用途故事 Job Story
「用途故事」是目前最被廣泛使用的工具，但也遭受很多用途理論研究者的批評，因為它過度簡化，容易被誤用。同時，提出者 Alan Klement 是個充滿爭議言論的人物（疑似致敬或意圖貶低的言論），所以得罪很多用途理論的開創者。不過，Job Story 仍然是個實用的語言工具。
下面這張圖，簡潔說明了 Job Story 用途故事的結構：
A Job Story format, Replacing The User Story With The Job Story
這個方法進一步被 Intercom 發揚，他們進一步解釋 Job Story 用途故事：
- (1) When： 引發需求的情境
- (2) I Want to （Motivation）： 顧客在情境中的選擇動機
- (3) So I can （Expected Outcome）： 在情境中的期待進展
然後，他們會用 1–2 頁 A4，提交一個名為 “Intermission” 的文件，當作一份產品/功能提案。在這份文件中，其中一段就是 Job Story，要能在幾百字內講完顧客需求。推測 Intercom 之後就用這幾百字的 Job Story 代表此產品/功能，在內部快速解釋顧客需求、溝通開發目的。
然而，實際上找出 Intercom 的 Job Story 案例，會發現幾個問題：
- 某些 When 其實沒有說明 situation，遺失了情境，只是把 As a user 改寫成 When I am a user ，可以把 user 替換成各種 persona、角色、職業等等；例如，我們看過這種寫法： When I am a Customer Support Manager… 和 When I manage a Customer Support Team…
- Motivation 和 Expected Outcome 的重複率很高，有時根本可以刪去一個
如果有以上問題，那 Job Story 就幾乎等於 User Story ，喪失意義。若能避開上述問題，用途故事適合用在以下情境：
- 即時口頭溝通時，把顧客需求濃縮成 3 句話，跟隊友說明
- 放在 Task 或 Backlog Item 中的 Description 「任務描述」中，簡短解釋顧客需求
- 模仿 Intercom，當成 PRD 或產品/功能提案的其中一段，解釋顧客需求，勾起讀者興趣，進而去看更詳細的「用途規格」或「用戶研究報告」
這篇文章，介紹了二個「結構化語言工具」：
- 用途規格 Job Spec
- 用途故事 Job Story
但這兩個工具都有明顯的缺點，如何補強這兩個工具的缺點呢？有沒有更簡潔明瞭的語言工具？
下一篇文章，跟大家介紹最後一個語言工具「渴望成果 Desired Outcome」，而且還會跟大家說明，如何串連這三個工具，並和原有的工具一起相輔相成。
如果你對用途理論也感興趣，或者想繼續看到系列文章，歡迎 [留言] 或 [鼓掌] ，藉此督促我不得拖稿囉！