做產品前一定要做使用者研究嗎? 一場關於工程師與設計師不同想法的思辯

2

文/ Seal Tseng

本文只是一篇思考,若想要從中獲得正確答案,請跳過~ 若想要參與反思與討論,請繼續閱讀。因為每個人心中都有自己的答案啊~ XD

某天,攻城獅同事 Jay 帶著挑釁的語氣問到 :「雖然耳熟能詳,但是,做產品前一定要做這麼多有的沒的使用者研究嗎??」

這個問題一丟出來好像有點…(黑人問號?)。 當然要做啊! 攤開各大講座或產品開發歷程第一步就是做使用者研究! 但仔細回想,我們還真有產品事前未做過完善的研究,但也進行得不錯(驚!!)。不禁讓我開始反思,設計師們習以為常的使用者研究,對於工程師到底是什麼樣的存在呢? (另一個擾人的東西)? 而這是否是設計師 VS 工程師思維的差距。

本篇目的並非爭論「該不該做使用者研究」,而是發現向來認為應該要有的過程,團隊中的其他角色卻不一定有相同看法。於是我決定試試用「被討厭的勇氣」的雙方論述,將我們的討論寫成一篇工程師 vs 設計師的對決(?),不是啦~是兩種不同角色的思辯過程。

▲ Image from Daria Nepriakhina on Unsplash

事件起源於設計師看到某篇產品歷程文章,涵蓋了設計發想+市場分析+使用者研究+Wireframe+設計稿+Prototype+開發+各種反覆迭代等過程(其實就是正規的產品開發歷程),覺得非常詳盡且激勵人心並分享給工程師。


工程師: 看起來是很完整啦~但要寫到這麼多,感覺應該已經是做完了再回去寫的感覺? 我覺得要是我,會很懶得去做前面一些 Persona 或者Story board之類的研究耶…

設計師: 恩恩~說來慚愧,之前XX專案也只簡單抓幾個User 過來聊一下就開始做了,要再回去做這麼詳盡的 Persona 有點難,也無法再回到當時了。

反思一 / 使用者研究,其實是阻力?

工程師: 是啊!不曉得為什麼,我一直覺得使用者研究雖能幫助聚焦,但某種程度上對於創意發想又是限制耶~

設計師: 哦,怎麼說? 如果你是指Persona, 它其實是讓團隊凝聚共識用的,因為怕一開始大家對於產品目標的理解與認知不一樣。但它是會隨著產品迭代改變的喔!

工程師: 那 User Journey 呢? 若是C2C 模式會需要畫兩份嗎? 感覺較為多功能性質的需求、或者某些情境無法用一份文件表達,拆開來不僅不方便我思考整體可能的功能,好像也會造成很多重複或者不容易檢討矛盾?這是我搞錯它的用途,又或者是工程師想讀的資訊和設計師不同?

設計師: 我認為應該2個C都需要畫 User Journey,因為可以從畫出來的流程確認產品需要哪些基本功能。就像拍賣一樣買賣雙方會因為不同的腳色就有不同的故事流程啊~至於整個Scope過大或情境過於複雜,導致多份文件,可能就需要拆解成較為單純的小任務,並做好版本控管來緩解這個問題吧~

工程師: 不過其實我想知道的是,這些研究是 Product design 的必備流程………….嗎?應該說,大家普遍都會做嗎?

設計師: (皺眉思考) 我覺得大家都會建議要做(Nice to have),但還真的沒聽過有人說不要做的。

你可以想像在看一個「客觀與主觀的光譜」,做與不做的結果並不會絕對落在客觀上或主觀上,但是他們的落點會不太一樣。或許有作研究組會較為客觀,然後可以用數據說服別人(老闆 or 客戶)為何這樣做;但沒作研究組就是比較主觀,很可能在某些關鍵會卡住而無所依據。

而產品會有不同的研究方式,且使用者研究的範圍可大可小。就我個人來說,即便我對這個產品掌握度很高,但我的 Minimum User Research是一定會抓幾個使用者來做訪談,不然心裡不安心 XD

工程師: 嗯嗯,我覺得這樣一講,多數使用者研究的產出感覺多半扮演的是溝通工具? 並能夠幫助制定統一的格式來描述這些情境,對於設計和開發有不同的必要性和好處。所以剛剛聽你說完,我覺得可能是因為我是工程師,本身就是要被說服的目標了,所以會覺得自己不想去做這些。

設計師: 可能喔!! 其實對原本是做平面設計跨足到UIUX領域的我來說,做使用者研究好累喔~(攤手) 但除了當作溝通工具,我覺得去分析這些的最基本好處是 : 能夠幫助聚焦使用者需求與目的,並設定各階段MVP。因為你自己的首要任務,可能跟一般使用者的不一樣。也就是說若一個產品有很多功能要做,但前期研究可以幫你凸顯哪個其實是使用者最需要的。

