UI Gathering 2007 Q3 參加心得

12月1號這場UI Gathering雖然辦得晚了些,報名的程序也有些紊亂,但是整個活動規劃卻是歷年來最具規模的。比起過去的溫馨、自在,這次的聚會顯得正式許多,有完善的場地、主題性議程、具啟發性的工作坊,參與人數也更勝以往,現場目測起碼有上百人。

UI Gathering 2007 Q3
UI Gathering 2007 Q3

這次UI Gathering的重頭戲,應該是易修的「設計角度談EeePC」,以及James O’Donnell 主持的工作坊「設計一個與糖尿病患有關的產品」。這兩個活動相當有趣,算是內行人看門道、外行人看熱鬧,深度與廣度兼具的好議題。看著大家對著易修的簡報檔狂拍照就知道了,這樣好的機會不趁機挖點寶,真的是很可惜,是吧?

我個人對於簡報資料沒有那樣著迷,倒是對於易修侃侃而談的小故事,以及工作坊的進行過程,有不少的感觸與啟發:

EeePC的開發過程,比產品更屌

時光回到一個多月前,由於身處在同一個產業裡,競爭與比較是免不了的,我們在EeePC發售的當天下午就已經拿到熱騰騰的實機,也著實地把玩了一圈。說實在的,當下看到EeePC時,並不覺得它在介面設計上有很大的突破,各個軟體客製化的程度不一,多工與整合的問題仍舊存在。舉個例來說,Skype跟MSN還是沒有整合在同一個介面下,在Email裡插入照片還是一樣麻煩。當時我們就在猜想,Linux整合客製化的問題,在華碩的研發團隊裡,應該也是一樣複雜難解吧?

結果是肯定的,Linux研發在哪家公司都一樣,免費的東西最花力氣,想要吃一頓免費的午餐,結果就是得親手下田耕種。只不過,在同樣艱難的狀況下,華碩團隊在開發過程當中所投注的決心與毅力,確實令人懾服。

設計角度談EeePC
設計角度談EeePC

據易修的說法,華碩在開發初期,為了整合EeePC所需的軟硬體,把30多位相關人員,包括ME、EE、SW、PM、UI等,全都抓到春天酒店裡,在兩天的時間裡,硬是要這群人把初步的系統架構一一訂出來。一開始方向並不是那樣明確,光是在按鍵的配置上,就有許多不同的意見。但是關關難過,關關過,反正操個兩天,又不含酒店住宿 (呵,華碩也很會cost down嘛…),大伙總是會硬著頭皮,想辦法盡快把系統架構決定下來。這個過程或許有些衝突與不自在,但是一群人總算是坐下來作了有效的溝通與整合,自此也為EeePC的架構定下基礎。

除了把30幾個人抓到春天酒店關兩天之外,華碩後續也投入相當多的研發人力,以歐美台三地、一天三班制的方式,日以繼夜地開發了半年。以這麼龐大的系統來看,半年的開發期真的相當短耶,這在軟硬體整合、跨部門溝通上,都是相當大的挑戰。不過華碩還是做到了,這也難怪,易修在簡報的最後,語重心長地強調「執行力」的重要性。是阿,關起門來做設計是一回事,實際做出來,並且及時把使用經驗傳遞出去又是另外一回事。EeePC的開發過程確實很屌,聽易修說這些開發歷程,比真的去用EeePC還要更迷人。

英雄所見略同!?

另外一個有趣的議程是,James O’Donnell 主持的「設計一個與糖尿病患有關的產品」工作坊。在這個工作坊裡,6個人一組的臨時團隊,必須在40分鐘內,根據兩位糖尿病患已知的生活習性與病理需求,為他們設計一個可以準時量測葡萄糖指數的產品或服務。

經過40分鐘的熱烈討論,現場10組團隊分別提出了各自的創意提案。有趣的是,白報紙一攤開,幾乎所有的提案都離不開手錶、耳環、戒指、手機等,只有第五組的感測貼布,以及第十組的人工胰臟比較突出外,其他的概念都大同小異,好像一個同一個模子刻出來的一樣。

這到底是英雄所見略同,還是大家的思考都太僵硬一致?不瞞大家,我第一個想到的也是手錶 (之後才想到筷子等餐具型偵測器),一點也沒有比較特別。只是現場各領域的60位UI設計師,想到的也大多是手錶之類的方向,如此高的一致性,可就真的出乎我的意料之外。

與糖尿病患有關的產品,各組都少不了手錶
與糖尿病患有關的產品,各組都少不了手錶

我想原因可能有兩個,第一是:缺乏足夠的第一手觀察。現場似乎沒有人是糖尿病患者,大多數人也都沒有照顧糖尿病患者的經驗。因此,現場沒有人真正體會糖尿病患者的難處,也沒有人深入了解他們的需求。在不了解糖尿病患者,而且現場也沒有患者可以觀察的狀況下,大家只好跳過他們,從身邊可及的裝置或服務開始聯想,直接去想解決方案,然後再套回到假想的病患身上,反推看看是不是有解決掉他們的問題。結果,一群手邊都帶著手錶的正常人,一起想出用手錶解決糖尿病患者的設計,大概也不是什麼值得意外的事。

