我在 Amazon 擔任UX 設計師的三年心得回顧

幾天前,加入Amazon的日子不知不覺滿三週年了。碰巧有位朋友也在這個時間問我,在Amazon做設計師有沒有什麼不一樣?剛好,利用這個機會好好來回顧一下自己在這1000多個日子的感受。不過,這些只是我個人待過的公司、團隊的經驗,並不代表全部。

長話短說,自己覺得除了從50%的英文變成100%的英文以外,其他的,真的沒有太大的不同。然而,既然朋友是問:『在Amazon做設計師有沒有什麼不一樣?』那我就從不同的地方先來分享。

知道如何問問題是一種基本能力

會不會問問題,在Amazon是一個非常重視的基本能力,它受重視到在面試時,都被當作一個重要的考核指標。我曾經聽過不只一次,來參與面試的人,各項專業能力都非常優秀,最後卻沒有被錄取,原因很簡單 — 面對面試官提出來的實作測驗,一個問題都沒有問,或者問了一些無關緊要的事,就開始作答。這樣的案例並不是只有發生在設計師的面試,即使工程師也一樣。

也許是台灣教育使然,在唸書的時候,許多學生常常都是老師說什麼就背什麼,不管懂不懂、對不對,考試背出正確答案就好,因此,對於問問題並不怎麼在行。離開了學校進入職場,因為鮮少有這樣的訓練,對於主管的要求提出問題,更是戒慎恐懼。再加上,鄉民們常說,台灣私人企業、政府機關對於解決問題的方式,都是解決提出問題的人,似乎都在告訴大家,問問題等於找麻煩,因此,許多會議中,總是惜字如金,沒有被cue到,絕不講話,我也一直是這樣,不覺得有什麼問題。然而,在從工程師轉換至設計師跑道之後,主管常常對我的設計,提出各種我事先從來沒想過的問題,讓我常為了自己沒搞清楚問題,就急著動手而犯了一些低級錯誤(rookie mistakes)感到無地自容。為了避免再犯同樣的錯,便強迫自己在每次開始設計之前,就把所有將來可能被問的問題,都先對自己問過一輪,回答不出來,就去問到答案,經常搞到快要人格分裂。但是,也因為這樣,漸漸把提問的能力磨練出來。

從一位UX設計師的角度來看,對產品經理問對的問題,能幫助你的設計,確切滿足商業目標;對工程師問對的問題,能幫助你在已知的技術限制下,提出創新的方案;對使用者問對的問題,能幫助你深入了解使用者的渴望,提出不僅可用(Usable)且有用(Useful)的產品。在Amazon,人人都是提問高手,如果你沒有在專案開始前,把一些重要的事問清楚、搞明白,在設計提案討論會時,肯定會被問到啞口無言、腦袋空白,漸漸地,你的專業能力便會開始受到質疑。一旦失去了團隊的信任,將很難在這個團隊繼續待下去了。

先稱讚、再給建議

另一個在Amazon感受最大的不同是,大家都不吝於感謝或給予讚美,而且,是非常具體的讚美,這也是從小在台灣長大的我,非常不擅長的一件事。過去,每當同事拿著設計來請我給意見的時候,總覺得,沒有讓他抱著一堆改善的建言回去,會讓對方覺得我不專業、吝嗇、留一手,所以,我都絞盡腦汁的挑出每一個可以給予意見的點,然後,帶著滿意的笑容看著同事,心想:『應該有讓你滿載而歸了吧。』

然而,在Amazon每一次的設計提案討論會,與會者一定都會從我的設計中,找到他喜歡的,並積極給予鼓勵、讚美,而且,是具體地說出哪些部分是他欣賞的,絕不會有那種『辛苦你了』空泛的口號。漸漸地,我慢慢體會讚美比批評(給建議),有更強大的力量,推動人們努力往更高的目標前進。如果,一場會議下來,你只有收到一堆改善計畫,接下來,會先感到挫折,然後,再由挫折轉成憤怒 — 我浪費了那麼多時間努力,竟然毫無建樹!就算最後化悲憤為力量,往往也打了一些折扣。然而,如果在建議之前,有收到一些具體的鼓勵,挫折感或許會大大降低,一般來說很少會進一步轉成憤怒,提案者很快就可以整理思緒,開始著手改善計畫。

