上次介紹了用條件抽換探索使用者真正的想法，但其實並非所有的使用者訪談，都適用一定的形式，針對不同的目的，使用者訪談的過程會完全不一樣。
舉例而言，當我們需要瞭解潛在需求是什麼，上次提到條件抽換就會派不上用場，甚至，我根本不會問太多具體的問題，而是改用一個很開放式的問法。
例如：你平常是怎麼完成這件事的。
這個問題的目的不像是要得到一個答案，比較像是觸發使用者去描述一個情境。然後我們從情境中去找出裡面的需求。
在這樣的過程中，最重要的心態是：完全避免去干涉使用者的想法，讓使用者自由發揮，然後對有興趣的部份讓使用者多說一點。（很特別，可以和我多說一點嗎？）
例如我會問：
可以和我聊聊你最近在做的案子嗎？
那你會怎麼開始處理這個案子呢？
OK，所以你會先去 google 法條，蠻特別的，一直以來都是這樣嗎？還是這個案子特例？
這邊我想請問一下，你剛說會把初步查到的判決存起來，用資料夾存嗎？那資料夾是怎麼命名的？會有日期嗎？當事人姓名呢？
你之前辦過類似的案子嗎？
那你搜尋判決大概花了多少時間有印象嗎？
透過這樣的方式，從很概括到很細節的瞭解使用者的使用情境，當然，我心中有一些可能的需求，但我不會透露給使用者，而是透過使用者的情境來驗證需求，另一方面也透過使用者的情境來看看有沒有我完全沒考慮過的需求。
例如使用者去 google 法條，再進到全國法規資料庫，而不是在全國法規資料庫中搜尋法條，因為前者只要點一次就可以看到法條，後者要點四次，這就是從使用者情境中探索出來的問題，也就意味者點擊次數是使用者找資料時會（下意識）考慮的一個點。
事實上我們也從這樣的訪談方式中 pivot 了很多產品方向，從訪談過程中我們得知法律系大學生帶筆電上課的人數不超過 5％，因此大學生使用線上產品的需求並不高等等。而這個流程是非常早期的過程，大部份的 UX 也不太有機會碰到這個部分。
另外，可以從數據觀察到的東西就可以不用訪談了，至於是否可以透過 MVP 來驗證就必須在時間和驗證方法做一個權衡，這是蠻難抉擇的事情，我們的原則是，如果是符合大方向的功能我們傾向透過 MVP 去驗證，而比較分支的功能則傾向透過訪談來驗證。
Emmett Shear 在史丹佛的演講對這一點有非常棒的解說，推薦看完。