第二是:從眾效應。在有限的時間內,要一個臨時組成的團隊,共同提出一個設計概念,並不是相當容易。最有效率的方法可能是,找幾個可能的方向,討論過後快速收斂,然後形成具體共識。一想到時間緊迫,又要一起上台報告,大家在討論當中總是會比較謹慎些,不敢作跳躍性的思考,或是貿然打斷當下正在討論的主要脈絡。在這種狀況下,最早被提出,或是最具可能性的做法,自然就會逐漸被包裹成主要結論。同樣地,一群手邊都帶著手錶的正常人,拼命地想尋求共識,最後又是手錶戰勝一切。

這算是英雄所見略同,還是大家都跳不出框框?網路上搜尋一下「diabetes UI concept」,看看各型各色令人噴飯的發想跟概念,大概就不言可喻了。 (哎,深切反省中…)

小插曲:不得其門而入的南港軟體園區

在參加聚會的過程中,發生了一個意外的小插曲。說來好笑也可恥,那就是,我居然被關在南港軟體園區的停車場裡,電梯上上下下來回了好幾趟,就是找不到一扇可以打開的門。

其實園區的停車場蓋得還蠻不錯的,車道寬敞,而且停車位也蠻容易進出的。在硬體上無可挑剔,可是在軟體上,就非常有問題。首先,停妥車走進電梯後,按一樓的按鍵卻沒反應,我傻了一下,是電梯壞了嗎?仔細端詳電梯裡的佈告跟說明,都沒有任何有用的說明跟指示。索性按下二樓的按鍵,電梯動了,看來電梯沒壞。

電梯門打開,我到了「所謂的二樓」,眼前看到的是明亮的大廳走廊,那剛剛那個昏暗的室內停車場,應該就是「所謂的一樓」吧?好吧,隨便你,開心就好。我往大片落地玻璃門走去,結果門沒開,也推不動,只見門上貼著告示:「於管制時間內,請刷卡進入」。刷什麼卡?停車卡、悠遊卡、信用卡?我沒有笨到一張一張試,想也知道,一定是「所謂的園區出入証」。我沒有什麼出入証,從停好車到現在,我一個人也沒看到,只在停車場入口跟機器拿了張停車卡而已。

這麼大的園區,總不會找不到地方進去吧!我開始懷疑,是不是有其他的出入口?該不會是剛剛那電梯的按鍵壞了,以至於讓我錯過了「所謂的一樓」?於是我換了台電梯,往一樓坐去,電梯門一開,眼前又是熟悉的室內停車場。傻了,我對這個空間的系統印象完全錯亂。

最後,在走遍所謂的二樓、一樓、B1以及B2之後,我終於確定,自己是被鎖在這個電梯間了。我用手機撥了「電梯故障專線」,很快地,電話另一端傳來熟練的聲音,用熟練的語氣跟音調,非常熟練地指示我到鎖著的二樓,熟練地替我刷卡開門,然後熟練地轉身消失在諾大的園區裡。

請刷卡進入,或者是打電梯故障專線求救
請刷卡進入,或者是打電梯故障專線求救

這是一個詭異的地方,真的。一個軟體園區,「硬體」弄得比「軟體」還要好,「電梯故障專線」比「大樓警衛」還要親切,真是相當令人不解。幾位當天卡在停車場,或是被堵在室外草地的朋友們,應該都跟我有一樣的疑惑:這是算是什麼使用經驗,這算是哪門子的軟體園區?

話說回來,要是James O’Donnell當天把題目改為:「設計一個南港軟體園區的門禁系統」,我想,大家想到的,應該就不只是手錶,而會根據切身之痛,提出各種瘋狂精采的idea吧!

延伸閱讀:

Diabetes Management Research — There’s No Vacation from Diabetes
http://www.adaptivepath.com/blog/2007/08/14/charmr-creating-concepts/

設計角度談Eee PC@2007 UI Gathering
http://www.lis186.com/?p=1795

UI Gathering 2007 Q3 Photo Set
http://www.flickr.com/photos/lis186/sets/72157603348566397/

作者:

David 陳文剛

長期專注於UX設計創新,專長為design coaching, team facilitation & consulting. 現為AJA Creative 使用經驗總監,UXTW 台灣使用者經驗設計協會 共同發起人。

在〈UI Gathering 2007 Q3 參加心得〉中有 1 則留言

  1. 關於文中最後一段小弟我深有同感耶

    還好我們朝著人多的地方移動也歪打正著找到

    這算不算映證了老話一句”往人多的地方就對了”…. :p

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *