Atomic Design là gì? 5 cấp atom→page và áp dụng

Brad Frost đề xuất Atomic Design năm 2013 với ẩn dụ hoá học: chia mọi giao diện thành 5 cấp xếp tầng — atom nhỏ nhất (button, input), molecule là cụm 2-5 atom (search box), organism là section độc lập (header, product card), template là wireframe placeholder, page là template điền data thật. Bài giải thích từng cấp với ví dụ shop online VN, map sang Figma/code, so sánh Component-Driven Development, và 3 case KHÔNG nên ép Atomic Design.

Phương pháp luận và ẩn dụ hoá học của Brad Frost

Brad Frost giới thiệu Atomic Design qua bài blog tháng 6/2013, sau đó mở rộng thành sách online miễn phí tại atomicdesign.bradfrost.com. Trước thời điểm đó, designer thường tổ chức UI theo lối page-based — mỗi trang là một file Photoshop riêng.

Atomic Design đề xuất tư duy bottom-up: xây block nhỏ nhất trước, ghép dần lên thành interface hoàn chỉnh — thay vì copy-paste cross-page gây inconsistency.

Ẩn dụ hoá học ánh xạ vào UI

Cấu trúc vật chất chia ra nguyên tử, phân tử, sinh vật — Brad Frost mượn nguyên cấu trúc này để mô tả UI. Mỗi cấp UI tương ứng một bậc trong tự nhiên, dễ ghi nhớ và dễ trao đổi giữa designer với dev.

Atoms: đơn vị nhỏ nhất không thể chia — hydrogen, oxygen trong hoá học; button, input, label trong UI.
Molecules: ghép 2-5 atom thành đơn vị chức năng — H2O gồm 2 hydrogen + 1 oxygen; search box gồm input + button + icon.
Organisms: tập hợp molecule + atom thành section có chức năng độc lập — header, product card, sidebar filter.
Templates: wireframe cấp trang chứa các organism với placeholder cho content thật.
Pages: template điền data thật từ database — đây là thứ user thực sự nhìn thấy.

Giá trị cốt lõi nằm ở tư duy hệ thống

Ẩn dụ này có hạn chế nhưng giá trị cốt lõi là chuyển tư duy từ thiết kế trang sang thiết kế hệ thống. Khi team nghĩ về UI dưới dạng atom + molecule tái sử dụng, ngầm họ đang xây design system mà không cần biết khái niệm chính thức.

Atomic Design vì thế là cánh cổng dễ vào nhất cho team mới tiếp cận design system. Cấp atom đặc biệt gần với khái niệm design token — nơi token được consume đầu tiên qua CSS variable.

Atoms — đơn vị nhỏ nhất không thể chia tiếp

Atoms là building block cơ bản nhất, một mình không có nhiều nghĩa nhưng là nền tảng cho mọi cấp trên. Trong UI thực tế, atoms thường gồm 4-6 nhóm chính.

4 nhóm atom phổ biến trong shop online VN

Phân loại atom theo function giúp team dễ tìm và dễ maintain. Bộ atom shop online VN thường rơi vào khoảng 20-30 cái cho shop trung bình, chia đều 4 nhóm dưới.

Form element nguyên thuỷ: button, input, label, checkbox, radio, select — wrap HTML primitive với class CSS.
Typography element: heading H1-H6, paragraph, link — định danh font-size, line-height theo token.
Visual primitive: color swatch, icon, divider, spinner, skeleton placeholder — render độc lập không phụ thuộc atom khác.
Semantic atom: badge (sale -20%, hot, new), tag, avatar đơn — wrap visual + 1 ý nghĩa.

3 đặc điểm của atom đúng chuẩn

Một atom đúng phải tách bạch với cấp trên về responsibility. Khi atom phình ra business logic, nó trở thành molecule mà không nhận ra.

Không có state phức tạp: atom chỉ có visual variant (size, color, shape), không có internal state lưu data.
Không phụ thuộc atom khác: có thể render độc lập trong Storybook story mà không cần wrap container.
Không có business logic: Button atom không biết click sẽ gọi API gì — đó là việc của molecule/organism wrap nó.

Atom là nơi consume design token đầu tiên

Atom là lớp gần gũi nhất với design token. Button atom thường có CSS như background var –color-primary, padding var –spacing-sm.

Đổi token một lần, mọi atom và cấp trên tự cập nhật — token và atom là 2 lớp foundation phải build chắc trước khi lên cấp cao hơn.

Molecules — ghép 2-5 atom thành đơn vị chức năng

Molecules là cấp đầu tiên có chức năng rõ ràng. Không chỉ visual mà thực sự làm 1 việc cụ thể — đây là cấp team thường thấy lợi ích design system rõ nhất.

