Dermapen 4 台灣官方網站開發

【專案背景】 Dermapen 4 是全球微針領導品牌，本案為其台灣官方入口網站。 國際品牌的台灣官網有一個特別的任務： 它同時要服務「想了解療程的一般消費者」與「想引進設備的診所」， 這兩種人要看的東西完全不同。 【最難的地方】 醫療器材的網站有法規限制，文案不能過度宣稱療效， 但又必須讓消費者感受到品牌的專業與國際地位。 我們的處理方式是把說服力放在「可驗證的事實」上—— FDA 認證字號、台灣 TFDA 認證、CE 認證、 全球佈局數字、原廠保固年限—— 用事實堆疊信任，而不是用形容詞。 【我們怎麼解】 1. 雙動線設計：消費者看療程與診所地圖，診所看設備與培訓認證。 2. 授權診所地圖，消費者可直接找到最近的合法授權院所， 同時也解決了品牌打擊非法水貨的需求。 3. GSAP 動效強化產品質感，但控制在不影響載入速度的範圍內。 4. 線上諮詢表單直接串接品牌方的名單流程。 【成果】 一個入口同時承接消費者諮詢與診所合作洽詢， 授權診所地圖也成為品牌區隔正貨與水貨的實際工具。

中央研究院 原子與分子科學研究所官網

【專案背景】 中央研究院原子與分子科學研究所官方網站。 學術研究機構的網站與一般企業官網有兩個根本差異： 無障礙規範是硬性要求，而且內容更新頻繁、由多位行政人員共同維護。 【最難的地方】 無障礙不是「加上 alt 文字」就結束的事。 鍵盤要能走完所有互動、螢幕閱讀器要念得出正確的閱讀順序、 色彩對比要達標、動態內容變更要能被輔助技術感知。 這些規範會實際限制版面與互動的設計方式， 必須從切版第一天就納入，不能等做完再補。 同時，網站要能被非技術背景的行政同仁自行維護—— 研究成果、近期活動、人才招募這些內容更新很頻繁， 每次都找廠商是不可行的。 【我們怎麼解】 1. 語意化 HTML 與完整鍵盤導航，符合無障礙規範。 2. 中英雙語架構，兩種語系內容各自獨立維護。 3. 後台涵蓋研究成果、學術榮譽、近期活動、人才招募， 行政同仁可自行上下架，不需技術背景。 4. 依機構資安要求進行部署與權限控管。 【成果】 網站上線後由所內同仁自行維護， 內容更新不再需要透過外部廠商。

機場接送預約排程與派單平台

【業主原本卡在哪】 車隊調度靠白板和電話。客戶打來訂車，客服要翻本子確認哪台車有空； 司機不知道今天要跑哪幾趟；客戶想確認司機到了沒，只能再打一次電話。 尖峰時段一忙起來，重複派單或漏單都發生過。 【最難的地方】 機場接送的難處在於「一趟任務會佔用車輛好幾個小時， 而且結束地點會影響下一趟能不能接」。 單純把訂單塞進時段是不夠的—— 系統必須考慮車輛跑完這趟之後人在哪裡、 回到市區要多久，才能判斷下一張單能不能派給同一台車。 這個邏輯沒處理好，排出來的班表看起來很滿，實際上跑不動。 【我們怎麼解】 1. 視覺化班表：車輛 × 時段一目了然，衝堂與空檔直接看得出來。 2. 派單時自動檢查車輛可用性，避免重複指派。 3. 多角色權限：客服看得到全部，司機只看得到自己的任務。 4. 派單後自動通知司機與客戶，客戶可線上查進度，不必打電話。 【成果】 調度從白板搬到系統，客服不再需要人工比對， 客戶自助查詢也大幅降低了客服來電量。

牙醫資訊平台（媒合・商城・課程・社群）

