嗨，我是 Yu。我設計產品，讓複雜的事情變得簡單易用。

我重視系統思考，也重視提出對的問題。我習慣用 AI 快速製作原型、及早驗證想法，把複雜的問題轉化為值得信賴的產品。

在東京的 PayPay，我為超過 6,500 萬名使用者設計付款與理財體驗，即使背後的規範相當複雜，使用起來依然輕鬆。在此之前，我在 Carousell 負責台灣與新加坡市場的成長與使用者互動。

工作之餘，我在 AAPD 擔任設計導師，也運用程式與 AI 開發小工具。

作品

PayPay

我主導 PayPay 錢包資金進出的設計，涵蓋儲值、ATM 與信用卡付款。

Carousell

我設計了註冊流程與通知中心，也打造了背後的行銷工具與設計系統。

我開發的工具

合作夥伴的推薦

Ryan 是我在 PayPay 團隊中的關鍵成員，在多個專案中持續交出高品質的設計。他也積極投入 Design Ops，改善 QA 流程與無障礙設計。
Ryan 是我在 AAPD 的夥伴，我們一起教授 Figma 與 UI 設計。他從助教做起，很快便成為講師，展現出優秀的學習能力、對細節的重視，以及清楚的溝通。
Ryan 是備受重視的團隊成員，獨立帶領多個需求不明確、極具挑戰的專案。他透過扎實的研究釐清方向，以耐心且有條理的方式解決問題。
Ryan 是我在 Carousell 的前同事，他總能在使用者需求與商業目標之間取得平衡，做出實用且周到的設計，這一點一直令我佩服。
當設計與開發出現落差時，他會冷靜地與團隊一起找出務實的解法。他對修正 bug 與改善體驗的建議，提升了產品品質，也讓團隊運作更有效率。

Ryan 是我在 PayPay 團隊中的關鍵成員，在多個專案中持續交出高品質的設計。他也積極投入 Design Ops，改善 QA 流程與無障礙設計。

改版後設計系統中的元件

Carousell 的設計系統已逐漸偏離原本的規範：元件難以重複使用、文件過時，設計師與工程師對同一個元件也有不同的稱呼。我主導了這次改版，建立清楚的更新流程、重新整理 Figma 元件庫，並撰寫連結設計與程式碼的文件。

現況

設計系統本身也是一項產品，它的使用者是設計師與工程師。因此我從他們著手：對工程師進行痛點問卷，並與設計師舉辦一場工作坊。許多設計師會將元件 detach 後自行修改，因為原本的元件不夠彈性。即使是資深設計師，也很難找到需要的元件。

缺乏一致性。 沒有明確的規範，元件仍使用 Figma 的舊功能，也沒有維持系統更新的流程。
不易查找。 設計與程式碼之間沒有連結，元件難以用名稱搜尋，也無法掌握有哪些變更。
溝通不順暢。 同一個元件有不同名稱，溝通管道分散，也缺乏結構化的回饋機制。

以按鈕進行試做

在全面改版之前，我先以各平台都會用到的按鈕測試這套做法。我邀請一位工程師共同參與，比對正式環境中的按鈕與設計系統中的按鈕。

盤點出的按鈕與 chip 變體

這次試做將所有問題集中呈現：

功能過時。 沒有 auto layout 與 properties，按鈕無法依設計師的需求調整。
文件不足。 使用說明老舊且不完整。
缺乏單一標準來源。 設計師各自製作自己的版本，與工程實作的落差越來越大。

參考其他團隊

我也研究了其他公司如何經營設計系統，並閱讀他們團隊分享的文章。

其他團隊的設計系統：Material 3、iOS、Polaris 與 Microsoft Teams

結合試做的結果，我們歸納出每個元件都要進行的三項改變：

以 Figma 最新功能重建。 包含 auto layout、properties 與 variants，當時仍是新功能，如今已成為標準做法。
將文件放在 Figma 中。 文件放在元件旁，而不是另外的 Notion 頁面，讓所有資訊集中在同一處。
連結到程式碼。 每個元件都標示對應的程式碼位置，讓設計與開發保持同步。

我向團隊與高階主管報告了按鈕的試做成果，獲得正面回饋，於是以相同方式處理其餘所有元件。

推動落地

這樣規模的改版無法由一個人完成。我負責主導，並建立團隊的協作方式：

負責人與進度追蹤試算表

明確的負責人。 透過試算表，依各團隊的使用頻率為每個元件指定負責人，並追蹤進度。

元件更新操作手冊

操作手冊。 以逐步說明的方式介紹如何更新設計系統，讓每個人遵循相同的流程。

Slack 上的每週更新

每週更新。 在 Slack 發布每週進度，讓設計師、工程師與利害關係人掌握最新狀況。

元件庫的呈現方式

現在每個元件都採用相同的版面：左側是文件，右側是變體，並附上註解，標示工程師對應的程式碼。

改版前後的按鈕頁面

Properties 與 variants 讓每個元件保持彈性，設計師不再需要 detach。每個元件也列出了在 Android 與 iOS 上的程式碼名稱。

透過 properties 調整按鈕的尺寸、類型與文字

在 Figma 中顯示按鈕的 Android 與 iOS 程式碼名稱

成果

設計檔中的元件覆蓋率: +32%
設計交接給開發的時間: −11%

工程師也回饋，元件庫變得更容易查找，而設計與程式碼一致之後，開發速度也隨之提升。

下一步

離開 Carousell 之前，我完成了基礎建置。後續規劃是先建立語意化的色彩 token，再處理字型樣式、間距與陰影，並全部以 Figma variables 與 modes 管理。

回顧

設計師同樣是使用者。及早聽取他們的意見，而不是獨自完成，影響了每一個決定。設計系統也是團隊合作的成果：信任夥伴並給予明確的負責範圍，比任何單一元件都重要。此外，沒有一套設計系統適用於所有團隊；最好的設計系統，是符合團隊現況、並建立在既有基礎之上的那一套。