最近恰好在 review 申請 UX 暑期實習的 design exercise。說實話，我最初沒有任何心理預設值，但當我看完第一份 exercise ，毫無防備地被感動到了。不是因為這個申請者的 design solution 有多麼創新，或是視覺上多麼美觀，而是我透過這份 exercise，看到了他在資源有限的情況下為了理解使用者需求所做的努力，看到了他緊緊圍繞著需求來進行設計，之後又透過 user testing 來檢驗設計的可行性，對結果進行反思、再設計。
這彷彿一切都聽起來平常得不能在平常。但在工作兩年多後，可能是因為工作內容隱私、或是時間人力資源有限、或是立項方式各式各樣，總之使用者調研的機會比較有限。我有時候感覺距離使用者彷彿很遠，都在憑“假設”和”直覺“進行設計，也因此走過彎路。在面試別人的時候，我們對於因為這種那種的限制，而”缺少對使用者的理解“的現象，好像有種心照不宣的默契。
於是當我看到這份 design exercise 後，
這種對“使用者”或者說對“人”的一種關心，這種為了“瞭解使用者需求”而想盡辦法的努力和熱情，讓我特別的感動，也帶給了我啟發。
所以在這篇文章裡，我想談談自己在工作中為實踐 ”以人為中心的設計“做過哪些嘗試和努力吧。
First thing first： Understand the problem（第一步：理解、定義問題）
剛開始工作時候很迷茫的一點就是
面對一個新專案不知從何下手
。有時候給我機會提問，我都不知道從何問起。由於對 constraint 的不瞭解，曾經花很多時間做 design exploration，但其中有好多在方向上就是不對的，於是白白浪費了精力。這一點聽起來是老生常談，但我在自己和周圍同事的身上，看到同樣的劇本一次又一次地上演。因此，我覺得
找到那些關鍵的、可以 define problem space 的問題十分重要
，能夠幫助我們少走點彎路。
逐漸地我找到了幾個放之四海而皆準的問題，可以幫助我們迅速在 high-level 上了解一個專案，並且能引出更多的細節問題：
What is the user problem？ （重中之重，從 user 的角度思考）
Why it‘s worth solving？ （impact 如何呢，意義何在？product value？technical value？）
How do we want to solve it？ （有沒有一些初步的方案、已知的流程呢？）
How do we measure success？ （定量還是定性？有什麼具體的 metrics 嗎，比如 CTR？）
What is the estimated timeline？ （根據 timeline 調整專案優先順序和設計流程）
我透過和 PM 共同探索這些問題，在大方向上爭取達成初步共識。接著我會根據對這個領域的瞭解，問更多有關 dependencies 和 constraints 的問題，比如說用什麼平臺、什麼裝置、和什麼 team 合作，是否有需要遵循的 design framework，有什麼技術上的限制，legal 上的限制，等等。這個過程好比用一個個面，在空間中切割出 problem space，然後在定義好的 space 中，進行有目的的設計。
聽起來好像挺簡單的哈哈~但在不同的領域，面對的問題也會不一樣，建立起適合自己的問題列表還是需要一點積累的吧。
Solve real user problem （解決“真實存在的”“使用者的”需求）
剛剛談到了“Understand the problem”，那我想接著聊一下對於“problem 真實性“的驗證。不像學校裡的專案，為了培養我們對方法的熟悉程度和應用能力，我們總是可以先做個 user study 搞清楚需求，再按部就班地開始設計。實際工作中，一個新專案可能始於工程師弄出了個新技術，可能是 design sprint 上一個拍腦袋但看著酷炫的 UI，也可能源於 PM 對產品發展空間的分析或直覺。
立項方式多種多樣，這本身沒有問題的，我其實蠻喜歡這種動態的平衡。但是，有時候我覺得一個專案開始的猝不及防，於是就忍不住問自己：我們的使用者是誰？他們真的有這個需求嗎？做出來的東西會有人用嗎？慢慢地我發現，在專案初期，尤其是在做業界沒有先例的專案的時候，
concept validation
（產品驗證）的重要性不容小覷啊。
工作中難免會有 solution 先行於 problem 出現的情況。作為“使用者的代言人”，我認為設計師一個重要的責任就是“挖掘使用者需求，驗證真實性”，然後把它和技術或產品的價值進行匹配。
前年“小紅書”的設計總監鄧超來灣區做過一次經驗分享。他講到在小紅書的初期，他們團隊商量後覺得，做旅行指南是個不錯的主意。於是，他曾經帶著這份“香港旅行指南”來到香港出入境管理中心，找準用戶群（去香港的，有空聊天的，女人 ），讓他們去試用 demo，給出反饋，是否需要這個產品。他說：“如果最有可能用你的產品的人都不喜歡，那這個產品生存的可能性就非常小了”。
Concept validation 最直觀的一個方法就是”找準用戶群“，然後聽聽他們的想法。我有時候會和 user researcher 合作，做一些 concept validation 的使用者調研。拋開 UI，而去關注使用者的需求和習慣。也曾經沒有時間去安排一個正式的 user study，我就趁著中午大家吃飯的時候，找獨自吃飯又看著不趕時間的人聊天，請他們給些 feedback。當然了，嚴謹性有待考證，需要辯證地看待調研結果。除此之外，我還發現和親手 build 這個產品的 eng 聊聊天會有意外的收穫。Eng 每天花巨大的時間精力在一個產品上，在一次又一次的 build 的過程中，往往有比較深入的觀察和思考。有的 engineer 的 product sense 很棒，對使用者的需求敏感，跟他們聊天也會帶給我一些新思路。
Evaluate your design as a user， not designer （以“使用者的角度”來評價設計）
在設計過程中會有很多 ideas，會畫很多很多的 mocks，而最後進行測試的只有一個或是幾個 UI。在這個過程中，我們會進行許許多多的比較，才能慢慢 narrow down 到一個比較有信心的方案。不過，
你有留意過自己是如何比較不同的設計方案嗎？
我發現自己有時候會不自覺地脫離“使用者需求”，單純地用“設計師”的眼光來評價設計。比如說，我要設計搜尋頁面結果的 UI，正在 list 和 grid 兩種 layout 之間做比較：“嗯，我覺得 list 好，因為視線豎著掃描下來很迅速，便於快速瀏覽；而 grid 需要折線形掃描頁面，瀏覽起來比較費力。”
可是，我覺得什麼比較好並不重要，甚至不一定對；
我要做的是站在”使用者“的角度去想，他們需要什麼，哪種設計更好地滿足了使用者的需求？
接著說 list vs grid 這個例子。我預設的是對於使用者來說”快速瀏覽“最重要，而我可能沒想到的是，對於我要服務的使用者群體，他們最看重的不是瀏覽速度，而是頁面所顯示的資訊量。如果用 list 的話，一個頁面可能只能顯示 6 條結果，而 grid 可以顯示 8 - 10 個。
當然傳統的 user study 可以幫助我們找到答案。可是每天要進行那麼多的 design explorations，這時候有個方便快捷的方法就十分有幫助了。
這個方法就是”自言自語“ (think aloud)。
靈感來源於一次 pilot user study。有一次我和 user researcher 合作，打算找一些參試者比較幾個設計方案。她為了檢驗 study script 是不是涵蓋了我想了解的所有問題，於是讓我假裝當用戶，過一遍 script。我跟著她一步步地想象著我的需求、使用情境，就在她讓我拿著手機試用這幾個 demo 的時候，一下子豁然開朗了。就好比鑽進一個死衚衕太久，忽然跳出了設計師的固有視角，獲得了很不同領悟。這讓我想起來，以前上學的時候，偶爾去請教學習好的同學一道題該怎麼解，正跟他們描述著問題呢，說著說著自己就想明白了。
Think aloud 有兩個重點：
第一，要講出聲音
。因為在心裡想很容易就注意力分散了，思路也被打斷；
第二，要有一些情境代入。
比如從demographic、到場景、到需求等等，儘可能貼近你所設定的使用者群體。舉個例子：”我是個在銀行櫃檯工作的職員，剛結束一天的工作回家。癱在沙發上好累，於是我開啟某個 app 看看搞笑影片。（拿出手機，開啟 app）嗯。。。主頁有新推送了，不過沒有我感興趣的（下滑 & 接著瀏覽）（滑了3、4次）這列表也太長了，算了不看了。“ 哈哈大概就是這種感覺，有時候說一說，可能就開竅了~
方法其實沒什麼難的，我認為難點在於有意識地跳出“設計師”的死衚衕，把“從使用者需求的角度思考”變成一種習慣。
好啦，關於“使用者”就先說這麼多啦。工作不是一個人的事兒，是一個團隊的事兒，所以下一篇就聊一聊溝通與協作吧~
上一篇：YIBO：我在 Google Search 做設計的 950 天：序言
下一篇：YIBO：我在 Google Search 做設計的 950 天：團隊溝通與協作
