---
title: 使用者訪談，我所學到、獲得的。
image: https://hackmd.io/_uploads/BJsvd8cPj.png
url: what-i-learn-from-user-experience-interview
tags: 部落格, 訪談, UI/UX
---

# 使用者經驗訪談，我所學到、獲得的。

:::success
State： Done 🙌
:::

Photo by <a href="https://unsplash.com/@pawel_czerwinski?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Pawel Czerwinski</a> on <a href="https://unsplash.com/s/photos/data?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>

這篇文章將分享我在接觸訪談前後，發現工作上的差異。
算是整理自己在這期間在實務上學習到的心得紀錄。(?)

## 接觸使用者訪談前
在接觸訪談前，蠻多時候設計是照著行銷需求、數據等調整。但有時我們不清楚為什麼某一區塊使用者總是停留，或是覺得該放的資訊都放了、流程也改了，不管怎麼調整，成效都有限。
那時的設計工作可能會有這樣的對話：
A：『 我覺得產品介紹很重要，應該要往上擺。』
B：『 但我覺得應該先讓使用者先看到優惠活動的訊息 。』
我：『 應該可以優惠活動訊息先放接著放產品介紹區塊，因為這次的優惠活動是臨時且對使用者受益的訊息，接著再放這次更新的產品介紹訊息。並且優惠活動的版位不要過高、佔滿手機畫面，在手機版可以讓使用者可以預覽產品介紹資訊。』
A,B ：『 那就這樣吧。』

而後從數據確認點擊、停留有沒有下降或上升，有上升或持平就維持設計，有下降就調設計。只是調了幾次之後，再也沒有更多改善的，那時的團隊或我都在思考，是不是我們忽略了什麼核心的問題？
後來才開始著手接觸使用者訪談、測試，試圖從這些方法中找到問題。

Photo by <a href="https://unsplash.com/@designhorf?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Ferenc Horvath</a> on <a href="https://unsplash.com/s/visual/c72fd571-4699-411d-a242-c2e8af5d80e5?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>

剛開始做使用者訪談或測試時，看文章、書籍、聽 Podcast，大部分內容總會提到各大成功的公司，因為做了訪談、研究、測試，發現了使用者如何操作，接著開發了哪些功能，最後爆紅、獲利等故事。

但現實是，我所待過的公司不是大公司、資源有限、不管哪個公司所要面對的產業環境、競爭對手、客群背景等，都與那些成功案例天差地遠。
更不用說，我那時還剛接觸訪談，又如何在極少經驗下評估或推動哪些事是正確的。

那時錯誤的認為，只要經過訪談和測試，就會『**找到一個答案**』，好像做了某些事，『**就會**』幫助我們解決一些困境。實際上沒有因為做了測試或訪談就有了『**重大的突破**』，甚至發現更多不是只靠『設計』能解決的問題，能夠換一張圖、改掉顏色都是簡單的，更困難的是品牌長期經營、不斷輩出的競品中找出區隔、不斷更新又必須考慮架構、技術或資源限制等。

但這樣，訪談就不重要嗎？測試就不重要嗎？

還是很重要。

## 使用者訪談後，設計工作的改變
在執行過訪談、測試後，團隊在討論功能規劃時，開始會依照使用者真實的情境拆解流程，那就像是我們在使用者身旁，看著他如何摸索所產品、如何透過滑鼠、鍵盤完成他的任務。
此時的團隊成員的討論會像是：

A：『 會提出的這個需求，是因為 OO 次的測試，使用者做了 OOXX 行為，所以...』
B：『 從 OO 次訪談中發現，使用者不斷提到...』

Photo by <a href="https://unsplash.com/@kellysikkema?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Kelly Sikkema</a> on <a href="https://unsplash.com/s/visual/e62af11f-21b4-4075-88e7-ca7669880448?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>

和夥伴一起照著使用者的情境規劃功能時，更快的能發現原本的流程或設計有哪些問題。
例如，原本的流程是 A 頁面-> B 文件 -> 開啟 C 文件
當我不確定為什麼是 A -> B -> C 這樣的流程，有沒有可能有忽略？
於是和提出需求的人一起進行了使用者情境的描述：
『我們現在想像是小明進到 A 頁面，然後他因為開會所以要打開 B 文件 ，這就像我們之前訪談過的 XXX ，但他那時是先打開 D 文件而不是 C 文件。』
此時我們都發現流程上的問題，忽略了 D 的步驟，最後再討論是否加入或修改流程。

回到上一段，提到是做了這些訪談、測試發現了更多問題，但也因為如此能將大問題拆成更多小問題，然後知道一點方向後各個擊破；沒有問題被解決完的一天，因為沒有完美的產品和服務，使用者的情境不同，解決方式也各有不同。

## 總結
我永遠不會忘記第一次執行正式訪談時，那時的顧問因為時間關係，無法在正式訪談前開會提醒。
但在那次訪談前，我們收到顧問一封短信，信中最最重要的一句話：

> 『保持好奇心！』

是的，不管是面對哪一場訪談、測試，或甚至設計工作。
我有沒有對這件事、對使用者、對我正在做的產品保持好奇心？
有沒有對使用者的經驗、操作情境，感到好奇？
有沒有想要更深入的了解，為什麼使用者會這麼做？

人們在操作或理解事物時，會有共同的感受、相似的經驗，但也有差異。我透過訪談知道，原來對一件事物理解的程度差異，會讓體驗感受有極大的落差。
之前有一個機會，要教新手工程師學員用 Figma 畫頁面的設計稿，那時的目標是至少用到 Figma 做按鈕、元件樣式，讓工程師至少可以規劃出自己的網站並且用統一的設計元素。
但在教學的過程中，才知道學員對設計工具中的圖層與群組的概念較模糊，可能要摸過好幾次才會感受到為什麼某個元素無法選取、為什麼總是選到不對的元件。學員一臉驚訝為什麼我會知道我自己選到哪一層，當我說出：『只是因為我很常摸這個工具啦！XD』我也能感受到這句話是無法降低對方在使用這個工具的挫折。

> 這個時候讓他們接觸 Figma 是對的嗎？

我對我自己的教材打了個問號。
在那次經驗後，我拿掉了 Figma 的內容，改教 [whimsical](https://whimsical.com/) ，原因是對一位新手工程師而言，頁面流程、功能位置比設計的好看、設計統一還重要。(對新手工程師而言連開發都要花很大心力去完成了，又怎麼能要求像設計師一樣？)
換了工具後，學員更能聚焦在『一頁應該要放哪些功能』、『哪個功能比較重要』的討論，而不是解決『Figma 這個元件為什麼沒辦法選』。
看到他們的改變，我也才知道自己之前做錯了多少啊...但也很感謝那時候和我提問的學員，真誠地給予回饋我也才能有機會調整教材和方向。

雖然這篇沒有什麼訪談交戰守則，更多是我自己記錄下這段期間的收穫。
畢竟，對我來說，還是好多要學習。