Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa được nhận vào một startup fintech ở Sài Gòn. Sản phẩm có khoảng 80 màn hình. Ngày đầu mở file Figma ra, bạn thấy một mớ hỗn độn: nút "Đăng nhập" ở màn này màu xanh #2563EB bo góc 8px, nút "Tiếp tục" ở màn kia cũng là xanh nhưng lại #1E40AF bo góc 6px, còn nút "Xác nhận" ở luồng thanh toán thì padding lệch 2px. Ba người thiết kế khác nhau, ba thói quen khác nhau, và kết quả là một sản phẩm trông như được ghép từ ba ứng dụng. Đây không phải chuyện hiếm — đây là tình trạng mặc định của mọi sản phẩm khi chưa có một cách tổ chức tư duy chung.
Atomic Design, do Brad Frost giới thiệu năm 2013, chính là lời giải cho mớ hỗn độn đó. Nó không phải một công cụ, không phải một plugin Figma, cũng không phải một thư viện code. Nó là một cách tư duy (mental model) về việc giao diện được cấu thành từ những mảnh nhỏ như thế nào — mượn hình ảnh từ hóa học: vạn vật được tạo nên từ nguyên tử, nguyên tử kết hợp thành phân tử, phân tử tạo nên những cấu trúc phức tạp hơn.
Tại sao bài này quan trọng với bạn? Vì nó là chiếc cầu nối giữa "biết vẽ component" (bài trước) và "xây cả một design system hoàn chỉnh" (các bài sau). Khi bạn nắm được tư duy phân tầng của Atomic Design, bạn sẽ ngừng vẽ từng màn hình rời rạc và bắt đầu xây dựng một hệ thống — nơi sửa một chỗ là cả sản phẩm tự cập nhật. Đây cũng là ngôn ngữ chung giúp bạn nói chuyện với lập trình viên, bởi cách React, Vue hay SwiftUI tổ chức component gần như khớp một-một với năm tầng của Atomic Design.
Khái niệm cốt lõi
Atomic Design chia mọi giao diện thành năm tầng, từ nhỏ đến lớn. Điều quan trọng cần nhớ ngay từ đầu: đây không phải một quy trình tuyến tính kiểu "làm xong tầng 1 mới sang tầng 2". Bạn thường nhảy qua lại giữa các tầng. Nó là một cách phân loại và sắp xếp những gì bạn đã có.
Tầng 1 — Atoms (Nguyên tử)
Atom là đơn vị nhỏ nhất, không thể chia nhỏ thêm mà vẫn còn ý nghĩa thiết kế. Ví dụ: một cái nút (button), một ô nhập liệu (input), một nhãn (label), một icon, một dòng văn bản tiêu đề.
Có một điểm tinh tế: ở tầng atom, người ta còn xếp cả những thứ "vô hình" như màu sắc, font chữ, khoảng cách (spacing) — chính là các design token mà bạn sẽ học sâu ở bài sau. Bản thân một atom đứng một mình thường chưa làm được gì hữu ích — một ô input trống lơ lửng giữa màn hình thì để làm gì? Nhưng nó là viên gạch nền tảng.
Nguyên tắc vàng: atom phải "ngu" (dumb) — nó chỉ biết hiển thị, không chứa logic nghiệp vụ. Nút bấm không cần biết bấm vào nó thì chuyển tiền hay đăng xuất; nó chỉ biết mình trông như thế nào ở các trạng thái default, hover, pressed, disabled.
Tầng 2 — Molecules (Phân tử)
Molecule là sự kết hợp của vài atom để tạo thành một đơn vị có chức năng đơn giản. Ví dụ kinh điển của chính Brad Frost: một ô tìm kiếm = label + input + button. Tách rời ra thì ba atom này chẳng để làm gì, nhưng ghép lại thì có một mục đích rõ ràng: nhập từ khóa và tìm.
Molecule là tầng đầu tiên mà nguyên tắc "làm một việc và làm tốt việc đó" (do one thing well) trở nên rõ ràng. Một form field hoàn chỉnh — gồm label, input, dòng helper text, và message lỗi — cũng là một molecule điển hình.
Tầng 3 — Organisms (Sinh vật/Cơ quan)
Organism là một nhóm molecule và/hoặc atom kết hợp thành một phần giao diện tương đối phức tạp và độc lập về mặt ngữ cảnh. Ví dụ: một header website gồm logo (atom) + thanh navigation (molecule) + ô tìm kiếm (molecule). Hoặc một product card trong trang thương mại điện tử gồm ảnh sản phẩm, tên, giá, nút "Thêm vào giỏ".
Đây là tầng bắt đầu mang "tính thương hiệu" rõ rệt. Hai sản phẩm có thể dùng atom giống nhau (cùng là input, button) nhưng organism — cách họ lắp ráp header, card — sẽ khác biệt và tạo nên bản sắc riêng.
Tầng 4 — Templates (Khuôn mẫu)
Template là nơi bạn sắp xếp các organism vào một bố cục trang cụ thể, nhưng chưa có nội dung thật — chỉ là placeholder. Template trả lời câu hỏi: "Trang này có những khối gì, đặt ở đâu, theo lưới (grid) nào?". Nó tập trung vào cấu trúc bố cục, không phải nội dung. Đây là điểm Brad Frost rời khỏi phép ẩn dụ hóa học để chuyển sang ngôn ngữ thực tế hơn cho web.
Tầng 5 — Pages (Trang)
Page là template được đổ nội dung thật vào: tên người dùng thật, ảnh thật, số liệu thật. Đây là tầng quan trọng để kiểm thử, vì chỉ khi có dữ liệu thật bạn mới phát hiện ra: tên sản phẩm dài 60 ký tự làm vỡ layout, giỏ hàng trống thì card trông kỳ cục, tên người dùng tiếng Việt có dấu làm tràn dòng. Page là nơi lý thuyết va chạm với thực tế.
Mối quan hệ quan trọng nhất
Hãy ghi nhớ: thay đổi ở tầng dưới lan lên tầng trên. Sửa màu của một atom button → mọi molecule, organism, template, page dùng button đó đều đổi theo. Đây chính là sức mạnh của tư duy này: tính nhất quán không còn là kỷ luật cá nhân, mà được "ép buộc" bởi cấu trúc.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT giả định "ChợViệt" gỡ rối 200 phiên bản nút bấm
ChợViệt là một sàn thương mại điện tử giả định ở Hà Nội với 12 designer và 40 lập trình viên. Sau hai năm phát triển nóng, đội QA phát hiện trong sản phẩm có tới 217 biến thể nút bấm khác nhau về màu, bo góc, hoặc kích thước chữ. Khách hàng phàn nàn app "trông thiếu chuyên nghiệp".
Đội thiết kế quyết định áp dụng Atomic Design. Họ bắt đầu từ tầng atom: định nghĩa lại chỉ 5 loại button chuẩn (primary, secondary, ghost, danger, link) với đúng một bộ màu, một bộ bo góc 8px, ba kích thước. Sau đó họ kiểm kê molecule: gom các "ô tìm kiếm", "form field", "price tag" về dạng chuẩn. Cuối cùng họ xây lại các organism quan trọng như product card và header.
Kết quả sau 3 tháng: số biến thể button giảm từ 217 xuống 5. Khi marketing muốn đổi màu thương hiệu cho dịp Tết, designer chỉ sửa atom button trong Figma, và 1.400 chỗ dùng nó tự cập nhật.
Bài học: Atomic Design không sửa được mớ hỗn độn bằng phép màu — nó buộc bạn phải kiểm kê và chuẩn hóa từ tầng nhỏ nhất lên. Đa số nợ kỹ thuật thiết kế nằm ở tầng atom và molecule.
Ví dụ 2 — Startup giao đồ ăn và bài học "đừng tạo organism quá sớm"
Một startup giao đồ ăn ở TP.HCM (gọi là "FoodNow") có một designer junior rất nhiệt tình. Bạn ấy đọc về Atomic Design và lập tức xây một organism khổng lồ tên "RestaurantBlock" gồm ảnh quán, tên, đánh giá, khoảng cách, danh sách 3 món nổi bật, nút yêu thích, và cả banner khuyến mãi — tất cả gói chung thành một component.
Vấn đề xuất hiện ngay tháng sau: trang chủ cần block không có banner; trang tìm kiếm cần block không có 3 món; trang "yêu thích" cần block thu gọn. Organism quá lớn này không tái sử dụng được ở đâu cả, designer phải tạo 4 bản sao chỉnh tay — đúng cái cảnh Atomic Design lẽ ra phải tránh.
Đội senior vào cuộc, tách "RestaurantBlock" thành các molecule nhỏ: RestaurantInfo, RatingBadge, DishChips, PromoBanner. Mỗi trang giờ tự lắp ráp organism từ molecule theo nhu cầu.
Bài học: Sai lầm phổ biến không phải là chia quá nhỏ, mà là gộp quá to quá sớm. Khi nghi ngờ, hãy giữ component ở tầng thấp hơn và linh hoạt hơn. Bạn luôn có thể ghép molecule thành organism, nhưng tách một organism cứng nhắc thì đau đớn hơn nhiều.
Ví dụ 3 — Ngân hàng số và sự đồng bộ Figma–code nhờ ngôn ngữ chung
Một ngân hàng số ở Đông Nam Á (tương tự mô hình Timo, Cake) có đội thiết kế và đội kỹ thuật hay "đá nhau" vì gọi tên component khác nhau. Designer nói "cụm thông báo số dư", developer gọi nó là BalanceWidget, còn tài liệu lại ghi "card tài khoản". Mỗi lần bàn giao là một lần dịch thuật mệt mỏi.
Họ thống nhất dùng từ vựng Atomic Design làm chuẩn chung. Trong Figma, các trang được tổ chức đúng theo Atoms / Molecules / Organisms. Trong code React, thư mục cũng chia atoms/, molecules/, organisms/. Tên component khớp nhau một-một: Button (atom), AmountField (molecule), AccountCard (organism).
Sau khi áp dụng, thời gian bàn giao một tính năng mới (handoff) giảm khoảng 30%, vì hai bên không còn mất thời gian "dịch" tên gọi và phạm vi của từng khối.
Bài học: Giá trị lớn nhất của Atomic Design đôi khi không nằm ở Figma, mà ở chỗ nó tạo ra một ngôn ngữ chung giữa thiết kế và kỹ thuật. Cấu trúc tư duy này gần như khớp trực tiếp với cách lập trình viên tổ chức component.
Hướng dẫn từng bước
Đây là cách áp dụng Atomic Design cho một sản phẩm có sẵn (audit) hoặc một sản phẩm mới.
Bước 1 — Chụp ảnh hiện trạng (interface inventory). Trước khi phân tầng, hãy chụp màn hình tất cả các giao diện hiện có và dán chúng lại với nhau. Brad Frost gọi đây là "interface inventory". Bạn sẽ choáng khi thấy mình có 11 kiểu màu xám và 9 kiểu bóng đổ. Đây là bước bắt buộc, đừng bỏ qua.
Bước 2 — Nhận diện atom. Từ bản kiểm kê, gạch ra mọi đơn vị nhỏ nhất: button, input, label, icon, badge, màu, font. Chuẩn hóa chúng: mỗi loại chỉ giữ lại bộ chuẩn duy nhất. Ở bước này bạn cũng bắt đầu định nghĩa các token màu và spacing.
Bước 3 — Gom atom thành molecule. Tìm những cụm atom luôn đi cùng nhau và phục vụ một chức năng đơn: ô tìm kiếm, form field có label + helper + error, price tag. Đặt tên rõ ràng theo chức năng, không theo hình dáng (đặt SearchField chứ đừng đặt BoxWithButton).
Bước 4 — Lắp molecule thành organism. Xây những khối giao diện độc lập, có thể đặt ở nhiều trang: header, footer, product card, comment block. Giữ organism vừa đủ — nếu thấy nó "ôm" quá nhiều việc, hãy tách ra (nhớ bài học FoodNow).
Bước 5 — Dựng template. Sắp xếp organism vào bố cục trang với placeholder, xác định grid, khoảng cách giữa các khối, thứ tự ưu tiên. Chưa cần nội dung thật.
Bước 6 — Đổ nội dung thật thành page và kiểm thử. Cho dữ liệu thật, đặc biệt là các trường hợp cực đoan: tên tiếng Việt dài có dấu, số tiền lớn, danh sách rỗng, ảnh thiếu. Đây là lúc bạn phát hiện và quay ngược về sửa atom/molecule.
Bước 7 — Tổ chức trong công cụ. Trong Figma, dùng Pages hoặc Sections để chia theo tầng. Đặt tên component theo cú pháp nhất quán (ví dụ Atom/Button, Molecule/SearchField). Sự nhất quán trong đặt tên quan trọng không kém bản thân component.
Lỗi thường gặp & mẹo
Lỗi 1 — Tranh cãi xem cái này là molecule hay organism. Đây là cái bẫy ngốn thời gian nhất. Sự thật: ranh giới giữa molecule và organism đôi khi mơ hồ, và không sao cả. Atomic Design là công cụ tư duy, không phải luật pháp. Nếu cả đội phân vân, hãy chọn một quy ước và đi tiếp; đừng họp 2 tiếng để cãi nhau về tên tầng.
Lỗi 2 — Coi đây là quy trình tuyến tính. Nhiều người tưởng phải làm xong hết atom mới được chạm vào page. Thực tế bạn nên làm song song và lặp đi lặp lại. Thường bạn vẽ một page trước để hiểu nhu cầu, rồi mới "rút" ra atom/molecule từ đó.
Lỗi 3 — Gộp organism quá lớn. Như ví dụ FoodNow: component ôm đồm quá nhiều thì mất khả năng tái sử dụng. Mẹo: nếu một component có hơn 5–6 thuộc tính bật/tắt (boolean props) để xử lý các biến thể, đó là dấu hiệu nó nên được tách nhỏ.
Lỗi 4 — Nhồi logic nghiệp vụ vào atom. Atom phải "ngu". Nút bấm không nên biết nó gọi API nào. Logic thuộc về tầng cao hơn (organism, page). Giữ atom thuần hiển thị giúp tái sử dụng tối đa.
Mẹo — Đặt tên theo chức năng, không theo hình dáng. PrimaryButton tốt hơn BlueButton, vì khi đổi màu thương hiệu sang đỏ thì cái tên BlueButton thành vô nghĩa, còn PrimaryButton vẫn đúng.
Mẹo — Atomic Design không bắt buộc dùng đúng 5 cái tên. Nhiều đội bỏ tầng "template" hoặc đổi tên cho dễ hiểu với người không rành hóa học. Tinh thần phân tầng mới là cốt lõi, không phải cái nhãn.
Bài tập thực hành
Bài 1 — Mổ xẻ một màn hình quen thuộc. Mở app bạn dùng hằng ngày (ví dụ MoMo, Shopee, hoặc Grab). Chọn một màn hình. Chụp lại và chú thích: đâu là atom, đâu là molecule, đâu là organism. Cố gắng tìm ít nhất 5 atom, 3 molecule, 2 organism. Viết tên gọi theo chức năng cho từng cái.
Bài 2 — Xây ô tìm kiếm theo tầng. Trong Figma, tạo các atom: một Input, một Button, một Icon kính lúp. Sau đó ghép thành molecule SearchField. Tạo ít nhất 3 trạng thái cho atom Input (default, focus, error) và quan sát chúng lan lên molecule như thế nào khi bạn đổi atom.
Bài 3 — Phát hiện organism gộp quá to. Lấy lại bài học FoodNow. Tự thiết kế một "product card" cho sàn TMĐT của riêng bạn, rồi liệt kê: card này cần xuất hiện ở những trang nào (trang chủ, tìm kiếm, yêu thích, gợi ý)? Mỗi trang cần card đó khác nhau ra sao? Từ đó, hãy tách card thành các molecule nhỏ và viết một đoạn ngắn giải thích quyết định của bạn.
Bài 4 (nâng cao) — Interface inventory thu nhỏ. Chụp 5 màn hình bất kỳ trong một sản phẩm, dán chung vào một file. Đếm xem có bao nhiêu kiểu button, bao nhiêu màu xám, bao nhiêu bo góc khác nhau. Đề xuất bộ atom chuẩn để gom chúng lại.
Tóm tắt
Atomic Design là một cách tư duy do Brad Frost đề xuất, mượn hình ảnh hóa học để phân loại giao diện thành năm tầng: Atoms (đơn vị nhỏ nhất như button, input, icon, token), Molecules (cụm atom có một chức năng đơn như ô tìm kiếm), Organisms (khối phức tạp độc lập như header, product card), Templates (bố cục trang với placeholder), và Pages (template đổ nội dung thật để kiểm thử).
Sức mạnh cốt lõi nằm ở quan hệ "dưới lan lên trên": sửa một atom là cả sản phẩm tự đồng bộ, biến tính nhất quán từ kỷ luật cá nhân thành thứ được cấu trúc bảo đảm. Nhưng hãy nhớ ba điều: đây là mental model chứ không phải quy trình tuyến tính; ranh giới giữa các tầng đôi khi mơ hồ và điều đó hoàn toàn ổn; và cạm bẫy lớn nhất là gộp component quá to quá sớm, làm mất khả năng tái sử dụng.
Khi bạn nắm vững tư duy phân tầng này, bạn đã sẵn sàng bước vào các bài tiếp theo về xây dựng design system, kiến trúc token, và tài liệu hóa — nơi Atomic Design trở thành xương sống cho cả một hệ thống thiết kế quy mô lớn.