Skip to content

開發者日記–探索使用者需求,需要的是觀察

上次介紹了用條件抽換探索使用者真正的想法,但其實並非所有的使用者訪談,都適用一定的形式,針對不同的目的,使用者訪談的過程會完全不一樣。

舉例而言,當我們需要瞭解潛在需求是什麼,上次提到條件抽換就會派不上用場,甚至,我根本不會問太多具體的問題,而是改用一個很開放式的問法。

例如:你平常是怎麼完成這件事的。

這個問題的目的不像是要得到一個答案,比較像是觸發使用者去描述一個情境。然後我們從情境中去找出裡面的需求。

在這樣的過程中,最重要的心態是:完全避免去干涉使用者的想法,讓使用者自由發揮,然後對有興趣的部份讓使用者多說一點。(很特別,可以和我多說一點嗎?)

例如我會問:


可以和我聊聊你最近在做的案子嗎?

那你會怎麼開始處理這個案子呢?

OK,所以你會先去google法條,蠻特別的,一直以來都是這樣嗎?還是這個案子特例?

這邊我想請問一下,你剛說會把初步查到的判決存起來,用資料夾存嗎?那資料夾是怎麼命名的?會有日期嗎?當事人姓名呢?

你之前辦過類似的案子嗎?

那你搜尋判決大概花了多少時間有印象嗎?


透過這樣的方式,從很概括到很細節的瞭解使用者的使用情境,當然,我心中有一些可能的需求,但我不會透露給使用者,而是透過使用者的情境來驗證需求,另一方面也透過使用者的情境來看看有沒有我完全沒考慮過的需求。

例如使用者去google法條,再進到全國法規資料庫,而不是在全國法規資料庫中搜尋法條,因為前者只要點一次就可以看到法條,後者要點四次,這就是從使用者情境中探索出來的問題,也就意味者點擊次數是使用者找資料時會(下意識)考慮的一個點。

事實上我們也從這樣的訪談方式中pivot了很多產品方向,從訪談過程中我們得知法律系大學生帶筆電上課的人數不超過5%,因此大學生使用線上產品的需求並不高等等。而這個流程是非常早期的過程,大部份的UX也不太有機會碰到這個部分。

另外,可以從數據觀察到的東西就可以不用訪談了,至於是否可以透過MVP來驗證就必須在時間和驗證方法做一個權衡,這是蠻難抉擇的事情,我們的原則是,如果是符合大方向的功能我們傾向透過MVP去驗證,而比較分支的功能則傾向透過訪談來驗證。

Emmett Sheary在史丹佛的演講對這一點有非常棒的解說,推薦看完。

 

 

 

分享這篇文章
  •  
  •  
  •  
  •  
  •  
  •  
發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *