Bạn mở Figma, dựng xong Button, Input, Card, Table, gom hết vào một file rồi đặt tên “Design System”. Vài tháng sau, team vẫn làm mỗi màn hình một kiểu, lập trình viên vẫn hỏi “khoảng cách chỗ này bao nhiêu?”, còn người thiết kế mới vào thì không biết dùng component nào cho đúng chỗ. Chuyện này quen lắm, và nguyên nhân thường nằm ở chỗ: bộ component chỉ là một phần nhỏ của Design System.
Bài này đi qua 7 tầng của một Design System hoàn chỉnh, từ nền móng đến trải nghiệm sản phẩm, kèm cách bắt đầu xây từng tầng để bạn áp dụng được ngay.
Vì sao UI Kit chưa đủ cho Design System
UI Kit là nơi lưu những thứ đã thiết kế. Design System thì khác: đó là hệ thống giúp cả team biết cách thiết kế, xây dựng và mở rộng sản phẩm một cách nhất quán. Một bên là kho chứa, một bên là cách làm việc.
Vì vậy hướng đi đúng không phải là “giao diện → component → thư viện”, mà là một chuỗi đi từ gốc lên ngọn:
Foundation → Token → Primitive → Component → Pattern → Template → Experience
Hiểu được chuỗi này, bạn sẽ biết mình đang đứng ở tầng nào và còn thiếu gì.
Tầng 1: Foundations, nền móng của hệ thống
Đây là nơi bạn quyết định “ngôn ngữ thị giác” của sản phẩm: màu sắc, kiểu chữ, khoảng cách, lưới bố cục, biểu tượng, độ nổi (đổ bóng) và độ bo góc. Chưa cần dựng gì cả, chỉ cần trả lời câu hỏi: sản phẩm này trông và cảm giác như thế nào?
Làm tầng này trước vì mọi thứ phía trên đều dựa vào nó. Nếu màu chính đổi mà bạn phải sửa tay ở hàng trăm chỗ, nghĩa là nền móng chưa được đặt cho đàng hoàng.
Tầng 2: Tokens, biến nguyên tắc thành giá trị dùng lại được
Sau khi có nguyên tắc, bạn cần đặt tên và gán giá trị cụ thể cho chúng. Đó chính là Design Token. Ví dụ:
color.primary.500, spacing.16, font.size.heading.lg
Lợi ích lớn nhất là người thiết kế và lập trình viên cùng nói một ngôn ngữ. Thay vì “xanh đậm đậm chút”, cả hai cùng gọi color.primary.500. Muốn đổi giao diện, bạn sửa giá trị ở một nơi và mọi thứ tự cập nhật theo.
Mẹo nhỏ: Đặt tên token theo vai trò (
primary,heading) thay vì theo màu hay kích thước cụ thể. Tên nhưblue-darksẽ trở nên vô nghĩa ngay ngày bạn đổi thương hiệu sang màu khác.
Tầng 3: Primitives, những khối cơ bản nhất
Primitive gồm Text, Icon, Divider, Avatar, Container, Shape và những thứ tương tự. Chúng chưa giải quyết được một bài toán trải nghiệm nào hoàn chỉnh. Một cái Avatar đứng một mình thì chưa giúp người dùng làm được việc gì.
Nhưng chúng là nguyên liệu. Giống như gạch và xi măng, bạn không ở trong đống gạch, nhưng không có gạch thì không xây được nhà. Tầng này cũng là chỗ các token bắt đầu được dùng thật sự.
Tầng 4: Components, có hành vi rõ ràng
Đến đây bạn mới ghép các primitive lại thành những thành phần có hành vi: Button, Input, Dropdown, Navigation, Card, Modal, Date Picker. Mỗi component cần rõ các trạng thái (bình thường, di chuột, đang chọn, bị vô hiệu hóa, báo lỗi) và cách nó phản ứng khi người dùng thao tác.
Đây là tầng mà Design System bắt đầu có ích trực tiếp cho team sản phẩm, và cũng là tầng nhiều người dừng lại rồi tưởng mình đã xong.
Tầng 5: Patterns, bước mà nhiều hệ thống bỏ qua
Nếu component trả lời câu hỏi “trông như thế nào”, thì Pattern trả lời câu hỏi khó hơn: khi nào và bằng cách nào nên dùng component đó?
Các pattern thường gặp gồm Form, Search, Checkout, Onboarding và Data Management (quản lý dữ liệu). Lấy ví dụ Form Pattern: nó quy định nhãn đặt ở đâu, báo lỗi lúc nhập hay lúc bấm gửi, nút chính nằm vị trí nào, cần bao nhiêu trường thì nên chia bước. Cùng là Input và Button, nhưng có pattern thì mọi form trong sản phẩm đều cho cảm giác giống nhau.
Nói gọn lại, Pattern biến các component đơn lẻ thành giải pháp trải nghiệm có thể dùng lại.
Tầng 6: Templates, không phải thiết kế từ con số 0
Template ghép nhiều pattern lại thành cấu trúc của một màn hình hoặc một nhóm trải nghiệm: Dashboard, trang danh sách (Listing), trang chi tiết (Detail), Checkout, trang quản trị (Admin).
Từ tầng này, team không còn phải ngồi nghĩ “trang danh sách thì bố cục thế nào” mỗi lần có yêu cầu mới. Họ lấy template, điều chỉnh nội dung, và dành thời gian cho phần thật sự mới của bài toán.
Tầng 7: Product Experiences, đích đến
Design System không sinh ra để có những component đẹp. Nó tồn tại để tạo ra bốn thứ: trải nghiệm nhất quán, sản phẩm mở rộng được, team làm nhanh hơn, và trải nghiệm người dùng tốt hơn.
Nên khi đánh giá Design System của mình, đừng hỏi “thư viện có bao nhiêu component”. Hãy hỏi “team ra tính năng mới có nhanh và đồng đều hơn trước không?”.
Bắt đầu từ đâu nếu bạn đã có sẵn UI Kit?
Phần lớn người đọc bài này đã có một bộ component, nên mình gợi ý đi ngược từ thứ bạn đang có. Đầu tiên, mở bộ component ra và tìm xem các giá trị màu, cỡ chữ, khoảng cách đang được gõ tay ở đâu. Gom chúng về token, đây là bước ít tốn công nhất mà lợi ích rõ nhất. Sau đó xem các component của bạn có đang dùng chung primitive hay mỗi cái tự làm một kiểu. Cuối cùng, chọn một luồng người dùng lặp lại nhiều nhất trong sản phẩm (thường là form đăng ký hoặc tìm kiếm) và viết thành pattern đầu tiên: dùng component nào, đặt ở đâu, xử lý lỗi ra sao.
Lưu ý: Không cần hoàn thiện tầng này rồi mới sang tầng khác. Nhưng hãy luôn biết tầng dưới của mình đã vững chưa, vì làm pattern trên nền token lộn xộn thì sớm muộn cũng phải làm lại.
Vì sao điều này quan trọng với người làm thiết kế
Người chỉ biết dựng UI Kit thường dừng ở tầng 4. Người hiểu cả 7 tầng nhìn được sản phẩm ở cấp hệ thống: vì sao nó nhất quán, vì sao team làm nhanh, và phải sửa ở đâu khi có gì đó lệch. Với ai muốn phát triển từ Designer lên hướng Design Strategist hay Product Designer, đây là khác biệt đáng kể trong cách tư duy.
Kết
Lần tới khi ai đó khoe “team mình vừa làm xong Design System”, bạn có thể hỏi nhẹ một câu: “Bộ pattern với template đâu rồi?”. Còn với sản phẩm của bạn, thử rà xem mình đang đứng ở tầng nào và tầng nào còn trống nhé. Bạn thấy tầng nào khó nhất khi làm thực tế? Chia sẻ bên dưới cho mình biết!
Để lại một bình luận