iCHEF 產品設計師的日常 — 談用戶訪談經驗
緊接著上一篇「聊聊 iCHEF 的公司文化，以及做產品設計時的那些事」，這次我們聚焦在 iCHEF 設計師在執行專案時，非常重要的步驟「用戶訪談」。
用戶訪談是 iCHEF 產品設計師的基本功
要了解用戶的想法和產品的使用情境，除了靠設計師本身的產業知識(Domain Knowledge)以外，最直接的方法就是訪談用戶。 iCHEF 的客戶包含各種類型的餐廳，因此每個新功能推出前，總要考慮各種不同的使用場景，例如早餐店、咖啡廳、便當店、火鍋店…等，每個業態使用 iCHEF POS 的方法都不盡相同，要靠設計師一個人盤點到所有情境是很困難的。
不過受限於專案時程和資源投入的考量，雖然用戶研究方法有很多種，最常被採取的方式就是用戶訪談。所以 iCHEF 產品設計師訪談的對象是誰？如何訪談？訪談成果又如何整理應用到設計呢？
希望你閱讀本文後，可以了解 iCHEF 以用戶為中心的設計文化，以及用戶訪談對產品設計師的重要性
文章內容一、是否要執行用戶訪談，誰說了算？
二、訪談前要準備什麼？
三、訪談時要注意什麼？
四、訪談完了，然後呢？
一、是否要執行用戶訪談，誰說了算？
前篇文章提到 iCHEF 公司文化，非常重視「尊重專業」。因此如果負責的產品設計師覺得需要訪談用戶，就可以執行。畢竟如果設計師不了解產品的使用情境，如何進行設計？
當 PM 端完成產品商業目標的探索後，會將專案交付給設計團隊，接著負責的設計師要做的第一件事就是進行估時。此時設計師可以根據幾個考量來決定是否需要進行訪談：
- 設計師對於使用情境的掌握度
- 用戶對於新功能的理解度
舉例來說，如果要在 iCHEF 雲端餐廳新增線上刷卡的功能，那情境可能比較單純(顧客從取餐時付款變成訂餐時先刷卡付款)，用戶對於新功能也大致理解(大多數人對線上刷卡有一定的認知)，此時就不需要進行訪談，只需要設計接近完成時進行易用性測試即可。
相對的，如果是會員集點功能(顧客來源可能有線上點餐、店內用餐，甚至有多個會員共用帳號集點的狀況)，那情境就會很複雜，而且店家不一定理解(一般人不會去操作會員系統的後台)，那可能就需要把用戶訪談列入估時中。
當然所有專案都有時程的考量，不是每次都能夠進行大量且深入的用戶訪談。此時就可以考慮找內部的代理人，也就是退一步，考慮訪談 1)業務、2)客服、3)產品營運人員。這些公司內的夥伴雖然不是餐廳老闆，但由於他們有第一線接觸客戶的經驗，給出的回饋也是有可信度的。這是在時間有限的情況下，轉寰的做法。
二、訪談前要準備什麼？
第一件事當然是選擇訪談對象。設計師會跟產品經理合作，挑選適合的店家進行訪談。 iCHEF 產品大多數的功能不會鎖定特定的餐廳業態，因此我們通常會是每一種業態挑1–2間進行訪談。
挑選正確的店家很重要，如果選錯對象的話就會發生訪談資料不具參考價值的狀況。例如之前在進行餐廳外送專案時，我們挑選在雲端餐廳網站有提供外送服務的店家，殊不知當天到了現場才發現老闆因為疫情趨緩，已經不再主打外送，也就是說這家店本身就不把外送當作主力，只是因為疫情暫時性的調整而已，那這次訪談結果的參考價值就比較低了。
第二件事是準備訪綱。關於訪綱撰寫與訪談技巧，網路上可以搜尋到很多教學（推薦新手看本丸大大的這篇文章）。實務上，除了透過訪談探索店家需求以外，有時候我們也會拿出初版的設計稿來尋求回饋。畢竟對於受訪者來說，比起用腦袋想像設計師口中的設計方向，有具體畫面更容易提供回饋。
第三件事就是打電話約訪。基本上都是挑餐期不忙碌的時候進行訪談，所以一般會是下午時段。不過之前也有遇過夫妻兩人經營的小吃攤，早上備料、下午開店，晚上收拾完已經9點多了。設計師只能透過 Google Meet 在老闆收拾完之後再開始進行訪談。（不用擔心，在 iCHEF 只要是執行工作需要都是可以報加班的🧐）
三、訪談時要注意什麼？
訪談當天通常會是設計師搭配一位夥伴前往受訪的餐廳。兩人一組的搭配，由負責專案的設計師進行主訪，另一位進行錄音與紀錄。深度訪談是非常耗費精力的，主訪者不僅要機動性的調整提問的內容以回應受訪者的答覆，還需要同時通常受訪者的神情舉動，推斷他內心實際的想法。因此另一位夥伴適時地做球給主訪者，讓訪談可以順序進行，也需要追問特定問題，確保該問的都有問到。
其實很多餐廳老闆對於「用戶訪談」這件事情理解程度大不相同。之前就有碰過一家鹹酥雞的老闆認為訪談就是來簡單地聊聊天、回答一些問題(當然約訪時我們也不希望說的太正式，怕老闆會拒絕)，因此就約了開店前的準備時間。結果就是老闆一邊炸著雞排，一邊跟我們聊天。這次的訪談就幾乎得不到什麼深度的回覆。
另一方面，我們也有遇過早午餐的店長，在下午沒客人的時候，很熱情地坐在店裡跟我們聊了兩個多小時，還請喝飲料(餐飲業設計師的福利😍)。後來我們都記取教訓，在約訪時清楚說明希望的訪談方式與時間需求，詢問老闆是否能夠配合。
四、訪談完了，然後呢？
整理訪談結果的方法有很多，我自己是習慣使用親和圖(Affinity Diagram)來整理出洞見與設計原則。
有了設計原則之後，就可以作為設計決策時的參考。舉例來說，之前設計雲端餐廳預約訂單功能時，一開始猜想店家會想區分哪些是預約訂單？哪些是即時訂單？因為合理推斷，店家會根據訂單類型來決定出餐的優先順序。結果訪談後發現，店家根本不在意類型，廚房排單時只需要考慮一件事就是取餐時間(即將取餐的先做，還沒取餐的後做)。因此在設計時，原則就會是取餐時間的辨識度應該比訂單類型高。
不過如果需要進一步對外溝通、分享訪談成果，質化訪談容易被質疑樣本數不足的問題，這時候就可能需要搭配量化數據提高訪談結果的說服力。
結語
不論公司是否有使用者研究員，使用者訪談絕對是每個產品設計師的基本功。是否發動訪談？如何執行訪談？產品團隊都會尊重產品設計師的決定。而 iCHEF 的產品設計師透過用戶訪談，可以用相對低的成本，快速掌握各種用戶的使用情境，彌補領域知識的不足，建立以使用者為中心的設計。
最後分享一下去年 iCHEF 與 Google 合作的 iCHEF X Google 我的商家 專案，這個專案因為跟過去 iCHEF 熟悉的餐廳營運流程有很大的不同，偏向餐廳的線上曝光行銷與顧客導流，對於 iCHEF 產品團隊與餐廳老闆們都是全新的領域，因此在專案的前期就花了很多時間進行深度的用戶訪談來確認產品價值與未來迭代的方向。
