UX設計師的時間都花在哪裡 — 寫給專案經理及工程師，也寫給設計師
一個產品的誕生幾乎都需要這三個角色的緊密合作，而這三個角色的人數加起來也往往超過產品團隊人數的一半，所以這三個角色之間的理解、誤解也就成為產品開發背後很有趣的宮廷劇。本來是想紀錄一個簡單功能怎麼繞了一圈又回到原點的設計之旅，不過想想之後，從幫助產品團隊夥伴彼此了解的角度切入也蠻有趣的，所以，就開始吧~
前言，有次剛好比較有空，所以雖然是個小功能，我也希望儘量地把體驗做到最好。是的，「有空」…很現實的是，想好好地做好每一個設計往往也是需要天時、地利、人和的。在對的時間(手上沒有一堆時限ASAP + 重要性Must have的工作)遇到對的人(老闆、專案經理、合作工程師不會看到你的工作空檔就眼睛一亮），並不只是用來形容愛情。這次的功能是要在系統中加入一個讓使用者選擇產品使用國家的設定，幫助我們可以確保WiFi的收訊設定以及時間會是正確的。是的，當時我也很難相信這些無法做到自動化，不過這些細節有點離題了，可是我保證我花不少時間在溝通跟確認這些真的是目前無法做到的。
在開始跳進去流程的細節設計之前，我總是會先上網儘量搜尋有沒有相關的好設計可以參考，或是這樣的功能介面有沒有哪些已知的痛點需要用設計去克服。許多人常常會把吸睛的設計跟好的設計混為一談，吸睛的設計需要具備突破既有框架讓人眼睛為之一亮的特質，但好的設計更專注在是否有效地解決使用者的痛點。剛開始做設計時，總會不由自主地希望做出吸睛的設計，而起點不同造成的結果可能是『每個設計看起來都很聰明但是並不是都有獲得好的使用者回饋』跟『使用者不會意識到每個你做的設計但偶而會有一些好用又聰明的設計激發出來』的差別。前面已經提過，我們需要使用者告訴我們他在哪個國家使用這個裝置，而聯合國總共有193個國家，如果要直接選擇國家絕對不是件簡單的事。上網搜尋一輪後，發現類似的設計主要有這些點需要注意 - 1. 指示必須清楚，國籍、使用地及語言相當容易混淆。 2. 國家名字可能有不同的習慣用字，例如荷蘭可能叫做Holland 或是 The Netherlands，要考慮兼容的問題。 3. 雖然英文是相當通用的語言，不過每個國家的選項應該還是要以當地主要語言做標示，以確保絕大多數的人都能理解。 4. 要把某些比較可能被選擇的國家放在列表前面應該要有所依據，不然也許會不小心觸碰一些國家敏感的神經，同時也能給予每個國家的人民基本的尊重。 5. 國家列表依字母排序是比較安全的做法，但是相對無法透過列表順序的安排提升選擇的體驗。尤其當國家是用不同語言列出，或是某些國家慣例上的排序並不真的是用首字母，例如The Netherlands 通常是排列在N的序列中，排序也是一門學問。
有了上述的了解後，一個同時允許使用者利用搜索或是瀏覽做選擇的互動介面看起來是個很不錯的選擇，而且搜尋應該要支援模糊搜尋，這樣使用者輸入Holland時，如果你提供的選項是The Netherlands還是可以被找到。至於設計的細節我就不多談了，這裡有一篇很不錯的文章可以參考。但就當我興高采烈地認爲已經做足準備要開始做細節的設計時我才發現一件事，因為VR空間為了配合人類視野的特性是橫式展開的，而這個功能的介面是呈現在一個嵌入的橫式手機介面之上，如果有特別留心過，手機的橫式介面其實是非常不友善的，尤其是像『設定』這種比較不會特別用心去做的介面上。在橫式介面上，鍵盤一跳出來基本上就擋住了絕大部分的空間，更不用說使用者能怎麼利用下拉式選單在輸入部分關鍵字之後快速選到他要選的國家。所以最終考量到這個功能的使用頻率跟有限的資源，我還是只能做一個分層的清單瀏覽設計，讓使用者先選擇國家所在的區域，然後在這個區域裡面將我們直接出貨的國家擺在列表的前面，這樣使用者就都能在選擇區域之後的第二層頁面在不超過六個國家的第一部份列表中找到自己要選擇的國家。
這樣的設計交到專案經理及工程師手上的時候，很容易產生『這麼簡單的設計為何你需要花那麼多時間』的誤解，不過UX設計師在團隊裡本來就有個很重要的任務 - 將使用者體驗盡可能地優化。而且就我的經驗而言，這些時間一點都不會白費。一來如果在某個探索時發現了什麼可行的方案，整個體驗也許就大大不同了；而就算繞了一圈之後發現常見且直覺就能想到的做法可能就是目前最好的做法，至少在團隊內部及對外部溝通時，因為已經探索過所有的可能性，所以這些溝通也能更順利、更快速地進行，最終一樣有益於產品的開發。當然我也有過很多相反的經驗，因為時間實在太趕加上常見的設計似乎就可以直接套用，所以整個產品團隊就直接往那個方向進行，不過等到產品功能大概有個雛型之後，突然發現這邊有個小問題，那邊又有個小爭議，結果就是花了更多時間在討論上，然後甚至會發現一個似乎更恰當的做法，於是的東西只能或多或少的打掉重做。
這些常見的誤解我覺得並不是任何一個人的錯，而是團隊每一份子需要一起努力的責任，設計師有責任幫助幫助其他成員了解為何我需要這些探索的時間，這些探索能怎樣幫助到產品而不是一種設計師的偏執；產品經理應該要給團隊的成員適當的時間完成開發，因為他們應該是最有經驗最知道欲速則不達的人；而工程師除了在開發程式上的全心投入，也應該把體驗也當成自己的責任，有任何的想法、任何的疑問應該都要能隨時提出來。因為只有一件事是最真真確確的，出了問題再來互相怪罪指責，對產品絕對是一點幫助都沒有。
