寫UI到底難在哪裡 4

作者: Armuro (人是天生探索者) 看板: Soft_Job
標題: Re: [請益] 寫UI到底難在哪裡
時間: Fri May  6 05:14:07 2011

※ 引述《gpmm (銀色)》之銘言：
: ※ 引述《vgod (single)》之銘言：
: : 如果仔細觀察, 就會發現這種軟體絕對不是只用了一些標準元件就交差,
: : 而是精心設計了特殊的呈現方式或是workflow來滿足user的需求
: : 一個好的UI是不會被現成的toolkit和元件限制住的, 而為了實現好的設計,
: : 背後就需要有堅強技術背景的工程師去實現它
:     小弟也來獻醜淺聊一下關於 UI 這件事，
:     其實我很能理解，為什麼 UI 是既簡單又困難的。
:     讓我們以先把 UI 的定義給狹義化，將顯而易見的專業部份移除，
:     也就是不管設計，不談程式技術，只聚焦在純粹的 user interface 上，
:     那麼 UI 的輪廓大致上還有以下三個區塊：


:     ．元件排版（layout）
:     ．互動反饋
:     ．行為流程
:     這三個部份都有一個共同的特性，就是沒有可供辨識的專業度，
:     舉個很常見的例子，在網頁專案上，一個「上一頁」的按鈕要放哪裡，由誰決定？
:     ※ 最一開始企劃提案的時候，放在畫面左上角 - 企劃決定，
:     ※ 到了設計師那裡，設計師的 sense 告訴自己，要放在左下角才對 - 設計決定，
:     ※ 到工程那裡套 code 的時候，老闆正好從後面經過，
:        看到畫面覺得很怪，於是告訴工程師把按鈕挪到右下角 - 老闆決定
:     ※ 專案交件了，送客戶端做測試，
:        兩天後客戶告訴業務，按鈕在那很礙眼，放到右上角吧 - 客戶決定
:     最後整個專案完成上線，結果成效非常  ◢▆▅▄▃ 崩╰(T皿T)╯潰 ▃▄▅▇◣
:     只因為很多使用者搞不清楚如何回到上一頁
:     這個例子的重點是，一個按鈕要放哪，其實誰都可以決定，
:     因為「要擺哪裡」這個動做完全不須要門檻，有門檻的是：「為什麼要擺那裡」
:     但是這個「為什麼」的門檻實在太過隱晦，
:     因為大家背後都有一個強大的夥伴足以協助無視這個門檻 － 使用習慣，
:     今天一個高 sense 的設計師，可能不需要有太多的 UI 背景，
:     就可以拉出一個不算太差的使用介面來，
:     就像一個吸收力強的企劃，也不需要有太多的 UI 專業，
:     就能畫出一套不會相差太多的行為流程，
:     UI 實際上的門檻在大家已經習慣的行為模式底下根本就被無視，
:     尤其是有太多太多中小企業都是這樣，
:     老闆（一邊盯著女秘書的屁股）說：
:     「這東西放這，那個流程那樣，這些互動要左左右右，誰都會呀！
:       拜託一下，這有什麼難嗎？你照著做就對了啦！」
:     所以說起來，我覺得 UI 真正的困難和深度，
:     要在面對全新未知的環境下（或著破壞式創新）才能顯露，


這系列許多的文章舉的例子都是很單純的關於什麼元件要放在哪裡

所以看不出困難跟深度在哪

我最近有一個研究是跟interaction designer的design practice有關

我訪問的幾位designer皆提到說 "喔~如果大家對介面有異議的話 就找已經很成功的

網站或軟體來當例子, 因為它們已經證明這樣子的介面是成功的."

因此許多designer他們有時候會做正式的comparative analysis 去比較市面上

的競爭軟體的介面 看看哪一些是好的哪些是不好的. 然後再看自己的產品

看看哪一些可以應用在自己公司開發的軟體上

就算不做正式的comparative analysis. 因為designer們自己本身平時都會看一些

設計的網站和使用者經驗的網站. 因此什麼東西怎麼擺平常也已經吸收成為知識

的確, 這樣子的設計是一個很有效的方式. 而且有一個好處是, 由於這些已經成功的

網站和軟體已經成功了. 所以就算他們原本的介面不是頂好 但是因為已經成為

