文/ Seal Tseng
本文只是一篇思考，若想要從中獲得正確答案，請跳過~ 若想要參與反思與討論，請繼續閱讀。因為每個人心中都有自己的答案啊~ XD
某天，攻城獅同事 Jay 帶著挑釁的語氣問到 :「雖然耳熟能詳，但是，做產品前一定要做這麼多有的沒的使用者研究嗎??」
這個問題一丟出來好像有點…(黑人問號?)。 當然要做啊! 攤開各大講座或產品開發歷程第一步就是做使用者研究! 但仔細回想，我們還真有產品事前未做過完善的研究，但也進行得不錯(驚!!)。不禁讓我開始反思，設計師們習以為常的使用者研究，對於工程師到底是什麼樣的存在呢? (另一個擾人的東西)? 而這是否是設計師 VS 工程師思維的差距。
本篇目的並非爭論「該不該做使用者研究」，而是發現向來認為應該要有的過程，團隊中的其他角色卻不一定有相同看法。於是我決定試試用「被討厭的勇氣」的雙方論述，將我們的討論寫成一篇工程師 vs 設計師的對決(?)，不是啦~是兩種不同角色的思辯過程。
事件起源於設計師看到某篇產品歷程文章，涵蓋了設計發想+市場分析+使用者研究+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 沒做研究流程的對照組」，產出來的產品會跟真正的使用者情境差距會多少呢???
授權來源：做產品前一定要做使用者研究嗎?
3 則留言
關於反思二，我個人認為使用者沒提到的也可能會是核心功能，因為有許多需求是使用者說不清楚或自己沒有意識到的，或是直到功能被創造出來繼而才產生相應的需求。當然，這類型的需求也是可以透過執行使用者研究挖掘，但很仰賴研究員發掘issue與insight的能力，又或是透過相當有經驗的領域專家，能夠在沒有做研究的狀況下洞察市場或創造新功能。我覺得關於要不要做使用者研究的debate(或討論哈哈），有點像是bottom-up (User data driven) vs top-down (Experts experience driven) 的議題，那兩者都是相當有貢獻且各有優點的方法，依據不同的情境與限制可以有不同比重。
這沒什麼好辯的，市場會直接給你答案，不辯自明，沒親身經歷的事情就以為自己想出來的方法一定是可以的，這種失敗無數的例子太多了
我認為研究不是發現什麼新功能要做？而是找出目前規劃用戶覺得不足的缺口，還有驗證是否規劃的產品如用戶想要，至於原本產品的定調與公司的商業價值與服務藍圖有關，不是研究說要做這用戶喜歡就做這個