9/5/2023, 16:00

只要有心,人人都可以是 UX Engineer

How hard is that?

在網頁領域,我們常常聽到 UI/UX,究竟 UI (User Interface)、UX (User Experience) 有什麼分別?在專案中又扮演什麼樣的角色?

其實坊間上已經有無數在探討兩者的文章了,這次我只想針對 UX 來深入,畢竟 UI 是相對來說更主觀的存在,每個人都有自我美感的定義,但是 UX 不同的是,他的定義就應該是反映絕大部分使用者的情境,而非單一個體,不是設計師,不是工程師 (當然隕石除外 ☄️)

UX 之我見

UX 對於我而言,涵蓋範圍之廣,任何產品與你的用戶的互動都應該視為 User Experience,小到介面按鈕是否清晰、易懂。

How to read 🙄 ?

大至消費者在你的網站上購買產品後的物流、開箱,一直到產品的售後服務都是 UX 的守備範圍,例如 ROG 的電競筆電,其中一個細節令我印象深刻的是那台西風之神,包裝盒在掀開上蓋的同時,會透過機械結構將電腦本體往上推出,比起 🍎 的使用體驗真的好上太多了 (僅止於開箱)

source: https://www.nova.com.tw/article/open/content/615ac9d4a3314
source: https://www.nova.com.tw/article/open/content/615ac9d4a3314

但實際上能夠做得這麼周到的公司堪比日本製造的壓縮機,狀況永遠都是需求大於體驗,身為前端工程師,除了核心任務:「讓用戶所見即所得」之外,在整個產品生命週期上,扮演的角色就是:讓使用者可以毫不費力的操作介面 (無論 APP 或 Web)。

修但幾勒!這好像是 UX 的工作吧?
修但幾勒!這好像是 UX 的工作吧?