使用者的期待 所以直接套用他們的模式的好處就是至少不會造成太大的user frustration

然而, 直接套用成功網站或軟體的介面可以說是一個誤導的方式

換個方式說. 套用大家已經習慣的pattern (或說convention)來設計是當你已經完成了

high-level的設計之後 準備要設計比較low-level功能的時候才該用的

舉個例子: 一個high-level的功能可能是指"管理文件功能" 那麼這個功能底下的

low-level功能可能就是 "儲存" "另存新檔" "列印" "分享" "輸出" blablabla等等

任何interaction design或user centered design的學者都會說high-level是透過

使用者目標, 需求, 和情境(context)來決定, 而不是大家已經習慣看到什麼功能

所以就給他們這個功能.

所以UI學問深度在哪?  深度在於你怎麼去決定你要有哪些high-level的功能

使用者研究首先當然是最可以解決這個問題的 (使用者研究本身其實也是很複雜)

但是從discover needs, 到 identify design requirements, 到synthesize design idea

這中間才是互動設計"最關鍵"的階段.

在design process裡應該要透過重複的 explore和filter的動作來決定最後要留下什麼

功能. explore是將design idea擴大範圍, filter是決定哪些該留下來哪些不該留

而這兩個動作即是UI困難點之一:

你怎麼決定哪些要留下? 哪些是決定的因素? 使用者需求? 預算? 時間? 實現難易度?

誰可以決定? 為什麼要這樣決定? 理由是什麼? 有根據嗎? 平衡點在哪裡?

怎麼評估這樣做是對的? 怎麼知道這評估是對的? 如果使用者目標和企業目標衝突

怎麼取得平衡點? 如何說服客戶留下這些是對的? 根據過去的統計研究? 根據自己做的

使用者研究? 還是跟他說大家都這樣做?


如果你目前為止覺得我講的很陌生的話

那代表你們平常設計的時候略過了使用者研究這最重要的階段

就我知道台灣目前軟體業的發展, 許多企業都是直接設計然後做使用者測試

這樣子發現的介面問題 老實說都只是反映表面上的usability problem

卻無法反映出使用者的目標,需求,文化,情境使用, 價值觀還有真正會在介面上執行的動作.

因為通常測試都是測試者已經先定義幾個任務給使用者做而已, 但是這些任務是哪來的?

是自己覺得使用者會這樣操作還是透過研究發現使用者會這樣操作?

如果是靠企業內部自己定義的 那可以說會有很大的潛在危險.

真正UI的學問不是在於系統是否usable而已. 這是1970年代HCI的學者在做的事情

就是專注在usability問題上面

usefullness是更進階一層的問題. 如果系統無法滿足需求 甚至無法滿足目標

那麼這是一個也許儘管好用 但是對使用者來說沒用的系統.

再更進階一點, user experience 也是使用者測試很難測出來的

在測試的時候使用者可以告訴你 你的介面直不直覺, 好不好用

但是他很難告訴你他會不會繼續用.

當使用者有選擇的權力的時候, 好用跟有用已經不足夠. 能帶給使用者愉悅經驗的

介面才有辦法一直留下來

為什麼Apple的死忠粉絲這麼多? 難道其他公司做的介面真的差這麼多嗎?

就算有差 有多少粉絲是連都沒用過就直接拒絕使用其他公司的產品?

這是因為Apple過去的產品帶給他們美好的經驗,而這個產品絕對不是只是好不好用

或有不有用而已

如果沒有考慮到這些因素, 的確UI是沒什麼困難也沒什麼深度

如果不需要在使用者跟你啪啦啪啦講一堆後去翻譯他們的需求 觀察他們的行為

然後再翻譯成為design requirement, 經過重複的考量各個重要的因素去排設計的優先

如果沒有去研究使用者的文化, 情境, 目標, 需求, 甚至是價值觀

的確UI沒有深度, 而只是看哪些東西要擺哪裡而已. 而這的確大家都會做


:     一旦某個使用環境逐漸成熟且被大眾所接受後，
:     它背後蘊含的 UI 設計深度就會不斷在大眾的習慣中流失掉，變得理所當然，
:     就像觸控式手機介面一樣。




--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.136.84.209
推 vgod:推 iterative design才是做UI的精髓所在                      05/06 07:40