Pixel364 點餐設計：從咖啡菜單到一張說得清楚的訂單

Pixel364 是我用咖啡場景探索功能型網站的專案。它不只展示菜單，也提供客製選項、桌邊 QR 點餐、外帶與預約入口。我關注的不是「能不能做出購物車」，而是顧客選完之後，店家能否理解這杯飲品的需求，以及接下來該怎麼處理。

菜單不是一張圖片

把菜單放上網，只解決了看見商品；點餐還需要把商品、可選項目與數量組合成明確內容。客製選項不應只靠自由文字表達，否則顧客以為選好了，店家卻可能收到無法判讀的需求。

我的設計思考是：先讓人選商品，再依商品提供適用選項，最後確認完整內容。並不是每杯飲品都應有相同設定，也不能為了畫面整齊，讓顧客選出無法製作的組合。這是規劃與檢查的準則，不是宣稱所有例外都已處理完成。

入口不同，確認內容也不同

桌邊 QR 的情境是「我正在店裡」，外帶則需要說清楚取餐安排；預約更不能直接等同一張已成立的餐點訂單。公開網站提供這些入口，實際開放項目與服務方式仍以網站當下顯示為準。

桌邊 QR／外帶入口 → 菜單 → 客製選項 → 確認內容 → 送出點餐
預約入口         → 填寫需求 → 送出預約 → 後續確認

這是顧客操作的簡化示意，不是付款或接單成功的證明。我希望確認畫面能讓人檢查商品、選項與服務方式，而不是只看到總價；送出之後也應明確區分「已提交」與「已確認」，避免讓顧客自行猜測。

前端與資料服務的分工

專案採用 React、Vite 與 TypeScript，搭配 Cloudflare Workers 與 D1。前端負責點餐介面與互動，Workers 承接 API，D1 保存結構化資料。平台機制上，React 前端可透過 Worker 使用服務綁定，而不是直接存取綁定資源；這點可參考 Cloudflare React 與 Vite 官方指南。

這套技術組合不會自動保證訂單正確。選項是否有效、送出失敗如何提示、重複操作如何處理，都需要另外設計與驗證。我更願意把它看成責任分工的起點，而不是用框架名稱代替品質說明。

網站可用，不等於所有整合已上線

實際付款、退款與硬體 POS 整合尚未全部上線，仍屬待完成與驗證的範圍。 不能因為有點餐入口，就宣稱顧客已能完成所有支付與門市作業。

接下來我想優先檢查手機操作、內容確認與失敗提示，再逐步完善外部整合；這些是後續方向，不是既有成效。本文也不宣稱點餐速度或營收已經改善。這個專案讓我體會到，小店系統的難處常常不在新增按鈕，而在讓顧客與店家對同一筆需求有相同理解。