Atomic Design & Design System

Atomic design là gì — và vì sao người viết yêu cầu cũng cần hiểu nó

Atomic design là một cách chia giao diện thành những phần nhỏ ghép lại được, theo năm cấp độ: atom (nguyên tử), molecule (phân tử), organism (cơ thể), template (khuôn trang) và page (trang thật). Cách gọi này được Brad Frost phổ biến từ khoảng năm 2013, mượn hình ảnh hoá học: thứ phức tạp được ghép từ vài loại hạt cơ bản. Ý tưởng chia giao diện thành component không mới với kỹ sư front-end, nhưng atomic design cho thiết kế, kỹ sư và người làm sản phẩm một bộ từ vựng chung để nói về cùng một thứ.

Vì sao PM, PO, BA cần biết, không chỉ designer? Vì phần lớn chi phí của một giao diện thiếu nhất quán phát sinh từ phía sản phẩm. Mỗi spec vẽ lại một màn hình mới; mỗi màn hình mới sinh thêm một kiểu nút; mỗi kiểu nút là một chỗ phải test, phải sửa khi đổi thương hiệu, và một chỗ người dùng phải học lại. Người viết yêu cầu là người quyết một màn hình được "ghép từ những gì đã có" hay "vẽ từ đầu". Nếu bạn không biết đội đang có những gì, bạn sẽ mặc định chọn vẽ từ đầu.

Kỹ năng này đi tiếp từ Wireframing & Prototyping Basics. Wireframe trả lời "màn hình này có những khối gì, sắp thế nào"; atomic design trả lời "các khối đó lấy từ đâu, và lần sau dùng lại thế nào". Wireframe tốt nhất là wireframe được vẽ bằng chính những thành phần đội đã có.

Năm cấp độ, minh hoạ trên ứng dụng ChợGần (giả định)

Bối cảnh (giả định): ChợGần là sàn thương mại điện tử bán đồ gia dụng và thực phẩm khô cho khoảng 1,2 triệu người mua ở các tỉnh phía Bắc, có ứng dụng iOS, Android và web. Sau bốn năm, 9 người làm sản phẩm và 22 kỹ sư đã xây hơn 180 màn hình. Mọi con số dưới đây là giả định để minh hoạ.

Ranh giới giữa các cấp không cần chính xác. Bộ chọn số lượng là molecule hay organism? Câu trả lời không quan trọng bằng việc cả đội gọi nó cùng một tên và chỉ có một phiên bản. Dùng năm cấp độ như một cái kệ để sắp đồ, không phải như luật.

Cấp page hay bị bỏ qua nhất khi viết yêu cầu, dù đó là nơi lỗi thật xuất hiện. Thẻ sản phẩm đẹp trong bản thiết kế với tên ngắn "Chảo chống dính 26cm" sẽ vỡ dòng khi gặp tên thật "Chảo chống dính đáy từ vân đá 26cm tặng kèm xẻng gỗ, dùng được bếp từ". Template chứng minh bố cục đúng; page chứng minh nó chịu được dữ liệu thật. Tiêu chí chấp nhận nên có ít nhất một dòng cho dữ liệu xấu nhất.

Vì sao đáng đầu tư một design system

Design system là bộ thành phần dùng chung (thường tổ chức theo atomic design), cộng với design token, tài liệu hướng dẫn dùng, và một quy trình để thêm, sửa, bỏ thành phần. Bốn lợi ích dưới đây là lý do bạn nên ủng hộ nó trong buổi lập kế hoạch — và cũng là bốn thứ bạn nên đo.

Cái giá cần nói thẳng: design system tốn người. Ở ChợGần, ước tính ban đầu là một designer và hai kỹ sư front-end dành khoảng nửa thời gian trong hai quý, sau đó một người giữ thường trực. Nếu sản phẩm còn đang tìm thị trường, tuần nào cũng xoay hướng, chi phí đó thường chưa đáng — một bộ thành phần nhỏ và một file màu dùng chung là đủ. Hệ thống đáng đầu tư khi bạn đã có nhiều màn hình, nhiều đội cùng sửa giao diện, và thấy rõ chi phí của sự trùng lặp bằng số.

Từ bản thiết kế đến code: component và design token

Mỗi thành phần trong file thiết kế nên có đúng một component tương ứng trong code, cùng tên, cùng các biến thể. Khi tên khác nhau — designer gọi là "Thẻ sản phẩm nhỏ", code gọi là ItemCardV2 — mỗi lần trao đổi lại mất một bước dịch, và sớm muộn sẽ có người dịch sai. PM và BA hưởng lợi trực tiếp: một tên dùng được trong spec, trong ticket, trong buổi review và trong báo lỗi.

Design token là những giá trị thiết kế nhỏ nhất được đặt tên: màu, khoảng cách, cỡ chữ, bo góc, đổ bóng. Thay vì viết thẳng mã màu #F26B1D ở 60 chỗ, mọi chỗ dùng tên color.action.primary. Đổi màu thương hiệu thì đổi một dòng. Token thường chia ba lớp:

