設計重點
- 資訊架構：將公開網站收斂成四個分類，讓居民快速找到時間、地點、公告與聯絡方式
- 公開／內部分流：把攤位、財務與 RSVP 等營運資料留在內部 Dashboard，不外露到公開頁面
- 漸進式揭露：以單一主視覺畫面搭配 modal，讓細節不必離開首頁就能讀完
專案定位
不只是活動頁，而是一套地方活動資訊系統
這是一個自主概念專案。情境是我自己設定的——假設社區第一次舉辦二手拍賣市集——並針對它設計數位端：公開網站讓居民快速看懂活動，內部 Dashboard 給主辦單位追蹤籌備進度。在這個概念裡，我處理的設計範圍是資訊架構、公開網站設計、前端實作與聯絡流程。這個題目沒有業主、也沒有實際舉辦，重點在系統性的拆解方式，而不是活動成效。
問題與目標
讓活動可信、好找，但不外露還沒整理好的營運資料
居民只需要時間、地點、入場方式、雨天備案與聯絡方式；主辦單位還要管理攤位、財務、來賓回覆與風險，但這些不適合放在公開網站。目標是首頁要有記憶點、細節要好找，而且在籌備資料持續變動時，公開內容仍能保持穩定。
關鍵設計決策
將公開理解與內部決策分開設計
- 公開導覽只保留關於、活動資訊、公告與聯絡四類，避免居民被籌備細節干擾。
- 用 modal 漸進揭露細節，讓使用者不離開主視覺畫面也能讀到完整資訊。
- 把攤位進度、財務、RSVP 與風險提醒移到內部 Dashboard，讓公開內容維持穩定。
主要畫面展示
以快速理解活動為核心的公開網站
這些畫面呈現居民進站後會看到的重點：活動名稱、時間地點、注意事項與聯絡方式。
營運工具案例
為籌備判斷建立內部 Dashboard
Dashboard 不放在公開網站裡，而是整理攤位進度、財務、RSVP 與風險提醒，讓主辦單位快速知道接下來要處理什麼。
- 用 KPI 卡片、進度圖與提醒事項，讓籌備狀態一眼就能看懂。
- 優先顯示整體狀態，避免直接曝光原始名單。
聯絡流程案例
把不確定的提問轉成可追蹤的路徑
公開網站沒有只放一支電話，而是把問題導向表單，讓主辦單位可以實際追蹤後續。
以下是我對自己設計所做的檢查，而不是實際活動的成果：居民能否快速看懂活動、內部營運資料是否沒有外露，以及主辦單位能否持續維護籌備資料。
- 4 個分類
- 公開網站資訊架構
- 24 個攤位
- 概念情境設定的規劃容量
- 1 個 Dashboard
- 內部營運視圖
反思與下一步
下一版應補上活動後資料與維護流程
目前版本涵蓋活動前的溝通與籌備。如果這個概念真的執行，下一步會是整理到場人數估算、主辦單位回饋，以及未來活動可重用的更新清單。
- 把這些假設拿去跟真實的居民與主辦單位驗證，再比對實際到場、攤位動線與詢問狀況的差距。
- 把網站與 Dashboard 整理成未來社區活動可重用的模板。