CASE STUDY

CASE STUDY

CASE STUDY

EV CSMS 充電樁管理平台重構

負責角色

UI/UX Designer

合作對象

前端工程師 ×1、後端工程師 ×4、PM ×1

負責項目

充電樁管理體驗、營運邏輯設計、Design System 整合

時程

2025/06 - 2025/12

專案背景

CSMS 是提供充電樁營運商管理站點與設備的 B2B 平台。隨產品即將進入商業化階段，團隊決定重新優化核心建置流程，以支援實際營運與後續產品擴充。

核心挑戰

重新梳理充電樁從建立到上線的管理流程，並將複雜的系統邏輯轉化成營運人員容易理解的操作方式，同時在既有開發節奏下逐步導入新的設計規範。

專案成果

簡化充電樁設定流程

重構充電樁建立流程，提升設備工程師操作效率。

推動產品商業化落地

核心流程建立後，產品已導入合作客戶場域，並正式啟動商業合作。

建立一致的介面規範

主動發起 Design Guideline 重建，強化設計與開發之間的對齊效率。

本專案涉及商業機密，部分畫面、硬體串接邏輯與技術細節已進行模糊處理或重新編排；畫面中所呈現之設備、站點與系統資料皆為示意內容，不代表實際營運環境。

本專案涉及商業機密，部分畫面、硬體串接邏輯與技術細節已進行模糊處理或重新編排；畫面中所呈現之設備、站點與系統資料皆為示意內容，不代表實際營運環境。

本專案涉及商業機密，部分畫面、硬體串接邏輯與技術細節已進行模糊處理或重新編排；畫面中所呈現之設備、站點與系統資料皆為示意內容，不代表實際營運環境。

01

釐清角色與既有流程

主要使用角色

平台管理員 (CPO)

平台管理員 (CPO)

透過 CSMS 管理站點、充電樁與營運資訊。

設備工程師 (Engineer)

設備工程師 (Engineer)

在 EVUI 與 CSMS 之間完成設備設定、連線與註冊確認。

CSMS 是營運管理平台，EVUI 則是設備端設定介面。本專案聚焦於 CSMS 端的流程重構，EVUI 僅用於說明跨系統設定

為什麼要將流程整合到 CSMS ?

1.原有設定流程分散在 EVUI 與 CSMS 兩個平台 ，工程師需跨系統切換並手動輸入 Charger ID、Server URL，增加操作與輸入錯誤的風險。

2.考量設備後續仍需回到 CSMS 進行狀態與營運管理，因此將設備建立入口整合至 CSMS，減少跨系統操作步驟，也讓建立與後續管理能在同一個入口銜接。

1.原有設定流程分散在 EVUI 與 CSMS 兩個平台 ，工程師需跨系統切換並手動輸入 Charger ID、Server URL，增加操作與輸入錯誤的風險。

2.考量設備後續仍需回到 CSMS 進行狀態與營運管理，因此將設備建立入口整合至 CSMS，減少跨系統操作步驟，也讓建立與後續管理能在同一個入口銜接。

1.原有設定流程分散在 EVUI 與 CSMS 兩個平台 ，工程師需跨系統切換並手動輸入 Charger ID、Server URL，增加操作與輸入錯誤的風險。

2.考量設備後續仍需回到 CSMS 進行狀態與營運管理，因此將設備建立入口整合至 CSMS，減少跨系統操作步驟，也讓建立與後續管理能在同一個入口銜接。

Before

😡 跨 EVUI / CSMS 往返操作

After

😀 CSMS 成為建立與管理起點

收斂待解問題

01

CSMS 缺少完整的充電樁管理能力

既有流程以設備設定為主，當充電樁管理逐步整合至 CSMS 後，需要一個能集中檢視設備、掌握狀態並進行後續操作的管理入口。

02

既有介面仍存在操作與資訊呈現問題

檢視現有介面後，也發現欄位命名、資訊呈現與狀態辨識等問題，因此一併納入新流程調整。

1

1

1

槍 (Gun) 篩選樣式與其他頁面不一致。

2

2

2

欄位名稱以「#」呈現，無法直觀理解其代表 ID。

3

3

3

槍頭數量需支援彈性顯示。

4

4

4

充電樁狀態難以快速辨識。

02

