Giải mã bí ẩn: Tại sao hệ thống thiết kế 'chết yểu' sau năm thứ hai?

Lê Lân

19/08/2025

Làm Thế Nào Để Tránh Sự Bùng Nổ Props, Hỗn Loạn Chủ Đề Và Ác Mộng Bảo Trì Trong Hệ Thống Thiết Kế Sau Hai Năm

Mở Đầu

Hệ thống thiết kế (design system) thường được xem là giải pháp cứu cánh cho việc xây dựng giao diện nhất quán và hiệu quả trong các sản phẩm số. Tuy nhiên, nhiều hệ thống rơi vào tình trạng phức tạp, khó bảo trì chỉ sau hai năm phát triển.

Mỗi đội ngũ phát triển phần mềm đều từng trải qua giai đoạn cần một hệ thống thiết kế để thống nhất giao diện và tiết kiệm thời gian. Ban đầu, hệ thống này mang đến sự tự do: các thành phần nhất quán, tiến trình phát triển nhanh hơn và giảm lỗi thiết kế. Nhưng theo thời gian, các vấn đề bắt đầu xuất hiện: các component trở nên phức tạp với vô số props, sự khác biệt giữa thiết kế trong Figma và code làm mất niềm tin, và việc mở rộng chủ đề hay hỗ trợ dark mode trở thành gánh nặng khổng lồ.

Bài viết này là cẩm nang sinh tồn để xây dựng hệ thống thiết kế bền vững, tránh được những cạm bẫy khiến nó sụp đổ chỉ sau một thời gian ngắn.

I. Giấc Mơ và Nỗi Ám Ảnh

Mọi nhóm phát triển đều đến một điểm chung: "Chúng ta cần một hệ thống thiết kế."

1. Sự kỳ vọng ban đầu

Có một bộ component thống nhất.

Tăng tốc độ prototype và phát triển.

Ít lỗi thiết kế hơn.

2. Thực tế tàn khốc

Button component có tới 12 props.

Các biến thể trong Figma không đúng với hiện thực trên code.

Thay đổi màu sắc vô tình làm hỏng nhiều tính năng khác.

Thêm dark mode phải viết lại hầu hết hệ thống.

Điều gì bắt đầu như một liên minh mạnh mẽ cuối cùng lại biến thành một đống hỗn độn cồng kềnh và dễ vỡ.

II. Dấu Hiệu Báo Động Sự Sụp Đổ

1. Bùng nổ Props

<Button variant="outline" size="sm" iconLeft="check" iconRight="x" loading primary secondary destructive subtle />

Một component đơn giản bị nhồi nhét quá nhiều tùy chọn khiến nó trở nên khó hiểu và khó quản lý.

2. Sự khác biệt giữa Figma, Storybook và thực tế

Không ai biết đâu mới là nguồn dữ liệu chính xác. Điều này gây mâu thuẫn lớn, làm mất thời gian kiểm tra và đồng bộ.

3. Phân mảnh token

Các token padding-sm, spacing.small và theme.space.s cùng tồn tại nhưng lại không thống nhất gây nhầm lẫn.

4. Ác mộng cập nhật chủ đề

Thay đổi một token màu dẫn đến sự cố với 15 component khác.

“Nếu hệ thống thiết kế của bạn cần một khóa đào tạo dài, có lẽ nó đã quá phức tạp.”

III. Nguyên Tắc Sinh Tồn Với Hệ Thống Thiết Kế

1. Bắt đầu với Token, không phải Component

Trước khi xây dựng bất kỳ component nào, hãy xác định và chuẩn hóa các token thiết kế:

Màu sắc (Color)

Khoảng cách (Spacing)

Kiểu chữ (Typography)

Độ nâng (Elevation)

Bán kính bo góc (Border radii)

Centralling these tokens giúp việc tạo chủ đề trở nên dễ dàng và hiệu quả hơn.

Có thể sử dụng các công cụ như Style Dictionary , Theo , Token Studio , hoặc bộ CLI Design Tokens để quản lý và đồng bộ token giữa code và Figma.

Ví dụ cấu trúc token cơ bản

