不只辦活動！企業家庭日活動管理系統

執行過程

家庭日不是單一使用者旅程，而是一群人在同一個時間、同一個場域裡交錯完成任務。只看參與者，會忽略攤商收款壓力；只看主辦方，又容易低估現場使用者的學習成本。

角色關係｜從角色關係開始理解現場

專案初期，我先從既有家庭日流程中梳理所有可能出現在現場的角色，包含員工、眷屬、來賓、攤商、主辦方、系統方、企業與工讀生。這一步的目的，是避免只從單一使用者角度設計，而忽略現場中不同角色之間的任務關係。

在整理角色關係後，我們發現「員工、攤商、主辦方」是最需要優先關注的三個核心角色。員工是家庭日活動的主要參與者，能否順利登入、消費、參與遊戲，會直接影響活動體驗與滿意度；攤商負責承接現場交易，若收款流程不順，會立刻造成排隊、爭議與現場壓力；主辦方則負責活動規則、身份資料、點數發放與異常處理，是讓整場活動能被管理與調整的關鍵角色。

因此，後續設計並不是平均處理所有角色需求，而是先聚焦這三個角色的行為邏輯：員工是否能順利參與、攤商是否能快速交易、主辦方是否能有效管理。其他角色如眷屬、來賓、工讀生與系統方，則依照與這三個核心流程的關聯，再進一步補上對應的權限與輔助流程。

流程洞察｜從現場行為找出主要體驗

在初期訪談中，我們還發現參與者參加家庭日的主要行為不只是觀看表演，而是「把公司發放的福利用掉」。而「市集消費」是最容易理解、也最立即有感的使用方式。其次，參加者可能會帶著家人一起參與遊戲、完成任務、獲得獎品或爭取團隊榮耀；相較之下，觀看表演或其他活動內容，通常是較次要的參與選項。

因此，系統設計應優先確保「交易消費」與「遊戲參與」兩個核心流程能順利完成，再逐步擴充其他活動體驗。

這個洞察讓後續 UI 設計不追求複雜功能堆疊，而是優先把高頻任務放在第一層，並透過清楚的狀態、回饋與紀錄，降低現場操作成本。

需求整理｜需求許願池

在訪談與流程盤點後，我將需求整理成「決策影響力 × 可行性」矩陣。高影響、高可行的需求會優先進入第一階段開發；影響較低或可行性較低的需求，則先放入許願池，作為後續版本評估。

讓團隊在時間有限的情況下，先處理最會影響活動運作的核心問題。例如登入方式、點數發放、攤商收款、現場監控與資料匯出，都會直接影響活動是否能順利執行，因此被放在較高優先級。

設計策略｜收斂成五個設計策略

根據前期研究，將整個系統的設計策略收斂為五個方向：

❶ 可復用架構

系統不應只為單場活動客製，而是要建立能延伸到不同企業、不同規則與不同活動規模的架構。角色權限、活動身份與規則設定都需要模組化，讓後續活動可以快速調整，而不必重新設計。

❷ 以員工為核心

雖然這是一個 B2B 專案，付費與決策者是企業客戶，但家庭日真正的現場體驗者是員工。只有員工能順利登入、消費、參與遊戲並感受到活動價值，系統才算是真正解決了問題。

❸ 降低學習成本

主辦方、攤商與參與者都可能是第一次使用系統，因此操作不能依賴大量教學。介面需要接近現場直覺，讓使用者在短時間內就知道自己可以做什麼、下一步要去哪裡。

❹ 預留補救流程

現場活動一定會有臨時狀況，例如資料錯誤、點數未領、交易異常或主辦方臨時加碼。系統需要保留補登、回報、人工協助與異常處理機制，避免使用者卡在流程中。

❺ 操作可追蹤

身份、點數、交易與分數操作都需要留下紀錄，方便活動中即時查詢，也方便結束後回溯與核對。對主辦方與攤商來說，這些紀錄也是信任系統的重要依據。

這五個原則成為後續功能取捨與介面設計的共同判準。

