Tổng thể – Atomic Design là gì?
Bạn đã bao giờ nhìn vào một sản phẩm và cảm thấy “cái button này sao khác với cái button ở trang kia”? Hay khi bàn giao file Figma cho Developer, họ hỏi “cái card này dùng padding bao nhiêu, có giống card ở trang chủ không?” và bạn phải mở từng frame ra kiểm tra thủ công?
Đó là triệu chứng của UI được thiết kế theo trang, thành phần, chớ không theo hệ thống.
Atomic Design ra đời để giải quyết đúng vấn đề đó, bằng cách thay đổi cách bạn nhìn về UI từ gốc rễ.
Định nghĩa
Atomic Design là phương pháp tổ chức và xây dựng UI theo 5 cấp độ từ nhỏ đến lớn, lấy cảm hứng từ cấu trúc hóa học: atoms (nguyên tử) kết hợp thành molecules (phân tử), molecules tạo thành organisms (tế bào/cơ quan), organisms lắp vào templates (khung layout), và templates được đổ nội dung thật vào để thành pages (trang hoàn chỉnh).
Tư duy cốt lõi chỉ có một câu: xây hệ thống, không xây trang. Thay vì thiết kế từng page riêng lẻ rồi copy-paste component, bạn xây những viên gạch nhỏ nhất có thể tái sử dụng, rồi lắp ráp chúng lên theo cấu trúc rõ ràng.
Tại sao Atomic Design được tạo ra?
Năm 2013, Brad Frost, một web designer người Mỹ, đang làm việc với một team ở Brooklyn trên dự án redesign cho TechCrunch. Lúc đó, responsive design vừa trở thành tiêu chuẩn mới và mọi người đang vật lộn với một câu hỏi: làm thế nào để thiết kế một UI có thể hoạt động tốt trên mọi kích thước màn hình, mà không tạo ra cả trăm file riêng lẻ?
Trong một buổi sketch, Frost bắt đầu dùng ngôn ngữ hóa học để mô tả cách các thành phần UI liên kết nhau. Atoms. Molecules. Organisms. Ý tưởng bắt đầu hình thành.
Cuốn sách Atomic Design của Brad Frost, xuất bản từ blog post năm 2013 rồi mở rộng thành sách đầy đủ, trở thành một trong những tài liệu tham khảo quan trọng nhất trong ngành design systems. Tư duy này giải quyết một vấn đề mà ngành đang gặp phải: UI ngày càng phức tạp, team ngày càng lớn, nhưng không có ngôn ngữ chung để nói về các “mảnh ghép” của interface.
Ý nghĩa và công dụng
Atomic Design giải quyết vấn đề gì?
Có hai vấn đề lớn nó giải quyết cùng lúc.
Vấn đề thứ nhất là UI inconsistency. Khi mỗi Designer trong team thiết kế theo trang riêng, button ở trang A trông khác button ở trang B, card component có 4 biến thể không ai nhớ hết, và Developer phải hỏi từng cái một. Atomic Design buộc mọi người phải agree trước về các “nguyên tử” rồi mới xây lên – tạo ra tính nhất quán từ gốc.
Vấn đề thứ hai là thiếu shared language giữa Designer và Developer. Khi Designer nói “cái block content ở trang này” và Developer hỏi “block đó là component gì?”, hai người đang dùng hai ngôn ngữ khác nhau. Atomic Design cho cả hai bên một từ vựng chung: atoms, molecules, organisms – và Developer có thể map trực tiếp với component tree trong code.
Nó được dùng nhiều nhất khi xây Design System hoặc khi sản phẩm đủ lớn để cần một UI library tái sử dụng. Không phải phương pháp phù hợp cho mọi dự án, đặc biệt là landing page nhỏ hay prototype nhanh.
Đối chiếu với cách thiết kế theo trang truyền thống:
Cách thiết kế “page-based” truyền thống bắt đầu bằng: mở Figma, tạo frame, thiết kế trang Home, rồi trang About, rồi trang Product. Mỗi trang là một tác phẩm riêng biệt.
Atomic Design đảo ngược thứ tự đó: bắt đầu bằng các thành phần nhỏ nhất, build chúng thành UX pattern có thể tái sử dụng, rồi mới lắp lên thành trang. Trang là output cuối cùng, không phải điểm xuất phát.
UI Kit – Một phần quan trọng trong Design system được xây dựng theo nguyên lý của atomic design
Ai dùng Atomic Design? Ai nhận thành phẩm từ nó?
Trong product team, Atomic Design thường được áp dụng bởi UI Designer hoặc Design System Designer, đặc biệt khi đang xây hoặc maintain một component library. PM thường không trực tiếp tham gia vào việc định nghĩa atoms hay molecules, nhưng là người benefit từ kết quả: feature mới được build nhanh hơn vì không cần design từ đầu.
Developer là người nhận thành phẩm quan trọng nhất của Atomic Design. Một file Figma được tổ chức theo Atomic Design giúp Developer hiểu ngay đâu là reusable component, đâu là layout wrapper, và cách các phần tử liên kết nhau – thay vì phải đọc annotation dài hoặc hỏi Designer từng pixel.
5 cấp độ của Atomic Design
Atoms – nguyên tử
Atoms là đơn vị nhỏ nhất của interface, không thể tách rời thêm mà vẫn giữ được ý nghĩa. Một button, một input field, một label text, một icon, một color swatch – đây là tất cả atoms.
Điểm quan trọng: atom tự thân nó không làm được gì có ý nghĩa với người dùng. Một button rỗng không có context. Nhưng atom là nơi bạn define style cơ bản: font size, color token, border radius, spacing unit. Tất cả quyết định visual ở đây sẽ ảnh hưởng toàn bộ hệ thống phía trên.
Molecules – phân tử
Molecules là kết hợp của 2-3 atoms tạo thành một đơn vị có chức năng rõ ràng. Search bar = input field (atom) + button “Search” (atom) + icon kính lúp (atom). Form field = label (atom) + input (atom) + helper text (atom).
Molecules bắt đầu có ý nghĩa với người dùng. Người dùng không tương tác với “một input” – họ tương tác với “cái ô tìm kiếm” hay “ô nhập email”. Đó là mức molecules.
Organisms – cơ quan
Organisms là các khối chức năng độc lập, phức tạp hơn molecules và có thể đứng một mình trên giao diện. Navigation bar, product card, comment section, footer – đây đều là organisms.
Organisms có thể chứa nhiều molecules, thậm chí có thể lặp lại cùng một molecule nhiều lần (VD: một list gồm nhiều product card). Điểm khác biệt với molecules là organism có thể được đặt vào bất kỳ template nào mà không cần context xung quanh.
Templates – khung layout
Templates là bộ khung layout của một trang, nơi các organisms được đặt vào đúng vị trí. Ở cấp độ này, bạn xác định grid, spacing, hierarchy tổng thể, nhưng chưa có nội dung thật.
Một template có thể là khung “trang sản phẩm” với navigation ở trên, product info bên trái, image gallery bên phải, related products ở dưới – nhưng tất cả vẫn là placeholder. Đây là giai đoạn trong wireframe và layout review.
Pages – trang hoàn chỉnh
Pages là khi templates được đổ nội dung thật vào: hình ảnh thật, text thật, dữ liệu thật. Đây là thứ người dùng cuối nhìn thấy, và là nơi để kiểm tra xem toàn bộ hệ thống có hoạt động tốt trong điều kiện thực tế không.
Pages cũng là cấp độ để stress-test thiết kế: title dài 80 ký tự có bị tràn không? Image thiếu có fallback state không? Đây là lúc bạn phát hiện ra atoms và molecules cần điều chỉnh để handle được edge case.
Ví dụ case thực tế: Shopify Polaris Design System
Shopify xây Design System của họ tên Polaris theo đúng tư duy Atomic Design. Atoms là các color token, typography scale, spacing units được define cẩn thận. Molecules là components như Button, TextField, Badge. Organisms là các phức hợp như ResourceList (danh sách sản phẩm), DataTable, Modal.
Kết quả là bất kỳ Developer hay Designer nào join Shopify đều có thể build feature mới trong ngày đầu tiên bằng cách ghép các component có sẵn, thay vì phải design từ đầu. Theo Design Systems, tư duy “build systems, not pages” này đã trở thành tiêu chuẩn cho hầu hết enterprise product ngày nay.
Trong team nhỏ hơn, cách áp dụng đơn giản hơn: bắt đầu bằng việc audit toàn bộ UI hiện tại, nhóm các component giống nhau lại, define atom-level styles trong Figma Styles hoặc Variables, rồi build component library từ đó. Không nhất thiết phải theo đúng 5 tầng một cách cứng nhắc ngay từ đầu.
Khi nào không nên dùng – và khi nào dễ lạm dụng?
Khi dự án quá nhỏ để cần system
Nếu bạn đang thiết kế một landing page đơn giản hay một prototype để pitch ý tưởng trong 2 ngày, Atomic Design sẽ làm bạn chậm lại không cần thiết. Thời gian define atoms và build component library chỉ có giá trị khi những component đó sẽ được tái sử dụng nhiều lần. Nếu bài toán là “ra nhanh để test”, hãy thiết kế theo trang như bình thường.
Khi team “over-atomize” mọi thứ
Ranh giới giữa atom và molecule không luôn rõ ràng – và đó là điều bình thường. Vấn đề xảy ra khi team cố gắng tách mọi thứ ra nhỏ nhất có thể đến mức phi lý: một “icon với tooltip” trở thành 3 atoms riêng biệt cần maintain riêng. Atomic Design là tư duy, không phải quy tắc cứng. Khi bạn phải giải thích quá nhiều để justify tại sao thứ gì đó là atom chứ không phải molecule, đó là dấu hiệu bạn đang over-engineer.
Khi nhầm Atomic Design với Design System
Atomic Design là phương pháp tổ chức và tư duy – nó chỉ là một trong nhiều cách tiếp cận khi xây Design System. Nhiều team nghĩ rằng “dùng Atomic Design” có nghĩa là đã có Design System. Thực tế, Design System còn bao gồm documentation, governance process, version control, và cách các team khác nhau trong công ty contribute và consume components. Atomic Design giải quyết phần tổ chức component, không giải quyết toàn bộ bài toán.
Khi áp dụng cứng nhắc vào tổ chức file Figma
Một số Designer tổ chức Figma file với 5 page tương ứng 5 tầng Atomic Design, rồi bắt đầu cảm thấy confused khi một component “thuộc về” cả molecule lẫn organism tùy context. Figma có cách tổ chức riêng (components, variants, sections) – đừng ép 5 tầng Atomic Design vào cấu trúc file một cách máy móc. Áp dụng tư duy, không áp dụng nhãn.
Kết luận
Atomic Design thay đổi cách bạn nghĩ về interface: không phải là tập hợp các trang, mà là một hệ thống sống được tạo nên từ những mảnh ghép có thể tái sử dụng và mở rộng. Tư duy này đặc biệt có giá trị khi bạn làm việc trong product team lớn, nơi tính nhất quán và tốc độ delivery đều quan trọng như nhau.
Với Designer đang học hoặc mới bắt đầu, hiểu Atomic Design không chỉ giúp bạn tổ chức file Figma tốt hơn – nó giúp bạn nói chuyện tốt hơn với Developer, contribute được vào Design System, và tư duy về UX pattern một cách có hệ thống. TELOS Academy có khóa học Design System dạy cách xây và maintain component library từ đầu, theo đúng tư duy này.
