我們能否透過簡化並數位化核心作業流程，改善中小型保險公司的使用體驗？
- 公司
- OneDegree Global
- 角色
- 資深產品設計師
- 平台
- Web、SaaS
- 期間
- 2021 年
專案概述
IXT 是一套企業級 SaaS，協助中小型保險公司數位化核心作業 —— 核保、保單管理、理賠。2.0 上線後，我持續負責 UI、互動與動效設計，重心放在一個數字寫錯就會造成實質損失的地方。
流程本身由專職 UX 設計師定義，我的角色是把已確認的定義轉譯成可上線的畫面、狀態與規格。但執行同樣需要 UX 的判斷：資訊層級、任務動線，以及使用者在哪裡有可能做錯。
目標
與產品與商務端共識讓中小型保險公司在金融法規特別嚴格的亞洲市場，能更快推出新的保險商品。
平台承諾的是「規模化的速度」。這也就決定了設計問題的位置：不是把保險做得漂亮，而是讓一個被法規與計算包圍的流程，對每天實際執行它的人來說是撐得住的。
問題
中小型保險公司在數位化核心流程時，面對的是高度的作業摩擦與真實的導入門檻。難的不是工具，難的是轉換成本。
範圍
Product · Policy · Application五個模組中優先三個 —— 挑的是商業需求與日常操作者需求重疊最多的地方。
我與產品經理一起釐清價值主張與方向，做競品比較，也參與了與精算師、保險商品經理的專家訪談。釐清商業需求是第一優先，也最容易錯：保險的規則，從外面是猜不出來的。
設計難點
保險商品帶著複雜的保費與保期邏輯，多個商品放在一起又會產生互相牽動的規則。限制條件是：在既有框架內交付清晰，而不是把設計系統撐大來遷就。
每一個新模式都要付兩次錢 —— 設計一次，工程再一次。所以每個畫面第一個要問的是：現有元件能不能承擔它。
設計流程
定義 → UI → 狀態 → 原型 → 重用- 對齊流程與規則定義在返工成本還低的階段，與 PM 和 UX 確認判斷點與例外。
- 把流程轉譯成可上線的 UI用更清楚的層級、分組與漸進式揭露，重整高密度的表單與表格。
- 定義 UI 狀態、驗證與邊界案例與工程一起處理驗證、警告、確認、載入、空狀態、錯誤。計算過程不只要正確，還要說得清楚。
- 用原型消除歧義靜態畫面定不下來的部分 —— 表格互動、分步流程 —— 用輕量原型與動效研究來收斂。
- 以可重用模式規模化把字體、間距與元件用法寫成文件，讓交付保持一致，而系統不必跟著長大。
框架
每個模組都繼承的東西每個模組都必須以同一個框架打開，讀者一到就已經知道該往哪裡看。
工作台頁面很長、資訊密度高。在這裡「不迷路」不是體貼而是前提 —— 丟失位置的讀者，得先把地圖重建起來才能做任何事。
- 內容區
- 左側導覽，加上留白充足的中央內容區。
- 情境標頭
- 主體身分與狀態始終可見 —— 保單或商品 ID、目前狀態、關鍵時間。
- 區塊
- 密集內容切成卡片式區塊便於掃讀，表格只用在真的需要互相比較的清單。
檢視狀態不能只是唯讀，它必須說出自己是唯讀。
編輯之後，成果會被核對、分享、確認。一個安全但看起來不安全的畫面，仍然會被當成「按錯一個鍵就會改到東西」來對待。
- 閱讀順序
- 把資訊呈現為可由上往下閱讀的結構化區塊，而不是一份靜止的表單。
- 說明狀態
- 停用的欄位與唯讀樣式承載狀態，使用者不必記得自己開的是哪一種模式。
- 分組
- 內容依層級分組，關鍵事實不必捲過一整片原始表單欄位就能核對。
導覽必須同時回答兩個問題 —— 我在哪裡，以及我改的是正式的那個嗎。
判斷密集的工作意味著不斷在區域之間跳動，而一個商品不是一件東西，是一連串帶著狀態的版本。兩個問題都不該需要繞路才能得到答案。
- 側欄與清單
- 固定的圖示側欄對應全域區域，內層是目前工作區的區塊清單，內容密集時可以收合讓出空間。
- 可預測
- 標籤與層級一致，含可展開的群組，使用者能預測某個設定會在哪裡。
- 版本狀態
- 即將上架、已上線、已下架 —— 版本選擇器把狀態放進標籤裡而不是擺在旁邊，答案就出現在他本來就要伸手去點的控制項上。
閱讀
先確認 —— 每個畫面打開時所在的狀態保單服務以檢視的狀態打開，每一個操作都是刻意伸手去做的。
保單服務是對一張生效中的保單做影響很大的操作。畫面打開時所在的狀態，就是絕大多數工作實際發生的狀態，所以預設決定了誤改有多容易。
- 情境
- 使用者需要立刻知道「這是哪張保單」「狀態是什麼」「我在看哪一段期間」。摘要標頭承載保單號碼、主次狀態、關鍵中繼資料，以及變更狀態的操作。
- 操作
- 預設是檢視 —— 可讀的卡片區塊 —— 並把操作抽出來：全域操作在右上、列層級操作在表格內、情境操作放在它該在的地方。誤改因此變難。
- 節奏
- 每個分頁都遵循同樣的模式：保單情境、區塊導覽、卡片區塊，然後才是密集清單用的表格。Policy Parties、Policy Details、Billing、Excluded Item 之間維持同一個形狀。
- 狀態
- 生效與待處理、逾期與已繳、續保關係。狀態帶有明確的標籤與徽章，例外會自己發出訊號，狀態變更則固定出現在一致的位置。
- 帳務
- 帳務是依「現在需要注意什麼」來設計的 —— 下一期應繳與付款方式放最上面，接著是帶狀態標籤的完整排程供對帳。Excluded Item 則是一個例外工作區，支援列層級的編輯與刪除。
像合約的內容必須變得可讀，但不能簡化掉在法律上有效力的細節。
計畫內容密集而且層層相扣 —— 主條款、條件、附約。沒有一項能被稀釋，所以唯一能改的是它被排版的方式。
- 層級
- 文件式的檢視器，具備真正的字級層級與間距，而不是一份裝著法律條文的表單。
- 分組
- 分組反映條款之間的關係，而不是把它們壓平成一整段。
篩選必須是可以反悔的 —— 不丟失位置，不會誤送出。
工作台清單需要彈性的篩選，而篩選是一件使用者會反覆試很多次才試對的事。試錯的代價必須接近於零。
- 面板而非頁面
- 由標頭展開的下拉面板，被篩選的那份清單情境不會因為篩選這個動作而消失。
- 結構
- 欄位 × 運算子 × 值的結構可以延伸到多個條件，帶型別標示的自動完成避免型別不符。
- 安全地嘗試
- 套用與取消並存，所以「試一個篩選」和「決定用這個篩選」是兩個不同的動作。
動手
一個數字寫錯就會很貴的地方以上是沒有人在改動任何東西時，這個平台在做的事。接下來是有人在改動時的事 —— 在這個平台上，那是「錯誤開始變貴的地方」的另一種說法。
複雜的輸入必須難以設錯 —— 而且不讓任何人在每個模組重新學一次模式。
許多欄位會餵進計算並影響後續行為，所以這裡的錯誤不是打錯字，是一個會送到客戶手上的錯誤數字。
- 層級
- 長表單被整理成一致的區塊與段落；標題、間距與對齊說明什麼屬於一起、什麼依賴什麼。
- 重用
- 下拉選單、開關、新增一列、行內說明與表格操作全部標準化，同樣的互動在任何地方行為都一樣。
- 狀態
- 可編輯與唯讀、必填與選填、驗證與警告 —— 這是「錯誤被攔下」與「錯誤被送出」之間的差別。
規則撰寫需要自己的工作空間，但仍必須屬於這個平台。
進階規則是寫出來的，不是設定出來的。這個空間要平衡專注書寫與快速尋找屬性，並且在兩者進行的同時讓錯誤訊息維持可讀。
- 配置
- 左邊工具、右邊內容，與工作台一致，情境切換的成本因此很低。
- 尋找
- 屬性選擇器可收合 —— 展開來搜尋，收起來專注。背後有兩種方式：階層式篩選用來瀏覽，帶型別提示（Num、Enum）的搜尋用來求快，再加上減少複製貼上的插入動作。
- 回饋
- 編譯結果與語法指引有自己的區域，除錯不必離開頁面。
- 表面
- 深色的編輯區對比較亮的 UI，不用標籤就說出這裡是程式碼。
- 這些是什麼
- 核保規則清單的三種狀態 —— 什麼都還沒有、草稿、已上線 —— 同一份清單的密集檢視，以及費率實際被寫進去的那張 Excel 形式的費率表。
- 一則說明
- 原始案例把這五張放在「More product module screens」這個標題底下，除此之外什麼也沒寫。它們出現在這裡的理由跟在那裡一樣：它們是這個模組的一部分，而且真的做出來了。出處沒有主張的事，這裡也沒有替它主張。
平台上風險最高的操作，必須讓每一個決定都明示且可覆核。
這裡的小錯誤會擴散 —— 退費算錯、帳務算錯、文件對不上 —— 而且通常發生在使用者趕時間、做到一半的部分解約裡。
- 步驟
- 三個步驟 —— 選擇對象、解約資訊、退費計算 —— 搭配常駐的進度指示。
- 漸進式揭露
- 預設保持最小，附約選擇只在部分解約時才出現。
- 注意力
- 置中單欄配上選填標示，把注意力導向真正有影響的欄位。
- 核對
- 退費預覽在總額之前先給出逐一計畫的明細，讓數字在送出前就被核對過。
設計系統
Area → Fundamentals → Components & Patterns當平台橫跨多個模組展開，我們需要一套能規模化又不增加返工的共用 UI 語言。我從企業識別建立視覺基礎，再把它變成團隊能直接套用的規則。
All 21 sheets
產品官網
動態，以及一頁隨著你讀而動的設計這個平台除了產品的一面，也有對外的一面。其中兩件：承載品牌的動態，以及一頁各區塊隨捲動出現、而不是靜靜等人讀的到達頁。
兩件事講的是產品同一個主張，只是對象不同。工作台靠可預期贏得信任；官網得先贏得注意，而它只有幾秒鐘。動態是拿來買那幾秒的，捲動設計則是把那幾秒花在一個有人決定過的順序上。
成果
平台上線了，而且持續在出貨。設計買到的是在複雜度底下鋪好的一層地板 —— 新模組可以直接開發，不必再重新談判一個表單該怎麼運作。