Ba nhóm token người làm sản phẩm nên đọc được:

• Màu — đặt theo ý nghĩa (hành động chính, nguy hiểm, thành công, chữ phụ), không theo tên màu. "Dùng màu cam" là chỉ dẫn yếu; "dùng màu cảnh báo" vẫn đúng khi thương hiệu đổi sang xanh.
• Khoảng cách — một thang cố định, thường là bội số của 4 hoặc 8 (4, 8, 12, 16, 24, 32). Khi khoảng cách chỉ được chọn trong thang, giao diện tự thẳng hàng và kỹ sư không phải hỏi "cách 14 hay 15 pixel".
• Chữ — vài kiểu chữ đặt tên theo vai trò: tiêu đề trang, tiêu đề khối, nội dung, chú thích, giá tiền. Tiếng Việt có dấu chồng nhiều tầng, nên chiều cao dòng phải được thử với chữ như "Ưu đãi Tết" và "HỖ TRỢ KHÁCH HÀNG", không chỉ với chữ Latin không dấu.

Bạn không cần tự viết token. Bạn cần đọc được chúng trong spec và trong thảo luận, và nhận ra khi một yêu cầu đòi một giá trị nằm ngoài hệ thống — "chữ đỏ đậm hơn một chút cho dòng khuyến mãi" — để hỏi: đây là token mới cho cả hệ thống, hay một ngoại lệ chúng ta không cần?

Kiểm kê giao diện: bắt đầu từ những gì đang có

Interface inventory (kiểm kê giao diện) là bước đầu tiên khi áp dụng atomic design cho một sản phẩm đã chạy: chụp lại mọi thành phần đang có, gom theo loại, xếp theo cấp độ, và đếm số biến thể. Mục đích không phải làm tài liệu đẹp, mà là cho mọi người cùng nhìn thấy mức trùng lặp. Một slide ghi "giao diện chưa nhất quán" không thuyết phục được ai; một trang đặt 14 kiểu nút cạnh nhau thì có.

Khi ChợGần kiểm kê lần đầu hai luồng mua hàng và sau mua, đội đếm được 14 kiểu nút, 9 bộ chọn ngày khác nhau (ngày giao hàng, lọc đơn theo ngày, ngày sinh, lịch lắp đặt, kỳ hạn trả góp...), 6 kiểu thông báo lỗi và 4 cách viết giá. Không ai cố ý thiết kế 9 bộ chọn ngày; mỗi cái ra đời hợp lý trong một sprint riêng, vì người viết spec không biết cái trước đã tồn tại.

Kết quả không phải một bản tài liệu mà là một danh sách việc: mỗi biến thể được quyết giữ, gộp hay bỏ, và năm đến bảy thành phần được chọn chuẩn hoá trước, có chủ. Làm theo từng bước trong hướng dẫn Kiểm kê giao diện theo atomic design, và ghi kết quả vào mẫu Bảng kiểm kê giao diện.

Viết spec và tiêu chí chấp nhận bằng tên thành phần

Khi đã có hệ thống, cách viết yêu cầu nên đổi theo. Thay vì đính kèm một màn hình vẽ lại từ đầu và mô tả từng chi tiết nhìn thấy, spec gọi tên thành phần đã có, chỉ ra biến thể, và chỉ mô tả kỹ phần thật sự mới. Spec ngắn hơn; kỹ sư biết ngay phần nào có sẵn; QA biết phần nào đã được test ở cấp thành phần; designer không phải vẽ lại thứ đã vẽ.

TRƯỚC — spec vẽ lại màn hình
Màn hình Đổi trả: xem ảnh đính kèm (thiết kế mới).
Nút gửi màu cam, bo góc, cao 48px. Có ô chọn ngày lấy hàng.
Hiện chữ đỏ nếu chưa chọn lý do.

SAU — spec tham chiếu thành phần
Màn hình Đổi trả, ghép từ template "Biểu mẫu một cột".
- Organism: Thẻ đơn hàng (biến thể rút gọn), chỉ đọc
- Molecule: Nhóm lựa chọn (Radio group) cho lý do, bắt buộc
- Molecule: Bộ chọn ngày (Date picker), chế độ một ngày;
  chỉ cho chọn từ ngày mai đến 7 ngày sau, bỏ Chủ nhật
- Atom: Nút chính (Button primary, full-width): "Gửi yêu cầu"
- Lỗi: dùng Field error chuẩn, không tạo kiểu mới
PHẦN MỚI (cần thiết kế): khối tải ảnh sản phẩm lỗi, tối đa 4 ảnh,
  mỗi ảnh dưới 5 MB.

Dòng "phần mới" cho mọi người biết công sức thiết kế thật sự nằm ở đâu. Tiêu chí chấp nhận cũng nên viết theo cách đó, để kiểm mà không phải so pixel với ảnh:

