State: Done 🙌
Photo by Pawel Czerwinski on Unsplash
這篇文章將分享我在接觸訪談前後,發現工作上的差異。
算是整理自己在這期間在實務上學習到的心得紀錄。(?)
在接觸訪談前,蠻多時候設計是照著行銷需求、數據等調整。但有時我們不清楚為什麼某一區塊使用者總是停留,或是覺得該放的資訊都放了、流程也改了,不管怎麼調整,成效都有限。
那時的設計工作可能會有這樣的對話:
A:『 我覺得產品介紹很重要,應該要往上擺。』
B:『 但我覺得應該先讓使用者先看到優惠活動的訊息 。』
我:『 應該可以優惠活動訊息先放接著放產品介紹區塊,因為這次的優惠活動是臨時且對使用者受益的訊息,接著再放這次更新的產品介紹訊息。並且優惠活動的版位不要過高、佔滿手機畫面,在手機版可以讓使用者可以預覽產品介紹資訊。』
A,B :『 那就這樣吧。』
而後從數據確認點擊、停留有沒有下降或上升,有上升或持平就維持設計,有下降就調設計。只是調了幾次之後,再也沒有更多改善的,那時的團隊或我都在思考,是不是我們忽略了什麼核心的問題?
後來才開始著手接觸使用者訪談、測試,試圖從這些方法中找到問題。
Photo by Ferenc Horvath on Unsplash
剛開始做使用者訪談或測試時,看文章、書籍、聽 Podcast,大部分內容總會提到各大成功的公司,因為做了訪談、研究、測試,發現了使用者如何操作,接著開發了哪些功能,最後爆紅、獲利等故事。
但現實是,我所待過的公司不是大公司、資源有限、不管哪個公司所要面對的產業環境、競爭對手、客群背景等,都與那些成功案例天差地遠。
更不用說,我那時還剛接觸訪談,又如何在極少經驗下評估或推動哪些事是正確的。
那時錯誤的認為,只要經過訪談和測試,就會『找到一個答案』,好像做了某些事,『就會』幫助我們解決一些困境。實際上沒有因為做了測試或訪談就有了『重大的突破』,甚至發現更多不是只靠『設計』能解決的問題,能夠換一張圖、改掉顏色都是簡單的,更困難的是品牌長期經營、不斷輩出的競品中找出區隔、不斷更新又必須考慮架構、技術或資源限制等。
但這樣,訪談就不重要嗎?測試就不重要嗎?
還是很重要。
在執行過訪談、測試後,團隊在討論功能規劃時,開始會依照使用者真實的情境拆解流程,那就像是我們在使用者身旁,看著他如何摸索所產品、如何透過滑鼠、鍵盤完成他的任務。
此時的團隊成員的討論會像是:
A:『 會提出的這個需求,是因為 OO 次的測試,使用者做了 OOXX 行為,所以…』
B:『 從 OO 次訪談中發現,使用者不斷提到…』
Photo by Kelly Sikkema on Unsplash
和夥伴一起照著使用者的情境規劃功能時,更快的能發現原本的流程或設計有哪些問題。
例如,原本的流程是 A 頁面-> B 文件 -> 開啟 C 文件
當我不確定為什麼是 A -> B -> C 這樣的流程,有沒有可能有忽略?
於是和提出需求的人一起進行了使用者情境的描述:
『我們現在想像是小明進到 A 頁面,然後他因為開會所以要打開 B 文件 ,這就像我們之前訪談過的 XXX ,但他那時是先打開 D 文件而不是 C 文件。』
此時我們都發現流程上的問題,忽略了 D 的步驟,最後再討論是否加入或修改流程。
回到上一段,提到是做了這些訪談、測試發現了更多問題,但也因為如此能將大問題拆成更多小問題,然後知道一點方向後各個擊破;沒有問題被解決完的一天,因為沒有完美的產品和服務,使用者的情境不同,解決方式也各有不同。
我永遠不會忘記第一次執行正式訪談時,那時的顧問因為時間關係,無法在正式訪談前開會提醒。
但在那次訪談前,我們收到顧問一封短信,信中最最重要的一句話:
『保持好奇心!』
是的,不管是面對哪一場訪談、測試,或甚至設計工作。
我有沒有對這件事、對使用者、對我正在做的產品保持好奇心?
有沒有對使用者的經驗、操作情境,感到好奇?
有沒有想要更深入的了解,為什麼使用者會這麼做?
人們在操作或理解事物時,會有共同的感受、相似的經驗,但也有差異。我透過訪談知道,原來對一件事物理解的程度差異,會讓體驗感受有極大的落差。
之前有一個機會,要教新手工程師學員用 Figma 畫頁面的設計稿,那時的目標是至少用到 Figma 做按鈕、元件樣式,讓工程師至少可以規劃出自己的網站並且用統一的設計元素。
但在教學的過程中,才知道學員對設計工具中的圖層與群組的概念較模糊,可能要摸過好幾次才會感受到為什麼某個元素無法選取、為什麼總是選到不對的元件。學員一臉驚訝為什麼我會知道我自己選到哪一層,當我說出:『只是因為我很常摸這個工具啦!XD』我也能感受到這句話是無法降低對方在使用這個工具的挫折。
這個時候讓他們接觸 Figma 是對的嗎?
我對我自己的教材打了個問號。
在那次經驗後,我拿掉了 Figma 的內容,改教 whimsical ,原因是對一位新手工程師而言,頁面流程、功能位置比設計的好看、設計統一還重要。(對新手工程師而言連開發都要花很大心力去完成了,又怎麼能要求像設計師一樣?)
換了工具後,學員更能聚焦在『一頁應該要放哪些功能』、『哪個功能比較重要』的討論,而不是解決『Figma 這個元件為什麼沒辦法選』。
看到他們的改變,我也才知道自己之前做錯了多少啊…但也很感謝那時候和我提問的學員,真誠地給予回饋我也才能有機會調整教材和方向。
雖然這篇沒有什麼訪談交戰守則,更多是我自己記錄下這段期間的收穫。
畢竟,對我來說,還是好多要學習。
or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Do you want to remove this version name and description?
Syncing