Design System Tối Thiểu Cho Website Nhỏ: Tokens, Components, States Và Accessibility

Website nhỏ không cần một design system khổng lồ như sản phẩm có hàng trăm màn hình, nhưng vẫn cần một nguồn sự thật chung để màu, font, spacing, button, form và trạng thái không thay đổi tùy từng trang. Design system tối thiểu giúp designer và developer giảm quyết định lặp lại, sửa đồng bộ và mở rộng mà không tạo thêm nợ giao diện.

Bài viết này xây một hệ thống “vừa đủ” cho landing page, website doanh nghiệp, blog, khóa học hoặc cửa hàng nhỏ. Trọng tâm là foundations, tokens, components, states, accessibility và cách bàn giao sang Framer, Webflow hoặc code.

1. Design system tối thiểu gồm những gì?

Lớp	Nội dung
Foundations	Màu, typography, spacing, grid, radius, shadow, icon
Tokens	Tên có nghĩa đại diện cho giá trị thiết kế
Components	Button, input, card, navbar, alert, modal
Patterns	Form, pricing, article, checkout, empty state
Documentation	Khi nào dùng, biến thể, trạng thái, accessibility

Không cần tạo component cho mọi khối chỉ xuất hiện một lần. Chỉ hệ thống hóa phần lặp lại hoặc có rủi ro không nhất quán.

2. Audit giao diện hiện tại

Chụp toàn bộ trang và thống kê:

• Bao nhiêu màu gần giống nhau?
• Bao nhiêu kích thước heading/body?
• Button có bao nhiêu chiều cao, radius và icon?
• Form có label, error và focus giống nhau?
• Card có spacing thống nhất?
• Mobile có dùng cùng hierarchy?

Audit giúp biết vấn đề thật thay vì thiết kế system theo lý thuyết.

3. Xây foundations

Màu

Không đặt tên blue-1 rồi dùng tùy ý. Tách primitive và semantic:

Primitive:
blue-600: #1547E6
red-600: #D92D20
neutral-900: #101828

Semantic:
color-action-primary: {blue-600}
color-text-primary: {neutral-900}
color-feedback-error: {red-600}

Semantic token cho phép đổi brand hoặc dark mode mà không sửa từng component.

Typography

Xác định font family, weight, size, line-height và letter-spacing. Một scale nhỏ thường đủ:

• Display.
• Heading 1–3.
• Body large/regular/small.
• Label/caption.

Không dùng kích thước khác chỉ để “vừa bố cục”; sửa layout hoặc token.

Spacing

Dùng scale dựa trên 4 hoặc 8:

space-1: 4px
space-2: 8px
space-3: 12px
space-4: 16px
space-6: 24px
space-8: 32px
space-12: 48px

4. Grid và responsive

Định nghĩa container max-width, gutter và breakpoint dựa trên nội dung, không dựa riêng thiết bị phổ biến. Component cần quy tắc co giãn:

• Card grid từ 3 cột sang 1 cột.
• Navbar chuyển menu.
• Button full-width trên màn hình hẹp khi cần.
• Table có phương án scroll hoặc chuyển layout.
• Typography scale phù hợp mobile.

5. Tokens trong Figma và code

Variables trong Figma có thể quản màu, số, string và mode. Ở code, dùng CSS custom properties hoặc token pipeline:

:root {
  --color-action-primary: #1547e6;
  --color-text-primary: #101828;
  --space-4: 1rem;
  --radius-md: .75rem;
}

Tên giữa Figma và code nên gần nhau. Nếu designer dùng “Primary Blue” nhưng developer dùng brand-electric-500, việc bàn giao khó kiểm tra.

6. Component anatomy

Mỗi component cần mô tả phần cấu thành. Button gồm container, label, icon trái/phải, loading indicator. Input gồm label, field, placeholder/value, helper text, error icon.

7. Variants không phải duplicate

Button có thể có:

• Hierarchy: primary, secondary, tertiary, destructive.
• Size: small, medium, large.
• Icon: none, leading, trailing, icon-only.
• State: default, hover, focus, active, disabled, loading.

