Kiểm kê giao diện theo atomic design

Chuẩn bị trước

• Quyền vào bản đang chạy trên từng nền tảng (iOS, Android, web), kèm tài khoản thử có dữ liệu: có đơn hàng, có voucher, có địa chỉ
• Một bảng trắng online hoặc file thiết kế trống để dán ảnh chụp
• Bản trống của mẫu Bảng kiểm kê giao diện
• Một designer, và nếu được một kỹ sư front-end, ngồi cùng ít nhất ở bước quyết định và bước chấm ưu tiên

Các bước

1. Bước 1 Chọn phạm vi: một đến hai luồng quan trọng, không phải cả sản phẩm

   Kiểm kê cả sản phẩm trong một buổi là cách chắc chắn nhất để bỏ dở giữa chừng. Chọn luồng người dùng đi qua nhiều nhất, hoặc nơi tiền chạy qua, vì thiếu nhất quán ở đó tốn kém nhất. Ghi rõ những gì không nằm trong phạm vi, để không ai hỏi vì sao thiếu trang khuyến mãi.

   Ví dụ

   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ô, có ứng dụng iOS, Android và web với hơn 180 màn hình. PO Trang và designer Minh nghi giao diện đã trôi xa nhau: người dùng phản ánh "nút mua mỗi trang một màu", kỹ sư than sửa một lỗi ô nhập phải sửa ở nhiều nơi.

   Trang chọn hai luồng: mua hàng (tìm kiếm, danh mục, chi tiết sản phẩm, giỏ hàng, thanh toán) và sau mua (theo dõi đơn, đổi trả, đánh giá). Ngoài phạm vi: trang chiến dịch, ứng dụng người bán, công cụ nội bộ.

   Mẹo: Nếu chỉ có thời gian cho một luồng, chọn thanh toán. Thành phần ở đó — ô nhập, nút chính, thông báo lỗi, bộ chọn ngày — xuất hiện lại gần như ở mọi nơi khác.

2. Bước 2 Chụp mọi màn hình và mọi trạng thái

   Đi qua luồng như một người dùng, trên từng nền tảng, và chụp lại. Không chỉ trạng thái đẹp: chụp cả trạng thái trống, đang tải, lỗi, hết hàng, chưa đăng nhập. Biến thể trùng lặp hay trốn trong những trạng thái ít ai thiết kế kỹ. Đặt tên ảnh theo luồng, nền tảng và trạng thái để bước sau không bị lẫn.

   Ví dụ

   Trang chụp Android và web, Minh chụp iOS. Sau 25 phút họ có 212 ảnh. Riêng màn hình thanh toán có 9 trạng thái: mặc định, chưa có địa chỉ, địa chỉ ngoài vùng giao, voucher hết hạn, voucher không áp dụng, chọn trả góp, chọn ngày giao, thanh toán lỗi, mất mạng.

   Ảnh đặt tên kiểu thanhtoan_android_voucher-het-han.png. Minh phát hiện ngay ở bước này: báo "voucher hết hạn" trên iOS là hộp thoại, trên Android là dòng chữ đỏ dưới ô nhập.

3. Bước 3 Cắt ra từng thành phần và gom theo loại

   Dán ảnh lên bảng, rồi cắt từng thành phần ra khỏi màn hình: mọi nút, mọi ô nhập, mọi thẻ, mọi thông báo. Gom vào các nhóm theo việc chúng làm — "Nút", "Ô nhập", "Bộ chọn ngày", "Thẻ sản phẩm", "Thông báo lỗi", "Hiển thị giá" — chưa cần quan tâm cấp độ. Mục tiêu của bước này là thấy các biến thể đứng cạnh nhau.

   Ví dụ

   Nhóm	Số lần cắt được	Ghi chú đầu tiên
   Nút	96	Ít nhất 4 sắc cam khác nhau, 3 độ bo góc
   Ô nhập	58	Nhãn lúc nằm trên ô, lúc nằm trong ô
   Thẻ sản phẩm	41	Giá nằm trên tên ở danh mục, dưới tên ở kết quả tìm kiếm
   Hiển thị giá	34	"129.000đ", "129.000 VNĐ", "129k", "đ129.000"
   Thông báo lỗi	23	Hộp thoại, chữ đỏ dưới ô, toast, banner đầu trang
   Bộ chọn ngày	17	Ngày giao, lọc đơn, ngày sinh, lịch lắp đặt, kỳ hạn trả góp

   Mẹo: Gom theo việc thành phần làm, không theo vẻ ngoài. Một nút trông như đường link vẫn là nút nếu bấm vào nó thực hiện một hành động.

