摘要
此專案由我提議並從草稿開始主導，逐步定義檔案架構、命名規則、範例檔案及工作流程，並負責同步資訊給主管階層。
我們最後交出了以三大檔案為主架構的Design system，並且成功以它們為基底重構從韓國設計團隊接手過來的所有設計檔案。
- Design Style (內容包含 typography 及色盤)
- Component Library (元件及所屬規範文件)
- Page Library (Internal) (供所有設計師內部參考用的實際使用場景)
背景與脈絡
即使LINE Bank已經開行多年，我們始終沒有一套正式的設計或元件規範，結果就是我們一再面臨同樣的問題：
- 在設計review時：「這個元件是從哪裡來的？」「我之前好像看過類似的東西，是在哪裡？」「這個元件正確的使用方式是什麼？」
- 在開發過程中：「我們會重複使用這個元件嗎？」「可以微調並沿用XXX專案裡的東西嗎？」「為什麼這裡會出現一個新的顏色？」
這些問題造成了不必要的來回溝通。因為我們作為Planner，同時扮演連接韓國設計師和台灣工程師之間的橋樑，很多時候我們只是一再重複同樣的說明。
在2024年接手韓國的設計檔案之後，我們意識到根本問題在於結構本身：沒有一套被設計使用的內部元件庫。與此同時，我們也不希望長期讓資源分散管理在多個地方，當我們手上同時接手來自韓國UX和UI團隊的雙檔案時，我們意識到，當下已然是建立一套具有規模性的元件庫系統的最佳時機。
角色
我是這項元件庫計畫的最初提議者，也是整體方向的負責人，職責包括：
- 定義我們需要多少個library、每一個library應該涵蓋哪些內容
- 建立檔案命名規則、檔案製作標準，以及範本
- 制定工作流程、階段性任務和專案時程
- 向管理層匯報進度和未來方向，讓他們清楚了解設計團隊正在打造什麼、以及背後的原因
執行與實踐
我們把整套library設計成三份互相連結的檔案，每一份都有明確的用途和使用對象：
- Design Style
- 最基礎的原子層級：字體排印（typography）、色彩，以及其他基礎樣式。
- 目標是確保每一個產品畫面，都參照同一套「唯一真實來源」（source-of-truth）樣式。
- Component Library
- 所有元件以及說明使用方式的規範文件所在之處。
- 這是設計師、工程師和PM共同參照的資源。
- Page Library (Internal)
- 一份僅限內部使用的library，收錄了過去各元件實際被使用過的真實範例。
- 它能幫助設計師快速找到「已驗證有效的模式」，減少重工。
在建立起這套結構之後，我們從韓國那邊接手的所有設計檔案，都透過這三個library重新整理並重建完成，讓基本樣式、元件，以及真實使用範例，能夠一致地互相連結並在文件上呈現。
案例: 非固定色碼到 tokens
在還沒有元件庫之前，我們曾遇到像是兩個幾乎一模一樣的顏色（例如 #222222 和 #232323 ），卻分別被使用在不同頁面和專案裡的情況。這讓一些基礎議題變得難以定義：
- 哪一個才是「真正的」主色？
- 應該保留哪一個？
- 該怎麼命名，才能讓整個團隊一致地使用？
在把library整理好之後，我們改採用以token為基礎的做法。設計師看到的不再是散落在各檔案裡的原始色碼，而是頁面已經套用了一個Primary色彩token，系統也會清楚顯示對應關係（例如：Primary = #222222）。這讓討論的方向，從「哪個色碼才是對的？」轉變成「我們該用哪一個token？」
關鍵決策與心得
命名與結構不僅是字面上意義，也關乎到營運層級
由於我們的內容來自既有的頁面和產出，我們一開始刻意避免大幅度的視覺改動。這也讓命名和組織架構變得更加重要——如果沒有清楚的結構，我們等於是在一份新檔案裡，重新製造出同樣的混亂。
責任歸屬和營運管理的討論，需要及早進行
我們花了不少時間跟開發團隊對齊，釐清這份規範文件到底該是什麼樣子，IT原本的期待，比較接近Apple的Human Interface Guidelines，也就是能直接提供給前端日常使用的程式碼，但從設計團隊的角度來看，我們最初的目標是溝通效率和一致性，而不是急著讓設計語言去對齊工程語言。
最後我們達成共識：此專案可以逐步進行，先專注在建立一套可靠的library，同時記錄下開發端的意見（例如作業系統的限制），藉此縮小規範文件和實際開發之間的落差。