我發現,這樣的方式套用在孩子身上,一樣管用(菸~)

懂得挑選戰場

我在Amazon的第一位主管,是個貼心、笑聲很爽朗,做事實事求是的德裔美國人,從她身上學到了許多一身受用的觀念。記得一次在討論工作規劃時,她告訴我,在Amazon,不會有人告訴你什麼該做、什麼不該做,你必須懂得挑選自己的戰場(pick your battles)。以前在台灣,主管總會跟我討論每年的工作項目,甚至到這個月要完成什麼都規劃好了,很開心在這樣的溫室裡上班,每天幾乎只要照表操課就可以了。

然而,加入Amazon之後,好像從一個整天被鞭子抽的私立高中,進入了放牛吃草的大學,突然間,好多事都想要做、也有好多事都懶得做,一段時間之後,發現比較自律的同學跟自己的程度越差越遠,驚覺好多事應該做、卻也好多事來不及做了。UX設計師在Amazon是個稀缺的資源,總有一堆案子想要你的幫忙,即便你無止盡的加班,都不可能全部交付,然後,還有一堆很有趣的案子,你迫切渴望地想參與。如果你不懂得正確地把時間,投資在值得做的事上面,到頭來,在做年終回顧的時候,你會發現說不出一個滿意的成績(success stories),覺得自己又瞎忙虛度了一年。

至於,什麼才是對的戰場,什麼才是真正值得花時間的專案,我自己的衡量方式很簡單 — 我能為哪一個專案帶給最大的價值(UX impact)。即使在Amazon,仍然存在部分人把UX設計師當成美化介面的工人,像這類的專案,每幫一次忙,就是在強化認同對方的觀點。基本上,能不做就不要做,或者是用最少的時間去完成(有很多方法可以達到這個目標,將來有機會再說)。如果,你發現你總是在做類案子,是時候去找你的主管聊聊了,這種案子做再多,對你的能力不會有什麼提升,對整個設計團隊的價值,也不會有任何加分。

Amazon Treasure Truck,一個我也很想參與的專案。

講完了三點體會最深刻的不同,接著來說說,曾經以為應該會不一樣,後來發現到哪都一樣的問題。

到哪裡都有不尊重專業的人

就像前面所說的,即便在Amazon這樣的公司,還是會有不尊重專業的人,記得去年,我曾經一整個氣到在自己的Facebook上怒吼:『當初是哪個瞎眼的錄用你!』不過,面對這樣的人,在這些年訓練下來,大概已經有一套自己的SOP了。首先,在專案開始的啟動會議(kick-off meeting)上,清楚的說明接下來計畫做的事、需要的時間,並慎重的解釋每一個步驟背後的原因,最後,一定要確認大家都認同。接著,每一個步驟開始前,都要讓專案相關人員知道,期間,盡可能讓他們一起參與,步驟結束後,一起檢討,這麼做的目的是,讓他們『體會』你做事的流程,以及每一個步驟對專案成敗的影響。正所謂,身教重於言教啊(親身參與比聽一堆設計流程演講有幫助多了。)

最近才遇到一位資深工程師,特地在會議之後,跑來跟我說:『我從來就沒有想到只有三個畫面,卻要思考這麼多細節,原來,UX設計真的不是想像中的動動滑鼠而已。』

當然,還是會有些人在經歷過這一切之後,依然不把你的專業當一回事,這時候,就是主管需要出手的時候了。在前一個團隊,碰巧歷經兩個做事風格迥異的主管,事情發生後,A主管,跑去跟K產品經理(就是讓我怒吼的人)一對一解釋設計流程,並跟K的主管反應,然而,K依舊我行我素,不當一回事。接著,B主管接管團隊之後,K又在接近下班的會議中,提出設計需求,並希望隔天中午前能夠收到設計,B主管只有簡單回一句:『這不是我們的做事方式,period!』好個鏗鏘有力的period!在那之後,K就只能乖乖照個我們要求的流程,送出需求申請了。

簡單的總結,遇到不懂你專業的人,邀請他體驗你的專業,讓他信服;遇到不管怎樣都不尊重你專業的人,必須會堅定的說不,必要時,當主管的必須硬起來。

