使用者研究＠Uber — 黑幕後的驚奇
寫這篇文章的一個半月前我從微軟加入了 Uber。主要原因是想要一個步調更快、更忙錄的工作環境。加入的三天後便做完一個小專案，兩週內規劃了為期近一個月的使用者研究，帶著十幾二十個同事去了三個國家，進行針對四類目標族群六種不同型別的研究。即便是這個速度（註一），還是時不時會聽到經歷過 Uber 過去歲月的同事說，你以為這個算快嗎？以前才叫誇張呢。
（註一：請勿以亞洲速度來評斷，美國規模較大的公司大部分很悠閒的。）
從微軟這個成熟穩定的大企業，來到換了 CEO 後狼性銳減但尚存的Uber，在短暫的時間裡已經有幾件從使用者研究員角度來看相當印象深刻的事。我在面試的時候偶爾會問面試官這個問題：加入這間公司後有什麼讓你改觀或驚艷的地方。如果今天換過來有候選人這樣問我，下面三點可能會是我的回答。
1. 非 UX 人員對使用者的熱忱
在許多公司，使用者研究員通常是最瞭解使用者、花最多時間跟使用者相處的人。Uber或許因為產品性質的關係（幾乎所有員工都是使用者），也或許只是剛好招募到重視使用者的人，公司裡不論職種，對使用者的需求與痛點都有一定程度的熱忱與瞭解。
工作第一週我做了一個很小的易用性研究。這個測試是臨時決定的，只有不到一天的時間準備，一切非常快速粗糙（quick and dirty），因此我沒有邀請任何團隊成員以外的人參與。西雅圖辦公室最大的負責人不知如何得知我們在進行研究，請他的祕書寫信給我，說他也想參加，要我把行事曆邀請發給他。雖然他最後因會議時間衝突沒有出現，但此舉已經讓我非常感動。過去為了要讓其他人參與觀看測試，使用者研究員通常得使出渾身解術，包含一對一面談分別擊破、利用咖啡甜甜圈吸引人等。
其中讓我最驚豔的是一個從微軟來的工程部門經理，過去負責微軟的開發者雲端軟體。姑且稱他為Ｄ好了。在微軟，一般工程經理幾乎是對使用者研究沒什麼興趣的，更不用說像 D 過去所在的B2B 產品團隊。然而，每次Ｄ到一個新的城市旅遊或出差時，總是會進行他自己的使用者研究 — 圖文並茂地記錄從機場開始搭 Uber的體驗、遇到的困難、與司機的談話、自己的觀察與發現等。寫完一整份檔案並分享給整個團隊後，他會在文末附上改善意見，標注相關功能的負責人，尋求行動。
為了更好地理解司機與乘客，我自己也成為 Uber司機，每天睡前開幾小時。但我不知道有家庭以及三個小孩的Ｄ也在開。Uber司機是個非常耗時耗心力的工作，尤其是在一份全職工作之餘。當我還在緩慢地撰寫我的司機心得文時，Ｄ已經自發地寫了一篇完整的心得、做了投影片、利用中午的全員會議時間向整個辦公室分享他作為司機的經歷。
當然Ｄ可能是個特例，想證明自己也可以從 B2B 轉向 B2C。其他人或許沒他這麼積極投入瞭解使用者，但到目前為止我的使用者研究中，從工程經理到最大的總產品經理都主動做筆記、錄影拍照等。團隊中許多人也對使用者研究有一定程度的理解。由於專案的時間緊湊，我無法一人執行所有的研究，有相關經驗的設計師跟專案經理便主動說他們可以分攤數場訪談，我甚至不需要跟他們解釋該如何訪談。過去我總是獨自完成所有研究相關的事，從做筆記到拍攝到出差，其他人只需坐待結果，研究員以外的人如此投入的協助也是我所沒遇過的事。
有些研究員會覺得如此降低了研究員的價值，況且很多產品經理或設計師說自己懂使用者研究，但其實一知半解。我想這樣的「好處」也帶來不同挑戰——如何保護自身專業與價值，同時讓覺得自己很懂的團隊成員有足夠貢獻與參與感。
2. 真正在真實世界中被使用的產品
Uber 在南美洲有車隊（Fleet）與現金支付與這兩個產品。車隊是給有數臺車的車主租他的車給其他人當 Uber 開；現金支付是給信用卡或數位支付不普及的市場中的乘客另一個付費選擇。
某天我在總部認識了一個新入職的同事，過去在德意志銀行負責防治洗錢。他說在一些南美洲國家，毒梟很有可能透過 Uber 這個平臺來洗白販賣毒品賺來的現金。如果將一大筆來路不明的現金存到銀行，勢必會引起懷疑。因此，毒梟招募大量人馬成為司機與乘客，把現金拆散成小筆給乘客，讓乘客搭自己的車隊去任何地方，利用現金付車資，這筆錢便成為乾淨的收入了。
他的工作便是防範這類事情發生。簡短的對話讓我對Ｕ這個平臺在實際生活中應用的可能性驚訝不已。
在體驗設計中，跨渠道的體驗總是特別有趣。以 Outlook這個產品為例，雖然人會在不同平臺不同情境下使用 Outlook，人終究還是透過一個數位介面在與之互動（至少以目前來說是如此） 。Uber 有趣之處在於，許多互動是線下的，就體驗設計來說有許多額外需要考量的地方。例如，Uber 在南美洲發行現金付費一陣子之後，司機夥伴多能理解該機制，也知道應該要去繳平臺費給Uber （若乘客是透過數位支付，司機收到的錢已扣除平臺費用）。然而，當地的客服部門卻遇到一個難題——司機們帶著大筆現金要來繳費，客服部門卻沒有收納現金的能力與機制。遠在舊金山的產品團隊在設計時忽略了整個旅程的末端，以及不同後臺部門可能會因此遇到的狀況。
司機、乘客的安全是另一項重要考量。在使用產品（乘車與開車）的過程中可能會發生各種狀況，Uber 招募了過去曾任職歐巴馬祕密保安的成員，來加強 Uber 的安全性。這也是我過去的工作中不太需要考慮到的問題。
3. 更密切的跨部門合作
使用者中心設計與設計思考不斷強調跨部門、跨角色合作的重要性。一方面是帶進不同觀點，一方面整合各部門有的片段的使用者資訊，確保使用者有一致的跨渠道體驗。
在企業端實際要做到很難。過去我主要的合作物件是產品經理和設計，偶爾和資料科學家、業務、行銷開會，工程師幾乎只有在有大型研究結果分享時才會出現。
加入Uber 第一天讓我最印象深刻的事是，在幾乎所有大大小小的會議中，除了工程師、設計、產品經理鐵三角很合理的會出席外，資料分析師以及產品營運（註二）等也在會議中。
當然，這樣的設定使每個人的會議時間加長。確實，過去在微軟時，儘管我所在的組織開發且力推了不少保護個人專注時間 （Focus Time）的產品與機制，我卻從來沒有需要用過。在 Uber 才第一週，我的行事曆便完全被會議佔滿，需要把行事曆上任何一點空檔都擋起來才有時間工作。然而就我看來，這個公司的資訊跟資料太多，每個人能掌握的知識有限（例如我無法獨自詳細追蹤 Uber 在美國西北25個主要機場的規範跟狀況），在相對早期將不同部門拉進來討論，能更好地利用組織隱性知識，並避免忽略重要的限制或考量。
（註二：營運團隊在各個城市負責跟政府、法規制定者、司機夥伴等協調溝通，並負責客製化 Uber 在不同城市的設定及定價等，確保 Uber在各個城市與區域能順利運作。Uber 的產品團隊大多集中在舊金山，每個城市則是有各自的營運團隊。）
Uber 在2017 年經歷了風風雨雨，名聲至今仍尚待加強。我在微軟的老闆對於我的選擇疑惑且擔憂，不斷提醒我苗頭不對就趕快回來。或許再過不久我對這個產品與公司的看法又會不同，但目前為止這個產業的複雜性及使用者研究團隊的能力，仍是十分吸引我的。
＊本篇純為個人觀察與心得，與公司立場無關＊