4. Bước 4 Xếp các nhóm vào atom, molecule, organism

   Với mỗi nhóm, quyết nó thuộc cấp nào. Atom là phần nhỏ nhất còn có nghĩa; molecule là vài atom làm một việc; organism là khối hoàn chỉnh đứng riêng được. Không tranh luận quá năm phút cho một nhóm — nếu đội chia đôi, chọn một cấp, ghi chú, đi tiếp. Template và page không cần kiểm kê ở đây: chúng chính là những màn hình bạn đã chụp.

   Ví dụ

   Cấp	Nhóm
   Atom	Nút, ô nhập, nhãn, biểu tượng, huy hiệu ("Freeship", "Mới", "-20%"), hiển thị giá
   Molecule	Ô tìm kiếm, bộ chọn số lượng, bộ chọn ngày, dòng giá có giá gốc gạch ngang, ô nhập mã voucher
   Organism	Thẻ sản phẩm, thanh đầu trang, khối địa chỉ giao, khối phương thức thanh toán, thông báo lỗi

   Đội mất mười phút tranh luận bộ chọn ngày là molecule hay organism. Minh chốt molecule, vì nó chỉ làm một việc là chọn ngày, ghi chú "bản lịch đầy đủ có thể là organism", và đi tiếp.

5. Bước 5 Đếm biến thể và gắn quyết định giữ, gộp, bỏ

   Trong mỗi nhóm, xếp các mảnh giống hệt nhau chồng lên nhau, rồi đếm số biến thể thật sự khác nhau — khác màu, kích thước, hình dạng hoặc hành vi. Với mỗi biến thể, ghi màn hình đang dùng nó và gắn một quyết định: giữ nếu nó có lý do tồn tại, gộp vào một biến thể chuẩn nếu khác nhau mà không có lý do, bỏ nếu chỉ còn ở màn hình cũ. Câu hỏi quyết định: nếu người dùng thấy hai biến thể này cạnh nhau, họ có hiểu chúng làm việc khác nhau không?

   Ví dụ

   Hai nhóm gây chú ý nhất:

   NÚT — 96 lần dùng, 14 biến thể
     Giữ (4): chính, phụ nền xám, viền, dạng chữ
     Gộp (8): 4 sắc cam khác nhau, 3 độ bo góc, nút "Mua ngay"
              xanh lá ở trang khuyến mãi -> đều về nút chính
     Bỏ (2): nút gradient chiến dịch 11.11 năm ngoái;
             nút có bóng đổ ở trang đánh giá cũ
     Kết quả: 14 -> 4, cần thiết kế thêm 1 biến thể "nguy hiểm"
     cho nút huỷ đơn
   
   BỘ CHỌN NGÀY — 17 lần dùng, 9 biến thể
     Giữ (2): chọn một ngày; chọn khoảng ngày
     Gộp (6): ngày giao, lịch lắp đặt, kỳ hạn trả góp và các bản
              lọc đơn -> hai biến thể trên, cấu hình ngày cho phép
     Bỏ (1): ô gõ ngày sinh tự do trên web, thay bằng ô
             ngày / tháng / năm
     Kết quả: 9 -> 2

   Mẹo: Designer quyết phần nhìn, nhưng PM hoặc BA phải có mặt ở bước này: nhiều biến thể tồn tại vì một quy tắc nghiệp vụ — ngày giao bỏ Chủ nhật, trả góp chỉ chọn theo tháng — chứ không vì sở thích. Gộp mà quên quy tắc là tạo lỗi.