{
  "color": {
    "base": {
      "blue500": { "value": "#0055ff" },
      "gray100": { "value": "#f5f5f5" }
    },
    "semantic": {
      "primary": { "value": "{color.base.blue500}" },
      "background": { "value": "{color.base.gray100}" },
      "buttonBackground": { "value": "{color.semantic.primary}" }
    }
  },
  "spacing": { "s": { "value": "8px" }, "m": { "value": "16px" } }
}

Style Dictionary sẽ chuyển đổi các token trên thành các định dạng phù hợp với từng nền tảng (CSS variables, SCSS, JS) giúp cập nhật dễ dàng.

2. Ưu Tiên Composition Hơn Configuration

Tránh tạo thành phần "to bự" với hàng tá props.

Ví dụ Prop Explosion

<Card heading="Welcome" content="This is a composed card." footerAction={<Button>Submit</Button>} />

Ví dụ Composition pattern

<Card>
  <CardHeader>
    <Heading level={3}>Welcome</Heading>
  </CardHeader>
  <CardContent>
    <Text>This is a card component built with composition.</Text>
  </CardContent>
  <CardFooter>
    <Button variant="primary">Submit</Button>
  </CardFooter>
</Card>

Composition giúp cải thiện tính rõ ràng, linh hoạt và khả năng bảo trì lâu dài.

3. Phân Biệt Rõ Giữa Hệ Thống Thiết Kế và Lớp Ứng Dụng

Hệ thống thiết kế không nên chứa logic kinh doanh của ứng dụng.

Sai cách:

<Button isUserAdmin={user.role === 'admin'} />

Đúng cách:

{user.role === 'admin' && <Button>Delete</Button>}

Giữ các component thuần về mặt giao diện với API dễ kết hợp.

4. Kiểm Tra Như Một Sản Phẩm Thực Thụ (và Đánh Giá Áp Lực)

Hệ thống thiết kế là một sản phẩm nên được kiểm thử kỹ càng:

Thử nghiệm visual regression (Chromatic, Percy, Loki).

Thêm kiểm tra khả năng truy cập (axe-core, Lighthouse) trong quá trình CI.

Yêu cầu QA thiết kế kiểm tra trên Storybook.

Đánh giá hiệu năng thực tế của các component: render bảng lớn, thay đổi kích thước lưới responsive, reflow trang nặng.

Tiêu chuẩn hiệu năng mẫu:

Tiêu chí	Mục tiêu
Render ban đầu	< 200ms
Độ trễ tương tác	< 100ms
Chỉ số CLS (Layout shift)	< 0.1

Sử dụng Lighthouse, WebPageTest, hoặc Công cụ đo Real User Monitoring để theo dõi.

Trọng tâm không chỉ là kiểm tra code mà còn là kiểm định các kỳ vọng: khả năng truy cập, điều hướng bàn phím, hỗ trợ screen reader, và quốc tế hóa.

5. Cắt Tỉa Quyết Liệt

Hệ thống thiết kế sẽ "mục nát" nếu giữ lại tất cả các props và biến thể vô dụng.

Loại bỏ props và variants không còn dùng.

Duy trì điểm số sức khỏe component (sử dụng, cập nhật, số lỗi).

Rà soát hàng quý, nếu biến thể nào không ai dùng nữa: loại bỏ.

6. Phân Công Sở Hữu, Quản Trị và Phiên Bản

Hệ thống thiết kế cần có nhóm chủ quản nhỏ gồm:

Nhà thiết kế

Nhà phát triển

Người đảm nhận đội sản phẩm (nếu có)

Họ sẽ duyệt các đề xuất, duy trì tiêu chuẩn và giải quyết xung đột.

Một cách hiệu quả là áp dụng quy trình RFC (Request for Comments):

Người đề xuất viết tài liệu Markdown ngắn trình bày lý do, thiết kế API, ảnh hưởng giao diện, kế hoạch di cư.

Nhóm core review hàng tuần hoặc hai tuần, sau đó duyệt hoặc trả lời sửa đổi.

Các thay đổi được ghi lại trong changelog và thông báo qua kênh nội bộ.

Ví dụ RFC:

# RFC: Thêm component `Tooltip`

## Tóm tắt
Tạo `Tooltip` hỗ trợ gợi ý trên hover và focus, chuẩn truy cập.