開發流程｜先驗證現場風險最高的流程

開發順序也是一種設計判斷。我和團隊先從參與者與攤商的手機端流程開始，因為登入、消費、收款最容易在現場出問題，也最直接影響活動能不能運作，這樣的開發順序，讓團隊能優先驗證最關鍵的現場風險。

系統地圖｜以活動生命週期規劃後台

依主辦方在活動前、中、後的任務壓力設計。

籌備期最怕名單錯誤、規則設定不清、商家資料不完整，因此後台需要支援建立活動、匯入名單、管理商家、設計關卡、列印 QR Code、自動發放點數與開放報名。

執行期最怕現場狀況失控、公告漏接、交易或遊戲異常無法補救，因此後台需要監控儀表板、即時公告、遊戲計分、排行榜、問卷回饋、抽獎活動與失物招領。

結案期最怕資料散落、核銷困難與無法整理成效，因此後台需要支援點數核銷與資料匯出。

這樣的規劃讓後台更貼近主辦方真實工作節奏，而不是讓使用者在大量功能中尋找下一步。

設計挑戰

產品在開發過程中，我們遭遇了許多設計上的困難與決策。這邊我將幾個比較重要的設計決策案例進行說明：

設計挑戰❶｜讓不同角色在同一套系統中順利完成任務

家庭日活動中會出現多種角色與身份，例如員工、眷屬、來賓、攤商、工作人員、主辦方與系統方。這些人都可能會使用同一套系統，但他們進入系統後能看到的功能、能執行的操作，以及需要驗證的資料都不一樣。

如果直接把「身份」與「權限」綁在一起，後續只要新增一種身份，例如 VIP 來賓、臨時來賓、眷屬或工讀生，就可能影響既有權限架構，讓系統變得難以維護。

因此，我們將系統拆成兩層邏輯：Role 與 Identity。

Role 代表系統權限，例如參加者、攤商、主辦方與系統管理者，決定使用者可以進入哪些功能。Identity 則代表活動身份，例如員工、眷屬、來賓或 VIP，決定使用者的驗證方式、活動資格、點數額度與參與規則。

透過這樣的拆分，系統可以在不破壞權限架構的情況下，依照不同活動需求新增身份或調整規則。也讓後續的登入、點數、交易與遊戲流程，都能建立在更穩定的角色架構上。

設計挑戰❷｜交易流程迭代

市集交易是家庭日活動中最高頻、也最容易造成現場壓力的流程。初期我們在辦公室內推演出最簡單的付款方式：參加者掃描攤商 QR Code 後，依照攤商口頭告知的總額手動輸入金額並完成付款。

第一次活動後，客戶希望未來能分析各攤商與商品的銷售表現，作為後續篩選參展廠商的依據。因此我們新增菜單功能，讓攤商可以建立商品與價格，參加者掃描 QR Code 後能直接選擇品項，由系統自動計算金額並累積商品銷售數據。

但在第二次活動現場，我們發現菜單功能並不適合所有攤商。部分攤商的商品品項過於細碎，名稱相似、種類繁多，參加者即使看到菜單，也很難快速判斷眼前商品對應哪個項目。這時反而由攤商直接告知總金額，再由參加者手動輸入，會比逐項選單更有效率。

因此最後我們將交易流程修正為雙支付模式：有菜單時預設進入菜單支付，無菜單時預設進入手動輸入，兩種模式也都可以在付款介面中自由切換。這讓系統不再強迫所有攤商使用同一種交易流程，而是依照攤商資料完整度與商品型態，提供更適合現場的付款方式。

其它關鍵設計決策與取捨

在真實活動情境中，往往不是最理想的流程，而是要在安全性、彈性、公平性與現場效率之間取得平衡。

例如家庭日現場經常會出現臨時加碼、特殊來賓、點數調整等需求。這些需求不能完全拒絕，但也不能讓主辦方任意改動規則。

