身為設計中心的使用者研究員,寫「使用者故事」或是「使用者描述」根本就是家常便飯。華碩電腦確實如外界報導,很認真落實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

%d