【我們為什麼挑選這篇文章】準時下班、跟許多強者一起並肩奮鬥，這可能是很多人對跨國企業內部的工作想像，不過實際上在 Amazon 工作真的事這麼一回事嗎？本文作者 James Liu 從工程師轉職 UX 設計師，進入 Amazon 工作三年後觀察到許多跟台灣企業不同的文化。從他的經驗中，我們也能進一步訓練思考，並從自身文化中跳出看到不一樣的觀點。（責任編輯：鄧天心）
幾天前，加入Amazon的日子不知不覺滿三週年了。碰巧有位朋友也在這個時間問我，在Amazon做設計師有沒有什麼不一樣？剛好，利用這個機會好好來回顧一下自己在這1000多個日子的感受。不過，這些只是我個人待過的公司、團隊的經驗，並不代表全部。
長話短說，自己覺得除了從50%的英文變成100%的英文以外，其他的，真的沒有太大的不同。然而，既然朋友是問：「在Amazon做設計師有沒有什麼不一樣？」那我就從不同的地方先來分享。
知道如何問問題是一種基本工
會不會問問題，在Amazon是一個非常重視的基本能力，它受重視到在面試時，都被當作一個重要的考核指標。
我曾經聽過不只一次，來參與面試的人，各項專業能力都非常優秀，最後卻沒有被錄取，原因很簡單 — 面對面試官提出來的實作測驗，一個問題都沒有問，或者問了一些無關緊要的事，就開始作答。這樣的案例並不是只有發生在設計師的面試，即使工程師也一樣。
也許是台灣教育使然，在唸書的時候，許多學生常常都是老師說什麼就背什麼，不管懂不懂、對不對，考試背出正確答案就好，因此，對於問問題並不怎麼在行。
離開了學校進入職場，因為鮮少有這樣的訓練，對於主管的要求提出問題，更是戒慎恐懼。再加上，鄉民們常說，台灣私人企業、政府機關對於解決問題的方式，都是解決提出問題的人，似乎都在告訴大家，問問題等於找麻煩，因此，許多會議中，總是惜字如金，沒有被cue到，絕不講話，我也一直是這樣，不覺得有什麼問題。
然而，在從工程師轉換至設計師跑道之後，主管常常對我的設計，提出各種我事先從來沒想過的問題，讓我常為了自己沒搞清楚問題，就急著動手而犯了一些低級錯誤（rookie mistakes）感到無地自容。
為了避免再犯同樣的錯，便強迫自己在每次開始設計之前，就把所有將來可能被問的問題，都先對自己問過一輪，回答不出來，就去問到答案，經常搞到快要人格分裂。但是，也因為這樣，漸漸把提問的能力磨練出來。
從一位UX設計師的角度來看，對產品經理問對的問題，能幫助你的設計，確切滿足商業目標；對工程師問對的問題，能幫助你在已知的技術限制下，提出創新的方案；對使用者問對的問題，能幫助你深入了解使用者的渴望，提出不僅可用（Usable）且有用（Useful）的產品。
在Amazon，人人都是提問高手，如果你沒有在專案開始前，把一些重要的事問清楚、搞明白，在設計提案討論會時，肯定會被問到啞口無言、腦袋空白，漸漸地，你的專業能力便會開始受到質疑。一旦失去了團隊的信任，將很難在這個團隊繼續待下去了。
Amazon 溝通文化：具體讚美
另一個在Amazon感受最大的不同是，大家都不吝於感謝或給予讚美，而且，是非常具體的讚美，這也是從小在台灣長大的我，非常不擅長的一件事。過去，每當同事拿著設計來請我給意見的時候，總覺得，沒有讓他抱著一堆改善的建言回去，會讓對方覺得我不專業、吝嗇、留一手，所以，我都絞盡腦汁的挑出每一個可以給予意見的點，然後，帶著滿意的笑容看著同事，心想：「應該有讓你滿載而歸了吧。」
然而，在Amazon每一次的設計提案討論會，與會者一定都會從我的設計中，找到他喜歡的，並積極給予鼓勵、讚美，而且，是具體地說出哪些部分是他欣賞的，絕不會有那種「辛苦你了」空泛的口號。
漸漸地，我慢慢體會讚美比批評（給建議），有更強大的力量，推動人們努力往更高的目標前進。如果，一場會議下來，你只有收到一堆改善計畫，接下來，會先感到挫折，然後，再由挫折轉成憤怒 — 我浪費了那麼多時間努力，竟然毫無建樹！就算最後化悲憤為力量，往往也打了一些折扣。然而，如果在建議之前，有收到一些具體的鼓勵，挫折感或許會大大降低，一般來說很少會進一步轉成憤怒，提案者很快就可以整理思緒，開始著手改善計畫。
我發現，這樣的方式套用在孩子身上，一樣管用（菸～）
更開放的環境更要懂得挑選戰場
我在Amazon的第一位主管，是個貼心、笑聲很爽朗，做事實事求是的德裔美國人，從她身上學到了許多一身受用的觀念。記得一次在討論工作規劃時，她告訴我，在Amazon，不會有人告訴你什麼該做、什麼不該做，你必須懂得挑選自己的戰場（pick your battles）。以前在台灣，主管總會跟我討論每年的工作項目，甚至到這個月要完成什麼都規劃好了，很開心在這樣的溫室裡上班，每天幾乎只要照表操課就可以了。
然而，加入Amazon之後，好像從一個整天被鞭子抽的私立高中，進入了放牛吃草的大學，突然間，好多事都想要做、也有好多事都懶得做，一段時間之後，發現比較自律的同學跟自己的程度越差越遠，驚覺好多事應該做、卻也好多事來不及做了。
UX設計師在Amazon是個稀缺的資源，總有一堆案子想要你的幫忙，即便你無止盡的加班，都不可能全部交付，然後，還有一堆很有趣的案子，你迫切渴望地想參與。如果你不懂得正確地把時間，投資在值得做的事上面，到頭來，在做年終回顧的時候，你會發現說不出一個滿意的成績（success stories），覺得自己又瞎忙虛度了一年。
至於，什麼才是對的戰場，什麼才是真正值得花時間的專案，我自己的衡量方式很簡單 — 我能為哪一個專案帶給最大的價值（UX impact）。即使在Amazon，仍然存在部分人把UX設計師當成美化介面的工人，像這類的專案，每幫一次忙，就是在強化認同對方的觀點。
基本上，能不做就不要做，或者是用最少的時間去完成（有很多方法可以達到這個目標，將來有機會再說）。如果，你發現你總是在做累案子，是時候去找你的主管聊聊了，這種案子做再多，對你的能力不會有什麼提升，對整個設計團隊的價值，也不會有任何加分。
講完了三點體會最深刻的不同，接著來說說，曾經以為應該會不一樣，後來發現到哪都一樣的問題。
到哪裡都有不尊重專業的人
就像前面所說的，即便在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 （哈！）
接著，就是坐下來好好跟團隊檢視，該如何妥協，最後，不管決定為何，都是團隊共同的決定，絕對不要在事後檢討時，把成敗責任歸咎於任何一個人。
結論
其實，還有很多、很多的事沒有講，有個是因為聽來的、有的是因為不是那麼明顯、還有因為我手酸了。不過，幾個感觸最深的點應該都提到了，而且，仔細想想也沒有真的那麼多不同。歡迎一起討論一下你聽到，或感受到的異同，大家一起交流一下。
__
（本文經原作者 James Liu 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈我在 Amazon 擔任UX 設計師的三年心得回顧〉。首圖來源：flickr CC licensed）
延伸閱讀
Amazon 面試 SEO PM 超詳盡過程分享：不同領域主管對談、追問式提問