## Lý do thiết kế
Các tooltip hiện tại không đồng nhất và chưa đạt chuẩn truy cập.

## API Đề xuất
<Tooltip content="Hướng dẫn chi tiết"><Button>Hover me</Button></Tooltip>

## Chiến lược di cư
Không cần di cư. Tính năng bổ sung.

## Thời gian xem xét
Mở góp ý đến cuối tuần tới.

Để giảm thiểu gián đoạn khi thay đổi lớn, dùng semantic versioning và changelog. Đánh dấu phiên bản chính với v2.0.0, cung cấp hướng dẫn di cư (MIGRATIONS.md), công cụ hỗ trợ chuyển đổi (codemods), cảnh báo trong CI hoặc console.

7. Khuyến Khích Áp Dụng Một Cách Thiết Kế

Hệ thống tốt nhất là hệ thống được sử dụng thực tế.

Tài liệu rõ ràng, dễ hiểu.

Quy trình onboarding không rườm rà.

Kênh hỗ trợ thường xuyên.

Chia sẻ thành công: ví dụ “Trang này được hoàn thiện nhanh gấp đôi nhờ dùng hệ thống.”

Áp dụng hệ thống thiết kế là một văn hóa hơn là một mệnh lệnh.

IV. Ứng Dụng Thực Tế: Quá Trình Chuyển Đổi

Một công ty SaaS vừa và nhỏ từng gặp thất bại khi hệ thống thiết kế cũ phình to hơn 130 component, nhiều cái chỉ dùng một lần.

Họ đã:

Đánh giá sử dụng các component, loại bỏ trùng lặp và legacy.

Thiết lập token chuẩn làm nguồn sự thật, đồng bộ với Figma và code qua Tokens Studio và Style Dictionary.

Ban hành quy tắc chỉ dùng bộ mới cho tính năng mới.

Áp dụng pattern composition giảm nguy cơ bùng nổ props.

Dùng codemods và flags chuyển đổi dần dần từng trang.

Lưu ý tránh:

Không công bố rõ deprecated dẫn đến song song 2 hệ thống.

Không đồng bộ thời gian thiết kế và phát triển.

Không thiết lập baseline hiệu năng khiến khó phát hiện lỗi regressions.

Kết quả trong 3 tháng: giảm 40% số component, cắt giảm 22% dung lượng bundle và thêm dark mode chỉ bằng 3 dòng override token.

V. Phần Thưởng: Đồng Bộ Figma và Code

Ngay cả hệ thống tốt cũng thất bại nếu thiết kế và lập trình không đồng bộ.

Chiến lược:

Sử dụng plugin token Figma (Tokens Studio) để sincronize.

Giới hạn người tạo variant mới trong Figma.

Tổ chức họp sync thiết kế – phát triển định kỳ 4-6 tuần.

Điều chỉnh variant Figma khớp với trạng thái component code (loading, focus, error).

Thường xuyên audit sự tương đồng giữa Figma và Storybook.

Nguồn chân thật của hệ thống không phải chỉ là code hay Figma, mà là sự phối hợp chặt chẽ giữa cả hai.

VI. Thành Quả

Một hệ thống thiết kế nhẹ, được bảo trì tốt đem lại lợi ích vô giá mỗi khi bắt đầu một trang hoặc tính năng mới:

Không cần chỉnh sửa pixel thủ công.

Không phải đoán mò thiết kế.

Không phải tái viết mọi thứ sau vài tháng.

Hệ thống thiết kế tốt không phải là phức tạp, mà phải rõ ràng. Hãy xây dựng hệ thống của bạn để tồn tại lâu dài.

Tham Khảo

Amazon Style Dictionary. https://amzn.github.io/style-dictionary/

Salesforce UX Theo. https://github.com/salesforce-ux/theo

Tokens Studio for Figma. https://tokens.studio/

Design Tokens Community Group CLI. https://github.com/design-tokens/community-group

“Building Design Systems” - Brad Frost

“Design Systems” - Alla Kholmatova

Accessibility Testing Tools: axe-core, Lighthouse

Visual Regression: Chromatic, Percy, Loki

Web Performance Tools: Lighthouse, WebPageTest, RUM Analytics