Chỉ tạo variant có use case. Quá nhiều thuộc tính tạo ma trận khó quản.

8. States bắt buộc

Component	States cần xem xét
Button	Hover, focus, active, disabled, loading
Input	Empty, filled, focus, error, disabled, read-only
Data	Loading, empty, error, success, partial
Upload	Idle, progress, success, failed, retry

Happy path không đủ. Nhiều trải nghiệm tệ xuất hiện khi mạng chậm, dữ liệu rỗng hoặc lỗi validation.

9. Accessibility từ component

• Color không phải tín hiệu duy nhất.
• Focus indicator nhìn thấy rõ.
• Touch target đủ lớn.
• Text và icon đạt contrast phù hợp.
• Icon-only button có accessible name.
• Form liên kết label và error.
• Modal quản lý focus và đóng bằng Escape.
• Animation có phương án reduced motion.

Nếu component nền đã accessible, toàn website giảm lỗi lặp lại. Tuy nhiên, context trang vẫn phải kiểm tra.

10. Component đầu tiên nên xây

1. Button và link.
2. Input, textarea, select, checkbox.
3. Typography styles.
4. Container và stack/grid.
5. Card.
6. Navbar/footer.
7. Alert/toast.
8. Modal/drawer nếu thật sự cần.

11. Pattern cho website nhỏ

Pattern kết hợp component thành luồng:

• Hero với CTA.
• Feature grid.
• Pricing table.
• Lead form.
• Article header/body/author.
• Product gallery.
• FAQ accordion.

Pattern có thể linh hoạt nội dung nhưng giữ hierarchy và accessibility.

12. Naming và organization

Foundations/
Components/
  Button/
  Form/
  Navigation/
Patterns/
Templates/
Documentation/

Tên component mô tả vai trò, không mô tả vị trí hiện tại. ProductCard tốt hơn HomepageBox3.

13. Documentation vừa đủ

Mỗi component có:

• Mục đích.
• Khi nào dùng/không dùng.
• Anatomy.
• Variants và states.
• Content rules.
• Accessibility.
• Ví dụ đúng/sai.
• Link code hoặc status triển khai.

14. Governance cho nhóm nhỏ

Không cần hội đồng phức tạp. Chỉ cần:

• Một owner.
• Quy trình đề xuất thay đổi.
• Changelog.
• Version.
• Review định kỳ theo dự án thật.

Component mới chỉ được thêm khi use case không thể giải quyết bằng component hiện có.

15. Definition of Done cho component

• Được dùng ở ít nhất một use case thật.
• Có states.
• Responsive.
• Keyboard và screen reader được xem xét.
• Token, naming và code khớp.
• Có tài liệu.
• Được test trong context sáng/tối nếu có mode.

16. Lộ trình 7 ngày

1. Ngày 1: audit screenshot và inventory.
2. Ngày 2: foundations và tokens.
3. Ngày 3: button, form, typography.
4. Ngày 4: layout, card, navigation.
5. Ngày 5: states và accessibility.
6. Ngày 6: patterns, responsive, code mapping.
7. Ngày 7: tài liệu, changelog, pilot page.

Kết luận

Design system tối thiểu không phải một file Figma để trưng bày. Nó là thỏa thuận giữa thiết kế và triển khai về giá trị, tên, hành vi và trạng thái. Bắt đầu từ phần lặp lại, dùng tokens có nghĩa, xây component đủ states và kiểm tra accessibility. Khi website lớn lên, system có thể mở rộng theo nhu cầu thật.

Đọc thêm bài Thiết kế landing page chuyển đổi cao để áp dụng system vào một trang hoàn chỉnh sau khi draft được xuất bản.

Nguồn tham khảo

• Figma Design Systems
• Material Design 3
• WCAG 2.2 Quick Reference

Phần mở rộng: khung vận hành design system

Bắt đầu từ nhu cầu thật

Hãy mô tả vấn đề người dùng đang gặp trước khi chọn công cụ cho design system. Một quy trình tốt bắt đầu từ đầu ra cần đạt, người chịu trách nhiệm và tiêu chí kiểm chứng. Đừng coi một bảng tính, template hay dashboard là sản phẩm chỉ vì nó trông hoàn chỉnh. Hãy phỏng vấn người dùng, ghi lại bước họ đang làm thủ công, điểm dễ sai và thời điểm họ sẵn sàng trả tiền hoặc quay lại. Những ghi chú này trở thành baseline để đánh giá thay đổi sau này.

