COURSE PROJECT · RESEARCH IN PROGRESS
Mealoop
讓打烊前的剩食，出現在下班原本就會經過的路上。
01 · OVERVIEW
專案概述
Mealoop 是一個 B2C 惜食平台：讓烘焙坊、咖啡廳在打烊前把剩下的食物上架，讓 22–35 歲的上班族在下班路上預訂、取貨。策略是「選商圈，不選品類」，先把一個商圈的店家密度做高，讓使用者在步行距離內訂得到。
- 類型
- 課程專題 · 6 人小組
- 我的角色
- 流程、UI／原型主責，研究副手
- 參與範圍
- 訪談、研究分析、Findings → HMW → MVP 範圍（主要流程由小組共同進行）
- 時間
- 2026.10–現在
- 研究
- 店家端 7 場、消費者端 8 場質性訪談，加上桌面研究與 7 個競品分析
- 目前階段
- 研究收斂 → MVP 範圍與視覺方向
這是仍在進行中的小組專案。這一頁是進度紀錄，不是完整案例：內容以目前的研究結論為準，之後會隨原型與測試更新。
02 · BRIEF
題目與重新定義
題目設定了一間虛擬的惜食新創，請我們設計店家端與消費者端的媒合體驗。我們沒有直接照著題目畫功能，而是先把題目拆成事實、解讀、解法和商業模式，再把每個設計問題改寫成可以在訪談中查證的問題。
- 題目設定
- 虛擬的食品科技新創「Mealoop 食循」，要把惜食袋模式從單一商圈的概念驗證擴展到台北全區
- 產品
- 即時媒合平台：店家在營業尾聲把即將報廢的食物組成惜食袋，以原價 3–5 折上架；消費者在 App 上預約、到店取貨
- 使用者
- 店家端是烘焙坊、咖啡廳、便當店等中小型餐飲業者；消費者端是 22–35 歲、重視性價比的都市上班族
- 核心挑戰
- 時間：店家要在對的時間快速上架，消費者要在對的時間看到附近的選項，整個流程要在食物品質的有效窗口內完成
- 成效指標
- 惜食袋上架率、預約到取貨完成率、消費者 30 日回購率
- 設計範圍
- 上架流程、探索與預約、取貨流程、資訊透明機制（品類說明、店家評價、食物狀態描述）
- 不在範圍
- 食品安全法規認證、物流配送、金流串接、店家 ERP／POS 整合
店家怎麼在打烊前快速上架？
老闆收店時實際在做哪些事？最近一次沒有處理剩食，那天發生了什麼？
消費者怎麼找到附近、判斷值不值得去？
最近一次找晚餐時，用什麼判斷「值得走過去」？
驚喜感和資訊透明怎麼平衡？
最近一次買內容不確定的東西時，什麼讓他滿意或失望？
取貨時段怎麼設計，才能降低爽約？
最近一次預約了卻沒去，發生了什麼事？
桌面研究推翻的兩個題目前提
台灣還沒有以即時剩食媒合為核心的主流平台
已經有同類平台上線，而且模式幾乎重疊。我們必須回答「差在哪」，最後把差異定在「訂得到」：先把單一商圈的店家密度做高。
惜食袋價格由店家自行設定
在其他市場，店家自訂價格引來「原價灌水、份量縮水」的假剩食負評。定價方式改列為待決策的問題。
題目把「時間」列為核心挑戰，這是出題方的解讀，所以我們把它當成待驗證的假設，而不是前提；成效指標也只當作商業上的篩選條件，不直接等於使用者價值。
03 · PROGRESS LOG
進度日誌
視覺方向：兩個情緒版並行
整理 7 個競品的配色、字體、食物照片與卡片資訊層級。觀察到多數惜食產品用綠色，而且點進店家看不到食物本身；小組偏好暖色，因為和「好吃」的連結最直接。
保留兩個差異明顯的方向：「傍晚的溫暖餐桌」主打下班趕得上，「清爽市集」主打品質與誠實。等 MVP 架構確定後，套到實際畫面上比較。
同時決定先做獨立 App，不做成外送平台裡的功能：嵌進別的平台要遵守對方規範，研究結論無法照自己的判斷落實。
FIGJAM 精簡 · 兩個情緒版方向
傍晚的溫暖餐桌 時間 · 下班趕得上
#F28C28琥珀橘 · 主色#E8613C夕陽珊瑚 · 倒數#FFF6E9奶油白 · 背景#2B2A33深墨 · 文字#5E8C61葉綠 · 環保點綴
清爽市集 品質 · 誠實
#1F3A4D深海藍 · 主色#C23B22番茄紅 · 價格／截止#E9B949麥穗黃 · 標籤#F3EDE2牛皮紙 · 背景#1E2A33墨黑 · 文字
兩個方向的色彩組合都先算過文字對比（WCAG AA）；橘色只用在倒數、價格和主要按鈕，避免處處像警示。
訪談分析：從證據到洞見
每場訪談整理成 15–25 張只寫事實、不含解讀的證據便利貼，並標上可回溯的來源編號。小組先人工分類，再用 AI 獨立分類一次，只討論兩邊不一致的地方。
消費者端收斂出 8 個主題、5 個洞見；店家端先寫出 18 條 Finding，再收斂成 7 個主題、4 個洞見。只有桌面資料、沒有訪談支持的主題，只能當待驗證假設，不能寫成 Finding。
FIGJAM 精簡 · 分析流程
- 證據一張便利貼一個事實
- 分類人工＋AI 各自分類
- 對照只討論不一致的
- Theme共同的行為主題
- Finding把原因講完整
- Insight對產品代表什麼
消費者端 8 個主題
店家端 7 個主題
訪綱 v2 與訪談
依回饋修訂訪綱：把假設性問題改成問過去的實際行為，列舉選項只在受訪者答不出來時才給，避免帶風向。
招募時刻意收「已停用」的使用者與店家，以及「沒有剩食」的店家當反證。
FIGJAM 精簡 · 訪談對象
7店家端烘焙、咖啡為主，便當店當對照；包含早午餐店、市場攤商、社區咖啡店
8消費者端22–35 歲上班族，分成現有使用者、已停用的使用者、沒用過的對照組
開始：拆解題目、列出待驗證假設
把題目拆成店家端、雙邊、消費者端共 8 個待驗證假設，每一個都寫下「支持證據長什麼樣」和「什麼情況算被推翻」。
桌面研究推翻了題目的兩個前提：台灣其實已經有同類平台上線；讓店家自由定價，在其他市場引來「假剩食」的負評。
FIGJAM 精簡 · 待驗證假設
- 店家H1每週有穩定、可媒合的剩食
- 店家H3收店流程裡有空完成上架和交貨
- 店家H8回收原本會損失的價值，是加入的首要原因
- 雙邊H2店家確定剩量的時間，早於消費者能出發取貨的時間
- 雙邊H5預約能形成雙方都會履行的承諾
- 消費者H4能排除不吃、不能吃的東西，就能接受不知道具體品項
- 消費者H6持續使用者有固定的時間或路線會開 App
- 消費者H7不會當餐吃完的人，買前會確認保存方式
04 · INSIGHTS
9 個研究洞見
兩端各自從訪談主題收斂出洞見：每一個都由多個主題串起，寫出行為和現況之間的矛盾，再轉成 HMW 問句。
消費者端 · 5 個
惜食是動線上的意外收穫，不是值得特地前往的目的地
使用者願意為惜食多付出的時間和移動幾乎是零，平台卻要他們配合店家的地點與打烊時段。
我們可以如何讓惜食出現在使用者原本就會經過的時間和路線上？
使用者買的是「這一餐」，平台賣的是「剩下的東西」
使用者從「今天想吃什麼」出發，平台從「店家今天剩什麼」出發；對不上時再便宜也不買。
我們可以如何讓使用者用這一餐的需求，找到剛好適合的剩食？
不確定性只有在風險可控時才是樂趣
驚喜包很吸引人，但一碰到份量失控、不想吃或吃壞肚子，就變成買一次就不再買。
我們可以如何保留驚喜包的樂趣，同時讓使用者對最壞情況有把握？
使用者最在意的是「確定拿得到」，而不是彈性
撲空的挫折遠大於省到的錢，受訪者寧願先付款、限制取消，也要換到確定性。
我們可以如何讓使用者出發前就確定，到了一定拿得到？
「做善事」是買完之後的好感，不是買之前的動機
大家認同不浪費，但驅動購買的是便利和想吃；只要一點摩擦就會離開。
我們可以如何讓惜食本身好用到不需要靠理念，也會一直用？
店家端 · 4 個
供給時間要彈性，但收店時間是界線
店家要到銷售尾聲才知道剩多少，卻不能因此延後收店。平台要配合店家的時間界線，不是反過來。
我們可以如何讓不確定的剩食供給，在不延誤店家收店的前提下完成媒合？
舊做法零摩擦，新管道要有淨誘因
送人、保存、報廢不一定有收入，卻不用多做任何事。店家缺的不是處理方式，而是「多做真的值得」的證明。
我們可以如何讓店家多付出的時間與成本，換得看得到的實際回報？
剩食變現和正價生意互相拉扯
折價能回收成本，卻可能傷到正價、客群與利潤；平台抽成又再壓一層。店家想多賺，但不願賠掉原有生意。
我們可以如何在保護正價與利潤的同時，讓剩食也創造額外價值？
有曝光，不代表有有效訂單
小店沒有餘力經營線上，加入平台也不保證有人買。店家看的是訂單與淨收益，不是流量。
我們可以如何在不增加店家行銷負擔的情況下，把曝光轉成有效購買？
05 · DIRECTION
選定的兩個 HMW
從 Finding 發想 HMW、再發散解法與親和分組後，兩端各選一個方向，推演未來的使用者旅程。以下是目前討論中的解法，還沒有經過驗證：
消費者端
如何降低使用者購買惜食所需的額外時間與移動成本？
- 顯示「需要多繞幾分鐘」，而不只是距離
- 依通勤路線推薦沿途的惜食
- 收藏的店家上架時通知
- 請順路的人代領
店家端
如何用極簡的上架流程降低店家負擔，讓剩食成為值得的額外收入？
- 常態品項一鍵上架、複製昨天只改數量
- 打烊前推播確認，只需按「是」或「改數量」
- 店面同時販售時，隨時調整平台剩餘數量
- 掃 QR Code 核銷取貨
06 · NEXT
接下來
- 01確定 MVP 範圍：在未來旅程上標記核心、保留但簡化、這次不做的步驟。
- 02把兩個情緒版套到實際畫面上比較，倒數提示做「低調」和「急迫」兩個版本。
- 03做出可操作原型，進行可用性測試。
研究樣本為少量質性訪談，洞見代表受訪者的共同傾向，不代表整體市場；課程資料與組員資訊不公開。