iCHEF
新增線上點餐外送服務，提升店家自行外送的效率
專案期間
2021/10 - 2022/2（五個月）
專案團隊
專案經理 *1
產品設計師 *3
軟體工程師 *3（前端、後端、iOS）
我的角色
產品設計師，負責：競品分析、店家訪談、流程與介面設計、利害關係人溝通
專案背景
iCHEF 是一間餐飲科技公司，為店家提供的其中一項服務為「雲端餐廳」，店家可以開通自己的點餐網站，並讓消費者點餐。我們觀察到，約有 17% 店家為了避免外送平台（例如 Uber Eats 和 foodpanda）的高抽成比例，選擇自行擔任外送員，在雲端餐廳接單。
使用痛點
原先雲端餐廳僅有外帶服務、缺少外送流程，因此容易造成雙方資訊落差，需要來回確認資訊。
雲端餐廳首頁
店家要自行在提醒事項輸入外送規則
店家接單時要自己判斷訂單為外帶或是外送
消費者要自行理解不同店家的不同規則
雲端餐廳購物車
消費者要自行在訂單備註欄位輸入地址
消費者要回到首頁才能了解是否符合外送門檻
若地址不完整，店家需要致電給消費者確認
商業目標
我們期望店家能夠因為雲端餐廳的適用性提高（同時支援外帶與外送服務），提升採用雲端餐廳的意願，並帶動提升線上訂單量，進而使線上結帳金額增加、分潤金額增加。外送服務於 2022 年 5 月上線後 12 週，達到了期待目標：
+
%
總訂單量成長百分比
+
%
線上結帳金額 (GMV) 成長百分比
設計挑戰
由於 iCHEF 提供從消費者點餐到店家接單的服務，因此設計師需要系統性的思考「後台設定、雲端餐廳、POS、印單」的設計流程和細節，以確保 B 端和 C 端的使用流程順暢，並符合目標使用者的需求。在此專案中，我主要負責後台與雲端餐廳的設計。
競品研究
在進入設計發想以前，為了獲得以下資訊，我選擇先進行競品分析研究：
了解消費者需求，回推店家需要在後台設定哪些項目、提供給消費者哪些資訊。
了解外送平台如何整合外送和外帶的功能和資訊。
了解消費者如何與外送員間接（瞭解外送員狀態）和直接（發訊息給外送員）互動。
該平台自己有簽約的外送員
該平台與 Lalamove 外送員合作
針對每一個平台，我都實際走過一次從外送點餐到取餐的流程，紀錄覺得順暢、有阻礙、產生疑惑的地方，並截圖整理在 Figma 中。
最後我整理出 3 個主要會影響外送點餐體驗的環節，並在後續設計的過程特別留意。
剛進店
不同點餐路徑
若對此店家不熟悉，會希望先輸入地址，試算運費。若對店家熟悉，會想直接點餐，再輸入地址。
點餐前
清楚的運費規則
由於 iCHEF 店家的運費規則不一，需要呈現清楚的規則說明，並提供即時運費試算。
點餐後
明確的訂單狀態
送出外送訂單後，需要呈現明確的訂單狀態變化與送達時間點，以讓消費者獲得確定性。
店家訪談
在競品研究中，我們得知「清楚的運費規則」對店家和消費者來說，是外送服務的一大關鍵，因此我們需要了解店家目前設計運費規則的考量，以及對 iCHEF 外送服務的期待為何，讓我們得以收斂出更貼近實際需求的規格。
Step 1. 設定訪談篩選條件
店家目前使用 iCHEF 雲端餐廳提供「外送服務」
推出外送服務一個月以上、近一個月有持續接受外送單
外送規則清楚詳細，才能了解店家如何與消費者溝通
目前仍有利用 iCHEF 雲端餐廳接單嗎？
目前透過雲端餐廳提供外送服務有多久了？
印象中，下訂外送/外帶訂單的顧客比例有多少？
電訪後，我們選擇擁有不同運費規則類型的 5 間店家，並進行各 60 分鐘的實地訪談。
完成訪談後，我們得出了以下 3 個洞察，也讓設計過程進行得更加順利。
行銷方向
易有團體訂購、不吃重實體氛圍的店家，有較大的外送需求
相較於餐廳、酒吧、餐酒館，飲料店、小吃店等店型有較多團購單，且不吃重實體用餐氛圍，疫情趨緩後外送需求量甚至有上升，我們可以對這類型店家精準行銷。
運費規則
店家皆以「距離」為思考運費規則的出發點
店家不希望消費者再多一道計算距離的程序，因此劃分出不同區域範圍。若能在後台設定不同距離區間、讓消費者能自動計算運費，就可以讓雙方用距離進行溝通。
印單資訊
店家會把距離相近的訂單排在一起，以規劃外送路線
店家會在製餐時，把送達時間、距離相近的訂單排在一起。印單上除了提供地址資訊以外，如果也連帶提供與店家的距離，就可以幫助店家加速排單流程。
店家目前的 workaround 是把外送送達時間寫在印單最上方
利用「餐點備註」欄位，請消費者寫下地址資訊
設計產出
後台
我們在後台「外帶/外送訂餐」的頁面裡，新增了不同選項，讓店家可以選擇功能類型，也能調整該功能的營業狀態。這些選項都會同步改變雲端餐廳上的資訊顯示和操作流程。
由於選擇外送功能前，店家一定要新增至少一條運費規則，因此我使用 disabled 以及說明文字的方式，希望能給予使用者充分引導。
不過在執行內部易用性測試後，發現引導效果不佳，所以進行了流程調整。
原先版本
第一時間目光會被「新增至少一條運費規則」吸引，對想要選用「外帶」的店家來說，會受到干擾。
字詞寫「外帶功能」、「外送功能」，會讓想同時想提供兩種服務的店家以為要選取這兩個選項。
調整後
讓店家專注在當下最主要的任務，先選擇期待的功能，再跳出錯誤訊息，減少認知負擔。
字詞改為「僅外帶功能」、「僅外送功能」，避免同時提供兩種服務店家以為要選取兩個選項。
後台
功能上線前，店家的 workaround 是在雲端餐廳的「提醒事項」欄位手動輸入運費規則，現在店家可以直接在後台新增多個運費規則，且有不同的欄位設定，應用更彈性多元。
1
距離是運費規則的核心，因此我們會讓店家先輸入該規則適用的距離範圍。
2
店家可以設定是否要有外送門檻，部分店家會希望達到一定消費金額後，才提供外送。
3
4
後台
為了讓消費者在雲端餐廳輸入外送地址後，準確計算外送距離，我們規劃了「地圖定位」功能，店家需要在啟用外送功能以前完成設定。店家可以在輸入地址後，調整地圖圖釘，取得經緯度參數，地址也會同步顯示於雲端餐廳「餐廳資訊」頁面上。
雲端餐廳
進到雲端餐廳的第一眼，消費者就能清楚辨識餐廳的服務類型，以及是否開放點餐。我們提供了兩種路徑，消費者可以先選擇取餐方式和時間，或是點餐後，再點擊「查看購物車」進行設定。
雲端餐廳
消費者輸入完地址後，系統將自動計算出該地址與店家位置的距離，並根據店家設定的運費規則，顯示外送時間和運費等資訊，消費者若有疑惑，也能進一步查看完整的規則說明。
雲端餐廳
若消費者已經輸入完外送地址，且要準備點餐，或是已加入部分餐點加入購物車，消費者可以在「查看購物車」按鈕上方，查看外送門檻與運費減免的資訊，藉此調整購物車內容。
雲端餐廳
店家在 POS 上接單後，消費者會在訂單狀態頁面即時地看到對應訊息，而店家在確定餐點送達後，也能將訂單狀態切換為「訂購完成」，結束一張訂單的生命週期。
POS
消費者在送出訂單後，店家就會在 POS 上即時收到訂單，並能透過左側 icon 區分不同訂單種類，包含「Uber Eats、foodpanda、雲端餐廳外帶、雲端餐廳外送」等訂單。接單後也能在「外帶/外送」列表頁查看相關資訊、進一步點進訂單查看細節。
POS
餐廳營運現場經常會面臨各種狀況，例如：現場客人太多、外送人手不足、有緊急事務要處理。因此我們也在 POS 提供快速設定的 toggle，讓店家不必到後台才能進行調整。
印單
店家接單並列印印單後，即能查看「訂單種類、編號、訂購人、送達時間、地址、餐點與備註」等關鍵資訊，並開始準備製作餐點，也能把距離相近的單排在一起，方便安排外送路線。
封測計畫
很開心的是，由於設計過程中進行了多場內部易用性測試，因此店家們並沒有遇到什麼設定阻礙，也很肯定 iCHEF 的用心。我們只需要修正部分的工程 bug 就好！
團隊影響力
除了專案本身，也為團隊帶來正向影響
這是我加入 iCHEF 的第一個專案，我必須先累積一段時間的信任感，才能進而為團隊帶來影響。在我確認我能對專案有一定的熟悉和掌握度後，就捲起袖子、推動大小事務。
發起游擊訪談計畫
透過對 iCHEF 店家游擊訪談，我得以快速獲取餐飲業知識和使用情境觀察，帶起其他夥伴進行游擊訪談的風氣，並互相分享洞察。
推動建立元件庫
原先雲端餐廳並沒有共用的元件庫，設計師需要從不同檔案裡找尋元件，因此我選擇主動協助建立 Design System，提升工作效率。
製作封測文件模板
由於 PM 在專案後期事務繁忙，當我們確定要進行封測後，我就開始協助製作封測文件，並作為模板讓其他團隊也能使用。
夥伴回饋
感謝實力堅強的專案團隊
雖然專案節奏緊湊，要在短時間內了解 iCHEF 的開發流程、商業目標、產業脈動，還有非常多需要留意的規格細節、Error Handling、Edge Case，但有這些夥伴的支持，讓我得以彈性變換視角，能顧及宏觀和微觀的設計。
謝謝 Kat 在加入 iCHEF 這麼短的期間，能把外送專案設計規劃得有聲有色，平時對於競品分享、任何事件的個人想法分享等，除了讓大家更了解市場與競品樣貌外，這樣的積極度會感染其他夥伴，對於團隊也有凝聚向心力的效果。
產品經理
謝謝 Kat 將設計稿畫得很清楚，範圍很大，但整理的很有條理，後續有改動也會標註修改時間並每天定時通知大家，很讚。
前端工程師
感謝設計師們提供詳細的 Figma 設計稿，並且在開發中有討論要修改的部份，都能持續更新在上面。