Search-box molecule gồm Input atom + Button atom + Icon atom. Có chức năng user nhập từ khoá rồi submit, có thể đặt ở header, ở sidebar filter, ở empty state.

Một site shop có thể có 4-6 chỗ dùng search-box. Tách thành molecule, chỉ build 1 lần, mọi nơi consume — refactor 1 chỗ tự cập nhật toàn site.

6 molecule phổ biến cho shop online

Mỗi molecule sau đây xuất hiện 3-10 lần trên nhiều shop trung bình. Tách thành abstraction giúp giảm code duplication so với inline mỗi nơi.

price-tag: Label “Giá” + value lớn + currency “đ” + nếu có sale thì kèm giá cũ gạch ngang.
quantity-selector: Button “−” + Input number + Button “+”.
rating-stars: 5 Icon star + Label số rating.
add-to-cart: Icon cart + Label “Thêm giỏ” + loading state.
breadcrumb-item: Link + Icon “>” cho separator.
form-field: Label + Input + Helper text + Error message.

Quy tắc 5±2 atoms cho mỗi molecule

Molecule không nên có 7+ atom — sẽ trở nên rigid và khó đặt tên chính xác. Khi thấy molecule phình to, tách thành 2 molecule nhỏ hơn hoặc nâng lên cấp organism.

Boundary giữa molecule và organism là cụm có 1 chức năng rõ và đủ nhỏ để tái dùng. Nếu cụm UI đã có nhiều logic như cart-mini hiện danh sách N item với total và checkout button thì đã là organism vì chứa nhiều molecule cộng layout.

Organisms — section có chức năng tự thân

Organisms là khúc lớn của UI, ghép nhiều molecule + atom + có khi nested organism khác. Mỗi organism là một section trên trang có chức năng tự thân, có thể tái sử dụng cross-page.

Organism phổ biến nhất là site-header gồm logo (atom) + nav menu (molecule link list) + search-box (molecule) + mini-cart (molecule) + user-menu (molecule với avatar + dropdown).

Header có 4 chức năng: navigation toàn site, search global, hiển thị cart count, login/logout. Tái sử dụng cho mọi page trừ checkout — checkout thường có header rút gọn riêng.

6 organism phổ biến trong shop online

Mỗi organism dưới đây có thể tái sử dụng cross-page với props khác nhau. Đây là cấp team cần kỷ luật abstract — quá detail thành rigid, quá generic thì mỗi nơi consume phải override CSS.

product-card: image + title + price-tag + rating-stars + add-to-cart.
product-grid: lặp product-card N lần với layout grid responsive.
filter-sidebar: collection filter molecule + chip molecule + sort dropdown.
cart-summary: list item + subtotal + shipping + total + checkout button.
checkout-form: multi-step form với address + shipping + payment.
footer: link grid + social + bản tin email signup.

Quy tắc Web22 phân biệt molecule và organism

Boundary mơ hồ là pain point lớn nhất khi áp dụng Atomic Design. Quy tắc Web22: cụm cần data từ API (reviews-list gọi API) là organism, chỉ render từ props là molecule.

Giúp team consistent, tránh tranh cãi.

Templates và Pages — layout so với data thật

Templates và Pages là 2 cấp cao nhất, khác biệt chính là data. Template là wireframe có placeholder lorem ipsum hoặc ô xám, page là template điền data thật từ database.

Templates định nghĩa layout cấp trang

Template collection-page định nghĩa: header trên cùng, breadcrumb, page title, filter sidebar trái 25% width, product grid 75% width, pagination, footer. Mọi collection (áo nam, áo nữ, giày, túi) dùng cùng template này.

Template không quan tâm content cụ thể, chỉ quan tâm cấu trúc. Đây là nơi designer và dev align về layout trước khi nghĩ về data — bỏ qua cấp này dễ rơi vào trường hợp design chỉ work với happy path.

Pages là template với data production thật

Page /danh-muc/ao-nam dùng template collection-page với title=”Áo nam”, filter các attribute áo nam (size, color, brand), grid 200 product áo nam thật từ DB, breadcrumb “Trang chủ > Áo nam”.

Page là thứ user thực sự nhìn thấy và search engine crawl. Khoảng cách từ template tới page là khoảng cách từ design tới production — test template kỹ giúp page hoạt động ổn định khi data thay đổi.

Vì sao không nên skip cấp Templates

Một số dev team skip cấp Templates vì thấy redundant với Pages. Brad Frost giữ cấp này vì lý do testing edge case data trước khi chạm production.

Empty state: template test với 0 product để verify layout không vỡ.
Full data: 200 product có pagination để check spacing và overflow.
Variant content: title dài 80 ký tự gây wrap line — bắt được bug truncate sai.
Different language: tiếng Anh dài hơn Việt 30% — test responsive sớm.

Áp dụng Atomic Design vào Figma và code song song

