我幾乎天天開 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，選項千萬不要用下拉選單，整店員嗎…（想想北韓飛彈打夏威夷）