2018/06/06

寫在使用 Persona 之前


需求,是建立一個服務的起點。

只有在極少的情況,服務能夠橫空出世,創造需求。幾乎所有的服務,都被建立在發現需求,解決需求的行為上。

而需求的源頭,通常來自於服務建立者本身的成長的環境、生活際遇,以及同儕影響等等.。於是當服務建立後,這個生活圈子中的需求被滿足,而有相似的生活體驗用戶,也開始使用這服務。

隨著不斷地擴張,服務面臨了要如何改善或是強化自己的問題,於是需求的參考者就不會僅僅只是開發者本身,而是在無數次的需求討論中,出現的「使用者」。

「使用者反映我們應該要加強我們的登入機制安全性,密碼應該要有大小寫以及符號,長度應該要超過 13 個字元」

「使用者反應我們應該要讓註冊更友善,密碼不要限制那麼多,記不起來」

於是我們發現,會議上對於功能的討論,常會發生使用者需求衝突的狀況,不同立場的會議角色,代言不同的「使用者」來爭辯著什麼樣的功能才是合理,能夠帶來更好的用戶體驗,但最後做出來的產品,卻是充滿著矛盾的設計,或讓那些沒有聲音的用戶有了更糟的使用者體驗。

於是為了收斂討論的共識,我們可以透過大量的需求訪談來得知客戶或未知的客戶的背景,以及他們對於服務的概觀、使用情境、遇到的困難,與可能會採取的行動,進一步產生一個或多個能夠代言某群體的角色。

然後再針對此角色產生了一份描述檔案(想像從上帝的檔案室拿出了一本亞當的人生設定資料... ),裡頭賦予了他幾乎等同於現實生活中的資訊,包含了姓名、成長環境、生活際遇、同儕、教育程度、收入、決策模式等資訊(亞當的檔案裡頭記載了他有偷竊案底,而且容易被慫恿,肋骨因為手術少一根...)。於是,會議中就不再是透過「使用者反映...」這樣的方式來討論需求,而是明確地去討論如何滿足「某A」的需求。

稍這時候有沒有發現,這與前面提到建立服務時所依據的資訊很類似?服務一開始或許只能透過滿足自身的經驗來開發,但現在就讓大家透過滿足 Persona 內的客觀人物來進行吧!

以上,就是為什麼需要創建 Persona 的基本意涵。

而至於建立 Persona 的流程,要如何做需求訪談?該如何將 Persona 展現出來?在實務上有不同的作法,建議直接 Google 他人的經驗,然後融會貫通適合自己的做法就好了。

No comments:

Post a Comment

有什麼想說的嗎?

肉包

小明總是在住家附近的肉包店買肉包,20 年來,肉包從一顆 10 元漲到一顆 30 元,從一天可以吃三顆,到一天只能吃一顆,今天他心血來潮問了老闆為何這些年漲了這麼多,老闆很驕傲地回答... 「這區的店租漲價了啊!然後你沒發現我們現在店面不但有冷氣,又有座位,還有 80"...