因此，我們將高風險操作轉成「可控的彈性」：
臨時加分不直接修改規則，而是透過加權調整處理；
VIP 消費不做無限制放行，而是透過數位禮物卡保留額度與交易紀錄；
點數流向不開放自由交易，而是用角色交易規則控管。

設計重點不是讓系統什麼都能改，而是讓必要的調整有權限、有紀錄、可追蹤。

而有些設計在規格上看起來合理，但到了現場才會發現使用情境不同。像 Email 登入雖然安全，卻不是所有員工都熟悉；菜單支付能累積銷售數據，但不一定適合品項複雜的攤商。

因此，我們沒有強迫所有角色使用單一流程，而是保留替代路徑：
登入同時支援 Email、OTP 與自定義欄位驗證；
交易同時支援菜單支付與手動輸入；
活動、遊戲與交易時間也拆成不同時間軸，讓主辦方能依現場需求調整。

設計重點不是追求流程最完整，而是讓不同現場條件下，都能找到可執行的操作方式。

UI 設計

這套產品並不是單一前臺或單一後台，而是依照使用情境拆成三大部分：使用者前臺、活動管理者中臺，以及系統方後臺。

參加者端一開始就沒有規劃 App，因為多數人只會在活動當天短時間使用。讓他們下載、註冊、學習一個新 App，反而會提高進入門檻。所以參加者使用 Web 前臺，透過連結或 QR Code 進入即可完成登入、查看點數、參與任務與查詢紀錄。

攤商端則比較特殊。初期我們也用 Web 統一處理，但實際進到現場後發現，攤商需要更明確的收款提示與交易回饋，尤其在人流密集時，任何提示延遲或不夠醒目都會影響結帳節奏。後來因此追加 App 版本，同時保留 Web 作為彈性入口，讓不同攤商能依設備與現場習慣選擇使用方式。

UI 設計｜讓不同年齡層都願意靠近

家庭日的使用者不像一般 SaaS 產品那樣集中在同一種工作情境裡。現場可能有年輕員工，也可能有長輩、眷屬、小朋友，大家對手機操作的熟悉程度差很多。這也是我在設計參與者端 UI 時，一開始就刻意避免過於強烈或太有科技感的視覺語言。

我選擇用乾淨的版面、柔和的圓角卡片、明確的分區與較大的點擊區域，讓畫面看起來親切、穩定，也比較容易被不同年齡層接受。對參與者來說，這不是一套需要學習的系統，而更像活動當天拿到的一張數位導覽卡。

這種設計語氣後來也帶來一個很實際的成果。在第一次大型企業家庭日測試中，另一家大型企業的人資團隊剛好也參與了活動。對方不是先被某個後台功能說服，而是在現場看到參與者端介面的完成度、親和力與實際操作流暢度後，主動邀請我們進一步提案下一場企業家庭日。

UI 設計｜以 Design Token 支援多品牌活動

而我們為了家庭日系統需要服務不同企業客戶，介面不能只綁定單一品牌色。如果每換一個客戶就重新調整整套 UI，後續維護成本會非常高。

我的做法是把色彩變成可配置的主色與輔色，再延伸到按鈕、圖示、狀態標籤、資訊卡、提醒訊息與重點文字。主辦方只要調整主要顏色與次要顏色，就能改變整體視覺風格，更貼近品牌。

總結與反思

回頭看，這個專案對我來說不是單純參與一個產品開發，而是一次完整主導產品設計的實戰。從需求怎麼收斂、角色怎麼切、流程怎麼排，到哪些功能必須先做、哪些規則不能寫死，我都參與了關鍵判斷。

這個專案讓我更確定：成熟的 UIUX 設計，不只是把畫面做漂亮，而是定義產品在真實世界裡如何運作、如何承受變化、如何被下一次繼續使用。

如果說這個專案帶給我最大的確認，是我不只想做介面設計，而是想成為能主導產品方向的 UIUX / Product Designer。能把混亂的真實流程整理成可使用、可維護、可延伸的產品系統，並在必要時做出清楚的設計取捨。對我來說，這才是設計真正有價值的地方。