Woodball Vista 木球競賽資訊系統

摘要

在這個專案中，我接手一套完成度約 25% 的木球競賽管理系統，從主導產品設計到兼任專案經理，把高度依賴紙本的傳統賽事作業，改造成「選手」與「管理者」雙角色的數位平台，並帶著它走過 15+ 場真實賽事的迭代。

在設計面，我重構整個設計系統與核心使用流程：過程中我從目標使用者（中高齡選手與年長球隊管理者）與實際辦賽流程出發，首先把舊版暗色系、螢光色的電競風格主視覺調整成白色系日間模式的主視覺，接著重構舉辦競賽的系統操作動線、把冗長的賽程編排換成行事曆介面。最終在導入電子計桿機制後，靠觀察現場作業流程找出「檢錄塞車的真正瓶頸不是找不到 QR Code，而是報到機台太少」這個關鍵問題，並且提出解決方案和設計。

在專案管理面，我面對的是「客製化的賽制需求不斷被提出 → 設計與開發時程被壓縮 → 上線後非預期錯誤發生率高」的惡性循環，我用「評估需求必要性、定義優先順序、分階段導入，並把賽事資訊提前轉化為可預測排程」的做法協助團隊跳出過去的惡性循環。這段經驗也是我從設計師正式轉任 PM 的契機。

專案成果：

• 系統累計支援 15+ 場正式賽事、10+ 球隊、單場最高 200+ 選手**
• 實測把賽事籌備從 1 週縮短到 1 天內、成績計算與排名發佈從 1 小時縮短到即時更新
• 取得中華民國新型專利，我為並列新型創作人之一。

歡迎繼續閱讀專案細節 ↓

---

專案背景

傳統木球賽事高度依賴紙本作業 — 計分卡、賽程表、成績公告全部是紙本。這帶來三個長期痛點：

1. 主辦方籌備賽事耗時
2. 比賽過程中成績與排名計算經常延遲
3. 紙本在戶外遇到天候不佳時難以執行

我接手這個專案時，前任設計師已在系統完成度約 25% 時離職，留下的版本有幾個明顯問題：

• 介面採用暗色系、螢光色的電競風格，明顯不利於目標使用者：中高齡選手與年長球隊管理者、在戶外進行木球賽事的選手 的介面視讀體驗
• 舉辦競賽的關鍵操作流程卡關，子步驟散落在多個獨立頁面之間。

我的任務，是 從這個半成品重新定義整個產品的設計系統與使用流程，並繼續完成當時待設計的功能。

我的角色帶來兩個面向的視角

我以 UI/UX 設計師身分接手，後期兼任專案經理，負責這個專案完整的 UX 流程與 UI 設計，並主導電子計桿等新機制的導入、測試與上線。

這個專案最能代表我的價值的一點是：我同時用設計師的眼睛看「產品設計好不好用」；用 PM 的眼睛看「每個需求值不值得現在做、做了會如何影響產品和團隊的運行」。

這兩個視角其實共用同一套解決：先拆解流程、找出真正的瓶頸，再決定如何下手，在介面上，它讓我找到使用者真正卡住的環節；在專案上，它讓我判斷哪些需求是核心、哪些可以延後。下面我分成「設計決策」與「專案管理」兩個面向說明。

設計決策：從使用情境回推介面

我的設計的時候通常會 先確認「誰在什麼情境下使用」，再回推介面該長什麼樣。

木球運動的主要客群是中高齡選手，辦賽人員也多為年長的球隊管理者，而練習賽計桿、查詢成績等功能會在白天的戶外球場使用。

就像最一開始舉的例子，這個使用情境直接推翻了前任的設計方向：暗色螢光的電競風格在烈日下幾乎無法閱讀。我把整套主視覺打掉重做，改為白色系日間模式，這不是美感偏好，而是從分析實際目標使用者的特性和使用情境推導出的可讀性改善決策。

一、舉辦競賽流程：從「散落多頁的子步驟」收斂為「線性而不失方向感」

接手時，舉辦競賽的功能已經有相當完整的「四大步驟」架構：編輯資訊、管理報名、安排賽程、管理成績。問題出在每個大步驟底下又有許多子步驟，而每個子步驟都是一個獨立頁面，靠「上一步 / 下一步」按鈕串接。

