Design system và AI: Token, MCP và governance

AI giờ có thể tạo một màn hình, một component hay cả một app chỉ trong vài phút. Tốc độ đó kéo theo một hệ quả mà designer nào cũng từng thấy: giao diện chạy được nhưng không giống sản phẩm của bạn. Màu lệch brand, spacing tự chế, thêm một kiểu button thứ tư không ai yêu cầu.

Cách giải không phải là làm AI chậm lại, mà là cho nó một thứ vững chắc để bám theo. Thứ đó chính là design system, và năm 2026 vai trò của design system đang thay đổi: không chỉ phục vụ designer và developer, nó còn phải đọc được bởi máy.

Bài này đi qua cách áp dụng design system cùng AI trong suốt quá trình phát triển sản phẩm, từ token, tài liệu, MCP server đến governance và một checklist thực tế.

Ý chính trong một câu: design system được viết ra càng rõ, kết quả AI tạo ra càng đúng brand.

Vì sao design system quan trọng hơn khi có AI

Mô hình ngôn ngữ không "nhìn thấy" brand của bạn. Nó dự đoán code và bố cục có khả năng xảy ra nhất dựa trên dữ liệu đã học và những gì bạn đưa vào context. Context càng mỏng, nó càng lấp chỗ trống bằng các pattern chung chung.

Design system thu hẹp những chỗ trống đó. Nó cho mô hình biết component nào đang có, giá trị nào được phép và khi nào dùng cái gì. Không có nó, mỗi prompt bắt đầu từ con số không. Có nó, mỗi prompt bắt đầu từ chính sản phẩm của bạn.

Còn một lý do nữa. AI khiến việc tạo UI mới trở nên rẻ, nghĩa là tạo ra sự thiếu nhất quán cũng rẻ. Càng nhiều người trong team dùng AI để tạo giao diện, một hệ thống chung càng trở thành thứ giữ sản phẩm thống nhất.

Lớp 1: Token là nguồn sự thật duy nhất

Design token là các quyết định thiết kế được đặt tên: màu, cỡ chữ, spacing, bo góc, đổ bóng, thời lượng chuyển động. Đây là phần nhỏ nhất và "thân thiện với máy" nhất của một design system.

Đã có một chuẩn ổn định. Tháng 10/2025, W3C Design Tokens Community Group công bố phiên bản ổn định đầu tiên của đặc tả (2025.10). Nó định nghĩa một định dạng file trung lập, không phụ thuộc công cụ, hỗ trợ theme và đa thương hiệu, các không gian màu hiện đại như Display P3 và OKLCH, và alias giữa các token. Đây là báo cáo của community group, chưa phải W3C Standard chính thức, nhưng được khuyến nghị để triển khai, và các công cụ như Style Dictionary, Tokens Studio, Terrazzo, Figma, Penpot đã hỗ trợ hoặc đang áp dụng.

Đặt tên token theo vai trò, không theo giá trị. Primitive token lưu một giá trị thô, như mã hex. Semantic token mô tả mục đích, như "màu, chữ, chính" hay "spacing, gọn". Mô hình chọn đúng thường xuyên hơn nhiều khi cái tên giải thích được ý định.

Tách primitive (bảng màu gốc) khỏi semantic token (dùng để làm gì).
Dùng một bộ token làm nguồn, rồi sinh ra CSS variable, Figma variable và file cho từng nền tảng từ đó.
Định nghĩa các mode (sáng, tối, tương phản cao, theo brand) ngay trong hệ thống token, không vá lẻ tẻ.
Không để output của AI chứa giá trị hard-code khi đã có token. Biến đó thành quy tắc, rồi kiểm tra.

Lớp 2: Viết tài liệu component cho cả người và LLM

Tài liệu component truyền thống thiên về hình ảnh: button trông thế nào ở từng trạng thái. Mô hình còn cần quy tắc: khi nào dùng component, khi nào không, và kết hợp với các component khác ra sao.

Hướng dẫn của chính Figma về design system sẵn sàng cho AI (bài "LLM context design") mô tả ba lớp phối hợp với nhau: token đặt tên tốt, spec nêu rõ quy tắc sử dụng, và một vòng audit để bắt những gì vẫn lọt qua.

