身為設計中心的使用者研究員，寫「使用者故事」或是「使用者描述」根本就是家常便飯。華碩電腦確實如外界報導，很認真落實Design thinking，在時間來得及的情況，產品開發會從「使用者瞭解」開始，邀請開發人員一起來接受「同理心」洗禮。

配合Design thinking的三個範疇，我們通常在撰寫User story的時候，除了使用者特質、需求與價值描述，也會涵蓋商業(消費行為)、與技術(新技術導入接受度與限制)層面的內容。當然報告呈現的方式有很多種，我們最常用的就是V-N-S/B的階層式架構：Value – Needs – Solutions/Behaviors。(消費行為與技術應用就用另外的表格)

這個架構其實是多年前在工研院的某工作坊學到的，當時覺得脈絡十分清楚、見樹又見林，現在上網查了很久，居然一點資料都沒有，看來也是被新工具埋沒了。

在搜尋的過程中，發現一個東西跟V-N-S/B很像，就是UX人員常用的Impact Mapping，它結合了Simon Sinek的說服力黃金三圓圈，加上「WHO」。其實還滿有道理的，因為很少人可以獨立完成一個任務或實現一個目標。

上圖是Impact mapping官網的架構圖，我加上WHY、WHO、HOW、WHAT來說明。雖然多數人都是以「專案導向」的寫法使用，但其實也可以改成「使用者導向」，就以上述「青春美麗」使用者故事再來示範一次，就會變成下圖。

仔細看，內容幾乎沒變，只是多了二種關鍵角色：支持者與阻礙者，而這二種人各自會施展不同的做法來影響事主。專案人員此時就得針對”Deliverable”去排序重要性，來添加或修改產品功能。Impact Mapping優點是完整呈現使用者實現任務的各種成敗因素，缺點就是稍微複雜，必須做二次討論、篩選、排序，才能有下一個動作。

講到這裡，一定要講可能是最多人用的「使用者故事」公式：

As a “role”, I want to “do something”, so that I can “get value”.

身為一個<角色>，我想要<做某些事>，讓我可以<得到某種價值/完成某種目標>

.

這是敏捷開發人員最常使用的「故事卡」內容。以上述例子來說，故事卡其中一張(通常一個專案會寫非常多張)就可以寫：「身為一個40歲OL，我想要吃低脂飲食，讓我保持外觀青春美麗」。不過這個內容，對軟體開發者來說，層次又過高，寫成這樣會比較貼近：「身為一個40歲OL，我想要瞭解每餐飲食油脂含量，讓我能夠簡單完成低脂飲食目標。」愈接近開發端，價值與需求的層級都要適時的調低。對故事卡有興趣的人可以參考這裡，比較可惜的是，故事卡其實都不是直接從research result來的，它可能是使用者自己寫的，多數是敏捷開發團隊人員腦力激盪出來的，再透過專案實踐過程中的測試去調整。

照片來源：Pixabay