iCHEF 設計團隊如何推動近萬間餐廳的營運升級 🍽
在加入 iCHEF 以前，我曾經短暫的在美式漢堡店打工過半年，當時的老闆並沒有導入 POS 系統，從點餐、庫存管理到營收清點，都是人工執行，記得我和另一位夥伴需要快速連按計算機計算出總額，還得不時探頭往內用區確認是否還有空桌，就不提還要製餐、收桌和洗碗了，完全可以體會何謂「廚房如戰場」！
這段每天手忙腳亂的打工經驗，讓我了解到擁有一套好用的 POS 系統，可以為餐廳營運流程帶來多大的改變，不僅僅是效率的提升，還有機會透過各種形式的行銷活動和會員經營創造更高的收益，甚至能從報表的數據觀察消費者的偏好，藉此作為調整菜單品項的依據。
不過餐廳類型百百種，光是在我的住處五百公尺以內的範圍，就有以外帶為主的早午餐店、以內用為主的咖啡廳；客單價低的小吃店、客單價高的餐酒館；品項單純的便當店、品項複雜的飲料店。每個餐飲型態都有各自的營運模式，iCHEF 設計團隊要怎麼應對這些「萬變」？又要如何評估每個功能為餐廳帶來的價值和風險？
本文將和你一起走過 iCHEF 產品設計流程的層層關卡，揭露背後的嚴謹規劃和思考，經過千錘百鍊後成為推動餐廳營運升級的力量 💪🏻
文章架構一、環環相扣的 iCHEF 全通路體驗
二、在日常中保有對餐飲場域的敏銳度
三、藉由測試和 Design Review 提升設計品質
四、專案結束就是功能迭代的開始
一、環環相扣的 iCHEF 全通路體驗
「iCHEF 不是只有開發 POS 系統嗎？那設計師發揮設計價值的空間感覺不大耶？」在正式加入 iCHEF 以前，我的確有這樣的誤會，實際上 iCHEF 的產品應用情境遠比我想像得多元，邏輯和機制也比預期中的更加盤根錯節，不只要考慮到各個平台的使用族群，部分功能還有國內外的規格差異。
當我們走進一間 iCHEF 餐廳，你會在點餐或結帳時看到外場人員操作一台 iPad，那就是一般消費者會接觸到的 iCHEF POS；你可能不會注意到的是一台出單機，它會列印出發票等各類單據；有些餐廳還會特別在菜單上放置 QRcode，掃描後可以看到 iCHEF 雲端餐廳的網站；而上述相關功能都可以在 iCHEF 後台進行設定。
iCHEF 設計師的挑戰之處就在於，我們需要用餐廳整體營運的角度來思考「後台 / POS / 印單 / 雲端餐廳」的使用對象、使用場景和頻率等特性。各平台是環環相扣的，稍有閃失就會牽一髮而動全身，因此在設計過程中要不斷來回放眼全局和檢視細節，才能創造餐廳和消費者之間流暢的消費體驗。
如果你是喜歡中高難度挑戰的設計師，那麼你可以在 iCHEF 獲得不那麼輕鬆但紮實又過癮的設計日常 😆
二、在日常中保有對餐飲場域的敏銳度
等待產品經理完成專案前期探索後，設計師們就可以開始準備執行設計了，根據專案性質、時程、範圍，我們會決定要採用哪些研究方法來推進設計，除了基本的競品研究，也會視情況訪談餐廳老闆，深入了解老闆的思考脈絡和行為模式，在眾多的餐飲型態之中，抓取出共同的痛點和期待。
由於餐飲科技是相對生活化的產業，我們不只在專案啟動時才發起研究，而是在生活中就會保持對餐飲場域的敏銳度。我在加入 iCHEF 以前，只會在意餐廳的食物好不好吃，現在一走進餐廳都會慣性觀察服務流程、環境配置、科技服務應用等，剛好遇到使用 iCHEF 的餐廳還會來個游擊訪談！
隨著接觸的餐廳數量越多，越可以理解老闆對於營運模式的設計考量，例如追求人情味互動的餐廳傾向來到桌邊點餐、人力資源較不足或是餐期較集中忙碌的餐廳傾向使用內用掃碼點餐；附近客群年齡層較高的餐廳多以內用或現場外帶客人為主、客群年齡層較低的餐廳訂單來源多為線上外帶或外送。
當然設計師造訪的餐廳數量和頻率還是比不上 iCHEF 強大的業務團隊，所以我們也會在設計發想的過程中向業務請教，盡可能在腦海中構建出接近實際情況的場景，對餐廳老闆和員工們在意的需求感同身受。
三、藉由測試和 Design Review 提升設計品質
即使探索研究做得再徹底，設計時難免還是會遇到思考盲點，為了讓視角跟觀點更清晰全面，設計師們會在專案完成到一定的程度時，自主發起易用性測試和 Design Review，以提升設計的完整性和細緻度，確保我們能把功能價值順利傳遞給餐廳和消費者，同時排除特殊型態餐廳（例如 24 小時營業或跨夜營業等）可能遇到的風險。
✦ 易用性測試
若專案時間充裕，我們會邀請符合條件的餐廳進行易用性測試；若專案時間較緊迫，就請 iCHEF 內部夥伴（資深業務經理、客服經理等）作為受測者。易用性測試要「通過」才算是有效，要達到什麼樣的標準才是「通過」呢？我們的定義是 —— 在沒有引導的前提之下，受測者可以自行完成操作。
畢竟餐廳在操作後台或 POS 時，業務或客服不會時時刻刻陪伴在身旁，我們希望產品是容易被理解和學習的，就算遇到錯誤也能釐清現況並自行排除。易用性測試結束後，設計師們會將測試計畫和報告整理在 Figma 檔案裡，讓相關成員可以查看測試紀錄和結果。
✦ Design Review
每個設計師都有自己較熟悉的產品線和思考模式，從每次 Design Review 的回饋中可以學習其他人會從哪些面向切入思考，也能不斷提升設計品質，更重要的是磨練「決策與當責」的能力！如同產品經理梁寧在《產品思維 30 講》裡提到的：「產品能力就是訓練一個人判斷信息，抓住要點，整合有限的資源，把自己的價值打包成一個產品向世界交付，並且獲得回報」。
我們的 Review 分為三種形式，分別由不同成員組成、在不同時機點發動：
- Design Review ➡️ 設計流程在充分掌握設計決策時即可分階段發起，參與者為1~2 位設計師，目的是對焦設計方向，以利後續專案進行
- PGO Design Review ➡️ 設計流程完成度達 80% 時即可發起，參與者為 Design Review 的設計師、PGO (Product Group Owner)、PM，目的是讓跨團隊的 PGO 管理者系統性地檢視設計方案，確保達成團隊 OKR、滿足產品相依性與協調性、規劃未來迭代方案等
- Stakeholders Design Review ➡️ 確定 PGO Design Review 通過即可發起，參與者為 PGO、專案與跨團隊 PM、業務經理、客服經理等，目的是拉齊大家對於功能規格的共識，避免進入到工程開發時產生大變動，也讓業務和客服夥伴預想功能上線後要如何介紹和教學
四、專案結束就是功能迭代的開始
走完好幾道 Design Review 的關卡後，隨即進入工程開發的階段，雖然規格不會再有大範圍的變動，但還是會因為工程實作考量而有部分調整。工程師們會提出各種設計師意想不到的 Edge Case（例如消費者同時開啟多個雲端餐廳分頁點餐、餐廳在消費者使用內用掃碼點餐的過程中更改了桌位），這時候設計師們就要因應這些低概率但仍有可能發生的情境，進行防守。
設計師的任務直到功能完成 Functional Test 功能測試 和 Integration Test 整合測試才算是告一段落。如果功能重要性較高、影響範圍較廣，我們會另外在功能正式上線之前挑選餐廳執行封測，觀察餐廳實際在場域內使用新功能的情況，蒐集從易用性測試中較難得知的潛在問題，在上線之前先行處理。
專案階段性結束就是下一次迭代的開始，PM 負責觀測相關數據和彙整餐廳回報給客服的意見回饋，以一個禮拜更新一個版本的步調，提供給餐廳更為完善的使用體驗，讓 iCHEF 得以持續推動近萬間餐廳的營運升級 🚀
結語
先前看了日本壽司之神小野二郎的紀錄片，小野二郎徹底將匠人精神貫徹於食材選用、料理手法、服務流程。為了讓章魚肉質變軟，於是幫章魚按摩 40 到 50 分鐘，甚至會注意到客人的慣用手是左手，出餐時特別將壽司放置在左手邊，讓每位客人都能得到滿足難忘的用餐體驗。
iCHEF 設計師的知名度雖然比不上小野二郎，但我們同樣盡全力把每個設計階段做到位，因為我們清楚知道 iCHEF 影響的不只有餐廳的營運，還有老闆的理想和抱負、客人的用餐體驗。如同廚師們追求更高的廚藝，iCHEF 設計師也在往更高層次的設計思維邁進。
感謝閱讀到這裡的你！如果你也對 iCHEF 的設計團隊有興趣，歡迎看看 iCHEF 的設計相關職缺 ▼
1️⃣ 資深產品設計師 Senior Product Designer💼 104 / Yourator💰 月薪 80,000~95,000 元2️⃣ 產品設計師 Product Designer💼 104 / Yourator💰 月薪 55,000~80,000 元3️⃣ 產品設計師 Product Designer (UI Special）💼 104 / Yourator💰 月薪 55,000~80,000 元
對於本文有任何建議、回饋、想法，歡迎在底下留言！也可以透過我的 Facebook 聯繫我 🙌🏻
