回頭整理一套診所營運平台的設計邏輯

這套產品距離最初設計已經有一段時間，因此這篇 case 不會逐一還原每個功能當時的細節，也不會把所有後續功能都視為我單獨完成。

我想整理的是：我在早期建立、並在後續帶領團隊延伸的一套設計邏輯——如何把診所每天會用到的預約總覽、服務／療程、人員設備、班表、線上預約設定與會員追蹤，整理成院所端可管理、民眾端可使用，也能支撐平台擴展的工作流程。

1Context自費診所不是把掛號流程換一個介面

在 PinMed Suite 之前，公司已經有一套服務中西醫診所的預約平台，能處理基本掛號與約診。但當產品要延伸到自費療程時，舊平台缺乏 RWD 與設計系統，也難以承載更彈性的預約設定與院所端管理流程。

現在回頭看，自費預約真正複雜的地方，不只是「病患選醫師和時間」。一筆預約能不能成立，常常取決於診所開放哪些服務／療程、每個療程需要多久、哪些人員或設備可以承接、哪些時段開放線上預約，以及預約後是否能接上提醒與會員追蹤。

因此這個產品不能只補一個線上預約入口，而需要重新定義診所後台如何管理自費療程的服務項目、人員設備、班表與預約流程。

2Insight預約安排其實是診所的資源調度工作

當我們把問題從「民眾如何預約」拉回「診所如何決定一個時段能不能被預約」，預約背後的複雜性才變得清楚。

從醫美、皮膚科與復健科等診所訪談中，我們看到三個共通點：

1. 預約入口不固定：有些診所希望民眾先選服務／療程，有些先選醫師／治療師，有些則以可預約日期與時段為主。這代表預約流程不能被設計成單一路徑。
2. 線上預約需要被院所控管：診所不一定想把所有服務、所有人員或所有時段都開放給民眾選擇。開放線上預約前，院所端需要先完成服務／療程、人員、班表與預約流程設定。這代表民眾端看到的簡單流程，必須建立在院所端可管理的規則上。
3. 系統要輔助管理，而不是取代現場判斷：服務時長、可接受預約人數、人員設備、班表與提醒設定都會影響預約如何被安排，但現場仍需要保留必要彈性。這代表系統需要提供結構，而不是消滅彈性。

這個 insight 讓設計問題變得更清楚：自費預約不是一條固定流程，而是一組需要被診所設定、開放與管理的資源調度邏輯。

3Design challenge讓複雜設定變得可操作

要讓自費診所真的用得起來，我需要解決三個設計挑戰：

1. 流程不能只服務單一科別：醫美、皮膚科、復健科對服務／療程、人員與時段的判斷順序不同，系統不能預設只有一種預約路徑。
2. 設定不能散落在不同地方：服務／療程、線上預約限制、人員顯示設定與線上預約班表都會影響民眾端是否能完成預約。這些設定需要被整理成診所能理解的管理入口，而不是靠櫃檯逐一記憶。
3. 後台需要兼顧效率與可控性：線上預約能減少人工處理，但診所也需要決定哪些服務開放、哪些人員顯示、哪些時段可約，以及哪些情境仍需要人工判斷。

4Strategy把零散功能整理成平台工作流

因此，我沒有把設計方向放在單一預約表單，而是回到診所如何安排一段服務流程，整理出四個可以支撐平台延伸的方向。其中前兩項是我早期直接參與較深的核心架構，後兩項則是在產品持續迭代後，作為設計主管協助團隊延伸與整合的方向：

1. 重定義日曆：讓日曆不只是時間表，而是診所每天安排人員、設備、服務／療程與病患的工作面。
2. 把設定前置：把服務／療程、人員設備與線上預約班表整理成後台設定，讓預約流程有明確依據。
3. 保留診所控制權：讓診所能依營運方式調整線上預約流程，例如是否先選服務／療程、如何選擇人員與時段。
4. 接上後續經營：把會員資料、提醒、標籤與個案追蹤視為預約流程的延伸。

這四件事串起來，才讓預約從「建立一筆時間」變成「管理一段診所服務流程」。

5Solution 1用預約總覽承載診所日常工作

第一層設計，是把「預約總覽」放在後台核心位置。

診所每天最常看的不是單一病患資料，而是：今天有哪些預約、每筆預約對應哪位病患、由誰負責、目前狀態是什麼、是否需要查看會員資料或後續提醒。因此我把預約日曆設計成主要工作面，讓日期、時段、病患、服務／療程、人員、狀態與備註能一起被檢視。

這樣做的重點不是讓畫面資訊變多，而是讓櫃檯不用在不同工具之間來回確認。原本分散在紙本、外部日曆、訊息與會員紀錄裡的資訊，被整理到同一個預約脈絡中。

6Solution 2把服務、班表與人員設備整理成可管理的設定

第二層設計，是把診所原本分散在人工經驗裡的預約條件，整理成院所端可以管理的後台設定。

如果預約總覽是日常工作面，那服務／療程、人員設備、班表與線上預約流程，就是讓每一筆預約能被正確安排的規則來源。回頭整理這套功能，我會把它理解成四個管理入口：

1. 服務／療程設定：診所可以建立可被預約的服務項目，設定預約時長、可接受預約人數、顏色標示，以及是否開放民眾在線上預約。
2. 人員與設備設定：這是我早期直接參與設計的核心之一。自費預約不只需要醫師，也可能牽涉治療師、診間、設備或其他資源，因此後台需要先定義哪些人員與設備會參與預約流程。
3. 線上預約班表設定：後續團隊在這套架構上延伸出更細的線上預約時段設定，讓診所可以控制民眾端實際看得到的可預約範圍。
4. 線上預約流程調整：團隊也進一步補上民眾端預約流程設定，讓診所能依營運方式決定民眾要先選服務／療程、人員，或日期與時段。