Tổ chức file Figma theo Atomic Design giúp designer dễ navigate và component dễ maintain. Phía code mirror cấu trúc Figma 1-1 để designer và dev nói cùng vocabulary.

Cấu trúc Figma file Design System

Cấu trúc phổ biến: 1 Figma file Design System chia 5 page tương ứng 5 cấp, cộng 1 page Foundation chứa token, 1 page Icon chứa icon set.

Trong page Atoms tạo component với variant property. Button có property Variant (primary/secondary/ghost/danger), Size (sm/md/lg), State (default/hover/active/disabled/loading), Icon (none/leading/trailing/only) — Figma tự gen variant matrix.

Page Molecules dùng instance atom đã có

Quan trọng: dùng instance của atom, không detach, để khi atom update molecule tự cập nhật. Đặt tên molecule theo chức năng: SearchBox, PriceTag, QuantitySelector.

Đặt trong frame có name Molecules/[Type]/[Name] để Figma cô lập navigate dễ. Tương tự cho Organisms, Templates, Pages — mỗi cấp ghép từ instance cấp dưới.

Phía code mirror cấu trúc Figma

Folder src/atoms/Button/, src/molecules/SearchBox/, src/organisms/SiteHeader/, src/templates/CollectionPageTemplate/, src/pages/CollectionPage/. Mỗi component file kèm Storybook story và unit test.

Chi tiết quy trình xây Figma DS xem cách xây design system trong Figma. Mapping code 1-1 với Figma tận dụng tối đa sức mạnh component instance — đổi atom Button một lần tự cập nhật trên 100+ molecule và organism dùng.

Atomic Design so với Component-Driven Development

Sau 2018, cộng đồng frontend chuyển dần sang Component-Driven Development (CDD) phổ biến qua Storybook và pattern micro frontend. CDD và Atomic Design overlap nhiều nhưng có khác biệt quan trọng.

CDD focus quy trình build-test isolated

CDD focus vào quy trình: build component isolated trong Storybook trước, test edge case, sau đó compose thành page. Không bắt buộc 5 cấp xếp tầng cụ thể như Atomic Design.

CDD cho phép flat structure — mọi component đều “component”, không phân atom/molecule/organism. Pragmatic hơn cho codebase lớn nơi việc phân loại 5 cấp gây tranh cãi giữa team.

DS modern 2026 dùng flat CDD structure

Đa số DS modern năm 2026 (Shadcn/ui, Radix UI, Mantine, Material UI) dùng CDD flat structure. Chỉ chia component theo functional category, không theo 5 cấp Atomic.

Form Components: Button, Input, Select, Checkbox, Radio.
Overlay: Modal, Drawer, Popover, Tooltip.
Data Display: Table, Card, Badge, Avatar.
Navigation: Tabs, Breadcrumb, Pagination, Menu.
Phản hồi: Alert, Toast, Spinner, Skeleton.

Kết hợp Web22 áp dụng cho khách

Atomic Design vẫn giá trị như mental model giáo dục — đặc biệt cho team mới làm DS lần đầu. Web22 thường dùng Atomic Design ở giai đoạn audit và planning ban đầu để categorize UI element hiện có.

Sau đó switch sang flat CDD structure khi implement code thực tế. Kết hợp này tận dụng ưu điểm cả 2: Atomic giúp thinking in systems, CDD giúp shipping fast.

Chi tiết về Storybook tham khảo storybook.js.org để xem pattern story-driven hiện đại.

Phê bình và 3 trường hợp KHÔNG nên ép Atomic Design

Atomic Design không phải silver bullet. Sau nhiều năm áp dụng, cộng đồng frontend chỉ ra 3 hạn chế lớn cần biết để áp dụng đúng ngữ cảnh.

Hạn chế 1: 5 cấp quá rigid cho project nhỏ

Project có 10-15 component (trang tiếp thị, blog, landing page đơn vị), việc phân atom/molecule/organism gây overhead nhiều hơn lợi ích. Team tốn thời gian tranh luận “Card là molecule hay organism” thay vì ship feature.

Cho project nhỏ, dùng flat structure hoặc 2 cấp (atom + composed) là đủ. Atomic Design dành cho project có 30-100 component và cần categorization để document.

Hạn chế 2: boundary mơ hồ giữa molecule và organism

Brad Frost không có quy tắc cứng cho boundary này, dẫn đến mỗi team tự định nghĩa khác nhau. Cùng một search bar có dropdown autocomplete — team A xếp molecule, team B xếp organism.

Tranh cãi này không tạo giá trị, chỉ làm chậm. Web22 đặt quy tắc “có API call = organism” để team consistent, nhưng quy tắc này không có trong sách gốc của Brad Frost.

Hạn chế 3: không cover state management và data flow

