我幾乎天天開 PTT Soft_Job 版,其中有一篇引起我的注意:[請益] 不懂這需求 是我很奇怪嗎?

很有意思,UX 設計師的構想、設計 UI 和工程師實作不是對等的,很常起衝突。也不會有「正確答案」這回事,有的話大家做的 APP 都該長一樣,上線的產品不過是「誰說服誰」的結果。

關鍵問題

文裡提到 2 個問題,底下原 PO 的推文補充說明提到POS機、WEB

  1. 為什麼綠茶大杯與綠茶小杯的圖片及描述需要不一樣?
  2. 為什麼綠茶大杯與綠茶小杯的冰塊圖片需要不一樣? 不就都是冰塊嗎??? 難道我賣20
    種飲料及大小杯就可以設定20張不同的冰塊圖片?

當然工程師專業的部份我不夠熟悉,就以 UX 和 UI 的角度來說。

工作角色

從 POS 機、WEB 這 2 點來看,我們可以猜得出來,「工作角色」有 2 種身份。

  1. POS 機,店員。主要操作任務:接單。
  2. 網頁,消費者。主要操作任務:網路訂餐。

這 2 種身份的「使用者」因為任務目標不同,想完成的任務也不會相同。

單一商品規格

文中以「飲料」為例,看起來是手搖店的飲料,以我個人日常生活買飲料的經驗來看,一杯飲料可以客製化的部份大略有下列數種。

  1. 飲料尺寸(大杯、中杯、小杯…)
  2. 甜度(全糖、半糖、微糖、無糖…)
  3. 溫度(冰、溫、熱、有冰、少冰、去冰…)
  4. 加料(珍珠、蒟蒻…)

(當然實際做專案還是去實體店面訪談觀察吧,本文只打算引導思考方向。)

思考點

因為文裡沒有提到這是 POS 機還是 Web,但原 PO 很在意兩邊的資料長不一樣,所以一起綜合思考。

為什麼綠茶大杯與綠茶小杯的圖片及描述需要不一樣?

首先,你的「大杯」和我的「大杯」是同個標準嗎?肯德基的「大杯」950ml、星巴克「大杯」480ml。冰滴濃縮咖啡大杯 950ml,冬瓜茶大杯 480ml…我拿到手一定會傻眼。

消費者透過 Web 訂飲料:什麼樣的資訊可以加快消費者完成任務?怎麼做可以減少消費者的遲疑與誤會?

圖片和文字描述都能幫助消費者快速了解商品、加快他們點餐的效率。但只有文字、只有圖片、圖文都有,以上 3 種方式哪一種對消費者者而言較有效率?如果是「滑鼠移到圖片上、出現說明文字」呢?

為什麼綠茶大杯與綠茶小杯的冰塊圖片需要不一樣?

最直接的疑問就是:大杯和小杯在實體店面用的冰塊不一樣?如果一樣的話為什麼要用不同圖片?因為「份量」不同?

那麼飲料店大杯的冰塊量和小杯的冰塊份量是以什麼當基準?在沒有客製的情況下,可能有這 2 種計算方式(比喻):

  1. 不管大小杯,就是一大杓。
  2. 依杯子的尺寸,裝半杯。

如果是 1 的話,點小杯的不就快整杯都冰塊?所以是 2 比較合理。回過頭來思考:為什麼要放冰塊圖。

  1. 提醒消費者要選冰塊量。
  2. 實體店放的冰塊量就是這麼多。

如果是 1 ,提醒消費者要選冰塊量的方式有很多,比如不選冰塊量就預設要有冰,或是不選冰量就不給加購物車等等,基於什麼原因採取圖片的方式呢?

如果是 2 ,消費者看圖片能知道這是全冰、少冰的實際份量嗎?使用者對冰塊量要求這麼嚴格(溶掉的怎麼辦)?使用者知道在這間店點大杯會放多少冰、小杯會放多少冰,自己會換算然後要求小杯的冰量是大杯的…

原 PO 提到「碎冰」,如果實體店有碎冰的客製化選項,方型冰塊和碎冰長得完全不同,放圖會讓使用者更明白兩種冰的不同。但如果實體店面只有一種冰塊,放碎冰圖會讓使用者以為到手的飲料裡是碎冰但怎麼拿到的是冰塊,產生「我不是訂這個」的想法,客訴的可能性大增,並影響消費者對這間店的信賴感。