• Nút "Gửi yêu cầu" là Button primary của hệ thống, ở trạng thái vô hiệu cho đến khi đã chọn lý do và ngày lấy hàng.
• Bộ chọn ngày là Date picker chuẩn; Chủ nhật và các ngày ngoài khoảng 1–7 ngày hiển thị ở trạng thái không chọn được.
• Khi gửi thất bại do mất mạng, hiển thị Toast lỗi chuẩn với nội dung "Chưa gửi được, vui lòng thử lại"; dữ liệu đã nhập được giữ nguyên.
• Không có giá trị màu, khoảng cách hay cỡ chữ nào ngoài token của hệ thống (kiểm khi review code hoặc bằng công cụ soát token).

Khi thành phần có sẵn không đủ: đừng viết "giống bộ chọn ngày nhưng thêm chọn giờ". Ghi rõ cần một biến thể mới hay thành phần mới, và đưa nó vào quy trình đóng góp ở phần dưới. Nếu không, đó chính là cách bộ chọn ngày thứ mười ra đời.

Quản trị: ai được thêm, đánh số phiên bản, đóng góp và khai tử

Design system ít khi hỏng vì thiết kế xấu; nó hỏng vì không ai quyết được ai được thêm gì. Có ba mô hình phổ biến:

Quy trình đóng góp gợi ý cho mô hình lai:

• Kiểm trước. Người cần thành phần mới tìm trong thư viện và hỏi kênh chung. Nhiều yêu cầu "mới" thật ra là một biến thể của thứ đã có.
• Đề xuất. Một trang ngắn: vấn đề, màn hình sẽ dùng, vì sao thành phần có sẵn không đủ, và ít nhất hai nơi sẽ dùng lại. Thứ chỉ dùng ở một chỗ thì để ở cấp sản phẩm, chưa đưa vào hệ thống.
• Duyệt. Người giữ hệ thống trả lời trong thời hạn đã hẹn, ví dụ 3 ngày làm việc: chấp nhận, gộp vào thành phần có sẵn, hoặc để ở cấp sản phẩm.
• Xây và ghi tài liệu. Thiết kế, code, đủ trạng thái, hướng dẫn dùng, kiểm tra tiếp cận — đủ năm thứ mới tính là xong.
• Công bố. Ghi vào nhật ký thay đổi và báo các đội; thành phần không ai biết là thành phần không ai dùng.

Phiên bản. Thư viện code nên đánh số kiểu major.minor.patch (semantic versioning): sửa lỗi tăng số cuối, thêm biến thể tăng số giữa, thay đổi làm vỡ chỗ đang dùng — đổi tên, bỏ thuộc tính — tăng số đầu. Với PM, nghĩa thực tế là: nâng một bản major là một việc có ước lượng, phải nằm trong kế hoạch sprint, không phải "cập nhật thư viện tiện tay".

Khai tử. Bỏ một thành phần theo ba bước: đánh dấu không khuyến khích dùng và chỉ ra thành phần thay thế; đặt hạn, ví dụ một quý; xoá khi số chỗ dùng về 0. Không xoá đột ngột — đội đang chạy chiến dịch sẽ phát hiện vào đúng ngày ra mắt.

Đo mức sử dụng hệ thống

Hệ thống không ai dùng là chi phí không có lợi ích. Đo để biết nó có được dùng thật không, và để có bằng chứng khi xin tiếp nguồn lực.

Đừng biến tỉ lệ phủ thành chỉ tiêu ép 100%. Một số màn hình — trang chiến dịch dùng một lần, công cụ nội bộ ít người dùng — không đáng chuyển. Đặt mục tiêu cho những luồng quan trọng nhất (tìm kiếm, giỏ hàng, thanh toán) trước.

Lỗi thường gặp

Luyện kỹ năng này trong tuần này

• Chọn một luồng quan trọng — ví dụ thanh toán — và chụp mọi màn hình của nó, kể cả trạng thái lỗi và trống. Đếm có bao nhiêu kiểu nút, ô nhập, thông báo lỗi khác nhau.
• Hỏi designer và một kỹ sư front-end: thư viện thành phần đang ở đâu, ai giữ, có bao nhiêu thành phần. Nếu hai người trả lời hai kiểu, đó là phát hiện đầu tiên của bạn.
• Viết lại spec của một tính năng gần đây theo cách tham chiếu thành phần: liệt kê thành phần có sẵn và biến thể, chỉ mô tả kỹ phần mới. So với bản cũ xem phần nào trước đây bị vẽ lại không cần thiết.
• Viết ba tiêu chí chấp nhận gọi tên thành phần và trạng thái, thay cho mô tả màu và kích thước.
• Chạy thử hướng dẫn Kiểm kê giao diện cho một luồng, ghi vào mẫu Bảng kiểm kê, và mang ba thành phần nên chuẩn hoá trước tới buổi lập kế hoạch.