設計決策與落地

補齊充電樁管理能力

在既定的系統方向與 PM 初步功能構想下，我重新梳理 Charger Management 的操作流程、資訊架構與設備狀態，將設備從建立到後續管理整理為三個核心環節。

建立充電樁

在 CSMS 新增 Charger，補齊建立所需資訊與流程。

銜接設定參數

整理 Charger ID、Server URL 等必要資訊，支援 EVUI 完成設備端設定。

集中管理

建立 Charger List，重新整理資訊層級與操作入口。

新增充電樁設定

將建立所需的設備、站點與 Connector 資訊集中於同一流程，建立完成後產生後續設備串接所需資訊。

集中檢視與後續管理

Charger 建立後集中進入管理列表，重新整理資訊層級與常用操作，讓設備辨識與後續管理更容易完成。

操作集中｜將 Edit / Delete 等操作集中於固定位置，提高可發現性。

設備銜接｜提供 Charger ID / Server URL 快速複製，協助完成後續設備設定。

資訊層級｜依管理需求重新排列欄位，常用資訊優先呈現。

操作集中｜將 Edit / Delete 等操作集中於固定位置，提高可發現性。

設備銜接｜提供 Charger ID / Server URL 快速複製，協助完成後續設備設定。

資訊層級｜依管理需求重新排列欄位，常用資訊優先呈現。

操作集中｜將 Edit / Delete 等操作集中於固定位置，提高可發現性。

設備銜接｜提供 Charger ID / Server URL 快速複製，協助完成後續設備設定。

資訊層級｜依管理需求重新排列欄位，常用資訊優先呈現。

建立清楚的充電樁狀態邏輯

Charger 建立完成並不代表設備已正式上線，因此我先依照設備註冊與上線流程，整理 Created、Onboarding、Registered、Rejected 與 Deprecated 等狀態，讓系統能反映設備目前所處的階段與異常情境。

為了讓使用者在大量設備列表中快速辨識狀態，我將不同階段對應到系統常見的語意色：藍色表示進行中、綠色表示完成、紅色表示異常，灰色則代表停用或不可操作。

為了讓使用者在大量設備列表中快速辨識狀態，我將不同階段對應到系統常見的語意色：藍色表示進行中、綠色表示完成、紅色表示異常，灰色則代表停用或不可操作。

設備排序與後續設定

設計前後對比

重新整理資訊層級、欄位順序與操作入口後，充電樁狀態、篩選方式與管理功能更加清楚，讓使用者更容易掌握設備狀況並執行操作。

After
Before
Before
After
After
Before
Before
After

03

上線驗證與營運擴展

上線後內部回饋

Charger 流程上線後，我邀請 3 位實際負責設備部署與設定的 RD 工程師操作新版流程，確認設備建立、資訊銜接、狀態辨識與列表管理是否符合實際工作情境。

流程與資訊更易辨識

RD 回饋設備狀態更容易辨識，ID / URL 直接在列表複製，減少在 EVUI 與 CSMS 之間反覆切換與查找資訊。

排序邏輯調整

原先將異常設備優先排列，但工程師更常尋找剛建立的 Charger，因此改為最新建立優先。

後續延伸的營運問題

核心 Charger 流程上線後，設計範圍也逐步延伸到更複雜的營運情境。除了單一設備的建立與管理，後續還需處理設備控制、規模化操作，以及不同站點與時區下的資訊判讀。

  • 設備運行與控制邏輯

    充電樁除了基本資訊外，還涉及多項設備參數設定與管理方式。

  • 跨時區與跨日管理

    不同站點可能位於不同時區，因此需要釐清 Site Time、UTC 與跨日計算的使用情境。

  • 設備運行與控制邏輯

    充電樁除了基本資訊外，還涉及多項設備參數設定與管理方式。

    批次管理與規模化操作

    當站點與設備數量增加後，逐筆設定會放大重複操作成本，因此我也提出批次管理的方向，讓管理者能一次處理多筆設備或設定。

    跨時區與跨日管理

    不同站點可能位於不同時區，因此需要釐清 Site Time、UTC 與跨日計算的使用情境。

  • 設備運行與控制邏輯

    充電樁除了基本資訊外，還涉及多項設備參數設定與管理方式。

    批次管理與規模化操作

    當站點與設備數量增加後，逐筆設定會放大重複操作成本，因此我也提出批次管理的方向，讓管理者能一次處理多筆設備或設定。

    跨時區與跨日管理

    不同站點可能位於不同時區，因此需要釐清 Site Time、UTC 與跨日計算的使用情境。

  • 設備運行與控制邏輯

    充電樁除了基本資訊外，還涉及多項設備參數設定與管理方式。

    批次管理與規模化操作

    當站點與設備數量增加後，逐筆設定會放大重複操作成本，因此我也提出批次管理的方向，讓管理者能一次處理多筆設備或設定。

    跨時區與跨日管理

    不同站點可能位於不同時區，因此需要釐清 Site Time、UTC 與跨日計算的使用情境。