這樣一來，預約不再只是把時間填進日曆，而是讓診所先定義「哪些服務可以被預約、哪些人員或設備能承接、哪些時段要開放給民眾」。

這一層功能不是在同一時間一次完成。早期我直接參與較深的是預約安排工作面，以及人員與設備如何進入預約流程的基礎架構；後續隨著產品擴展，團隊再依不同診所與線上預約需求，逐步補上服務／療程設定、線上預約班表與預約流程調整等功能。我的角色也從直接設計核心流程，逐步轉為設計主管，協助團隊把後續功能延伸回同一套平台邏輯裡。

7Solution 3把院所端設定轉譯成民眾端可預約流程

如果前一層是在院所端建立規則，第三層設計則是處理：這些規則如何被轉譯成民眾端看得懂、也選得動的線上預約流程。

過去我們容易把預約想成「診所有班，民眾就能選時間」。但實際產品設定與線上預約流程顯示，院所端完整班表不一定等於民眾端看得到的可預約時間。診所需要依照服務／療程、人員、班表、時間間隔與開放規則，決定哪些選項要呈現在民眾端。

因此我在設計上支援線上預約流程設定，讓診所能依營運方式調整民眾端的預約順序：

• 日期優先：民眾先看可預約日期與時段
• 服務／療程優先：民眾先選服務，再依服務看到可預約時間
• 人員優先：民眾先選人員，再接續選擇服務與時段

這樣的拆分讓診所保留營運控制權：他們可以有完整班表，但只開放部分時段給線上預約；也可以依不同服務／療程或人員，呈現不同的可預約時間。對民眾來說，看到的是簡化後的可選流程；對診所來說，背後仍保留班表、服務與人員設定的彈性。

8Scaling從 PinMed Suite 整合進 1.Talk

前面三個 Solution 說明的是早期預約平台邏輯如何被建立；而 Scaling 這一段要回到另一個問題：當產品從 PinMed Suite（自費）逐步整合進 1.Talk，成為不分科別的醫病關係管理平台時，這套邏輯如何被保留、重整，並交由團隊延伸。

這個階段，我的角色也從單一產品設計師，逐漸轉為設計主管。設計挑戰不再只是完成某個功能，而是做平台整合時的判斷：哪些早期使用習慣要保留、哪些架構需要重新整理、哪些功能可以交由不同設計師延伸，以及哪些預約、人員設備與班表邏輯必須維持一致。

對既有使用者來說，穩定、可預期、低學習成本，有時比全新介面更重要。因此在整合過程中，我們優先延續診所熟悉的操作邏輯，再針對 1.Talk 的新架構調整資訊架構與模組邊界。我的工作也從「把單一流程設計完整」，轉為協助團隊判斷每個後續功能是否仍接得上原本的預約工作面、資源關係與線上預約規則。

當產品進入日本市場後，設計判斷也不只停在功能移植，而開始碰到語言、時區、字體、角色視覺與醫療溝通習慣等文化差異。這些在地化議題不是這篇 case 的主軸，因此我只在這裡作為平台擴展的轉折帶到；更完整的日本市場與文化性設計思考，會放在 Localization, Below the Surface。

後續 1.Talk 也被定位為能支援全科別診所、一站管理「健保給號制掛號」與「自費時段制預約」的約診暨排程管理工具。這也回頭驗證了早期將人員、設備、療程時長與班表納入日曆工作面的決策，不只是為醫美場景補功能，而是在建立可擴展的平台底層。對我來說，後續的設計主管角色，就是協助團隊在擴展功能與市場時，不斷把新的需求接回這套底層邏輯。

9Outcome從自費預約工具到診所營運平台

這套預約與營運能力後續成為 1.Talk 平台的一部分，支撐產品拓展至台灣與日本超過 2,000 家診所。1.Talk 累計發送約診提醒訊息超過 4,400 萬則、惠及 550 萬人次，並獲得 2024 GOOD DESIGN AWARD 日本優良設計獎 與 2025 金點設計獎 肯定。

在產品內部，我們也透過 Design with Data，把「預約安排」與「會員管理」從功能模組轉成可觀測的核心行為，例如每月使用次數、最近一次使用時間、新增預約所需時間，以及 DAU / MAU、7 天與 30 天留存率。這些數據不是只用來呈現成效，而是幫助團隊回頭判斷：哪些功能真的被診所持續使用、哪些流程造成操作成本、哪些設計需要再簡化或調整。

更重要的是，這個專案讓團隊建立了一套可擴展的診所後台設計方法：先由核心工作面與人員設備架構出發，理解診所如何安排預約；再把服務、班表、人員設備與流程選項整理成可管理的設定；最後透過數據回頭驗證功能是否真的進入日常工作流。

10Reflection回頭整理一套平台的設計邏輯

這個案子讓我理解，B2B 醫療產品的設計重點不只是效率，而是信任、可控性與可延伸性。

1. 後台設計要把規則變得可操作

診所現場有很多人工判斷。設計不是把這些複雜性藏起來，也不是讓系統取代所有判斷，而是把已知的服務、班表與人員設備條件整理成可維護的設定，把必要彈性留給現場。

2. 可控性比完全自動化更重要

線上預約不代表所有事情都要開放給病患操作。對診所來說，知道哪些可以開放、哪些需要保留人工判斷，才是願意使用系統的前提。

3. 平台化不是功能變多，而是底層邏輯能支撐更多場景

從 PinMed Suite 到 1.Talk，我重新理解產品擴展時的設計責任：早期設計師需要建立足夠穩定的核心架構，後續設計主管則需要協助團隊判斷哪些功能能延伸、哪些體驗要保留，以及不同設計師接手的細節是否仍然回到同一套產品邏輯。