Xác định phạm vi

Phạm vi rõ giúp design system không phình to. Viết phần có trong phiên bản hiện tại, phần chưa làm, dữ liệu cần và điều kiện bàn giao. Khi có yêu cầu mới, đặt nó vào backlog thay vì âm thầm thêm vào cam kết cũ. Mỗi mục nên có owner, deadline tương đối và bằng chứng hoàn thành. Cách này bảo vệ chất lượng, thời gian và niềm tin với người dùng.

Thiết kế trải nghiệm

Trải nghiệm của design system cần ít ma sát nhưng vẫn minh bạch. Người dùng phải biết họ đang ở bước nào, nhận được gì, giới hạn nào áp dụng và làm gì khi có lỗi. Dùng ngôn ngữ cụ thể, ví dụ thật và trạng thái rỗng có hướng dẫn. Kiểm tra trên màn hình nhỏ, mạng chậm và tài khoản không có quyền đặc biệt; đó là những tình huống thường tạo ra khiếu nại nhất.

Dữ liệu và cấu trúc

Với token, component, accessibility, documentation, testing và governance, hãy thống nhất tên trường, định dạng ngày, mã phiên bản và cách xử lý dữ liệu thiếu. Không dùng một cột tự do cho nhiều ý nghĩa. Tách dữ liệu người dùng nhập khỏi dữ liệu hệ thống, lưu lịch sử khi cần và đặt quy tắc xóa hoặc lưu giữ. Cấu trúc rõ làm việc tìm kiếm, xuất báo cáo và chuyển giao cho người khác ít rủi ro hơn.

Kiểm chứng trước khi phát hành

Trước khi đưa design system đến khách hàng, tạo một checklist kiểm chứng gồm happy path, dữ liệu biên, quyền sai, lỗi mạng và trường hợp thanh toán hoặc hoàn tiền nếu có. Nhờ một người không tham gia xây dựng làm thử theo hướng dẫn. Các điểm họ dừng hoặc hỏi lại thường là lỗi nội dung, không phải lỗi kỹ thuật, và cần sửa trước khi quảng bá.

Định giá và giá trị

Giá của design system nên phản ánh kết quả và mức hỗ trợ, không chỉ số lượng file hay số giờ làm. Ghi rõ khách hàng nhận gì, cập nhật trong bao lâu, kênh hỗ trợ nào có và điều kiện gia hạn. Nếu có nhiều gói, mỗi gói cần khác nhau về quyền hoặc mức độ đồng hành; tránh tạo ba tên gọi cho cùng một lợi ích.

Quyền và cấp phép

Hãy ghi giấy phép, quyền sử dụng, giới hạn chuyển nhượng và cách ghi công cho mọi tài sản liên quan design system. Không giả định một asset tìm thấy trên Internet là được phép dùng thương mại. Lưu URL nguồn, ngày truy cập, tác giả và phiên bản. Khi không chắc, thay bằng nguồn có điều khoản rõ hoặc xin phép bằng văn bản.

Quy trình cập nhật

Một design system tốt cần lịch cập nhật. Đặt chu kỳ xem lại nội dung, kiểm tra link hỏng, thay ảnh lỗi thời và ghi changelog. Mỗi bản cập nhật nên có số phiên bản, ngày phát hành và mô tả thay đổi. Người dùng cũ cần biết họ nhận được gì; người dùng mới cần thấy sản phẩm còn được chăm sóc.

Hỗ trợ và phản hồi

Tạo một kênh phản hồi duy nhất, phân loại câu hỏi và cam kết thời gian trả lời thực tế. Ghi lại lỗi lặp lại, yêu cầu tính năng và lý do hoàn tiền. Dữ liệu hỗ trợ giúp cải thiện design system tốt hơn nhiều so với đoán ý qua lượt xem. Khi một vấn đề được sửa, thông báo lại cho người đã báo để đóng vòng tin cậy.

