「簡單易用或許是無形的，但沒有它卻是萬萬不行。」─IBM
我發現大家，尤其是開發者的圈子裡，對使用性最普遍的迷思是：使用性是一種主觀的感覺。這些人認為使用性可以依照他們的主觀判定，與使用者無關，而且最好直接跟著大老闆的風向球走，有誰在乎紅配綠會影響閱讀興這類的事情呢？所以，當你試著在團體或企業裡導入使用者導向設計時，你可能會遭受一些阻礙與挑戰。
或許你覺得自己是團體裡唯一在乎使用者經驗的人，每次你跟同事們談起良好的介面設計有多重要時，他們總是不當一回事。的確，這是一條漫長又寂寞的路，但還是有些方法可以為你的理念發聲並降低批評的聲浪。其中之一就是教育你的團隊或組織這樣的設計方式有什麼價值。要這樣做，你就得了解甚麼是使用者導向設計，更重要的是：甚麼不是使用者導向設計。
使用者導向設計(UCD)不等於使用性(Usability)
我知道把這兩個名詞混在一起會造成你們的困擾。使用性一開始屬於人因學(humman factors)的範疇，研究人與產品之間的互動關係。實務上，使用性可以應用到各種產品，無論是烤麵包機、大門手把，甚至是它的包裝。
人機互動(Human computer interaction，HCI)源自於使用性，但聚焦在人與電子產品之間的互動關係。
使用者導向設計(User-centered design，UCD)則是從人機互動衍生而來的設計方法。基本上，它可以幫忙開發者和設計者們做出符合使用者需求的應用程式。
我們可以這麼說：實踐使用者導向設計可以確保你的應用程式擁有良好的使用性，因為這本來就是一體的！把使用者放在開發流程裡，自然就可以免除許多設計上的不確定性，並擄獲使用者的心。
另一個主題是使用者經驗(User experience，UX)，通常是指產品整體的使用體驗。除了功能面之外，還包括使用起來愉悅的程度和令人著迷的感受，因此使用經驗一詞所涵蓋的範圍會比較軟體本身還要大。落實使用者導向設計也可以提升應用程式的使用體驗。
UCD不是主觀的
使用性及其所有的基礎理論都是由科學所建構而成。它基於人因學、心理學、人類學等各領域的知識，絕對不是主觀認定或自由心證的。
使用者導向設計必須證明其設計決策是有效的，任何設計決策都應該來自觀察和傾聽，而非一時興起的念頭或個人偏好，這點與主觀認定的看法正好相反。使用者導向設計一但做得好，使用者自然就會對應用程式產生好感。
我們常聽到：「數字會說話」。使用者導向設計是依據數據和資料來支持設計決策的。其中一個方法就是使用性測試(詳見第9章)。另外，藉由直接觀察使用者並做出統計，也是可以避免主觀假設的偏誤。這些資訊都提供了更可靠的基礎，作為軟體開發的參考。
UCD不只是美學設計
這可能使人們對使用者導向設計最常見的迷思了。這些人(大部分是我們開發者)認為使用者導向設計就是美學設計。當然，應用程式的視覺設計也是很重要，但並不是一切。
使用者導向的思維不僅是思考如何讓東西看起來好看而已，也不只是做出絢麗的動畫及流暢的轉場效果；使用者導向設主要是要確保應用程式能滿足使用者的需求。一個外型好看的產品，搞不好實際使用起來是一場夢靨。
但是反過來說，良好的視覺設計的確是使用者導向設計重要的一環。使用性測試可以幫助我們揪出那些不合理的使用介面(UI)。也就是說，要讓產品成功，使用者介面是很重要的，但並不是一切。
UCD不會白費金錢和時間
執行使用，者導向設計步是一件容易的事，因此需要花費大量的時間反思和觀察。老實講，如果你用開發的時間去思考設計問題，你可能會覺得開發進度毫無進展；甚至當你從使用性研究中發現了設計上的問題，因此得放棄先前的程式碼，這時候更是會讓人感覺進度在倒退！
使用者導向設計就是要了解使用者對產品有什麼意見。有時候我們不想聽到他們的批評，或自認為早就知道使用者在想想什麼。接受回饋也意味著接受抱怨，沒有人樂意聽到別人說自己的產品有多麼糟糕。當某人在給予建議時，可能會說出「這個應用程式沒有什麼價值」之類的話。
為了躲避這些批評，開發者經常對使用者視而不見，不讓他們發表意見；於是我們只專注在寫程式，希望與程式不相干的事情可以船到橋頭自然直。
以上這些想法我都能理解。身為開發者，我們必須熟悉的工具及知識越來越多，因應時代而改變的新技術、新軟體架構如雨後春筍出現。這一分鐘才剛弄懂一套複雜的API(應用程式介面)，下一分鐘可能有看到部落格文章說這個技術已死，將會有一個全新的API取代它。
每個程式開發者都知道，在這一行必須不斷學習新知，並投許多時間和資源，才能跟上日新月異的技術。這些外在的挑戰使得開發者被迫沉淨再技術的世界，隔絕那些讓他們分新的事務，像是使用性測試。
使用性價值的推廣者Billy Hollis認為這一層隔閡對開發者帶來很大的挑戰。他暗示開發者設全再使用性領域失去了領導地位，因為他們無法再學習新技術和了解使用者之間取得平衡，最後只能選擇其中一種。所以，大部分的開發者都只能得到程式碼，他們只想把時間花在學習新的API上，Hollis說：
開發者圈子裡面的人都非常熱愛專研程式技術，以致對於其他的事情不感興趣。我想這也是造成開發和設計之間隔閡的原因之一。
使用者導向並不是非A即B的概念，你可以一方面追尋新技術，另一方面又將使用者的回饋納入流程中，不是只有使用者經驗的專家才能運用這些實用的設計準則。
Hollis用學習滑雪做比喻：
當你去滑雪的時候，我想你不會期待自己學習奧運選手的滑雪動作。你只能學著如何安全抵達上底，不要跌到就很好了。
我們必須要打破「不寫程式就表示進度停滯」的心態，接受「花心思在使用者身上」本來就是開發流程的一部分，就如同吸引新技術或寫程式一樣必須且重要。有一些開發者花很多時間決定要使用那一種軟體架構，卻不花時間思考如何提供使用者更有價值的東西；他們似乎假設他們點子的價值是無庸置疑的。
事實上，如果好好地執行使用者導向設計，是可以節省時間的。如果能夠確認使用者的需求，就不會白費成本或走冤枉路。請注意，如果無法滿足使用者的期待而必須重新開發應用程式，其實反而更浪費時間。
我認為暫時跳脫程式，可以幫助你思考新的道路。先放鍵盤和滑鼠，休息一下，做個使用者調查或使用性測試，你將會用不同的角度來看待問題。當你在度回來寫程式時，會更有想法，並更清楚需要改進的方向。
你也許想做使用者研究，但經費上不允許。畢竟，時間就是金錢，把時間花在寫程式以外的事情乍聽之下是不符合經濟效益的。
本書討論範圍並不包含使用者導向設計投資報酬率(ROI)的驗證，但是我鼓裡你們把使用者導向設計當作避免「浪費」金錢的方法。修復產品的錯誤和支援使用者克服操作上的困難，一樣要耗費不少成本。
Arnold Lund在interactives雜誌上曾提到：
把使用性測試當作軟體品質管理的一部分，並且證明他可以降低將來程式錯誤所造成的成本花費。這些成本包含軟體導入的支援成本，以及導入的維修成本。
如果你無法說服主管擁抱使用者設計所大來的效益，可以考慮用另一種財務的角度來看，例如使用者導向設計可以避免其他的花費。
UCD不是程式錯誤報告
你可能認為你早就在做使用者導向設計了，因此你做了程式錯誤的回饋機制。
這的確值得讚許，並且應該持續下去，但千萬別把錯誤報告誤當使用者研究。你可以持續關注使用者回報的錯誤訊息，但這無法讓你得到他們最根本的需求。
假設使用者回報一筆功能無法正常運作的問題，你可能馬上就一頭栽進程式碼、尋找修復的方法，企圖盡快地解決他。
如果你沒有試著問使用者：「發生這個問題時，他想要完成目標是什麼？」那麼你就沒有辦法獲得有意義的啟發，進而從根本上改善你的程式。
探索並詢問使用者一些非關程式錯誤的問題，可能會發現使用者想要用你原本沒想過的方式來使用軟體。這時候你就可以思考如何改良功能，讓操作流程更清楚、更好用，甚至可以激發出新的點子，讓你的應用程式更多價值。
以我的例子來講，我曾經自作聰明設計一個自動化的錯誤回報信件，信件裡面包含了錯誤發生時的一切技術細節及錯誤訊息。每當使用者發生程式錯誤時，這封信件就會自動產生，並寄到我信箱，我完全不用浪費任何時間根使用者溝通。現在想起來，真是一個天大的錯誤！
有一個使用者每天都要送出紀錄，程式就會發生錯誤。我收到錯誤回報後，花了好幾個小時檢查程式碼，試著找出與法或成是邏輯上的問題。我看遍了所有資料庫的連結，甚至還檢查資料庫本身。後來實在束手無策，於是只好打點話給那位使用者，問她做了什麼操作以致造成錯誤，結果真像終於大白；原來她在填寫某一表單的欄位時，輸入了無效字元。
的確，這不應該發生的事。當使用者可能會輸入這些特殊字元時，我應該要從程式上做出一些限制，但真正令我感到驚訝的是：她竟然想用一般的意見欄位，填寫重要的醫療資料。
跟她溝通後，我才知道要建立更多的輸入欄位，才能滿足使用者的需求。由此看來，自動產生的錯誤報告並不能夠完整表達出問題的全貌，如果只單純把錯誤修復了，而錯失了與使用者對化的機會，我無法察覺這個新的使用者需求，使用者恐怕繼續使用一般的意見欄填寫重要的醫藥資訊。
因此，完整的使用者回饋不應該只是錯誤訊息的回報。錯誤報告應該被是為設計策略的其種輔助資訊而已。
UCD不會模糊焦點
你是否曾在聽取使用者需求時，馬上就神游到技術方案裡？
- 該做成網頁好呢？還是直接連結資料？
- 這個系統可以建立在公司的入口網站上嗎？
- 該使用那一種程式語言呢？
- 應該可以在產品上建立一些模組吧？
- 有機會把它做成行動裝置的應用程式嗎？
這些技術性的思考都沒有錯，但其切入點和客戶需求無關，因為我們還不了解他們的需求！使用者導向設計始終關注客戶最核心的需求，讓開發者獲得最有義意的資訊，避免為了技術而使用技術。
就算真的有技術上的障礙要克服，開發者也一定能夠在一開始就找到真正合適的技術解決方案。使用者導向設計先從需求出發，在尋ˋ襖技術解決方案。這種目的導向的方式可以幫助我們依循正確的程序完成開發任務。我們會在第4章詳細探討。
現在我們知道關注使用性並不是多餘的工作。事實上，他反而能夠幫助我們聚焦在正確的問題上，避免做白工。使用者導向設計的流程會讓你保持正確的心態，問對的問題，並挑戰任何先入為主的觀念。
以下是幾個非技術面的問題，提供你作為一開始思考的線索：
- 使用者需求為何？這是一個技術可以解決的問題嗎？還是一個程序或政治問題？又或者是工作流程、教育訓練等其他的問題？
- 為什麼使用者對這個訊息感到困惑？使用者如何詮釋此訊息？我應該用不同的方式解釋它嗎？
- 為什麼使用者會在這兩個畫面之間迷路？
- 為什麼使用者沒有看到這個警告？只是因為忽略了嗎？如果是，為什麼？
- 為什麼使用者會用錯誤的方法完成操作？有更好的介面設計讓操作更順利嗎？
使用者研究最基本的課題就是問為什麼。使用者導向設計讓我們開始關心使用者及他們的行為；這樣的開發架構可以協助我們找出對使用者需求最有效的回應方式。
結合使用性、使用者導向設計及使用者經驗，你將以一個更完整的程序來開發應用程式。這需要專注、決心、甚至一點點的犧牲；然而今日市場競爭如此激烈，如果忽略這些做法的話，對你及你的使用者來說都是一種傷害。
沒有留言:
張貼留言