Dựng xong một design system mới chỉ là vạch xuất phát. Phần khó hơn nằm ở những tháng sau đó, khi mỗi đội dự án tự thêm màu, tự sửa khoảng cách, tự vẽ lại một cái nút “cho nhanh”. Vài tháng không ai trông coi, bản thiết kế trong Figma và code chạy thật bắt đầu nói hai ngôn ngữ khác nhau, và hệ thống mất luôn lý do tồn tại.
Vì sao design system chết nếu không nuôi
Một design system không phải tài sản dựng một lần rồi để đó. Nó là sản phẩm sống, có người dùng (chính là designer và lập trình viên trong đội) và có vòng đời. Nguyên nhân phổ biến nhất khiến nó chết được Nielsen Norman Group và nhiều đội thực chiến chỉ ra là drift (trôi lệch — bản thiết kế và code mỗi nơi một kiểu theo thời gian).
Drift xảy ra rất tự nhiên. Một đội cần gấp một biến thể nút mà hệ thống chưa có, họ tự code riêng. Một designer đổi sắc độ coral trong file của họ mà không cập nhật lại token gốc. Vài chục quyết định nhỏ như vậy cộng dồn, đến lúc nhìn lại thì sản phẩm thật không còn giống design system nữa, và không ai dám tin vào nó. Khi đó người ta quay về copy-paste, hệ thống thành một bộ tài liệu chết.
Nói cách khác, design system không chết vì thiếu component. Nó chết vì thiếu người và quy trình nuôi.
Đánh số phiên bản để báo thay đổi rõ ràng
Cốt lõi của việc duy trì là cho mỗi lần thay đổi một cái tên rõ ràng, để cả đội biết thay đổi đó nặng hay nhẹ. Cách phổ biến nhất là semantic versioning (đánh số ngữ nghĩa — MAJOR.MINOR.PATCH), theo chuẩn được EightShapes và nhiều đội lớn dùng:
| Loại | Khi nào tăng | Ví dụ |
|---|---|---|
| PATCH (2.4.1) | Sửa lỗi, không đổi cách dùng | Chỉnh lệch 1px của icon |
| MINOR (2.5.0) | Thêm mới, không phá cái cũ | Thêm một biến thể nút mới |
| MAJOR (3.0.0) | Phá vỡ, đội dùng phải sửa code | Đổi tên token, xoá thuộc tính cũ |
Đi kèm số phiên bản là một changelog (nhật ký thay đổi — ghi mỗi lần đổi gì ở một chỗ tập trung). Đây là nơi đội dự án vào đọc để biết bản mới có gì, có gì cần sửa theo. Không có changelog, mọi người nâng cấp trong sợ hãi vì không biết cái gì sẽ vỡ.
Quy trình đóng góp và duyệt component mới
Design system sẽ phình hoặc lệch nếu ai cũng được thêm component tuỳ ý, mà cũng sẽ chết cứng nếu chỉ một người được thêm. Lời giải mà phần lớn đội chốt lại là một contribution model (mô hình đóng góp — quy tắc ai được đề xuất gì và duyệt ra sao) đủ nhẹ để khuyến khích tham gia nhưng vẫn có cổng kiểm soát.
Một vòng đời component thường gọn lại thành các bước:
- Đề xuất — đội cần một component mô tả nhu cầu, kèm ảnh chụp chỗ đang phải tự chế.
- Duyệt — đội lõi xét: nhu cầu này đã có component nào lo được chưa, có đáng đưa vào dùng chung không.
- Dựng và viết tài liệu — làm cả bản thiết kế lẫn code, kèm hướng dẫn dùng.
- Phát hành — tăng phiên bản, ghi changelog, báo cho cả đội.
Câu hỏi quan trọng nhất ở bước duyệt là: “Cái này dùng lại ở nhiều chỗ hay chỉ đặc thù một màn hình?” Thứ chỉ dùng một lần không nên vào hệ thống dùng chung, nếu không hệ thống sẽ phình to mà không ai dùng hết.
Đồng bộ bản thiết kế với code để không trôi lệch
Đây là khâu hay vỡ nhất. Nhiều đội đặt token trong Figma, xuất ra code một lần, rồi không bao giờ đồng bộ lại — và thế là drift. Đồng bộ design với code không phải việc bàn giao một lần, mà là việc duy trì liên tục.
Hai hướng giúp giảm lệch:
- Một nguồn sự thật cho token — màu, cỡ chữ, khoảng cách định nghĩa ở một nơi rồi tự đẩy sang cả thiết kế lẫn code, thay vì gõ tay hai lần. Cách đặt tên theo tầng (gốc → ngữ nghĩa → component) giúp việc này bền hơn; bạn có thể xem chi tiết ở bài về design token là đơn vị nhỏ nhất của hệ thống.
- Dựng mẫu bằng component thật — khi designer prototype bằng đúng component đang chạy trong sản phẩm, khoảng cách giữa “cái được thiết kế” và “cái được code ra” tự thu hẹp.
Đây cũng là lợi thế khi cùng một đội vừa thiết kế vừa lập trình. Tại Web22, hệ thống giao diện của web22.dev (font Inter Tight, màu coral, các component dùng lại trong theme web22-core) được nuôi bởi chính những người dựng nó, nên bản thiết kế ra đúng như code, không bị tam sao thất bản qua khâu bàn giao.
Chống phình và xử lý component cũ
Hệ thống càng sống lâu càng dễ phình, vì người ta giỏi thêm mà ngại bỏ. Cần một chính sách loại bỏ (deprecation — báo trước rằng một component sẽ ngừng dùng) rõ ràng, thường theo ba nhịp:
- Cảnh báo — đánh dấu component là “sắp bỏ”, chỉ ra cái thay thế.
- Chờ — giữ song song cả cũ lẫn mới một khoảng đủ dài để các đội kịp chuyển.
- Gỡ — xoá hẳn ở một phiên bản MAJOR, kèm changelog.
Định kỳ rà soát thứ không ai dùng và mạnh tay bỏ đi cũng quan trọng như thêm mới. Một design system gọn mà ai cũng tin còn tốt hơn một kho khổng lồ không ai dám đụng.
Checklist duy trì định kỳ
- Có người (hoặc đội lõi) được giao rõ trách nhiệm trông coi hệ thống.
- Mỗi lần đổi đều tăng phiên bản và ghi changelog.
- Token có một nguồn sự thật, không gõ tay hai lần ở thiết kế và code.
- Có quy trình đề xuất và duyệt component mới.
- Rà soát định kỳ component ít dùng để loại bỏ theo ba nhịp.
- Đo mức độ sản phẩm thật còn bám sát hệ thống.
Câu hỏi thường gặp
Bao lâu nên cập nhật design system một lần?
Không có con số cố định. Việc cập nhật nên gắn với nhu cầu thật của sản phẩm, kèm một nhịp rà soát định kỳ (ví dụ mỗi quý) để dọn component cũ và kiểm tra độ lệch.
Duy trì khác gì với xây design system?
Xây là tạo ra hệ thống lần đầu. Duy trì là nuôi nó sống sau đó qua versioning, duyệt component mới và đồng bộ liên tục. Bạn có thể đọc thêm về design system là gì và gồm những gì để thấy bức tranh tổng quan.
Đội nhỏ có cần versioning phức tạp không?
Đội nhỏ có thể dùng versioning nhẹ hơn, nhưng changelog và một nguồn sự thật cho token thì gần như đội nào cũng nên có, vì chính chúng chống drift.
Nếu bạn muốn một hệ thống giao diện được dựng và nuôi bởi cùng một đội để không bị lệch theo thời gian, hãy tham khảo dịch vụ thiết kế và xây dựng design system của Web22.