Đo lường chất lượng

Đừng chỉ nhìn doanh thu hoặc lượt tải. Theo dõi tỷ lệ hoàn thành, thời gian đến giá trị, số lần cần hỗ trợ, tỷ lệ quay lại, lỗi và churn. Với design system, mỗi chỉ số phải có định nghĩa, nguồn dữ liệu và người sở hữu. Một dashboard ít chỉ số nhưng chính xác hữu ích hơn bảng lớn chứa số liệu không ai hành động.

An toàn và riêng tư

Thu thập dữ liệu tối thiểu, giải thích mục đích và giới hạn quyền truy cập. Không đưa thông tin cá nhân vào ảnh chụp, log hoặc tài liệu công khai. Kiểm tra quyền tải xuống, chia sẻ liên kết và xóa tài khoản. Nếu dùng bên thứ ba, đọc điều khoản lưu trữ và chuẩn bị phương án xuất dữ liệu khi cần.

Bàn giao

Tài liệu bàn giao của design system cần có cấu trúc, nguồn, quyết định đã chốt, việc còn mở và cách khôi phục khi có lỗi. Ghi cả những điều không nên làm. Một người mới phải có thể tiếp quản bằng tài liệu và quyền được cấp, không cần hỏi lại người tạo. Đây là thước đo quan trọng của một hệ thống trưởng thành.

Thử nghiệm có kiểm soát

Khi thử giá, nội dung hoặc luồng mới cho design system, chỉ thay đổi một biến và đặt thời gian đánh giá. Chia nhóm hợp lý, ghi giả thuyết trước khi chạy và tránh kết luận từ vài lượt xem. Nếu kết quả xấu, rollback và ghi nguyên nhân; nếu tốt, cập nhật quy trình chính thức thay vì để thành mẹo truyền miệng.

Kế hoạch rủi ro

Liệt kê rủi ro có xác suất và tác động cao: mất dữ liệu, nguồn bị gỡ, thanh toán lỗi, người dùng hiểu sai, chi phí tăng hoặc người phụ trách vắng mặt. Với mỗi rủi ro, ghi dấu hiệu sớm, hành động giảm thiểu và người có quyền quyết định. Kế hoạch ngắn nhưng cụ thể giúp design system không bị động khi sự cố xảy ra.

Kết luận thực hành

Hãy bắt đầu design system bằng một phiên bản nhỏ, có nguồn rõ, lời hứa vừa sức và cách đo cụ thể. Sau mỗi vòng, dùng phản hồi thật để sửa nội dung, cấu trúc và hỗ trợ. Tốc độ chỉ có ý nghĩa khi chất lượng, quyền sử dụng và khả năng duy trì cùng tăng. Quy trình này tạo nền tảng để mở rộng mà không đánh đổi sự tin cậy.

Token, component và quy trình kiểm thử

Design token nên dùng tên theo vai trò như color-text-primary, surface-panel và space-4 thay vì tên theo giá trị. Tách token nền tảng khỏi token ngữ nghĩa để thay đổi màu hoặc khoảng cách mà không làm mất ý nghĩa. Với website nhỏ, hãy bắt đầu bằng tập token hẹp, có ví dụ và người chịu trách nhiệm. Chỉ thêm token khi một quyết định lặp lại thật sự xuất hiện.

Mỗi component cần anatomy, variant và trạng thái. Button phải có hover, focus-visible, disabled và loading; input phải có label, hint, lỗi và trạng thái chỉ đọc; modal phải có focus trap và cách đóng bằng bàn phím. Component chỉ nên được tái sử dụng khi cả cấu trúc lẫn hành vi tương đồng. Nếu khác mục đích, giữ khác biệt ngữ nghĩa thay vì ép vào một component quá nhiều prop.

Kiểm tra accessibility trong luồng thật: bàn phím, thứ tự focus, zoom, tương phản, thông báo lỗi và nội dung dài trên mobile. Không dùng màu làm tín hiệu duy nhất. Mỗi thay đổi cần ghi lý do, ảnh hưởng, ví dụ trước/sau và component cần cập nhật. Dọn variant trùng, kiểm tra màn hình liên quan và duy trì changelog ngắn. Design system tốt là hệ thống giảm quyết định lặp lại và làm lỗi dễ nhận ra.