【專案規模】 Dentalk 是牙醫產業的綜合資訊平台，一套系統裡同時包含四個子系統： 人才媒合、線上商城、課程系統與社群討論。 另有行動 App 供使用者隨身使用。 【最難的地方】 四個子系統的使用者其實是同一群人，但身分不同： 同一位牙醫師，在媒合裡是求職者、在商城裡是買家、 在課程裡是學員、在社群裡是發文者。 如果每個子系統各自管理會員，資料會立刻分裂。 我們把會員與權限抽成獨立的核心， 四個子系統共用同一份身分與權限模型， 再各自延伸自己需要的資料，避免日後互相打架。 【我們怎麼解】 1. 會員與權限單一來源，四個模組共用身分。 2. 前台以 Astro 5 + Vue 3 建置，兼顧 SEO 與互動性—— 對資訊平台來說，被 Google 搜到就是流量命脈。 3. 後端 Laravel 11 + Filament 提供完整後台，營運端可自行管理。 4. 行動 App 以 Flutter 開發，iOS / Android 同一套程式碼。 【成果】 單一平台承載四種截然不同的業務型態， 營運端只需要一個後台，不必在四套系統之間切換。

WMS 倉儲管理與 iOS PDA 行動

【業主原本卡在哪】 倉庫揀貨靠紙本清單。新人不知道貨放在哪個儲位， 揀錯了要等出貨後客戶反映才發現，退換貨成本全由公司吸收。 主管想知道今天出了幾單，只能等下班後人工統計。 【最難的地方】 倉庫的網路訊號往往不穩，PDA 掃到一半斷線是常態。 如果每一次掃碼都要即時打 API，實務上根本不能用。 我們的處理方式是離線暫存：掃碼先寫本地， 恢復連線後批次同步，並在伺服器端做重複與衝突檢查， 確保同一件貨不會被重複扣帳。 【我們怎麼解】 1. 建立儲位管理，每個品項都有明確位置，新人照著走就找得到。 2. iOS PDA 掃碼揀貨，掃到非清單品項系統當場擋下，錯的貨出不了門。 3. 波次揀貨：把多張訂單合併成一趟路線，減少倉庫來回走動。 4. 出貨進度即時回傳，主管在後台就能看到今日進度。 【成果】 揀貨從「靠記憶與紙本」變成「照著手機走」， 錯揀在出貨前就被攔下，新人上手時間大幅縮短。

視覺化 SOP 流程編輯器與待辦控管

一張訂單該由誰、依什麼順序、做哪些步驟—— 多數公司的答案是「問資深員工」。人一離職，流程就跟著走了。 我們做的是一套讓業主自己畫流程的系統。 【業主原本卡在哪】 跨部門的訂單流程只存在老員工腦袋裡與 LINE 群組中。 新人不知道下一步該找誰，主管不知道單子卡在哪一關， 每次流程要調整，都得回頭找工程師改程式。 【最難的地方：範本快照】 這是整個專案最難、也最容易被忽略的一件事。 流程範本是會改的。問題是：當流程改版時， 那些「已經跑到一半」的舊單怎麼辦？ 如果讓舊單直接套用新流程，就會出現「單子開的時候有 5 個步驟， 做到第 3 步時流程改了，突然變成 7 個步驟，而且前面做過的對不上」 ——這種資料錯亂事後幾乎無法救。 我們的做法是範本快照：每張單建立時， 把當下的流程範本完整複製一份綁在這張單上。 之後範本再怎麼改，都只影響新單，舊單照原本的規則跑完。 這件事在需求訪談時客戶不會提，因為他不知道會發生。 但只要系統上線超過三個月，一定會遇到。 【其他幾個關鍵設計】 ・主線步驟與例外步驟分離：缺料、退件這類分支可以隨時展開， 不必為了少數情況把主流程畫得像迷宮。 ・跨範本跳轉：一張單可以在流程中途轉到另一套範本， 處理「這筆改走急件流程」這類真實情境。 ・領域驅動的狀態機與事件：每次狀態轉換都是一個事件， 完整留下軌跡，事後可追可查。 ・RBAC 權限模型：誰能看、誰能簽、誰能改流程範本，分層控管。 ・Zod 全鏈路型別驗證：資料進出都驗，減少上線後的意外。 【成果】 流程從「只有資深員工知道」變成一張畫在畫面上、 所有人都能看懂的圖。每張單自動長出待辦， 誰該做什麼、卡在哪一關，主管打開就看得到。 流程要調整，業主自己在畫面上拉，不必再等工程師排程。