寫在使用 Persona 之前

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

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

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

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

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

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

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

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

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

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

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

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