More

另外,把工作角色、操作任務、商品規格綜合起來思考。

相較之下,店員比消費者更需要「精準」操作各種客製規格,畢竟消費者點錯餐還可以掏訂單出來說「是你自己這樣點的」,店員輸入錯誤重做不止麻煩,這年頭奧客這麼多…

依店員的職務來說,必須熟悉商品種類以及可客製化的各種選項。如果有觀察他們怎麼操作 POS 機,常常看到他們用手指、或拿著一枝鉛筆用筆尾的橡皮擦戳螢幕。

在操作 POS 機「接受點餐」的情境下,店員捲動螢幕選擇商品規格會增加完成任務的時間(需要更多的注意力在螢幕上)。且他們不需要圖片輔助說明商品(自家產品不熟?),夠大的按鈕(不容易按歪)、盡量用「點擊」的方式(順著版面走向一路戳戳戳),一頁放不下所有選項時放到第 2 頁(換頁也用戳的)會比讓往下捲(按住拖動還是戳捲軸按鈕?)更有效率。

(留言 1F 補充:「適當的圖片能幫忙記憶。熟練的店員並不會閱讀文字,而是神經反射。脫線時,圖形加顏色更易於定位。」)

(我沒印象 POS 機用滑鼠操作,要滑鼠直接電腦裝軟體就好要機器幹嘛?)

消費者沒有店員這麼熟悉商品細項,且飲料店的商品種類非常多樣,需要圖片輔助說明幫助消費者理解商品。他們透過網頁購買,裝置為手機或是電腦,在「完成點餐」的時間急迫性上沒有店員這麼短,頁面稍長一些、使用捲軸並不會嚴重操作效率。

限制條件

(額外想提出來講的部份啦,和原文無關。)

什麼情況下可以選冰塊量呢?

限制條件這回事非常吃邏輯,設計師沒想好,倒楣的就是工程師了。一個沒想好就會出現熱拿鐵少冰的訂單了。

如果這樣做,如果不這樣做

「這樣做,對使用者有什麼影響?」
「如果不這樣做,對使用者有什麼影響?」

如果這樣做如果不這樣做,某些程度上能問出是否需新增此功能、或這種作法對使用者來說有什麼幫助。當然「好用的產品」和「好寫的程式」不對等,以及職務不同、關心的點不同,價值觀、立場等等都會引起衝突,就看誰被說服了。

後續的 PTT 回文

版上後續有 2 篇回文,我也覺得滿有趣的,寫一下自己的想法。

未上線的東西,沒人可以知道到底符不符合市場需求。

是啊,但在開發初期可以做使用者研究,訪談觀察需要操作 POS 機的使用者、透過 Web 網路訂餐的使用者,他們在使用競品的操作流程、過程中遇到什麼問題或困擾,這些都可能變成自家產品的優勢之處。

開發過程中做 Prototype 進行使用者測試,不敢保證是否符合市場需求,但能確定使用者是否能透過自家產品順利完成任務,並確認自家產品的開發走向。

這種東西不到一天就改完了 還拉一堆人進去開會討論

我也覺得這麼細節的東西幹嘛拉一堆人去開會討論,光是開會成本都大過客訴成本了。

一開始寫 User Story 就能理解工作角色不同、任務目標和操作任務流程也不同。有做使用者研究,這種細節問題 UX 設計師就能有憑有據說明「為什麼自己會這樣設計」,根本不會到需要一堆人開會討論這玩意的地步。

真的要個答案,Prototype 做 2 個,一個照 UX 想要的、一個照 RD 想要的,抓行政單位的人來測,計時,看哪邊快、錯誤率低。都比至少 6 個人 x 2 次會議的成本低太多。(雖然我不喜歡這種作法,但沒人敢負責又想佔理的時候也只能這樣硬幹了。)

最後,雖然原文裡沒提到,但我還是想囉嗦一句:不管 POS 機還是 Web,選項千萬不要用下拉選單,整店員嗎…(想想北韓飛彈打夏威夷)

comments powered by Disqus