需求,是建立一個服務的起點。
只有在極少的情況,服務能夠橫空出世,創造需求。幾乎所有的服務,都被建立在發現需求,解決需求的行為上。
而需求的源頭,通常來自於服務建立者本身的成長的環境、生活際遇,以及同儕影響等等.。於是當服務建立後,這個生活圈子中的需求被滿足,而有相似的生活體驗用戶,也開始使用這服務。
隨著不斷地擴張,服務面臨了要如何改善或是強化自己的問題,於是需求的參考者就不會僅僅只是開發者本身,而是在無數次的需求討論中,出現的「使用者」。
「使用者反映我們應該要加強我們的登入機制安全性,密碼應該要有大小寫以及符號,長度應該要超過 13 個字元」
「使用者反應我們應該要讓註冊更友善,密碼不要限制那麼多,記不起來」
於是我們發現,會議上對於功能的討論,常會發生使用者需求衝突的狀況,不同立場的會議角色,代言不同的「使用者」來爭辯著什麼樣的功能才是合理,能夠帶來更好的用戶體驗,但最後做出來的產品,卻是充滿著矛盾的設計,或讓那些沒有聲音的用戶有了更糟的使用者體驗。
於是為了收斂討論的共識,我們可以透過大量的需求訪談來得知客戶或未知的客戶的背景,以及他們對於服務的概觀、使用情境、遇到的困難,與可能會採取的行動,進一步產生一個或多個能夠代言某群體的角色。
然後再針對此角色產生了一份描述檔案(想像從上帝的檔案室拿出了一本亞當的人生設定資料... ),裡頭賦予了他幾乎等同於現實生活中的資訊,包含了姓名、成長環境、生活際遇、同儕、教育程度、收入、決策模式等資訊(亞當的檔案裡頭記載了他有偷竊案底,而且容易被慫恿,肋骨因為手術少一根...)。於是,會議中就不再是透過「使用者反映...」這樣的方式來討論需求,而是明確地去討論如何滿足「某A」的需求。
稍這時候有沒有發現,這與前面提到建立服務時所依據的資訊很類似?服務一開始或許只能透過滿足自身的經驗來開發,但現在就讓大家透過滿足 Persona 內的客觀人物來進行吧!
稍這時候有沒有發現,這與前面提到建立服務時所依據的資訊很類似?服務一開始或許只能透過滿足自身的經驗來開發,但現在就讓大家透過滿足 Persona 內的客觀人物來進行吧!
以上,就是為什麼需要創建 Persona 的基本意涵。
而至於建立 Persona 的流程,要如何做需求訪談?該如何將 Persona 展現出來?在實務上有不同的作法,建議直接 Google 他人的經驗,然後融會貫通適合自己的做法就好了。
No comments:
Post a Comment
有什麼想說的嗎?