6. Bước 6 Chấm ưu tiên và chọn 5–7 thành phần chuẩn hoá trước

   Không chuẩn hoá tất cả cùng lúc. Chấm mỗi nhóm theo ba câu hỏi, mỗi câu từ 1 đến 3: xuất hiện nhiều không (số lần dùng, có nằm trên luồng tiền không), gây hại không (bấm nhầm, lỗi tiếp cận, ticket), và dễ gộp không (bao nhiêu chỗ code phải sửa). Cộng điểm, chọn 5–7 nhóm cao nhất. Gán cho mỗi nhóm một người chủ — người quyết thiết kế chuẩn và theo đến khi các chỗ dùng đã chuyển.

   Ví dụ

   Thành phần	Xuất hiện	Gây hại	Dễ gộp	Tổng	Chủ
   Hiển thị giá	3	3	3	9	Tuấn (FE)
   Nút	3	3	2	8	Minh (designer)
   Thông báo lỗi	2	3	2	7	Minh
   Ô nhập	3	2	2	7	Tuấn
   Bộ chọn ngày	2	2	2	6	Trang (PO) cùng Hà (FE)
   Thẻ sản phẩm	3	1	1	5	Để quý sau

   Hiển thị giá đứng đầu dù là thành phần nhỏ nhất: bốn cách viết giá trên cùng một luồng làm người dùng nghi giá có đúng không. Ticket "giá ở giỏ khác giá ở trang sản phẩm" chiếm 9% ticket tháng trước — dù thực ra cùng một con số, chỉ khác cách viết.

7. Bước 7 Trình bày bằng hình và chốt danh sách

   Mang kết quả tới buổi lập kế hoạch trong một trang: ảnh biến thể của hai, ba nhóm tệ nhất đặt cạnh nhau, bảng số lượng, danh sách ưu tiên có chủ. Đừng xin "làm design system". Xin một việc cụ thể, có giới hạn và đo được. Lưu bảng kiểm kê ở nơi cả đội tìm được, và hẹn ngày đếm lại sau một quý.

   Ví dụ

   Tin nhắn Trang gửi Head of Product, kèm ảnh 14 nút xếp thành hàng:

   Kiểm kê hai luồng mua hàng và sau mua: 14 kiểu nút, 9 bộ chọn ngày, 4 cách viết giá, 6 kiểu thông báo lỗi. Đề xuất quý này chuẩn hoá 5 thành phần (giá, nút, thông báo lỗi, ô nhập, bộ chọn ngày), khoảng 20% thời gian của Minh và hai bạn FE trong 6 tuần. Đo bằng số biến thể còn lại và ticket về giá. Không đụng thẻ sản phẩm và trang chiến dịch quý này. Bảng kiểm kê đầy đủ ở link đính kèm.

   Head of Product đồng ý, với điều kiện hiển thị giá xong trước đợt khuyến mãi 12.12. Ngày đếm lại được đặt vào 10/01.

Bạn xong khi

• Có ảnh chụp mọi màn hình và trạng thái của các luồng trong phạm vi, kể cả lỗi và trống
• Mọi thành phần đã được gom theo loại và xếp vào atom, molecule hoặc organism
• Mỗi nhóm có số lần dùng và số biến thể; mỗi biến thể có quyết định giữ, gộp hoặc bỏ
• Mỗi quyết định gộp có ghi quy tắc nghiệp vụ cần giữ, hoặc ghi rõ là không có
• Có 5–7 thành phần chuẩn hoá trước, mỗi cái có điểm ưu tiên và một người chủ có tên
• Bảng kiểm kê nằm ở nơi cả đội tìm được, và có ngày đếm lại trên lịch

Lỗi thường gặp

Tiếp theo

Ghi kết quả vào mẫu Bảng kiểm kê giao diện để lần đếm lại sau một quý dùng cùng cột, cùng cách đếm. Kỹ năng Atomic Design & Design System đi tiếp từ đây: design token, cách viết spec và tiêu chí chấp nhận gọi tên thành phần, và quản trị hệ thống sau khi đã chuẩn hoá. Khi cần vẽ màn hình mới, hãy dựng wireframe bằng chính các thành phần vừa chuẩn hoá — xem Wireframing & Prototyping Basics.