ArgusHack ─ 演練計分功能改版
專案期間
約 3 個月（2025 Q4，與其他專案並行推進）
開發方式
敏捷開發
服務公司
盧氪賽忒（Leukocyte-Lab ）
擔任角色
UI/UX 設計師
負責任務
Spec 文件撰寫、Wireframe、Mockup
使用工具
Figma、Notion
背景與問題
Background
ArgusHack 是一套 BAS（Breach and Attack Simulation）資安攻擊模擬平台，就像消防演習一樣，透過在企業環境中模擬真實攻擊，協助企業在真正遭受攻擊前驗證防禦成效、找出潛在缺口。整個流程分為三個階段：
演練結果是使用者判斷防禦強度、規劃後續補強方向的重要依據。然而，產品使用者涵蓋資安工程師與不具技術背景的管理者，舊版流程高度依賴工程師的專業判讀，導致非技術使用者難以獨立完成操作，產出的分數也可能失去參考價值。因此，多數客戶長期反應，希望能以更自動的方式取得演練成果。
這項需求在技術端有了突破後才得以推進 — 系統能在演練結束後自動判斷攻擊是否成功。而我的工作，是將這項技術成果轉化為使用者真正能理解、也能使用的體驗。
角色與產出
Teamwork
這是我首次獨立主導大型功能設計的專案。過去設計團隊通常由我與 Design Lead 分工負責同一專案中的不同部分；隨著 RD 開始推動由個人負責單一功能、從需求到落地全程追蹤的工作方式，設計團隊也開始調整合作模式。這次我擔任功能的設計 Owner，從問題定義、設計規劃到方案產出皆由我主導，Design Lead 則擔任討論與設計檢核的角色。
由於功能複雜度較高，我先透過 Spec 明確定義問題與設計範圍，再依序完成 Wireframe 與 Mockup；過程中提出設計方案與判斷依據，並與 Design Lead 及前端夥伴共同討論，驗證方案的可行性。在缺乏使用者數據的情況下，跨角色交流成為我校準設計判斷、確保方案貼近實際使用情境的重要方式。這個專案也成為我從執行者走向功能負責者的重要轉折，開始累積從問題定義到設計落地的完整經驗。
現有問題
Focus on Problems
產品最初的價值主張放在準確度上。早期的使用者多為政府單位與大型組織，他們願意為了精確的結果投入時間，因此取得分數的流程也是依這樣的前提設計的。但隨著使用族群逐漸擴大，這個前提開始失效 — 新加入的使用者多半沒有專職的資安人力，難以負擔對應的操作成本。團隊也曾嘗試以 AI 輔助的方式緩解，但受限於技術條件，仍只是暫時的解法。
這些限制，具體反映在取得分數的兩種方式上。演練結束後，系統必須先知道每個攻擊步驟是否被防禦設備偵測到，才能算出分數，而舊版提供的兩條路徑，都有各自的門檻：
方式一｜手動上傳 Logs 並標註偵測狀態
使用者必須逐條比對演練時間與防禦設備的 logs，找出對應時段的紀錄貼回系統，再根據 logs 判斷防禦設備當下的偵測狀況。整個過程就像為了確認一件事，必須自己翻找對應時段的監視器畫面，再逐一判讀當下究竟發生了什麼。
使用者需為每個攻擊步驟找出對應時段的 logs，並自行判定偵測狀態
這個方式仰賴技術知識，操作本身也相當繁瑣。多數使用者無法自行完成，導致分數常常是 0 或偏低；而隨著演練的頻率與規模增加，即使是具備技術背景的使用者，也開始反應這個流程耗時、容易遺漏。為了減輕比對與判讀的負擔，團隊後續導入了 AI 輔助標註，讓系統先完成大部分的工作。
方式二｜AI 協助大量標註狀態
導入第三方防禦設備後，系統可以整包自動比對，使用者只需要檢核 AI 是否貼上正確時段的內容、判定的偵測狀態是否正確，負擔比手動低上許多。但這項功能理想的位置應該在演練執行的過程中，受限於當時的開發時程，最後只能先放在演練結果頁的一個分頁裡。入口不明顯，多數使用者根本不知道它的存在；而檢核 AI 的產出仍需要一定的技術判斷力，對不具技術背景的使用者來說依然不容易。
使用者輪廓
Users
產品後期的客戶以中小企業為主。對這些企業而言，資安通常不是核心業務，內部也少有專職的資安人力；真正推動他們處理這件事的，多半是法規上的合規要求。因應方式也不盡相同 — 有些企業組建小型的資安團隊，有些則將整個資安維運外包給服務商協助處理。
這也表示，實際打開產品操作的人是誰，其實無法事先預期：可能是具備技術背景的資安人員，也可能是負責合規的管理職，或是外部的服務商。若從使用目的來看，可以歸納出兩種明顯不同的需求：
*資安產品難以直接接觸使用者，此分類由業務轉述的回饋與 AI 情境推演收斂而成
兩者的需求彼此衝突，一邊要的是零操作就能拿到結果，一邊要的是能深入檢視每個細節。這次改版沒有在兩者之間折衷，而是以分眾設計讓不同需求的使用者各取所需。
分眾設計
Segmentation
拆分方式
新版將演練結果拆分為兩種分數，以滿足不同使用者對效率與精準度的需求。
演練完成後，系統會自動產出防禦面分數，快速回應攻擊是否成功，讓大多數使用者無需任何額外操作即可獲得結果。而需要深入分析的使用者，則可在後續透過 AI 或手動標註上傳 logs，取得精準度更高的偵測面分數。由於自動判定只能判斷攻擊是否成功，兩者也必須分開呈現，避免使用者誤以為防禦設備沒有發揮作用。
兩種分數代表不同的成本取捨：防禦面分數以較低的精準度換取零操作成本，而偵測面分數則需要額外的標註流程，但能提供更高的分析準確性。透過將流程分眾，使用者可以依照自身需求，自由選擇希望投入的操作成本與取得的分析精準度。
命名決策
兩種分數並非高低階的關係，而是從不同角度檢視同一場演練。命名上參考競品的做法，以「防禦面」與「偵測面」區分分析視角，避免使用者將自動產出的初步結果誤解為較低價值的結果，或將兩者解讀為分數的高低階。
設計文件
Spec
分眾方向確立後，接下來的挑戰是如何讓這套設計順利落地。過去設計團隊僅有兩人，與 RD 採取高度協作的工作模式，因此設計稿不會涵蓋所有細節；實作過程中若有疑問，前端多半直接在設計稿留言，或與設計師口頭討論即可完成溝通。
然而，這次的規劃橫跨演練前後多個階段，涉及兩種使用者情境與多條流程分支，已超出即時溝通能有效涵蓋的範圍。僅靠設計稿與口頭討論，不僅難以讓 RD 理解完整的設計意圖，也增加了 QA 驗證流程的困難。
因此，我參考 RD 既有的文件架構，建立了設計團隊第一份完整的 Spec，將流程、User Story 與規格整合為共同文件，作為設計、開發與測試之間的溝通依據。
設計產出
Focus on Problems
演練前：確認劇本是否支援自動判定
由於自動判定功能尚未涵蓋所有劇本，且支援範圍未來會隨劇本更新逐步擴大，使用者在選擇劇本時需要能提前確認哪些劇本支援此功能。因此，我在劇本列表與詳情頁加入支援狀態標示，並提供排序功能協助篩選，讓使用者在開始演練前即可確認該劇本是否能產出防禦面的結果。
演練中：專注呈現執行過程，不需額外操作
讓演練執行中的畫面專注呈現過程本身：每個攻擊步驟採用的手法，以及系統自動判定的執行結果。使用者可以逐一查看細節，也可以讓演練自動完成，不需在過程中進行操作；偵測狀態的標註則改於演練結束後處理，並在畫面右側以提示說明演練結束後可取得偵測面分數，讓成效資訊集中於 Result 頁面呈現。
演練後：呈現整體成效，使用者可視需求取得進階分析
演練結束後，系統會整合自動判定結果，於 Result 頁面呈現防禦面分數；若需要進一步判讀，使用者可在同一頁透過 AI 或手動標註偵測狀態，取得偵測面分數。由於舊版 AI 標註入口不明顯，使用者不易察覺，因此這次將 AI 與手動標註整合為頁面主要操作，並搭配說明文字引導，讓使用者可以依需求選擇是否進一步標註，不強制完成操作。
提供分數計算依據，讓使用者理解結果來源
由於舊版介面並未說明分數的計算方式，使用者拿到結果後，時常需要另外詢問才能理解分數的來源。因此，我在演練進行中、Result 頁面，以及演練報告中都加入了說明，整理各項判定狀態的定義與計算公式，讓使用者無論在查看演練過程、結果或事後回顧時，都能隨時對照分數的組成。
*此功能原定於 Design System v2 完成後上線，後因公司決策調整，最終改以舊版設計系統如期上線，此本案例呈現的設計稿為原始的 v2 規劃版本，關於 v2 的規劃內容可參考 [Design System v2 改版]。另外，本案例內容已取得前公司同意公開，部分細節未於此處呈現，歡迎於面談時進一步交流。
成果
Results
自動化判斷落地，讓產品更具競爭優勢
功能上線後，補足了產品長期在自動化能力上的不足，
分眾設計也讓業務在競品比較中更具說服力，
強化了產品的市場競爭力。
學習與反思
Takeaways
文件的價值在溝通，而不只是規範
在建立 Spec 的過程中，我重新理解設計文件的角色。它不只是記錄規格，更重要的是成為團隊溝通時的共同依據。當 RD 和 QA 對流程有疑問時，能透過文件快速對齊，而不是依賴口頭記憶或個別理解。這也調整了我後續撰寫文件的方式：與其追求完整記錄所有細節，更重要的是釐清容易產生歧義的部分，讓文件真正協助團隊做出一致決策。
命名難以一步到位，在精準與易懂之間取得平衡
防禦面分數的命名花了不少時間。由於結果是由系統自動判定產生，初期希望透過名稱傳達判定來源，因此選擇了能反映計算方式的名稱（Auto-Evaluation Result），讓使用者理解這個數字背後的產生邏輯。但功能上線後，仍收到部分使用者反應難以理解名稱含義。這次經驗讓我再次確認，產品命名需要在專業準確與使用者理解之間取得平衡 — 過度偏向技術，容易增加理解門檻；過度白話，則可能失去原本想傳達的資訊。名稱並非僅靠設計階段判斷即可決定，而需要透過實際使用情境持續驗證與調整。