Với mỗi component, hãy ghi lại:

Mục đích trong một câu, bằng ngôn ngữ đơn giản.
Khi nào dùng, và khi nào nên dùng thứ khác.
API: thuộc tính, variant, giá trị cho phép và mặc định.
Ví dụ đúng và sai, kèm lý do ngắn gọn.
Yêu cầu accessibility: nhãn, hành vi focus, kích thước vùng chạm tối thiểu, độ tương phản.
Quy tắc nội dung: độ dài nhãn, giọng điệu, cách viết hoa.

Cấu trúc tài liệu để mô hình dễ điều hướng. Figma khuyến nghị cách này cho Make kit: một file guidelines tổng quan ngắn giới thiệu hệ thống và dẫn tới các file chi tiết hơn, như tổng quan về component, icon, token, layout, cùng một file riêng cho mỗi component phức tạp. Cấu trúc này hợp với mọi công cụ AI, vì mô hình đọc "bản đồ" trước và chỉ đọc chi tiết khi cần.

Viết bằng Markdown, câu ngắn, ưu tiên quy tắc ("Mỗi màn hình chỉ dùng một primary button") thay vì mô tả ("Primary button rất quan trọng").

Lớp 3: Kết nối Figma, code và công cụ AI

Figma variables. Variable là nơi token nằm trong Figma. Nếu chúng phản chiếu đúng file token, cùng tên và cùng mode, designer và công cụ AI sẽ làm việc trên cùng một bộ giá trị. Dev Mode có thể hiển thị cú pháp code của từng variable, để cái tên developer thấy khớp với tên trong codebase.

Code Connect. Code Connect nối component trong Figma với component thật trong codebase. Khi đã thiết lập, code hiển thị cho một component trong Figma dùng đúng lệnh import và props thật, thay vì markup chung chung. Bạn còn có thể thêm hướng dẫn cho từng kết nối, như cách dùng props hay quy tắc accessibility.

Figma MCP server. MCP (Model Context Protocol) là chuẩn mở cho phép công cụ AI kết nối với dữ liệu và công cụ bên ngoài. MCP server của Figma cung cấp cho AI coding agent context thiết kế có cấu trúc từ file của bạn: layout, component, variable, style và asset. Khi component đã được nối qua Code Connect, context còn kèm lệnh import thật, đoạn code mẫu và hướng dẫn riêng của bạn, nhờ vậy agent dùng lại component có sẵn thay vì tự dựng lại. Server cũng có thể tìm kiếm component và variable có sẵn trong các thư viện đã kết nối, và nếu được thiết lập phù hợp, có thể ghi nội dung native ngược lại canvas. Figma khuyên phần lớn người dùng dùng server remote đặt tại mcp.figma.com.

Công cụ AI builder và editor. Các công cụ như Cursor, Lovable và Figma Make đều có chỗ lưu hướng dẫn lâu dài: project rules trong Cursor, project knowledge trong Lovable, guidelines và Make kit trong Figma Make. Make kit có thể đóng gói design system package đã publish cùng guidelines, và Make có thể soạn sẵn guidelines từ package để bạn duyệt lại. Dù dùng công cụ nào, nguyên tắc vẫn vậy: đặt quy tắc design system ở nơi AI đọc trong mọi yêu cầu, không chỉ trong một prompt.

Lớp 4: Giữ UI do AI tạo đúng brand

Kể cả có context tốt, mô hình vẫn có thể lệch. Hãy coi output của AI như bài làm của một đồng nghiệp mới làm rất nhanh: hữu ích, nhưng cần được review.

Ràng buộc trước. Yêu cầu công cụ chỉ dùng component và token trong hệ thống, và hỏi trước khi tạo thứ gì mới.
Tham chiếu, đừng mô tả. Chỉ vào một component hay màn hình thật ("giống trang settings") thay vì tả phong cách bằng tính từ.
Tạo từng phần nhỏ. Một section hay một component mỗi lần dễ review hơn cả một app.
Yêu cầu đủ trạng thái. Loading, empty, error, success, nội dung dài, màn hình hẹp. AI hay bỏ qua chúng.
Đưa phần sửa vào hệ thống. Khi bạn sửa cùng một lỗi lần thứ hai, hãy biến nó thành một quy tắc viết trong guidelines.