這邊就要講到個人對於所謂「前端工程師」的範疇分類了:

  • 第一類:形象網站,舉凡各種企業官方網站、電子商務或一頁式行銷活動等等,UI:UX 權重我會給 5:5,用戶可能是因為觸及廣告,或者其他不經意的原因進到網站,UI 會是留住用戶眼球的第一步,接著 UX 才能發揮效用
  • 第二類:CMS、CRM、ERP 等以訊息數據為主的後台系統,這類型的用戶意圖明確,他們很清楚自己在使用網站的目的是什麼,例如分析數據、輸出報表,UI:UX 會是 2:8
  • 第三類:動畫效果滿點的互動式網站 (e.g. https://labs.lusion.co/) ,在市場上相對其他兩者就比較少見,但通常一出現就是讓人為之驚豔的視覺效果,比起什麼 UX 的,我更想知道還有哪個角落有我沒發現的彩蛋 👀,UI:UX 不意外地給到 8:2

以上三個類型是我工作至今對於前端的領域劃分,其他還有像是個人網站 (敝站) 這種隨意發揮即興表演的不在上述範圍內,當然三者各自都對於前端技能樹選擇上有些微的迥異,雖然第三類才是我踏入行的初衷,但接下來只針對我工作範圍佔大多數的第二類探討。

我只是個敲鍵盤的,UX 與我何關?

在現今前端開發的生態上來說,UI 已經不是一個令人頭痛的問題了,只要打開瀏覽器 google 「UI framework」,啪地幾十種任君挑選,就算你不熟悉任何前端框架,我們永遠還有 Bootstrap 陪伴,已經不再是過去那些只有生硬的 HTML 拼湊出來的縫合怪了,所以就站在第二類開發者的我而言:

UX 即是開發系統唯一的指標

說到這邊,就要闡述一個對於 UI framework 的認知前提,這些 UI framework 一定都具備某種程度上的基礎 UX 設計,舉個 🌰

多數 UI framework 的按鈕都會有明確的層級命名,根據這個邏輯我們在排版時就應該盡量避免一種操作有超過多個 Primary Button 的並列組合,有了這個默契後再繼續往下走。

可以理解每間公司,甚至每個產品都想要有一套自己的視覺風格,當然有開發資源的話,我也想要每個產品都有自己獨到的 Style guideline,可是現實卻並非如此,大部分團隊不會花太多的心力自己造輪子,因為系統重要的是業務邏輯,視覺只是輔助 (除非貴司大到跟那些赫赫有名的大企業一樣,有一幫專門的 UI framework team 😑),值得高興的是,現在規模比較大的 UI framework 都有提供客製化參數來滿足上述需求 🙌,所以在 Style guideline 這部分只需要根據基底的 UI framework 稍作微調即可擁有專屬產品的視覺特色,UI/UX 定義 Style guideline 後,所有功能遵照規範設計即可,前端也可以一併把復用性高的 component 抽出管理,而一個團隊中最怕的就是:每次有新的 feature ticket,就會伴隨著新的 component 🤯,這張票的估時就會因為不必要的改動而徒增開發者的心智負擔,更別說這個 ✌️創意發想✌️ 對 end user 可能還有額外的學習成本。

Consistency 一致性

來人啊,上 🌰

Modal title
Lorem ipsum dolor sit amet consectetur adipisicing elit. Aspernatur, expedita!
Modal title
Lorem ipsum dolor sit amet consectetur adipisicing elit. Aspernatur, expedita!
Modal title
Lorem ipsum dolor sit amet consectetur, adipisicing elit. Eius in explicabo fugit commodi nam! Incidunt.

Consistency (n.) 一致性 蕩然無存,如果相同的操作卻引發不一樣的反饋,試想用戶在流程上是不是還要多一份心力去注意:「我做了什麼?為什麼這個不一樣?」(至少我會 🙄),對工程師亦是如此,每次撿票總是要經歷一次:「這次又是哪個 component?!」

“Consistency is one of the most powerful usability principles: when things always behave the same, users don’t have to worry about what will happen.” - Jakob Nielsen

這時候回過頭看,咦?這個問題不是在帶入 UI framework 的時候就一併解決了嗎?!甚至根本不該是個問題,然而卻因為不同的 UI/UX 或甚至隨著時間迭代,迸出了許多毫無意義的變體,這樣的結果不管是對開發者還是使用者都會造成相當程度的困擾。

Usability 易用性

so close ...

呼... 還好你沒選另一個危險的按鈕 😅,但想想如果是你的用戶在面臨這種危險性操作的時候,例如「刪除」訂單,還要反覆確認哪個按鈕才是刪除、哪個按鈕才是取消?那可以預見工程師後續一定會接到不少「復原訂單」的需求吧。

再來一個 🌰,後台系統常見的基本組件之一:Data table,如下 Generally 所示 (僅簡單示意),我們會在上方看到一個整合篩選/搜尋的區塊,除了方便一眼就知道我在這個頁面被允許使用哪些條件來排列組合以外,在操作時也能以最小幅度的移動範圍變更條件;反觀 Extraordinary,完全沒有界定操作區域,所有條件都只跟 table head 綁在一起,試想如果是以瀏覽器上下頁移動的朋友是要怎麼知道眼前這堆資料到底是由什麼組成的?就算有用 icon 來輔助,不逐一點開也沒辦法知道內容,更何況這張 table 會有多少欄位?要滾動多遠才能找到所有的篩選?最後,我要怎麼重置所有篩選條件 😀?

Order number
Customer
Phone
Email
Country
Address
Status
Amount
Created at
ORDER_26769870275591John Doe+12345678900john@mail.comUnited StatesNew York, 10th Avenue, 45Pending$ 1,250.002021-08-12 12:00:00
ORDER_12345678901234Jane Smith+19876543210jane@example.comCanadaToronto, Main Street, 123Shipped$ 850.502022-03-25 14:30:00
ORDER_87654321098765Alice Johnson+442012345678alice@gmail.comUnited KingdomLondon, Oxford Street, 789Delivered£ 500.752022-05-18 09:15:00
ORDER_55555555555555Bob Brown+15555555555bob@example.comUnited StatesLos Angeles, Sunset Blvd, 321Processing$ 600.002022-07-10 17:45:00
ORDER_98765432101234Emily Davis+11234567890emily@mail.comUnited StatesChicago, Elm Street, 567Pending$ 1,000.252022-09-02 08:20:00

總而言之,現在還存在檯面上的 UI framework,一定有他設計的基本道理在,不論是他們的 UX 工程師亦或是整個團隊,做過的 User research 都比大部分的人多,當我們想要改變這些規則時,不妨先自問:「我要解決他的什麼問題?我能帶來什麼樣的優化?」。

結語

抒發這些感觸並不是出自於我認為我有最好的 UX 理念,而是聽一些朋友說他們合作的 UI/UX 老是把使用者掛在嘴邊的,但做的卻是 MI/MX (aka My interface/My experience),如果搬出有悖於多數使用者認知的改動,卻又提不出數據,甚至沒有任何使用者反饋來背書的話,那我們每個人都可以稱為 UX 工程師對吧?實務上不免會看到業務為了客戶 A 的個人習慣,而發出全面改革的工單,但是否曾想過其他 99% 的用戶沒說話並不表示他們不會有意見呢?確實 UX 並不是永恆不變的鐵則,本文的所有示例也沒有絕對的是非,他是會隨著不同產品、不同領域、甚至不同時代而有所迭代,所以才會需要 UX 這個位置來時刻反映用戶習慣,而團隊也應具備基本的 UX 敏感度,適時地挑戰 designer,也許會蹦出更好的做法也不一定。「創新」也要能夠解決問題,才有創新的意義。團隊不能僅僅只是視覺仔、切版仔跟 DB 仔三個不相交的臭皮匠,UX 能夠理解後端在處理資料時會出現的各種狀況,提供 0-1-100 的示意圖給前端實踐,前端也能根據 UX 想要呈現的結果與後端敲定回傳結構,就算彼此只了解對方的一顛顛皮毛 🤏,都能有效加快合作效率。

Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know. - Jakob's Law of Internet User Experience

廣義來看,其實 UX 並不陌生,我們生活中習以為常的一個小動作,可能就是 UX 的成果,鍵盤排列、手機尺寸、電燈開關等不勝枚舉,但你我在「使用」任合事物上一定都有主見,所以擁抱 MX 的同時也別忽略了 UX 的重要性。

UX 可能可以說是一件投報率很低的領域,因為在網頁的世界,真正意義上「好用」的反饋反而是在無形中才能體現的,覺得好用的使用者往往不會有感覺,但是東西難用大家一定都知道 😭;我當然也是常常抱著一份 MI/MX 的使命感在達成自己的前端畫面,在不會面對到客戶的地方拼命地嘗試各種可能,也因為上述的認知,讓我想嘗試完成一個讓使用者「無感」的系統,反而會讓我有成就感的期待,但我畢竟不是什麼受過專業訓練的 UX designer,就佛系前進吧 🤞。

I'm not an expert; I'm just another user who knows exactly what I don't want. 以上言論僅代表個人淺見,並非專業見解,絕不雷同,也無巧合,共勉之。