Checklist bàn giao design system

Bàn giao cần có bảng token, danh sách component, trạng thái bắt buộc, ví dụ dùng đúng và ví dụ dùng sai. Ghi rõ breakpoint, quy tắc responsive, focus state, nội dung dài và cách xử lý lỗi. Nếu có file thiết kế và mã nguồn, đối chiếu tên token để người nhận không phải dịch thủ công. Một component chưa có trạng thái lỗi vẫn là component chưa hoàn chỉnh, dù giao diện mặc định trông đẹp.

Trước khi chốt, hãy chạy qua các màn hình có mật độ cao và nội dung thật. Kiểm tra text dài, ngôn ngữ khác, ảnh lỗi, tài khoản không có dữ liệu và thao tác bằng bàn phím. Những tình huống này thường làm lộ thiếu sót của system nhanh hơn việc chỉ xem một trang showcase. Ghi issue theo mức độ ảnh hưởng và sửa các lỗi cản trở trước lỗi thẩm mỹ.

Review định kỳ

Mỗi thay đổi trong design system cần được thử trên màn hình thật, nội dung thật và trạng thái lỗi. Hãy chọn một nhóm đại diện gồm trang marketing, form, bảng dữ liệu và mobile. Kiểm tra tương phản, focus, zoom, text dài và tốc độ tải. Nếu một token hoặc component tạo ra nhiều ngoại lệ, đó là tín hiệu cần xem lại mô hình thay vì tiếp tục thêm biến thể.

Tiêu chí đánh giá sau khi triển khai

Sau khi áp dụng quy trình, hãy đánh giá bằng bằng chứng thay vì cảm giác. Ghi lại mục tiêu ban đầu, hành động người dùng cần thực hiện, thời gian hoàn thành, lỗi phát sinh và kết quả đầu ra. Một quy trình chỉ được xem là hiệu quả khi người khác có thể làm theo mà không cần người tạo giải thích riêng từng bước. Nếu kết quả phụ thuộc vào một cá nhân, hãy biến phần kiến thức đó thành hướng dẫn, ví dụ, checklist hoặc trường dữ liệu rõ ràng.

Hãy chia review thành ba lớp. Lớp đầu kiểm tra chất lượng đầu ra và mức độ đúng ngữ cảnh. Lớp hai kiểm tra quyền, nguồn, phiên bản, dữ liệu và khả năng truy vết. Lớp ba kiểm tra trải nghiệm trên mobile, lỗi mạng, nội dung dài và trạng thái không có dữ liệu. Mỗi lớp cần một người chịu trách nhiệm và một tiêu chí pass/fail. Những lỗi nhỏ nhưng lặp lại nên được ưu tiên vì chúng tạo ra chi phí hỗ trợ lớn.

Cách cải tiến qua từng vòng

Không nên thay đổi quá nhiều biến cùng lúc. Chọn một giả thuyết, thử trong phạm vi nhỏ, đo trong khoảng thời gian đủ dài rồi ghi quyết định. Nếu thử nghiệm không đạt, rollback và nêu nguyên nhân; nếu đạt, cập nhật tài liệu chính thức. Changelog giúp người dùng hiểu thay đổi, còn nhật ký quyết định giúp đội ngũ không lặp lại cùng một tranh luận. Khi quy mô tăng, hãy chuyển các mẹo cá nhân thành quy tắc có thể bàn giao.

Cuối mỗi vòng, đặt câu hỏi: điều gì đang tạo giá trị thật, điều gì chỉ làm hệ thống lớn hơn, rủi ro nào chưa được kiểm tra và bằng chứng nào còn thiếu? Cách làm này giữ cho nội dung, workflow và tài sản liên quan luôn rõ ràng, có thể bảo trì và đáng tin cậy trong thực tế.

Ghi lại kết quả kiểm thử và người chịu trách nhiệm cho từng thay đổi để việc bảo trì không phụ thuộc vào trí nhớ cá nhân.