之前做產品經理(PM)時,公司決定導入UX 的職位、設計與文化。當時我是第一次接觸 UX 的觀念(不只是我,整個公司都是第一次),在與 UX 設計師 合作專案時,發生了許多的互動磨合的片段,簡直可用血淚史來形容。至今,許多問題我心中還是沒有標準答案,因此把整個過程記錄下來分析與檢討,同時思考如果再來一次,我會怎麼做。
你的公司是否也這麼土炮?
公司的產品是 “企業級監控攝影機管理軟體”,原本是由做為 PM 的我負責定義功能與規格,然後設計介面,方法非常土炮:研究競爭者有什麼功能?介面長得怎樣?然後擷取並修改成適合的第一版設計(用 Word 畫框框與流程!),接著開始跟工程師討論,經過一連串的溝通(妥協)後定案,接著進入開發與專案管理流程。當然,中間會因一些實作的問題繼續改改改,直到接近功能發佈,改到不能再改為止。
最後,公司決定要 導入 UX ,因此聘請了專業的 UX 設計師(就叫他 小U 吧!)。我非常高興終於能「讓專業的來」了,因為畫圖實在太花時間。此外,我也認為產品經理其實應該更專注於了解用戶的「需求」,不需要著墨於產品介面的設計細節。但想不到這樣的合作與磨合過程,並不是我想像中的那樣 …
一件簡單的事為什麼變得這麼複雜?
當時我們合作的第一個功能是要設計「影像在警報觸發後跳出」這個功能。也就是當攝影機 A偵測到有異常事件發生(例如有人闖入),監控端畫面要跳出攝影機 A 的畫面。這是一個許多競爭者及公司其他產品都已經具備的功能,所以我們認為應該算是簡單。
我跟 小U 稍微介紹了一下這個功能,還有客人為什麼需要這個功能。當時我認為已經將需求釐清了,接下來就讓他設計出漂亮又專業的頁面就搞定了!
但 小U 並沒有要看競爭者介面的意思,也沒有要研究公司產品既有的介面,而是要求與使用者對話,想要知道「使用者會怎麼使用」。
是的,我們都知道,了解使用者的需求很重要,但是公司的營業模式是 B2B,而且是「公司 → 代理商 → 經銷商 → 系統整合商 → 終端客戶」複雜的模式,光是碰觸到終端客戶就相當困難,更何況是要問到使用者會怎麼用這個功能!舉個例子,終端客戶聯絡窗口可能是總務或 IT 人員,做決定的是老闆,但使用者可能是保全人員,老闆怎麼會讓他的保全人員跟你討論產品功能呢?
想像力就是你的超能力?
所以我開始發揮「想像」推理情境給 小U:我是保全人員,一次要監控數十隻,甚至數百隻攝影機,平常不可能一直盯著它們,所以某隻攝影機有異常事件發生時我可能根本沒注意到,所以需要影像直接跳出來,覆蓋原本的螢幕畫面,讓我可以專注地看發生什麼事情。
但 小U 開始問我許多細節,例如:如果保全就沒在看螢幕了,畫面跳出來他還是不知道呀?如果是有人闖入,等原本在發呆的保全人員去看那支攝影機的時候,那個人可能已經不在了,所以他會看到空蕩蕩的畫面?保全人員看到畫面之後他會做什麼事呢?保全人員把事情處理完之後畫面要恢復原本的畫面嗎?對保全人員來說,怎麼樣是「事情處理完」呢?如果他處理不了怎麼辦?如果同時有兩隻以上的攝影機偵測到異常事件怎麼辦?…… 等等問題。
我繼續憑著我的想像力回答著,卻越來越心虛。不得不承認,我不是使用者,我以為我已經帶入使用者的角色,但那其實只是非常扁平的想像而已。但由於前述的公司業務性質,根本無法接觸到實際使用的人,更別提釐清這麼多細節了,所以我們就在這邊面臨第一道關卡。
我只好拜託 小U,先照著我說的去做吧!之後我們拿畫出來的介面跟客人確認這是不是他要的吧!(其實有點耍賴)
開始無限發散的需求與設計
小U 勉為其難答應了,結果畫出來的第一個版本和我想像中的完全不同 … 應該說,和我研究的其他競爭者,以及公司既有產品線的設計完全不同。但……也說不出哪裡不行,所以我提交給我的主管看(就是之前公司其他產品線,同樣功能的設計者)。主管看了說,為什麼不照公司其他產品設計就好了?這樣無法滿足 XXX 的要求呀!
所以我再度回去和 小U 討論,小U 再度出圖,卻又再度被主管打槍說,這雖然滿足了 XXX,但無法滿足 OOO 要求呀!這樣的迴圈週來復始,設計為了符合各種 OOO﹑XXX﹑ZZZ,變得越來越複雜。我夾在中間不停被拉扯,一方面覺得自己好像在踐踏專業,一方面又覺得哪這麼複雜。以過去的經驗,早就畫完並已經在開發了!以為找 UX 省了我的拉圖時間,結果怎麼反而花更多時間!
工程師加入戰場
接著,小U 說,能不能拿這份版本先跟工程師討論,他覺得逐漸完備了,不過他們可能有不同的意見,希望能早期將他們的意見容納進來。我當時想說,你這個設計這麼複雜,工程師一定不會答應的,一定被大砍,但沒想到工程師蠻興奮的!
他們一邊聽著 小U 說「故事」:使用者遇到什麼狀況,可以用什麼方法解決,一邊開始建議可以 XXX 又 OOO,我下巴都快掉下來了。
這時候我才發現工程師其實喜歡知道使用者會怎麼使用他們寫出來的東西,亦或他們喜歡做新奇有趣或更具有技術挑戰性的東西。
所以根據工程師的建議,小U 又回去改稿……
好不容易改完,工程師說可以估時間了。終於!我們要進入正常的開發流程了!
時程不含測試,出第一個版本,就要三個月!Excuse me?有人在乎 PM 的感受嗎?大家知道老闆跟業務都急著要這個功能,已經快把 PM 掐死了嗎?
產品經理最大的朋友,也是最大的敵人:時間,現在已經把我壓得喘不過氣了。光是來來回回的討論、畫稿,已超過一個月,現在還要三個月的開發,未來加上測試和改 Bug 的時間,不知何年何月才能看到它生出來。而且這才只是一個功能!我快崩潰了。
我開始想,再怎麼符合使用者的需求,又有什麼用呢?保全人員會因為太好用了跟老闆說,我就是要用這套軟體嗎?且符合了一個使用者的需求,那又怎麼樣呢?這不代表其他人也會這樣用呀?
我心中只想快點把這一切結束,趕快讓功能成功推到市場上。
最後,PM 主管也受不了了,一聲令下「照其他產品的設計做就好,這些進階設計可以之後再補強」。我很愧疚地跟 小U 說這件事,他也很無奈,也對這來來回回一直修改與妥協的過程感到痛苦。最終,我們反而走了回頭路,使用了原有產品的設計,UX 變成純粹畫漂亮圖的人……
當然,沒有所謂的「之後再補強」……
我從 導入 UX 的過程中學到什麼?
這段經驗非常痛苦,且最終是失敗的,但這激起了我進一步了解 UX 的動力,也逐漸了解為什麼小 U 想跟實際使用者接觸,但我還是以一個產品經理的立場及目前對 UX 的理解,來總結一下三點感想。
1. 產品經理要做的事應該是「平衡各方利益」,找到「現實世界中的相對最佳解」
UX 追尋的是使用者的體驗,工程師追尋的是做厲害東西的感覺,老闆追求的是趕快賣錢。但是讓任何一方做到太過極致,都可能導致災難(除非像賈伯斯這樣,又能追求體驗,又能做厲害東西,又能賣錢,還改變了世界!)
產品經理應該要善用其「能聆聽各方聲音與各種資訊,挖掘各方需求,用不同語言對不同對象說話」的能力,追尋用戶體驗/商業價值/開發流程/團隊動力的交會與平衡,如下面這張圖。
簡單地說,產品經理如果不成為雜耍大師,就是就被耍著玩啊!(手上耍著同時五個以上道具,還要踩著單輪車!同時保持微笑!)這可以參考我的另外一篇文章:菜鳥PM的震撼教育!夠專業的PM,不會只是「傳聲筒」
2. “改變” 不能一蹴可及
在這個案子中,公司從原本沿用多年的產品經理土炮設計,要直接轉為 UX 來設計,希望一切可以順暢轉換,變成蘋果第二。但其實各部門對 UX 的工作流程與需求都還沒有認知清楚,mindset 與合作模式都還沒建立起來,甚至也還沒有對新人完全信任,導致那些來來回回溝通與修改的過程,其實都花費多方的精力,而這些磨合的過程都是在毫無心理準備的立場碰撞,所以又痛又沒效率。
要改變組織習慣的工作模式,是需要有階段性的策略。例如這個案子,如果可以先有一段推廣期,先讓各部門了解 UX 的流程與價值,還有自己的職位在其中應該扮演什麼樣的角色。也可以先從更小、更沒迫切性的專案開始實驗,相信未來就能更加順暢。(我們以為很簡單,但這可是企業級軟體啊!之後在手機 app 上的嘗試就蠻成功的)
3. 「參與」這件事對團隊的價值
在整個過程中,我對工程師的“積極”印象深刻,我也認知到追求 UX 這件事的價值:不只是更了解用戶需求、解決用戶問題而已,而是一個讓開發部門更瞭解自己在做什麼的過程。在討論的過程中我也有種更瞭解工程師,更有「一起做一件了不起的事」的感覺。
試行 UX 一段時間之後,團隊的工程師們甚至逐漸在開發時,根據 UX 設計師的「故事」,順手加減一些更能符合這些故事的行為,這是讓我非常驚喜的。原本讓之前順著 PM 的設計,一個口令一個動作的工程師,轉變成滿足客戶夢想的執行者,也激勵團隊的積極度,這是我當初始料未及的。
但我至今無法解決的是,如何在 B2B 的產品設計當中,真正碰觸到使用者的問題,也不知道怎麼處理「使用者不是做決定的人」,這個攸關商業價值的問題,很期待有人可以跟我分享。
之後另外一次與 UX 交會的震撼教育,出現在我轉職到品牌廠硬體公司之後,且加入了一個「什麼都想插手又變來變去的老闆」的角色,讓整個戰況變得更加激烈,有機會之後再分享。
Evonne Tsai
財金人.科技人.行銷人,現為外商跨國經理人。定位自己為人類學家,永遠保持好奇心與熱情,學習跨領域新事物,希望最終能成為一個完整的人。
原文轉載於 –產品經理的UX導入血淚史
本文章所屬設計大舌頭與作者所有,未經授權,不得轉載!如需轉載,煩請通知。