我判斷這個結構的風險在於：辦賽是一種需要反覆在步驟間確認資訊的操作（例如安排賽程時要回頭核對報名名單），而獨立分頁會讓使用者在大步驟與子步驟的層級裡迷失方向，不知道自己走到哪、還剩多少。

我的做法是把原本獨立的子步驟頁面，改為垂直可展開 / 收縮的區塊，依序排列在同一個大步驟頁面中。這樣 每個大步驟就只對應一個頁面，使用者能在不離開當前頁面的前提下，依序完成各子區塊的設定，隨時看得到整體進度。

至於子區塊裡的複雜操作（例如批次報名、賽程表細部安排），則用彈出視窗呈現，同樣就可以避免使用者被迫切換到另一個獨立步驟而失去方向。

這個取捨的核心是：在「步驟清楚」和「不失去全局感」之間找到平衡。完全攤平成單一長頁面會讓人找不到重點，完全拆成多頁又會迷失方向，垂直區塊是兩者之間的解。

二、報名管理：把「先輸入、再分組」的兩段流程合而為一

原本的報名管理是分段的：先輸入選手名單，再從一整批選手裡逐一找出對應的人、選入各組別。當選手數量一多，「在多人中找到要分組的那個人」就變成一件耗時又容易出錯的事。

我重新設計的方向很單純——把分組的決策時機提前到輸入的當下。使用者在輸入名單時，就能直接為該選手選擇要參加的組別，省去事後交叉比對選手與組別的整段流程。

這個決策看起來很小，但它反映的是我看流程的方式：與其優化「在大量資料中尋找」這個動作，不如直接消除「需要尋找」這件事。

三、賽程安排：用使用者熟悉的「行事曆」取代冗長的賽程表

舊版的賽程安排是把選手賽程一排一排直接列在頁面上，非常冗長；同時選手名單會一直固定在畫面側邊供拖拉使用。結果是畫面資訊過於繁雜，而且所有相關聯的操作選項散落各處、彼此不連貫，使用者無法照著自然的邏輯依序完成設定，而是得在散落的介面裡到處找需要的選項。

我導入了使用者本來就熟悉的行事曆介面來取代一排排的賽程表。原本冗長的賽程，變成時程表上一個個的區塊，能一眼看出賽事的時間順序與長短；點選區塊後才開啟視窗進行選手安排，避免一開始就把所有資訊塞滿畫面。

更重要的是視窗內的引導順序——我讓使用者依「時間 → 組別 → 競賽階段」的順序選擇，全部選完後才顯示對應的選手名單供安排。這個順序不是隨意的，而是對應過去實務上在木球賽程時的順序，讓選項出現的次序對應使用者腦中本來的決策邏輯，使用者就能在介面引導下，照合理的順序很直覺地完成安排。

行事曆是這個專案我最滿意的決策之一，因為它同時解決了三件事：降低學習成本（沿用熟悉的心智模型）、收斂畫面資訊（先看重點再看細節）、以及讓操作順序符合直覺。

四、電子計桿檢錄：找出「真正的瓶頸」，而不是優化錯的地方

一般計桿穩定運作一年後，我們開始嘗試在正式競賽導入電子計桿機制。計桿介面本身刻意與選手平時練習賽的介面一致，除了開賽前要掃描 QR Code 登入之外幾乎沒有學習成本，結果上線後最大的問題反而出現在檢錄環節。

檢錄時，計桿人員需要到報到櫃台掃描主辦方提供的計桿卡 QR Code，但現場通常只有 1～2 台電腦能提供掃描，一張一張開啟讓人掃，導致檢錄時間被嚴重拉長。

我沒有急著調整當下現有的介面，而是我先回頭去理解「過去紙本時代的檢錄是怎麼運作的」。我發現過去是印出紙本計桿卡、核對姓名後直接發出，不受機台數量限制，而且現場其實有「多位」工作人員在協助檢錄，只是電子化之後，所有人被迫擠在那 1～2 台機台前，人力反而被機台數量綁死。

換句話說，瓶頸不是「找不到 QR Code」，而是「能提供掃描的裝置太少」。釐清這點之後，我也排除了一個直覺但錯誤的方案——把多個 QR Code 一次全攤在畫面上，那只會製造新的尋找與誤掃問題。