反思二 / 我們只能做「使用者要的」嗎?

工程師: 嗯,但若你提的需求,是使用者沒想過的呢?

設計師: 使用者沒想過,那有沒有可能不是他們最需要的呢? 是否那個功能就會變成是額外的加分條件,但不是首要條件?

工程師: (皺眉)我覺得這點可能就是讓我反感的地方? 有種「掛著使用者大旗來壓人的感覺(過去的惱人經驗)」。我自己覺得許多創意的發想是伴隨許多假設而來的,但「根據研究這不是使用者需要的」說法可能可以直接抑制沒有充足資源做完整使用者研究的主題?又或者無法做很多奇妙的嘗試。有些原生就沒有需求的 User story,想出來後很容易被挑戰,雖有收斂/修正發想的好處,但偶爾被噹一下也是會消耗點熱情。

設計師: 不會啊~應該說開發團隊應該要有共識,80%力氣在把基本功能做到好,20%的力氣去做好得令人驚豔的功能,這可以併行吧? 只是執行的先後與花的力氣的問題。另外若對基本功能的掌握度夠強,其他人沒提過的功能就可以把它轉換變成亮點。

基本上我覺得一個產品若光有新奇的功能,但基本功能不好用,我還是會刪掉;反之若基本功能都不錯,即便有小小的缺點我還是會留著等他改善,就像Medium一樣。

工程師: 嗯,這也是沒錯,核心功能守住,其他的都可以排程再做,就是取捨,我想團隊對內要在一定程度上達成共識、認同共同方向後,對外被質詢時就只能考驗本身的Model和研究說服力了?

設計師: 哈哈,我們對話可以變成一篇文章嗎? ,像是寫「被討厭的勇氣」,不過我不知道會不會有人想看就是了 XD,感覺是 Common sense,但我真沒思考過做跟不做的結果會差距多少? 或是不做也沒差,那又該如何是好?

工程師: 當年伽利略不也是用對話形式出版科普文章嗎? 就是討論一個議題,但是不直接描述自己的觀點,而是放上三個角色( 兩個極端 & 一個中立)來討論。

設計師: 哈哈,我的答案也不一定是正確答案,期待更多人參與討論啊~還是交回給大家了! 這是個開放式結局? :PP


關於「做產品前一定要做使用者研究嗎?」我認為 Nice to have ,但

1. 還是要視團隊對於產品目標掌握度(e.g. 「使用者是誰」、「情境及需求是什麼」) 是否足夠,來做適度刪減。因為有時開發團隊有可能也是使用者。

2. 開發時程的多寡也勢必影響到使用者研究的範圍與深入程度,像是兩個月內要完成的東西跟兩週內要完成的思考脈絡就會不一樣。

3. 最後我認為,「使用者研究的結果」是避免過於主觀,且很有力的溝通依據之一,畢竟很多專案腳色,如老闆、客戶或工程師等合作夥伴甚至是我自己(?)都很難被說服,因此還是看著研究數據心裡較為踏實啊!

以上論述並不代表所有的設計師與工程師,還不夠深入甚至也缺了個產品設計師的中介角色參與思辨。不過初衷是想拋出工程師同事的2個疑問:

1. 使用者研究是否反而成為限制   2. 我們只能做使用者要的嗎?

總覺得好像可以做個實驗啊~ 究竟「有做研究的實驗組VS 沒做研究流程的對照組」,產出來的產品會跟真正的使用者情境差距會多少呢???

授權來源:做產品前一定要做使用者研究嗎?

 

Share.

About Author

Seal Tseng

現任半導體產業之 UIUX 設計師;也是位具有懷疑精神的觀察家。 近期因深怕被AI人工智慧取代,正積極潛進高科技資訊產業並嘗試異業合作,找尋能不被滅亡的答案 :P

2 篇迴響

  1. Avatar
    Yun Shen on

    關於反思二,我個人認為使用者沒提到的也可能會是核心功能,因為有許多需求是使用者說不清楚或自己沒有意識到的,或是直到功能被創造出來繼而才產生相應的需求。當然,這類型的需求也是可以透過執行使用者研究挖掘,但很仰賴研究員發掘issue與insight的能力,又或是透過相當有經驗的領域專家,能夠在沒有做研究的狀況下洞察市場或創造新功能。我覺得關於要不要做使用者研究的debate(或討論哈哈),有點像是bottom-up (User data driven) vs top-down (Experts experience driven) 的議題,那兩者都是相當有貢獻且各有優點的方法,依據不同的情境與限制可以有不同比重。

  2. Avatar

    這沒什麼好辯的,市場會直接給你答案,不辯自明,沒親身經歷的事情就以為自己想出來的方法一定是可以的,這種失敗無數的例子太多了

Leave A Reply