Wesley 前幾天寫了一篇讓我心有戚戚焉的「你是做UI的,那懂不懂UX」一文,裡面提到了 UI 設計師被問到有關 UX 工作的愛恨情仇,身為一為略懂略懂的 UX 工作者,突然很想從 UX 角度回去看 UI,到底 UI Designer UX Designer 這種互看不爽「既生瑜何生亮」的若離若即怎麼來著。

警告:以下文字含有大量哀愁與悲傷,請小心服用

設計是問題與解決的最大公約數。

Wesley 內文提到兩個最重要的角色:使用者界面設計師(UI Designer)跟使用者經驗設計師 (UX Designer),避免後面的咬文嚼字,我就簡稱它們為 UIer UXer 吧。

從古至今,人就是不斷的製造問題和解決問題,因為要讓生活更便利更美好,所以人們得想辦法把問題解決,雖然有時候會讓更多問題被產生。也因為這樣的關係,有許多社會科學被發展出來,這些社會科學都有一個共同點,都是為了解決「人」的問題。

和純科學比較不一樣,人是感情的動物,每個神經元在傳導與散佈時,因為過於離散所以無法正確的推斷這和實驗室裡可操控的結果有所不同。也因為人有感情,會思考,所以至今人工智慧仍無法追趕上「真人」的智慧,就算電腦再會運算再會記憶,它們終究不是生物。

如果你是一位使用者經驗設計師,UXer 的最主要工作會是解決「人」的問題,這個人可能是用戶,可能是用戶身邊的人,可能是老闆,可能是出資者,也可能是政府部門的誰。在這樣的定義下,「使用者經驗」已經不全然是透過 UI 和系統互動的那個「人」而已。

當然,一位使用者經驗設計師的養成訓練中,我們有許多科學方法和計量工具可以協助設計師有效率的產出結果。專案是有時程,預算是有限,老闆是有壓力的,沒有一個單位可以讓設計師不顧其他合作單位慢慢的產出結果。到這邊為止,我們仍然是把設計當做問題和解決的最大公約數。

設計是一連串的為什麼。

問問題也是一個工具,如同筆者前面提到,UXer 透過科學方法和計量工具去探索世界,然後將設計交付給 Stakeholder。誰是 Stakeholder?Stakeholder 在組織中又扮演怎樣的角色?

你想想看誰在團隊中拿著棒子站在你身後,如果你不乖就給你一棒,那人就是 Stakeholder。

在這樣的氛圍下,有時候 UXer 也不是真的是在研究用戶,往往是為了 Stakeholder 的喜好來做設計,所以筆者戲稱 UXer 為 Stakeholder Experience Designer。當一位使用者經驗設計師在問為什麼時,他們除了想知道用戶的喜好外,有一大部份的時間是在和真實世界(主管、程序猿、攻城獅、腦闆、出資者)打交道,畢竟 UXer 不是純藝術家(不過他們常自認自己是藝術家,so do I),他們設計出來的東西不是放在美術館裡收藏的,是要給人用的。

你是做 UX 的,那會不會畫 UI

自從筆者到美國耍廢之後,對於「略懂、略懂」這件事又有更深刻的體驗了。在筆者之前就讀的設計課程是隸屬於資訊學院之下,我們戲稱學生可以分三類:會寫程式的、不會寫程式的、和不會寫程式又不願意學的。對於會寫程式或者是願意學寫程式的學生,通常會有一種共通特質:資訊素養較佳。從維基百科可以知道,資訊素養(Information Literacy)是確認資訊、檢索及尋獲資訊、組織及整理資訊、使用及創造資訊、評估的能力(張臺隆,2004)。資訊素養較佳的學生,問題解決能力也較強,所以在作品呈現時,往往也都能拿出比較好看的結果。

ElnFBTq

當你問那些學生,你會不會畫 UI,他們的回答都會是「Yes」。

努力不代表有能力,能力不等於實力,實力也要看努不努力。

不過我們又可以把能力分三種層次,第一種是自己覺得自己會什麼,第二種是別人覺得自己會什麼,第三種是自己真的會什麼。回答會的人,不代表真的會,但代表他們願意,或者是有辦法找到解決方法。畢竟表現出態度,往往才有機會領到入場卷。

略懂

然後在亂世之中,又不是「略懂略懂」就夠了,對於 UXer 來說,Capacity 非常重要,如果能認清這個事實,對於被問到會不會 XX 時就不會如此糾結。

既生瑜何生亮。

從團隊的角度來看,不就是搶功勞先分工合作,一起盡快把專案結束。筆者個人認識也非常欣賞許多優秀的 UI Designer,他們設計的功力,對於產品的執著,都不是一時半刻可以追趕上的。也因為如此,我不認為 UIer 一定要跨做 UX,相對的,UXer 也不能因為略懂 UI,就把工作給統包了。術業有專攻,行行出狀元。不管是使用者界面設計師或是使用者經驗設計師,都是為了要讓人們的生活更美好而來到這個世界。

138199077202

學習對方的語言,是為了要和對方溝通,而不是要取代對方 – 至少我是這樣告訴我自己。