最後的解法是設計一個手機版檢錄頁：讓檢錄人員用自己的手機登入後台，選擇自己有權限協助的競賽，直接開啟檢錄名單，搭配關鍵字搜尋，只要輸入選手姓名就能找到對應的電子計桿卡 QR Code，用手機畫面提供選手掃描。這等於把「報到裝置」從 1～2 台，擴張成「現場每一位工作人員的手機」，活用了原本就存在、卻被機台數量閒置掉的人力。

---

專案管理：在客戶需求與開發時程之間取得平衡

設計只是這個專案的一半。隨著系統導入越來越多真實賽事，更大的挑戰其實在專案管理層面。

破解「需求 → 壓縮時程 → 上線出錯」的惡性循環

木球賽制至今尚未標準化，各地方賽事組織常有自己的辦賽規則，因此不斷提出計分方式、賽制設定上更彈性的客製需求。早期我還沒參與專案管理時，接到這類需求就盡量調整設計去滿足，主管也常要求在很臨近的賽事中導入新機制，結果就是設計、開發、測試的時間都相對較趕，上線後出現的非預期錯誤又持續發生。團隊陷入一個循環：新需求進來 → 時程被壓縮 → 開發測試不足 → 上線處理錯誤 → 再被下一個需求追著跑。

我和主管與團隊多次溝通後，建立了三個機制來挑脫這個循環：

1. 從源頭評估需求必要性：設計前先一起評估每個新需求是否非滿足不可，或有沒有折衷方案，而不是無條件全接。
2. 定義優先順序、分階段導入：把需求依重要性排序、分批導入，收斂每次迭代的目標，不讓單次範疇無限膨脹。
3. 把不確定的需求變成可預測的排程：我發現賽事日期、賽制與人數其實能提前向主辦方問到，於是主動請主管提供未來半年內每場賽事的日期與賽制人數，讓我能為測試上線時程根據具體的競賽時程預留更多緩衝。

這套做法施行後，團隊跳出了惡性循環，後續新機制的上線比過去順利許多，也正是因為長期協助主管溝通需求優先度與排程，我才從設計師正式轉為兼任 PM。

跨職能協作

身兼設計與 PM，我負責協調設計、開發、測試三方的節奏，並在每次迭代前與主管對齊「這一版要解的核心問題」。我具備基本的前後端開發知識，能在規劃時就評估技術可行性與開發難易度，把需求轉成開發團隊接得住的合理時程，而不是單純提出一份我認為最理想的設計而不與開發人員溝通合理性。

成果

這套系統在競賽管理功能上線後，2 年內導入台灣約 15+ 場正式木球地方賽事，每場約 100 位參賽選手、最多達約 200+ 人，並持續吸收使用者回饋調整。實測效益：

• 賽事籌備與報名準備：從 1～2 週縮短至 1 天內
• 成績統計人力：從紙本時代的 2～4 人，降至 1 人輸入系統自動計算排名，導入場上電子計桿後更是趨近 0 人執行統計
• 頒獎等待時間：因成績自動計算，從等待 1～3 小時縮短到成績輸入完成後 10 分鐘內即可頒獎
• 紙張使用：從單場數百張降至數十張

即時計桿與即時成績排行輪播功能，首次應用於公司自行籌辦的地方沙灘木球競賽，獲得全國與地方層級木球協會、地方政府、贊助單位的肯定，爭取到成為官方認證地方賽事的機會，並取得隔年再次協辦的認可。

另外，本系統並獲中華民國新型專利認證，我也為並列新型創作人之一。

反思

這個專案讓我確認了兩件事。設計上，好的決策往往不在介面，而在對使用情境的理解深度：檢錄那段如果急著做介面，很可能做出「把 QR Code 全攤開」這種加劇問題的方案。

專案管理上，真正解決問題的不是更努力地趕工，而是改變解決需求的方式：把不可控的客戶需求，轉成可預測、可分階段的排程。

如果重來，我會更早把「現場實地觀察」排進設計流程，也會更早在團隊裡建立需求評估的機制，而不是等到被惡性循環追著跑才開始溝通。