本段涉及設備控制邏輯與商業機密，僅呈現設計問題與決策方向，詳細流程與技術細節不予公開。

04

讓產品在持續開發中維持一致

我主動發起設計系統重建

在重構 Charger 流程的同時，我也發現既有產品累積了不少 UI 樣式與元件規則不一致的問題。由於產品仍持續 Sprint 開發，無法一次全面重構，因此我採取漸進方式，優先整理高頻元件，再逐步擴大到整體介面與設計規範。

先找出最影響開發的一致性問題

用漸進方式重整高頻元件

與其一次全面替換，我先從開發中最常使用、也最容易產生差異的元件開始整理，並在每個 Sprint 中逐步導入新規範，降低大規模改版對既有功能的影響。

整體視覺與介面優化

經過約兩個月的漸進式調整後，我還是覺得只修正個別元件，無法真正解決產品整體的介面問題。因此，我重新檢視字體、元件規範與視覺一致性，整理出更完整的介面優化方向。在提案中，我重新定義文字樣式與介面風格，並以易用性與閱讀性為核心，建立一套能實際導入，也能支援後續功能擴充的設計系統。

經過約兩個月的漸進式調整後，我還是覺得只修正個別元件，無法真正解決產品整體的介面問題。因此，我重新檢視字體、元件規範與視覺一致性，整理出更完整的介面優化方向。在提案中，我重新定義文字樣式與介面風格，並以易用性與閱讀性為核心，建立一套能實際導入，也能支援後續功能擴充的設計系統。

Design Guideline 重新建立

除了重新整理元件樣式與狀態，我也補充各元件的使用原則、適用情境與細部規範，避免相同元件在不同頁面出現不一致的做法。

同時，我也在 Notion 建立系統文件，整理元件的命名邏輯與實際使用方式，讓設計與開發在後續維護時都有明確依據。

除了重新整理元件樣式與狀態，我也補充各元件的使用原則、適用情境與細部規範，避免相同元件在不同頁面出現不一致的做法。同時，我也在 Notion 建立系統文件，整理元件的命名邏輯與實際使用方式，讓設計與開發在後續維護時都有明確依據。

教學影片支援

為協助客戶與新加入團隊的同仁快速理解平台操作，我也製作中英文產品教學影片，支援系統導入與內部交接。

專案反思

這是我第二次接觸 IoT 硬體相關產品。相較於過去在乙方只能理解部分需求，這次參與自家產品，讓我能更深入理解充電樁、OCPP，以及裝置端與管理平台之間的關係。我也更明確感受到，這類產品不能只從介面出發，而必須建立在設備邏輯與實際操作流程上。


在設計系統的建立上，最大的挑戰不是單純統一元件，而是在產品持續擴充下，找到一致性與彈性的平衡。既有功能無法一次重做，新需求也持續加入，因此必須配合開發節奏逐步調整，也讓我重新思考設計規範如何被導入與維護。


回顧專案，最需要改進的是訪談與驗證的時機，雖然曾透過內部成員取得回饋，但驗證開始得較晚、次數也有限。若能在前期就安排研究與驗證節點，設計判斷會有更完整的依據。與資深軟硬體團隊合作也是這次重要的收穫，他們提供許多產品與實作知識，幫助我快速補足技術理解；同時，我也重新梳理設計提案與開發交付方式，讓需求與核心功能的討論更有依據。

Thanks for reading

Thanks for reading

Thanks for reading 😀

觀看其他專案

觀看其他專案

回首頁

回首頁

回首頁