Atomic Design chỉ nói về visual hierarchy, không address: component nào fetch data, component nào dùng global state, component nào local state. Modern frontend cần phân biệt smart components (kết nối data) vs dumb components (chỉ render từ props).

Atomic không có vocabulary cho điều này. Khắc phục bằng cách adapt Atomic thành 3 cấp đơn giản: primitives (atoms), components (molecule + organism gộp), composed (template + page gộp) — giảm ambiguity đáng kể.

Khi nào nên áp dụng và khi nào skip Atomic Design

Sau đánh giá ưu nhược, dưới đây là 4 trường hợp Atomic Design hữu ích nhất và 2 trường hợp nên skip để tránh over-engineering.

4 trường hợp Atomic Design phát huy giá trị

Atomic Design có 4 use case rõ ràng cho team Việt Nam mid-size. Ngoài 4 case này, methodology gây friction nhiều hơn benefit.

Team mới làm DS lần đầu: cần khung tư duy có cấu trúc — Atomic là entry point dễ nhất.
Project có 30-100 component: cần categorization để document và navigate.
Team mix designer + dev: shared vocabulary atom/molecule/organism là language chung dễ hiểu.
Viết docs DS giáo dục cho non-technical: ẩn dụ hoá học dễ minh hoạ hơn primitive vs composite.

2 trường hợp nên skip Atomic Design

Atomic Design không phù hợp cho mọi project. Hai case dưới đây nên dùng flat CDD structure thay vì ép 5 cấp.

Project nhỏ dưới 15 component: 5 cấp overkill, dùng flat structure phân theo functional category.
Team đã mature về DS: chuyển sang CDD và Storybook-first workflow, 5 cấp gây friction so với functional category.

Lộ trình Web22 tư vấn khách hàng

Web22 tư vấn khách bắt đầu với Atomic Design ở giai đoạn 1 audit + foundation, sau 3-6 tháng evaluate. Refactor sang flat CDD nếu thấy categorization gây tranh cãi.

Chi tiết về sổ tay phong cách vs design system giúp phạm vi đúng.

Câu hỏi thường gặp

Atomic Design có bắt buộc khi xây design system không?

Không bắt buộc. Atomic Design là 1 trong nhiều phương pháp luận tổ chức UI — alternative gồm Component-Driven Development (CDD), Functional CSS approach (Tailwind utility), hoặc flat structure tự định nghĩa.

Đa số DS hiện đại 2026 (Shadcn, Radix Themes, Mantine) dùng flat structure không theo Atomic. Bắt đầu với phương pháp nào team thấy thoải mái nhất, có thể đổi sau khi grow.

Trong Figma nên đặt tên frame theo “Atom/Button” hay “Components/Button”?

Cả 2 đều OK, miễn consistent toàn file. Pattern Atom/Button phù hợp khi áp dụng Atomic strict, dễ filter bằng search “Atom/” để xem all atoms.

Pattern Components/Button phù hợp khi áp dụng CDD flat. Web22 thường recommend Components/[Category]/Button với category là functional (Form, Overlay, Navigation) — kết hợp ưu điểm cả 2 approach.

Có thể có Pages mà không có Templates trong Atomic Design không?

Có nhưng không recommend. Skip template tier khiến mockup mất 1 layer test edge case như data dài, empty state, loading state.

Hệ quả: design chỉ work với happy path, production runtime gặp data lệch là vỡ layout.

Brad Frost giữ template tier vì lý do này. Nếu muốn gọn, gộp template vào page nhưng phải đảm bảo mock 3-5 data variant cho mỗi page để cover edge case.

Atomic Design áp dụng được cho mobile native iOS/Android không?

Có, ẩn dụ hoá học không phụ thuộc platform. iOS dùng SwiftUI component (Atom: Text, Button, TextField; Molecule: SearchField cluster), Android Jetpack Compose tương tự.

Pattern hierarchy giống hệt web. Khác biệt chính: mobile native ít cấp template/page (vì navigation hệ điều hành quản lý), thường stop ở organism.

Pattern phổ biến cho mobile là 3 cấp atom + molecule + organism, skip template + page.

WordPress với block editor có support Atomic Design không?

Có, mỗi WordPress block có thể coi là một component theo Atomic. Block đơn (paragraph, button, image) = atom.

Block group (search form = search input + button) = molecule. Block pattern (hero section) = organism.

Block template = template tier.

Pattern này hoạt động native trong WordPress 6+ với Full Site Editing, không cần addon. Tham khảo component library là gì để hiểu cách layer code đứng sau Atomic Design.

Web22 thường tư vấn áp dụng Atomic Design ở giai đoạn audit và foundation cho khách mới làm design system, sau đó tuỳ scale có thể chuyển sang flat CDD structure. Tham khảo Dịch vụ thiết kế UI/UX chuẩn doanh nghiệp tại Web22 với phạm vi build foundation token + component library 4-12 tuần.