Từ Zero đến Principal Frontend Engineer (P9): Xây Dựng Design System Ở Quy Mô Lớn – Khi UI Trở Thành Một Sản Phẩm

"Làm UI thì cần gì Design System? Cứ code thẳng component là xong!"

Đó là suy nghĩ của mình 5 năm trước, cho đến khi phải maintain một dự án với:

• 10+ developers cùng sửa giao diện, mỗi người một style.
• 3 phiên bản button khác nhau chỉ vì không ai biết component nào là "chuẩn".
• 1 tháng chỉ để đồng bộ lại CSS cho toàn bộ app.

Lúc đó, mình mới nhận ra: Design System không phải là thứ xa xỉ, mà là công cụ sinh tồn khi frontend phát triển đến một quy mô nhất định.

1. Design System Là Gì? Và Tại Sao Nó Lại Quan Trọng?

Không chỉ là UI Kit!

Nhiều người lầm tưởng Design System chỉ là một thư viện component. Thực tế, nó bao gồm:

• Design Tokens: Biến đổi màu sắc, spacing, typography thành dạng data (JSON/JS).
• Component Library: Button, Modal, Dropdown... được chuẩn hóa API.
• Documentation: Hướng dẫn sử dụng, best practices.
• Quy trình cập nhật: Versioning, changelog, deprecation policy.

Lợi ích khi áp dụng Design System

• Tốc độ phát triển: Thay vì mất 2 ngày để build một form, giờ chỉ cần kéo component có sẵn.
• Nhất quán UX: User không bị "giật mình" khi chuyển giữa các trang.
• Dễ bảo trì: Thay đổi brand color chỉ cần sửa 1 chỗ.

2. Kiến Trúc Một Design System "Cứng Cáp"

2.1. Design Tokens – Nền Tảng Của Mọi Thứ

Thay vì hard-code màu:

/* Cách cũ - Khó maintain */
.button { background: #3b82f6; }

Chuyển thành tokens:

// tokens.js
export const colors = { primary: "#3b82f6", danger: "#ef4444",
};

→ Dùng ở mọi nơi:

<Button bg={colors.primary} />

Ưu điểm:

• Dễ áp dụng dark/light theme.
• Share được với Android/iOS (dùng cùng file JSON).

2.2. Component API Phải "Dễ Dùng, Khó Phá"

Một component tốt phải:

• Có PropTypes/TypeScript: Để auto-complete khi sử dụng.
• Hỗ trợ Composition:

<Card> <Card.Header title="Profile" /> <Card.Body>Content</Card.Body>
</Card>

• Xử lý lỗi rõ ràng: Nếu thiếu prop bắt buộc, log ra lỗi cụ thể.

2.3. Versioning & Monorepo

Khi Design System phát triển, cần:

• Quản lý version (SemVer: major.minor.patch).
• Dùng monorepo (Turborepo, Nx) để share code giữa các packages.

/packages /design-tokens /react-components /docs

3. Công Cụ & Quy Trình Triển Khai

3.1. Storybook – "Cửa Hàng Demo" Cho Components

• Mỗi component đi kèm docs + examples:

  ## Button
  - Props: `variant`, `size`, `disabled`
  - Usage: `<Button variant="primary">Submit</Button>`
  

• Visual Testing: Dùng Chromatic để tự động phát hiện UI bị vỡ.

3.2. Tích Hợp Với Figma

• Figma → Code: Dùng plugin như Figma to React để tự động gen component từ design.
• Single Source of Truth: Đảm bảo design file và code luôn đồng bộ.

3.3. Làm Sao Để Team "Chịu Dùng"?

• Pha "Cưỡng Chế":
  • Thêm rule ESLint: Cấm hard-coded colors/spacing.
  • Code review từ chối nếu không dùng Design System.
• Pha "Dụ Dỗ":
  • Demo: "Xài component này, build form nhanh hơn 50%".
  • Tổ chức internal contest: Team nào dùng Design System nhiều nhất được thưởng.

4. Những Bài Học Xương Máu

4.1. Đừng Over-Engineering

• Startup 5 dev? Chỉ cần 1 file shared-components.tsx là đủ.
• Công ty 50+ dev? Cần chia thành multi-package với lịch release rõ ràng.

4.2. Accessibility Phải Được Ưu Tiên Ngay Từ Đầu

• Mọi component phải work với keyboard + screen reader.
• Test bằng Axe hoặc Lighthouse.

4.3. Design System Là Một Sản Phẩm Sống

• Cần dedicated team (dù chỉ 1 người part-time) để trả lời câu hỏi:
  • "Component này dùng sao?"
  • "Làm sao thêm variant mới?"

Kết Luận: Design System Là Chiến Lược, Không Phải Công Cụ

Khi UI trở thành sản phẩm, bạn không còn là "thợ code giao diện", mà là người xây dựng nền tảng để cả team cùng phát triển.

Bạn đã sẵn sàng?

1. Thử chuyển 1 màu trong app thành design token hôm nay.
2. Setup Storybook cho 3 components đầu tiên.

"Một Design System tốt không làm bạn code nhanh hơn ngay lập tức, nhưng nó giúp bạn không bao giờ phải code lại từ đầu."