Từ một button nhỏ đến cả trang giỏ hàng, giao diện số cũng đang được xây dựng theo cách nguyên tử tạo thành vật chất.
Bạn đã bao giờ mở file Figma và thấy hai button có cùng chức năng, nhưng mỗi cái lại dùng màu sắc và kiểu bo góc khác nhau? Bảng màu không ai kiểm soát và những component được tạo riêng cho từng trang cũng khiến cả hệ thống phình ra rất nhanh. Đến chính đội ngũ thiết kế cũng có thể không nhớ nổi sản phẩm đang có bao nhiêu phiên bản.
Vấn đề càng rõ hơn khi sản phẩm đó phải hoạt động trên điện thoại, máy tính bảng và laptop với đủ kích thước màn hình. Cách thiết kế “từng trang một” (page-based design) dần đuối sức, bởi mỗi màn hình mới lại kéo theo thêm nhiều phần tử cần chỉnh sửa và kiểm soát.
Trong tự nhiên, nguyên tử đứng riêng gần như chưa tạo nên thứ gì có giá trị sử dụng. Nhưng khi hàng triệu nguyên tử liên kết đúng cách, chúng có thể tạo thành cả cơ thể sống. Đến năm 2013, chuyên gia thiết kế web Brad Frost đã mượn chính hình ảnh này để giới thiệu Atomic Design (thiết kế nguyên tử).
Vậy chúng ta sẽ “lắp ráp” một giao diện theo tư duy hóa học như thế nào?
Atomic Design là gì?
Atomic Design là cách phân rã một giao diện phức tạp thành các thành phần từ rất nhỏ đến hoàn chỉnh. Thay vì coi mỗi trang là một thiết kế độc lập, phương pháp này xem giao diện như một hệ thống gồm nhiều component liên kết với nhau.
Điều thú vị là Frost không bắt đầu bằng quy trình hoàn toàn mới, mà quan sát cách nguyên tử (atoms) tạo thành phân tử (molecules), rồi những phân tử phức tạp hơn tạo nên sinh vật (organisms). Ông đưa trật tự đó vào UI, giúp designer và developer cùng nhìn vào thành phần ấy, gọi nó bằng một tên chung và hiểu nó đang nằm ở đâu trong toàn hệ thống.
Vì vậy, giao diện giữ được sự nhất quán nhưng vẫn linh hoạt khi thay đổi. Các component cũng dễ được dùng lại ở nhiều màn hình. Khi có màn hình mới, chúng ta không phải bắt đầu gần như từ đầu.
Khi giao diện không còn được vẽ theo từng trang
Triết lý chính của Atomic Design là thiết kế dựa trên cấu phần (component-driven design). Nhà thiết kế không còn mở Figma và vẽ riêng từng màn hình tĩnh. Họ xây tập hợp các component liên kết chặt chẽ, sau đó ghép chúng vào nhiều màn hình và bối cảnh khác nhau.
Để hệ thống này không sớm “vỡ trận”, có 3 nguyên lý:
Tính kế thừa tuần tiến (progressive inheritance): Về nguyên tắc, cấp độ cao hơn được lắp hoàn toàn từ những cấp độ thấp hơn. Nếu các component được liên kết đúng cách, việc đổi một thuộc tính ở tầng atom sẽ giúp những tầng phía trên tự động đồng bộ theo.
Tách biệt cấu trúc và nội dung: Template giữ phần khung sườn, còn nội dung, dữ liệu và hình ảnh thật được đưa vào sau. Hệ thống được thiết kế để thích ứng với mọi kịch bản dữ liệu, kể cả những trường hợp “khó đỡ” như tiêu đề quá dài hay ảnh có tỷ lệ lạ.
Ngôn ngữ chung: Mục tiêu là quy ước tên gọi và thuộc tính của một button trong Figma trùng khớp với component tương ứng trong React hay Vue. Điều này giúp designer và developer bớt phải “dịch” ý của nhau mỗi khi bàn giao.
Nói cách khác, Atomic Design không chỉ là chuyện giao diện đẹp hay xấu. Nó còn giúp cả đội đứng chung một hệ quy chiếu, khi designer và developer dùng cùng tên gọi, thuộc tính cho từng component.
5 cấp độ của Atomic Design
Mô hình Atomic Design gồm 5 cấp độ, đi từ trừu tượng đến cụ thể: atoms, molecules, organisms, templates và pages.
Atoms (nguyên tử)
Atom là phần nền tảng của hệ thống, không thể chia nhỏ hơn mà vẫn giữ được công năng thiết kế. Trong cách phân loại này, atom gồm những yếu tố phi vật lý như design token (mã màu, khoảng cách, đổ bóng, bo góc), cùng các yếu tố nhìn thấy được như label, input, button và icon.
Atom đứng riêng đôi khi khá… vô dụng. Chẳng hạn ô input trống và thiếu label chỉ dẫn sẽ không cho người dùng biết họ cần nhập gì. Nhưng cũng chính những atom này là nơi định hình toàn bộ phong cách thị giác (visual identity) của sản phẩm.
Molecules (phân tử)
Khi các atom ghép lại, chúng bắt đầu có mục đích sử dụng rõ ràng. Molecule thường chỉ “làm tốt một việc duy nhất” (single responsibility), không ôm nhiều chức năng cùng lúc.
Chẳng hạn thanh tìm kiếm được tạo từ 3 atom: label giúp bạn biết đây là gì, input nhận từ khóa và button kích hoạt lệnh tìm. Ba phần đơn giản ghép lại thành một chức năng hoàn chỉnh. Vì vậy, molecule dễ được dùng lại ở nhiều màn hình.
Organisms (sinh vật)
Organism là component lớn, phức tạp và có thể hoạt động như một cấu phần độc lập, thường đại diện cho một vùng cụ thể trên giao diện. Nó có thể lặp lại nhiều molecule giống nhau, như một Product Grid chứa 10 Product Card, hoặc kết hợp nhiều molecule khác nhau, như một Header gồm Logo, Menu điều hướng và Thanh tìm kiếm.
Templates (bản mẫu)
Đến cấp độ này, hệ thống rời khỏi phép ẩn dụ hóa học và bước vào ngôn ngữ thiết kế thực tế. Template là một khung xương chưa có dữ liệu thật, quy định cách phân bổ thông tin trên màn hình.
Ở cấp template, bạn cần xác định kích thước ảnh, giới hạn số chữ và vị trí các khối chức năng trên từng kích thước màn hình. Vì vậy, câu hỏi template cần trả lời không phải “nội dung ở đây là gì”, mà là “hệ thống sẽ co giãn ra sao khi nội dung thay đổi?”
Pages (trang)
Page là cấp độ cụ thể nhất, khi template được đổ đầy dữ liệu thật, chẳng hạn từ API hay CMS. Đây cũng là lúc bạn thử giao diện bằng những tình huống xảy ra trong thực tế.
Một tiêu đề sản phẩm quá dài có làm tràn dòng? Giỏ hàng trống sẽ trông thế nào so với giỏ hàng đầy? Bên cạnh việc kiểm tra những trường hợp này, page còn là cấp độ để chạy A/B testing và tối ưu hành vi chuyển đổi trên giao diện thật.
Ráp thử một trang giỏ hàng
Để dễ hình dung, chúng ta có thể thử phân rã một giao diện giỏ hàng thương mại điện tử theo đúng 5 cấp độ trên.
Ở tầng atom là những phần nhỏ nhất: icon thùng rác, nút nền đỏ, đoạn text hiển thị giá, ảnh sản phẩm và nhãn tên sản phẩm. Ghép ảnh với tên, ta có molecule “Thông tin sản phẩm”. Nút trừ, số lượng và nút cộng tạo thành “Bộ tăng giảm số lượng”, còn icon thùng rác nằm trong nút đỏ trở thành “Nút xóa nhanh”.
Ba molecule này cộng với phần giá tiền tạo nên organism “Dòng sản phẩm trong giỏ hàng”, nơi xử lý việc hiển thị và chỉnh sửa một sản phẩm. Một organism khác là “Bảng tóm tắt thanh toán”, dùng để gom các dòng tính phí và nút thanh toán.
Template đặt hai organism đó vào bố cục 2 cột: danh sách dòng sản phẩm nằm bên trái, bảng tóm tắt nằm bên phải và được giữ cố định khi người dùng cuộn trang. Đến cấp page, hệ thống nhận dữ liệu của một khách hàng cụ thể, gồm đúng sản phẩm họ đã chọn, đúng số lượng và đúng tổng tiền, sẵn sàng cho nút thanh toán được bấm. Từ một icon thùng rác đến cả trang giỏ hàng hoàn chỉnh, đó là hành trình lắp ráp của Atomic Design.
Atomic Design giúp gì cho một dự án số?
Tái sử dụng: Những phần UI giống nhau không cần được viết lại trên từng trang. Điều này giúp giảm tối đa các đoạn trùng lặp. Mã nguồn có thể nhẹ hơn và trang tải nhanh hơn.
Giữ giao diện đồng bộ: Nếu bạn muốn đổi bo góc của mọi button từ vuông sang tròn, bạn chỉ cần chỉnh thuộc tính tương ứng ở cấp atom. Những component phía trên sử dụng atom đó sẽ được cập nhật theo.
Rút ngắn thời gian phát triển: Khi thư viện component đã đầy đủ, một tính năng mới chủ yếu còn là việc lắp ghép các khối lego có sẵn. Cả đội không cần thiết kế và lập trình lại từ đầu.
Bảo trì dễ hơn: Nếu thanh tìm kiếm gặp lỗi, developer biết ngay cần kiểm tra molecule SearchForm. Họ không phải rà soát hàng nghìn dòng code của cả trang.
Thu hẹp khoảng cách giữa design và code: Figma và Storybook được tổ chức theo cùng một cấu trúc và hệ tên gọi. Vì vậy designer và developer không còn phải “nói hai thứ tiếng”.
Bắt đầu xây design system từ đâu?
Quy trình thực tế thường đi qua 5 bước: UI audit, định nghĩa token, thiết kế và lập trình, viết tài liệu, sau cùng là lắp ghép và thử nghiệm.
Kiểm kê giao diện hiện có: Nếu đang tối ưu một sản phẩm có sẵn, bạn có thể gom toàn bộ button, icon, bảng màu và font chữ đang tồn tại vào cùng một nơi. Kết quả thường thấy là 15 sắc xanh, 20 kiểu button khác nhau, đủ để cả đội nhận ra hệ thống cần được dọn dẹp đến mức nào.
Định nghĩa design token: Những thông số nền tảng như color-primary, spacing-sm hay font-body-regular được đặt tên dưới dạng biến. Điều này giúp màu sắc, khoảng cách và font chữ được áp dụng đồng bộ trong toàn hệ thống.
Thiết kế và lập trình song hành: Phía Figma dựng component cùng những biến thể cần thiết. Mỗi component có các trạng thái Default, Hover, Focus, Active, Disabled. Trong khi đó phía code xây component tương ứng, sao cho props khớp với các lựa chọn đã có trong thiết kế.
Ghi lại tài liệu hướng dẫn: Storybook dành cho developer, còn Zeroheight hoặc một trang nội bộ giúp designer tra cứu cách dùng. Tài liệu cần trả lời được những câu hỏi cụ thể như khi nào dùng Button Primary, khi nào dùng Button Secondary.
Lắp ghép và thử nghiệm với dữ liệu thật: Đừng chỉ đặt những dòng chữ vừa vặn hay hình ảnh có cùng tỷ lệ vào template. Bạn nên thử cả tiêu đề siêu dài, ảnh có tỷ lệ lạ và những dữ liệu biên khác để biết hệ thống chịu được đến đâu.
Những lúc Atomic Design dễ “vỡ trận”
Atomic Design giúp việc tổ chức giao diện rõ ràng hơn, nhưng trong thực tế hệ thống này vẫn có thể “vỡ trận” vì một số lý do.
Molecule hay organism?
Đội thiết kế và lập trình có thể cãi nhau khá lâu để xác định một Product Card là molecule hay organism. Cách đơn giản là xem molecule như một thành phần tối giản, đơn nhiệm, không thể bóc tách thêm mà vẫn giữ được nghĩa, trong khi organism là tổ hợp đa nhiệm và quản lý một vùng giao diện cụ thể.
Tuy nhiên nếu vẫn khó phân định, gọi chung là “component” và phân cấp theo mức độ lồng nhau cũng chẳng sao.
Chia nhỏ quá mức
Tạo quá nhiều atom hay molecule cho những phần chỉ xuất hiện đúng một lần sẽ khiến thư viện ngày một phình to. Điều này cũng làm tăng tải nhận thức cho thành viên mới, bởi họ phải ghi nhớ nhiều component nhưng không phải cái nào cũng thực sự được tái sử dụng.
Một cách xử lý là tái cấu trúc đúng lúc (just-in-time refactoring). Bạn không cần thiết kế hết mọi atom trước khi dựng trang. Có thể bắt đầu từ một vài page chính để quan sát toàn bộ giao diện, rồi phân rã ngược những phần tử đã lặp lại từ 2-3 lần trở lên.
Design và code lệch pha
Designer thay đổi giao diện trong Figma nhưng quên báo developer, hoặc developer tự sửa CSS để kịp tiến độ. Sau nhiều lần như vậy, design system có thể dần “lệch sóng” mà không ai để ý.
Để hạn chế tình trạng này, đội ngũ nên có quy trình duyệt thay đổi ở cấp atom/molecule giữa Lead Designer và Lead Front-end Developer. Bên cạnh đó, đội ngũ có thể tận dụng Figma Variables xuất sang JSON để code tự nạp các giá trị màu sắc, khoảng cách mà không cần gõ lại bằng tay.
Một hệ thống Atomic Design “khỏe mạnh” trông như thế nào?
Atomic Design không dừng ở cách vẽ giao diện. Về cơ bản, đây là một tư duy tổ chức hệ thống. Nếu các cấp độ được liên kết đúng, một button hay ô input nhỏ có thể lớn dần thành một sản phẩm số vận hành trơn tru trên mọi kích thước màn hình.
Muốn biết hệ thống của mình đã “khỏe” hay chưa, hãy kiểm tra xem tên component trong Figma có trùng với tên file trong code. Margin và padding cũng cần dùng chung một bộ spacing token, thay vì mỗi nơi tự đặt một con số khác nhau. Các button, ô input cần có đủ 5 trạng thái Default, Hover, Focus, Active, Disabled. Và quan trọng nhất, hệ thống đã được thử với những dữ liệu “khó ở” như tên sản phẩm siêu dài hoặc giỏ hàng trống chưa?