O!Pack
從零建立跨服務的虛擬資產基礎架構，將複雜的資產流通轉化為一般用戶也能理解的體驗，並在技術限制與多方商業考量中找到設計的落腳點。
🔒 本產品開發中， 部分內容因保密考量省略，歡迎面試時詳談。
集團旗下多個事業體都有各自的虛擬資產，但分散在不同系統，缺乏統一的保管、驗證與流通機制。產品定位參考證券市場的集保中心角色，提供跨事業體的資產基礎建設。
亮點 1
從產品定位，拆出可落地的 0→1 架構
從產品定位一路拆解至頁面、欄位與狀態，建立團隊共同理解的產品架構，並將尚未釐清的問題轉化為跨角色持續對焦的依據。
從定位到可開發的產品架構
面對一個沒有既有系統可以沿用的產品，我先從核心定位出發，用 Xmind 展開完整功能架構，從五大功能主幹逐層拆解到頁面、欄位與不同狀態。過程中，我不把未確認的問題留到後續，而是直接在架構圖中標記開放問題，讓它不只是資訊架構文件，也成為 PM、設計與工程之間持續對焦的討論工具。
讓 Web2 用戶無感，Web3 用戶仍可驗證
資訊呈現上，我們希望一般用戶不需要理解區塊鏈也能完成主要任務，同時保留進階用戶驗證資產真實性的能力。因此我將一般資產資訊與鏈上資訊分層呈現：Web2 用戶看見完成任務所需的資訊；Web3 用戶需要時仍能進一步驗證鏈上資料。讓技術存在於產品底層，而不是成為使用產品的前置門檻。
亮點 2
重新設計跨服務商的資產流通體驗
將原本依賴背包地址的 Web3 資產流通流程，轉化為一般用戶也能理解的移轉與交換體驗，同時在操作門檻與防詐安全之間取得平衡。
第一道門檻：為什麼我的東西要先「移進來」？
用戶必須先將其他服務商中的資產移入 O!Pack，才能進行後續交換。但對不了解底層系統的用戶來說，「東西明明已經是我的，為什麼還要先移到另一個地方？」本身就是一道理解門檻。因此移轉確認不只是確認動作，而是需要先建立心智模型：告訴用戶移入後能做什麼 → 允許「下次再說」→ 完成後給予明確回饋。這是用戶第一次接觸「跨系統資產移動」的入口；如果在這裡產生不安，後續交換與販售流程都會受到影響。
從「輸入地址」重新思考交換方式
原本的交換方式依賴背包地址，但取得、理解與輸入地址本身，對一般用戶都是額外成本。因此在梳理流程時，我們進一步提出另一種 interaction model：透過連結交換。發起者選擇欲交換的資產後，由系統產生交換連結；另一方開啟連結即可進入交換，不再需要雙方事先取得並輸入彼此的背包地址。這不只縮短操作流程，也把「地址」這個 Web3 技術概念從主要體驗中抽離，讓交換更接近一般用戶熟悉的分享行為。
安全與順暢之間沒有免費的選擇
過去曾發生用戶私下約定交換後單方毀約的詐騙情況，因此 PM 提出雙向確認的安全需求。交換流程最終採用：發起交換 → 對方回應 → 發起者再次確認 → 完成交換。確認機制能降低單方毀約的風險，卻也意味著每增加一步，就多一個理解成本與可能的流失點。因此這段設計真正需要處理的，不是單純把流程做短，而是：哪些摩擦是應該消除的，哪些摩擦其實是在保護用戶？
亮點 3
從商業取捨到品牌識別
在產品落地初期，與設計夥伴梳理三種品牌架構的商業取捨，提供高層決策依據，再將最終策略轉化為可延伸的品牌識別。
品牌不是先從 Logo 開始
產品進入落地階段後，我們首先面對的不是「Logo 長什麼樣」，而是 O!Pack 在集團品牌架構裡究竟應該扮演什麼角色。我與另一位設計師整理三種方向：獨立品牌長期辨識度高、對外合作彈性大，但初期缺乏集團信任背書；前綴式品牌能直接承接集團品牌資產、降低推廣成本，但長期可能限制獨立發展；Co-branding 兼具獨立性與母品牌背書，但短期需要更多市場教育。同時參考 Meta、Google Workspace、Dropbox 等品牌架構與更迭案例，作為討論依據。
設計提供 trade-off，高層決定階段策略
我們原先較傾向「獨立品牌＋母品牌背書」，在初期借力集團信任、同時保留長期獨立發展的彈性。CEO 則從產品當下的市場階段判斷，初期應更直接承接集團品牌紅利、降低認知成本，因此最終確立 O! 系列方向，架構上附屬 Gama Pass。這並不是單純選擇哪個 Logo，而是不同階段下對品牌資產、推廣成本與長期彈性的取捨。
把商業決策轉譯成視覺系統
方向確立後，我再從母品牌既有識別拆解規則，包括前後綴粗細對比、字距比例、大小寫平衡與基線關係，讓 O!Pack 能承接母品牌辨識度，同時保有作為子品牌的獨立性與未來延伸空間。
其他貢獻
橫屏 Layout 規劃
考量主要使用族群包含遊戲玩家，實際情境中可能長時間維持橫向操作，因此額外檢視並調整橫屏 layout，確保資訊層級與主要操作在不同螢幕比例下仍維持可用性。
成效
- 階段品牌成果獲高層正向回饋｜品牌識別提報後獲得正面回饋，基礎樣式的延展性也被認為有利於後續應用。
- 架構圖成為跨角色的共同對焦工具｜原本用於拆解產品的架構圖，隨著開放問題持續被標記與解決，也逐漸成為 PM、設計、工程共同確認功能範圍與待決事項的工作文件，降低資訊散落在不同討論中的情況。
產品仍在開發中，因此目前不以使用數據作為成效證明。
Retrospective
有些摩擦，是為了保護用戶
跨服務商的資產流通同時涉及多方利益與風控需求。這段經驗讓我更明確地理解，好的體驗不一定代表步驟最少；有些摩擦應該被消除，有些則是在建立信任與安全感。設計的工作，是讓必要的摩擦變得可以理解。
沒有前例時，先建立自己的判斷框架
Web3 的技術陌生度，加上 0→1 沒有既有系統可以沿用，讓很多問題沒有現成答案。比起急著進入 UI，我更需要先釐清產品定位、資訊關係、技術限制與商業目標，建立一套足以支持後續設計決策的判斷框架。