May 2015

五年,養成

2010 年,我認識了 ilya,跟他一起在中研院辦了場「Digital Natives Workshop」活動;那一年,我很不習慣他教我的「做事方法」。囉嗦,大概是認識他的人都會用以描述的形容詞,不過這不足於描述他帶人時所表現出來的氣度,「沒事找事做、把事情複雜化」我認為是更為具體的描述。

當年,我認為我是一位「研究助理」,負責協辦活動的各項庶務工作,所以應該是主管交派工作事項,然後我就逐一去完成吧,不過實際狀況卻是,我常常站在他桌邊,或辦公室的黑板前,聽他講述某件事應該怎麼處理、怎麼「想」的「教訓」。很多時候,我是不能理解他的話語,總是似懂非懂的說,「是,我知道了」,但我想眼神應該有不小心出賣我,因為受過心理學訓練的他,總是一再地說更多話,講更多例子,來試圖找出適合我的頻道(channel)。不過,不知道是他的程度不夠,還是我的程度不夠,總之,我們兩個當時沒在同一個頻道上,我所接受到的,大部分都是雜訊,沙沙沙沙地穿插在他所說出的語句當中。

合作之道

前天,在某個活動的場合,遇到 Drupal 社群的朋友,聊了些關於社群、合作的事。

我們一直強調要團隊合作,要開放精神,但其實我們的文化中並沒有埋入「合作」的基因,舉例來說,國外的軟體設計,一定會加入 API(Application Programming Interface,應用程式介面),來做為跟其他軟體溝通的接口,像是 Drupal 這類的開放原始碼軟體專案,就有很好的 API 設計;然而我們卻鮮少在開發一個系統時就已經先設想了 API 的架構規劃。

我一直覺得,這些軟體可以具體、設計得出這麼好的 API,想通怎麼在不同的軟體系統間進行資料交換、流程交換,這深層的意義正表示,這些軟體的設計者很清楚何謂「合作」,因此他們定義好自己的「接口介面」,用自己的方式處理別人丟進來的資料,再提供對方所需要的資料。

在我的職場生涯中,有遇到需要 API 的案例就是做電商網站時,需要做金流介接,因此需要金流廠商提供 API,但在使用這些 API 的過程中,就會發現許多狀況,例如金流廠商回傳的錯誤訊息定義不清、擅自變更 API 規格致使傳送資料格式必須變更等,我認為,這正是說明著,我們沒有以「合作」為基礎的文化因子,因此我們設計出來的物件,也不具備跟其他物件合作的能力。

資訊生活:使用者中心設計

四月初,因哲學新媒體的引介,到台北教育廣播電台參與「生活 In Design - 爆潮流」的節目錄製,我設定的主題是「資訊生活:使用者中心設計」。

內容還是以我專注和擅長的領域出發,談資訊生活的設計,以及如何運用「使用者中心設計」的概念來讓設計更貼近使用者。

雖然時間不夠講得很清楚,但算是設計研究所就學這近三年來的心得和收穫,以此記錄。

Ref: http://www.philomedium.com/audio/79187