Lớp 5: Governance và QA

Design system được AI sử dụng cần governance giống như khi con người sử dụng, cộng thêm vài bước kiểm tra tự động.

Người chịu trách nhiệm. Ghi rõ ai duyệt component và thay đổi token mới. AI có thể đề xuất, con người quyết định.

Quy trình đóng góp. Khi AI hoặc đồng nghiệp tạo ra thứ hệ thống chưa có, nó đi vào hàng chờ review, không vào thẳng thư viện.

Kiểm tra tự động.

Lint code để bắt màu, spacing, cỡ chữ hard-code lẽ ra phải là token.
Chạy visual regression test cho các component cốt lõi.
Chạy kiểm tra accessibility (tương phản, nhãn, focus bàn phím) trong pipeline.
Theo dõi component nào thực sự được code do AI tạo sử dụng, để phát hiện lỗ hổng và độ lệch.

Quản lý phiên bản. Đánh version cho token và component, công bố changelog, và cập nhật guidelines cho AI trong cùng đợt phát hành. Guidelines lỗi thời còn tệ hơn không có, vì mô hình sẽ tự tin làm theo.

Quy trình từ discovery đến handoff

Discovery. Dùng AI để tóm tắt research và gom nhóm insight, nhưng quyết định vẫn thuộc về team. Ghi lại vấn đề đụng tới những pattern nào đang có.
Define. Viết user flow và danh sách màn hình. Kiểm tra trong hệ thống xem component nào đã đáp ứng từng nhu cầu.
Explore. Tạo nhanh các phương án trong Figma Make hoặc một AI builder, giới hạn trong design system kit của bạn. Bỏ đi phần lớn; đó chính là mục đích.
Design. Tinh chỉnh hướng đã chọn trong Figma với component và variable thật. Đánh dấu mọi thứ mới là đề xuất.
Prototype. Dựng prototype chạy được bằng công cụ AI đã nạp guidelines. Test với nội dung thật và người dùng thật.
Handoff. Developer hoặc coding agent lấy context thiết kế qua Dev Mode và MCP server, với Code Connect trỏ tới component thật.
Review. So bản build với thiết kế, chạy kiểm tra tự động, và đưa quy tắc mới trở lại hệ thống.

Vòng lặp quan trọng hơn bất kỳ bước đơn lẻ nào. Mỗi dự án nên để lại một design system rõ ràng hơn một chút so với trước.

Checklist thực tế

Token theo một nguồn sự thật duy nhất, tên semantic và có định nghĩa mode.
Figma variables khớp tên và mode của token.
Mỗi component cốt lõi có mục đích, quy tắc sử dụng, API, ví dụ và ghi chú accessibility.
Guidelines viết bằng Markdown, có một file tổng quan ngắn dẫn tới các file chi tiết.
Code Connect nối các component Figma chính với code.
Công cụ AI có rules hoặc knowledge lâu dài trỏ tới design system.
AI được yêu cầu dùng component có sẵn trước và báo khi tạo thứ mới.
Lint bắt giá trị hard-code; test accessibility và visual chạy tự động.
Có người chịu trách nhiệm và quy trình review cho component và token mới.
Guidelines có version và được cập nhật mỗi lần hệ thống phát hành.

Kết luận

AI không làm design system bớt quan trọng. Nó biến design system thành tài sản thiết kế quan trọng nhất của team. Hệ thống trở thành bản brief mà mọi công cụ AI đọc trước khi dựng bất cứ thứ gì.

Với designer, đó là tin tốt. Những kỹ năng tạo nên một design system mạnh, đặt tên rõ ràng, quy tắc chính xác, chăm chút từng trạng thái và tài liệu tốt, cũng chính là thứ khiến AI trở nên hữu ích thay vì hỗn loạn. Viết hệ thống của bạn đủ rõ để máy hiểu, và thường nó cũng sẽ rõ hơn cho con người.

Nguồn tham khảo

Thông tin được kiểm tra ngày 16/10/2026.

Design system thời AI: Áp dụng xuyên suốt quy trình phát triển sản phẩm