中小型保險公司要怎麼上一頁商品頁，而不用排隊等工程？
- 客戶
- OneDegree Global
- 角色
- 資深產品設計師
- 平台
- Web、SaaS
- 期間
- 2022
專案概述
Launchpad 是一套給中小型保險公司用的模組化頁面編輯器 —— 這些公司需要跑得快，卻沒有可以配合的內部工程團隊。在它之前，一檔新活動或一次商品更新就意味著一次客製開發，一次上線經常要超過三個月。
行銷把需求交給產品，產品排隊等工程，連改一句文案都要佔用開發時間。不同商品、不同品牌之間的頁面結構和品質逐漸走樣，因為沒有任何東西是共用的。
Launchpad 用一套專為保險業做的模板式 CMS 取代這個流程：用可重複使用的區塊組出頁面、設定表單、上傳素材、發布完整的購買流程 —— 全程不用寫程式。我負責整個編輯器的 UI 與互動設計，並在產品成長過程中接手新功能的 UX。
目標
與產品及業務共同確認- 把開發者從日常變更中移出調個版面或改個文案，不該需要開一張工程單。
- 讓頁面品質標準化結構統一，產出不會在不同商品與品牌之間走樣。
- 縮短上市時間拿掉客製開發，把一次上線從數個月壓到數週。
- 讓非技術團隊也能操作做頁面的是行銷和維運同仁，不是工程師。
問題
三個痛點在每一次內部訪談都會出現，而且三個的根源相同：頁面上沒有任何東西是可以重複使用的，所以每一件事都變成一次開發。
- 連小改動都要依賴開發者就算只是調整版面或更新內容，也得排進工程的待辦佇列，等於在日常工作的動線上卡了一個專業職。
- 結構與品質不一致不同商品與品牌的頁面組成方式各不相同，因為每一頁都是各自蓋出來的。
- 上線或更新要三個月 — 累加出來的結果需求整理、等待、開發、測試層層疊加，這個延遲長到足以讓一檔活動的前提本身失效。
研究
內部關係人 — 業務、導入、客服在接觸不到終端使用者的情況下設計
因此證據來自離他們最近的人：業務、導入與客服，這幾個部門每天都在承受現行流程的後果。這裡所有的洞察在結構上都是間接的 —— 我沒有把它們當成別的東西看待，設計判斷也刻意偏向可回復的結構性選擇，而不是押注在特定的使用者行為上。
任務盤點與排序
我盤了非技術使用者要讓一頁商品頁上線，實際上必須完成哪些事：選版面、編輯內容、設定表單與步驟，然後在發布前確認結果。只鎖定這四件、刻意不去支援例外情境，才讓編輯器維持可預測 —— 一個什麼都支援的builder，最後什麼也沒教會使用者。
限制
技術 · 品牌設計開始之前就有兩件事是動不了的。編輯器無法做出真正的即時預覽，而且視覺必須消失在別人的品牌後面。
兩者都沒有商量空間，而且指向同一個方向：這不是一個能靠表現力取勝的產品。最初的版本試過比較有個性的介面 —— 柔和陰影、圓角、模糊效果。利害關係人的評估很清楚地指出，任何有自己個性的介面都會和保險公司自己的品牌規範打架，於是風格被收回到中性而結構化的方向。
預覽的限制更難處理。一個沒有即時預覽的頁面編輯器，等於要求使用者憑信心按下發布，而那正是非技術使用者開始不信任工具的那一刻。我沒有把它當成既定限制接受，而是提出用 Standard API 串接真實商品資料，讓使用者編輯時看到的東西，至少在結構上就是發布後的頁面。
實際做出來的
編輯模型整個產品都建立在一個判斷之上：頁面不是一份文件，而是一疊區塊。其他一切都從這裡推導出來 —— 一致性、重複使用，以及行銷人員可以自己操作這件事。
如果頁面是用一組固定區塊組出來的，品質就不再取決於是誰做了這一頁。
每一頁都從零開始蓋，所以跨版本沒有任何累積，也維持不了一致性。
- 區塊
- 商品重點、FAQ、表單、媒體都是可抽換的區塊
- 提供預設版型作為起點
- 主題色切換與背景圖上傳
- 結構由系統維持，不依賴編輯者的自律
- 效果
- 頁面從「蓋」變成「組」，這正是把工程團隊移出日常工作的關鍵。
不論選到什麼，開出來的都是同一個面板 —— 只要學一套結構，而不是每種區塊各學一套。
非技術使用者不會為每個功能各建一套心智模型，他們建一套然後重複使用。每個模組一套編輯介面，等於區塊有幾種，工具就要學幾次。
- 模式
- 選任何模組，右側都開出同一個面板
- 文字、素材、顯示設定共用同一套排列
- 選取狀態、拖放、轉場只定義一次
- 效果
- 只要學一套結構，而不是每種頁面各學一套 —— 這是整個產品裡把學習成本壓得最低的一項。
核心區域
CMS · 購買流程 · 設計系統商品資料是匯入的，不是重打的 —— 手動打進頁面不是小風險，那是法遵風險。
編輯器透過 API 與 IXT 平台或外部系統串接。保險商品資料受監理且有版本控管，所以頁面必須引用公司已經在維護的那份紀錄，而不是變成第二份。
- 流程
- 匯入商品資料、送出審核、排定上線、下架，全部在同一套模板式介面裡完成。
- 效果
- 商品資料只有一個來源，而且維運人員可以獨力跑完發布流程。
幾乎每一家中小型保險公司的購買流程都是同樣五步 —— 所以它以模板出貨，而不是客製開發。
這是保險公司最不能出錯的一段，同時也是他們最沒有能力自己做的一段。把它模板化，是這個產品價值最高的地方。
- 步驟
- 建立帳號、選擇方案、填寫表單、報價、結帳。
- 效果
- 不需要另立一個開發專案，就能有一套完整的購買體驗。
Token 命名的是狀態而不是數值，所以淺色與深色從同一份定義推導出來。
以 Atomic Design 為基礎 —— atoms、molecules 與可重複使用的版面區塊，新模組是繼承而來，不是重新發明。
- Token
- 語意化色彩系統：default、hover、error、success，命名的是它代表什麼，而不是它剛好是什麼顏色。
- 意圖
- 讓介面在長時間編輯中保持安靜，同時中性到足以同時放在好幾家保險公司的品牌底下。
- 效果
- 商品頁與購買頁維持一致，交付給開發時也明顯順暢，因為狀態早就命名好了。
探索過但未採用
評估後決定不走結果
以下數字是預估值與合作夥伴的初期回饋，不是實測結果。在有正式環境資料可以驗證之前我就離開了，我不打算把它們講成比實際更多的東西。
這個工具是針對保險業設計的，功能齊全而且好用。
印證了押在保險專用模板、而非通用型 builder 的判斷。
我們也試過 WordPress，但學習成本太高。這個工具感覺是為我們量身做的。
要跨過的門檻是學習成本，而跨過它的正是那個統一面板。
我從這個案子帶走的
- 在理想與團隊實際的運作方式之間校準為傳統產業做設計，必須對照真實的工作流程與工具成熟度來調整。一個不符合團隊運作方式的先進功能，不叫先進，叫沒人用。
- 理解領域本身就是設計工作保險的業務規則大多沒有文件，存在人的腦袋裡。透過訪談把它們挖出來，翻譯成一個行銷人員能操作的結構，才是這個專案的實體 —— 而不是疊在上面的那層介面。