Amazon也是要加班的

以前的公司,常有機會跟北美的同事合作,當時最大的誤會是:『老外都不加班的。』現在來到了溫哥華,我變成了那個最不想要的加班的『老外』。然而,非得加班的原因有很多,例如專案時程很趕、專案複雜度超過當初的預期、跟跨時區團隊合作…等等。幸好,Amazon絕大多數的團隊對於在家工作的態度是很開放的,現在的老闆就曾經跟我說過:『你也不是第一天工作了,再加上能夠進入Amazon,應該也很清楚責任跟義務,所以,要在哪工作、要什麼時候工作,我真的不是很在意。』

平時花一點心思在專案進度管理,除了可以提高合作夥伴,對於你時程估算的信任感,也可以幫助你取得老闆的認可,讓你可以自由決定要在公司或在家裡加班,在家加班,心情上也會比較不那麼折磨,接著,再加上懂得挑選戰場的能力,就可以避免很多不必要的加班。回想過去,很多時候加班都是把時間花在很多根本不急、不重要的事情上,而真正重要的事,也許是因為太挑戰、也許是因為沒那麼有趣,拖到火燒屁股了,只好加班趕進度。

如果,你所待的團隊,加班是常態,那需要停下來思考一下加班原因是什麼?為了實現一個崇高的抱負?為了搶下一個重要的市場先機?還是為了改變世界(咦!)?又或者是因為時間控管能力不佳?花太多時間在當救火隊?還是老闆還沒走我不能走(啊~)?加班有時候是必要之惡,然而,加班要有意義,加班要有效率,不然,久而久之,疲乏了,能拖就拖,上班先看看臉書、跟同事哈拉哈拉,等到午休結束,再來看看今天想做什麼。

在家工作可以挑適合的飲料,幫助專注力(誤)。

UX絕不是最重要的

最後,這點由一位UX設計師來說,似乎很尷尬,不過,事實就是如此。不是公司文化的問題,至少,在我在待過的公司都一樣。如果,UX設計師在參與專案時,抱著一副『我將用最佳的UX設計來拯救產品』的心態(我剛入行就是這樣),那麼,UX設計師就是一個問題製造者(trouble maker),只會讓團隊對UX更不重視。一個產品要成功,絕不可能單純因為良好的UX設計而達成,即便像UX被大家捧上天的Apple,如果沒有超強的技術團隊、頂尖的市場行銷,跟賈伯斯(哈),它也不可能一直推出偉大的產品。

這些年下來,幾次碰壁之後,我的心態已經轉變,我的參與,是為了幫助團隊更深刻的探索客戶需求是什麼?如何才能更有效地滿足客戶的需求?然而,在我的定義中,產品經理是我的客戶、研發工程師是我的客戶、客服人員是我的客戶,當然,終端使用者也是我的客戶,唯有大家一起合作,才有機會推出成功的產品,設計跟研發不應該是敵對的陣營,大家都在同一艘船上,唯有產品成功,一切的努力才有意義。

再者,有不少時候,UX必須為了許多原因去妥協,善用各種用戶研究方法,去幫每一項設計方案訂出優先級別,同時,記住一個很重要的觀念 — 寧可犧牲功能完整性(scope)也不要犧牲使用者體驗(customer experience)。使用者很殘酷,他可以等你功能逐步完整,但是,萬一他的體驗很糟糕,通常就是一去不回頭,特別是在手機應用程式領域,開啟到決定刪除一個應用程式,一般只要八秒鐘。除非,你在產品提供服務的領域,是幾乎沒有替代方案,比方說,Amazon Web Services (哈!)

接著,就是坐下來好好跟團隊檢視,該如何妥協,最後,不管決定為何,都是團隊共同的決定,絕對不要在事後檢討時,把成敗責任歸咎於任何一個人。

即便Bezos說要成為全球最重視使用者經驗的公司,UX仍不是最重要的。

結論

其實,還有很多、很多的事沒有講,有個是因為聽來的、有的是因為不是那麼明顯、還有因為我手酸了。不過,幾個感觸最深的點應該都提到了,而且,仔細想想也沒有真的那麼L多不同。歡迎留言一起討論一下你聽到,或感受到的異同,大家一起交流一下。