Bảng kiểm kê giao diện
Mẫu & ví dụ Design TemplatesBảng ghi mọi thành phần giao diện theo atom, molecule, organism: biến thể tìm thấy, nơi dùng, số lần dùng, quyết định giữ, gộp, bỏ, người chủ và ưu tiên — kèm ví dụ đã điền cho một sàn thương mại điện tử.
Mẫu này giúp bạn
Hiểu vì sao kiểm kê đi trước việc dựng design system, và biết phân biệt atom, molecule, organism đủ để xếp một thành phần vào cấp hợp lý.
Lập bảng kiểm kê cho một đến hai luồng với số lần dùng, biến thể, nơi dùng và quyết định giữ, gộp, bỏ có kèm quy tắc nghiệp vụ; chấm ưu tiên để chọn 5–7 thành phần có chủ, hạn và cách đo; và đếm lại mỗi quý với cùng phạm vi để chứng minh tiến bộ.
Mẫu, ví dụ đã điền và cách dùng
Bảng kiểm kê giao diện dùng để làm gì?
Bảng kiểm kê giao diện ghi lại mọi thành phần đang có trên sản phẩm — mỗi loại một dòng — kèm cấp độ theo atomic design, số biến thể tìm thấy, nơi dùng, và quyết định cho từng biến thể. Nó biến cảm giác "giao diện lộn xộn" thành một danh sách việc có số đếm, có chủ và có thứ tự.
Bảng có hai phần. Phần A là kiểm kê: mỗi loại thành phần một khối, đếm số lần dùng và số biến thể, quyết giữ, gộp hay bỏ. Phần B là kế hoạch chuẩn hoá: năm đến bảy thành phần làm trước, với người chủ, số biến thể mục tiêu và hạn. Đi kèm là thư mục ảnh chụp — bảng nói con số, ảnh làm người đọc tin con số.
Giá trị lâu dài của bảng nằm ở lần đếm lại. Lần đếm đầu cho bạn bằng chứng để xin nguồn lực; lần đếm sau một quý, cùng phạm vi và cùng cách đếm, cho bạn bằng chứng rằng nguồn lực đó đã có tác dụng — hoặc chưa.
Dành cho: PM · Product Owner · BA · Designer · Kỹ sư front-end · Head of Product (người duyệt)
Dùng khi: Khi bắt đầu áp dụng atomic design hoặc dựng design system cho một sản phẩm đã chạy; trước một đợt đổi thương hiệu; và mỗi quý một lần để đếm lại sau khi đã chuẩn hoá.
Khác gì với tài liệu design system và một buổi review giao diện?
| Trả lời câu hỏi | Không trả lời | |
|---|---|---|
| Tài liệu design system | Thành phần chuẩn trông thế nào, dùng ra sao | Sản phẩm thật đang lệch khỏi chuẩn bao xa |
| Review giao diện (heuristic, tiếp cận) | Một màn hình có dễ dùng, dễ tiếp cận không | Cùng một thành phần đang tồn tại bao nhiêu phiên bản trên toàn sản phẩm |
| Bảng kiểm kê giao diện | Đang có những gì, bao nhiêu biến thể, ở đâu, giữ hay gộp hay bỏ, làm cái nào trước | Thành phần chuẩn nên thiết kế thế nào — việc đó làm sau, cho từng dòng ưu tiên |
Kiểm kê đi trước tài liệu: bạn không viết được chuẩn cho nút khi chưa biết đang có 14 kiểu nút và mỗi kiểu tồn tại vì lý do gì.
Bản trắng — copy và dán vào tài liệu của bạn
Phần A: một khối cho mỗi loại thành phần, mỗi biến thể một dòng con kèm quyết định. Phần B chỉ chứa những dòng đã chọn làm trước. Phần đếm lại để trống đến quý sau.
BẢNG KIỂM KÊ GIAO DIỆN — [Tên sản phẩm]
Phạm vi (luồng, nền tảng): ......
Ngoài phạm vi: ......
Người kiểm kê: ...... Ngày: ...... Lần đếm: [đầu tiên / đếm lại]
Thư mục ảnh chụp: ...... Số ảnh: ......
PHẦN A — KIỂM KÊ
Cấp: ATOM / MOLECULE / ORGANISM
Quyết định: GIỮ / GỘP vào [biến thể nào] / BỎ
#. Thành phần: ...... Cấp: ......
Số lần dùng: ...... Số biến thể tìm thấy: ......
Biến thể:
a) ...... dùng ở: ...... Quyết định: ......
b) ...... dùng ở: ...... Quyết định: ......
c) ...... dùng ở: ...... Quyết định: ......
Quy tắc nghiệp vụ cần giữ khi gộp: ...... (hoặc "không có")
Số biến thể sau khi xử lý: ......
Điểm: xuất hiện ...(1-3) + gây hại ...(1-3) + dễ gộp ...(1-3)
= ......
Chủ: ...... Ưu tiên: [làm trước / để sau / không làm]
PHẦN B — KẾ HOẠCH CHUẨN HOÁ (5-7 dòng)
Thứ tự | Thành phần | Biến thể: nay -> mục tiêu | Chủ | Hạn | Đo bằng
1. ......
2. ......
3. ......
NGOÀI KẾ HOẠCH LẦN NÀY (ghi lý do)
......
ĐẾM LẠI
Ngày đếm lại: ...... Người đếm: ......
Thành phần | Lần trước | Lần này | Ghi chú
Duyệt: ...... Ngày: ......Từng ô điền gì, và vì sao ô đó tồn tại
| Ô | Điền gì | Bỏ trống thì hỏng ở đâu |
|---|---|---|
| Phạm vi và ngoài phạm vi | Luồng và nền tảng đã kiểm, và những gì cố ý chưa kiểm. | Không ghi thì người đọc tưởng bảng phủ cả sản phẩm, và lần đếm lại so hai phạm vi khác nhau. |
| Cấp | Atom, molecule hoặc organism. | Cấp giúp sắp thứ tự: chuẩn hoá atom trước thì molecule và organism dựng trên nó tự đúng theo. Không cần chính xác tuyệt đối. |
| Số lần dùng | Số lần thành phần xuất hiện trong ảnh chụp của phạm vi. | Không có số thì thành phần ở 96 chỗ và thành phần ở 3 chỗ trông như nhau, và ưu tiên thành ý kiến. |
| Biến thể và nơi dùng | Mỗi kiểu khác nhau một dòng con, kèm màn hình đang dùng nó. | Thiếu nơi dùng thì không ước lượng được việc gộp tốn bao nhiêu, và kỹ sư không biết phải sửa ở đâu. |
| Quyết định giữ, gộp, bỏ | Giữ khi biến thể có lý do; gộp thì ghi gộp vào biến thể nào; bỏ khi chỉ còn ở chỗ cũ. | Bảng chỉ đếm mà không quyết là một bức tranh, không phải kế hoạch. |
| Quy tắc nghiệp vụ cần giữ | Ràng buộc khiến các biến thể khác nhau: ngày cho phép, giới hạn số lượng, định dạng. | Đây là chỗ PM, BA đóng góp nhiều nhất. Gộp bộ chọn ngày mà quên "không giao Chủ nhật" là đưa lỗi lên production. |
| Điểm ưu tiên | Ba câu hỏi, mỗi câu 1–3: xuất hiện nhiều, gây hại, dễ gộp. | Không chấm thì thứ được làm trước là thứ designer thích nhất, không phải thứ tốn kém nhất. |
| Chủ | Một người có tên quyết thiết kế chuẩn và theo đến khi các chỗ dùng đã chuyển. | Không có chủ thì thành phần chuẩn được thiết kế xong, nằm trong thư viện, còn màn hình cũ vẫn dùng bản cũ. |
| Đo bằng (phần B) | Số biến thể mục tiêu, hoặc một chỉ số như ticket, lỗi tiếp cận, thời gian làm màn hình. | Không có cách đo thì không biết khi nào xong, và không có bằng chứng để xin tiếp nguồn lực. |
| Đếm lại | Ngày và kết quả lần đếm sau, cùng phạm vi, cùng cách đếm. | Không đếm lại thì một năm sau biến thể mới lại mọc ra mà không ai nhận thấy. |
Cách dùng — buổi đầu 45–60 phút, đếm lại mỗi quý
- Điền phạm vi trước khi chụp ảnh. Chọn một đến hai luồng quan trọng, ghi cả phần ngoài phạm vi. Nếu đây là lần đầu, làm theo hướng dẫn Kiểm kê giao diện theo atomic design.
- Chụp, cắt, gom theo loại rồi mới mở bảng. Mỗi nhóm trên bảng trắng thành một khối trong phần A.
- Đếm số lần dùng và số biến thể. Xếp các mảnh giống hệt nhau chồng lên nhau; chỉ đếm kiểu khác nhau thật — màu, kích thước, hình dạng, hành vi. Khác nội dung chữ thì không tính là biến thể.
- Ghi quyết định cho từng biến thể, có PM hoặc BA ngồi cùng. Điền ô quy tắc nghiệp vụ trước khi viết "GỘP".
- Chấm điểm và đánh dấu ưu tiên. Đưa 5–7 dòng điểm cao nhất vào phần B; dòng còn lại ghi vào "ngoài kế hoạch" kèm lý do.
- Gửi bảng kèm ảnh của hai, ba nhóm tệ nhất cho người duyệt. Một trang ảnh 14 nút xếp cạnh nhau thuyết phục hơn mọi đoạn văn.
- Đặt lịch đếm lại sau một quý, giữ nguyên phạm vi, cột và cách đếm. Bảng so sánh lần trước và lần này là kết quả bạn báo cáo.
Ví dụ đã điền đầy đủ
ChợGần (giả định) 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 — cùng ví dụ với hướng dẫn kiểm kê. Đây là lần đếm đầu tiên của PO Trang và designer Minh cho hai luồng mua hàng và sau mua. Phần A rút gọn còn sáu khối quan trọng nhất.
BẢNG KIỂM KÊ GIAO DIỆN — ChợGần (iOS, Android, web)
Phạm vi: 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ộ
Người kiểm kê: Trang (PO), Minh (designer) Ngày: 08/10
Lần đếm: đầu tiên
Thư mục ảnh chụp: "Kiem ke Q4" Số ảnh: 212
PHẦN A — KIỂM KÊ
1. Thành phần: Nút Cấp: ATOM
Số lần dùng: 96 Số biến thể tìm thấy: 14
Biến thể (rút gọn):
a) Cam đặc, bo 8 chi tiết SP, giỏ, thanh toán GIỮ (chính)
b) Cam đặc, bo 4 tìm kiếm, theo dõi đơn GỘP vào a
c) Cam nhạt hơn, bo 8 toàn bộ web GỘP vào a
d) Xanh lá "Mua ngay" trang khuyến mãi trong app GỘP vào a
e) Viền cam giỏ, đánh giá GIỮ (viền)
f) Gradient 11.11 2 banner còn sót BỎ
... 8 biến thể khác: 5 GỘP vào a hoặc e;
2 GIỮ (phụ nền xám; dạng chữ);
1 BỎ (bóng đổ, trang đánh giá cũ)
Quy tắc cần giữ: nút "Đặt hàng" vô hiệu khi chưa có địa chỉ
Sau xử lý: 4, cộng 1 biến thể "nguy hiểm" cho huỷ đơn (cần
thiết kế mới)
Điểm: 3 + 3 + 2 = 8 Chủ: Minh Ưu tiên: làm trước
2. Thành phần: Hiển thị giá Cấp: ATOM
Số lần dùng: 34 Số biến thể tìm thấy: 4
a) 129.000đ chi tiết SP, giỏ, thanh toán GIỮ
b) 129.000 VNĐ toàn bộ web GỘP vào a
c) 129k thẻ SP ở kết quả tìm kiếm GỘP vào a
d) đ129.000 theo dõi đơn (Android) GỘP vào a
Quy tắc cần giữ: giá sau voucher hiện cạnh giá gốc gạch ngang;
không làm tròn
Sau xử lý: 1
Điểm: 3 + 3 + 3 = 9 Chủ: Tuấn (FE) Ưu tiên: làm trước
3. Thành phần: Bộ chọn ngày Cấp: MOLECULE
Số lần dùng: 17 Số biến thể tìm thấy: 9
a) Lịch một ngày ngày giao hàng GIỮ
b) Lịch khoảng ngày lọc đơn theo ngày (web) GIỮ
c) Danh sách 7 ngày lịch lắp đặt GỘP vào a
d) Ô chọn tháng kỳ hạn trả góp GỘP vào a
e) Ô gõ tự do ngày sinh (web) BỎ, thay bằng
ô ngày/tháng/năm
... 4 biến thể khác (các bản lọc đơn trên app): GỘP vào b
Quy tắc cần giữ: giao từ ngày mai đến 7 ngày, bỏ Chủ nhật;
lắp đặt chỉ khung 8-17 giờ; trả góp chọn theo tháng
Sau xử lý: 2
Điểm: 2 + 2 + 2 = 6 Chủ: Trang, Hà (FE) Ưu tiên: làm trước
4. Thành phần: Thông báo lỗi Cấp: ORGANISM
Số lần dùng: 23 Số biến thể tìm thấy: 6
Hộp thoại, chữ đỏ dưới ô, toast, banner đầu trang,
trang lỗi riêng, chữ đỏ trong nút
Quyết định: GIỮ 3 (lỗi dưới ô nhập, toast, banner hệ thống);
GỘP 2 (hộp thoại, trang lỗi riêng vào banner);
BỎ chữ đỏ trong nút
Quy tắc cần giữ: lỗi thanh toán luôn giữ dữ liệu đã nhập
Sau xử lý: 3
Điểm: 2 + 3 + 2 = 7 Chủ: Minh Ưu tiên: làm trước
5. Thành phần: Ô nhập Cấp: ATOM
Số lần dùng: 58 Số biến thể tìm thấy: 7
Quyết định: GIỮ 2 (nhãn trên ô; ô tìm kiếm); GỘP 5 vào
"nhãn trên ô"
Quy tắc cần giữ: số điện thoại chỉ nhận chữ số, đủ 10 số
Sau xử lý: 2
Điểm: 3 + 2 + 2 = 7 Chủ: Tuấn Ưu tiên: làm trước
6. Thành phần: Thẻ sản phẩm Cấp: ORGANISM
Số lần dùng: 41 Số biến thể tìm thấy: 5
Quyết định: GIỮ 2 (dạng lưới, dạng danh sách); GỘP 3
Quy tắc cần giữ: huy hiệu "Freeship" chỉ khi người bán đăng ký
Điểm: 3 + 1 + 1 = 5 Chủ: chưa có Ưu tiên: để sau
PHẦN B — KẾ HOẠCH CHUẨN HOÁ QUÝ 4
Thứ tự | Thành phần | Biến thể | Chủ | Hạn | Đo bằng
1. | Hiển thị giá | 4 -> 1 | Tuấn | 30/10 | ticket "giá lệch"
2. | Nút | 14 -> 4 | Minh | 15/11 | số biến thể
3. | Thông báo lỗi | 6 -> 3 | Minh | 30/11 | số biến thể
4. | Ô nhập | 7 -> 2 | Tuấn | 30/11 | lỗi tiếp cận
5. | Bộ chọn ngày | 9 -> 2 | Trang, Hà | 15/12 | số biến thể
NGOÀI KẾ HOẠCH LẦN NÀY
Thẻ sản phẩm: ít gây hại, phải sửa 41 chỗ; xem lại quý 1
Trang chiến dịch: ngoài phạm vi; mỗi chiến dịch tự hết hạn
ĐẾM LẠI
Ngày đếm lại: 10/01 Người đếm: Trang, Minh
Thành phần | Lần trước | Lần này | Ghi chú
(điền khi đếm lại)
Duyệt: anh Khoa (Head of Product) Ngày: 10/10Chú ý thứ tự ở phần B: hiển thị giá đứng đầu dù chỉ có 4 biến thể, ít hơn hẳn nút. Nó được 9 điểm vì nằm trên luồng tiền, gây ticket thật — "giá ở giỏ khác giá ở trang sản phẩm" chiếm 9% ticket tháng 9 — và chỉ cần sửa một hàm định dạng dùng chung. Ngược lại, thẻ sản phẩm xuất hiện 41 lần nhưng bị để sau: người dùng không nhầm lẫn vì nó, còn gộp thì phải sửa 41 chỗ. Để ý thêm dòng "quy tắc cần giữ" ở bộ chọn ngày: ba quy tắc nghiệp vụ khác nhau là lý do 9 biến thể từng ra đời, và là thứ phải mang theo khi gộp còn 2.
Hiccups thường gặp và cách xử lý
| Hiccup | Vì sao xảy ra | Xử lý |
|---|---|---|
| Bảng có 200 dòng, không ai đọc hết | Mỗi biến thể thành một dòng riêng thay vì một khối cho mỗi loại thành phần | Một khối cho mỗi loại; biến thể là dòng con. Biến thể ít quan trọng gom thành "... N biến thể khác". |
| Hai người đếm ra hai con số | Mỗi người hiểu "biến thể khác nhau" một kiểu | Thống nhất trước: khác màu, kích thước, hình dạng hoặc hành vi thì là biến thể; khác nội dung chữ thì không. |
| Gộp xong thì phát sinh lỗi nghiệp vụ | Ô quy tắc nghiệp vụ bị bỏ trống | Không ghi "GỘP" khi ô quy tắc còn trống; BA kiểm ô này trước khi gửi duyệt. |
| Phần B có 15 dòng | Muốn sửa hết trong một quý | Giới hạn 5–7 dòng; phần còn lại ghi lý do ở "ngoài kế hoạch". |
| Có thành phần chuẩn rồi, màn hình cũ vẫn dùng bản cũ | Chủ chỉ chịu trách nhiệm phần thiết kế | Chủ theo đến khi số chỗ dùng bản cũ về 0, hoặc ghi rõ lý do giữ lại. |
| Lần đếm lại không so được với lần đầu | Đổi phạm vi hoặc cách đếm | Giữ nguyên phạm vi và cột; nếu mở rộng, đếm phạm vi cũ riêng để so. |
Vì sao vai trò của bạn cần cái này
| Vai trò | Bạn dùng nó để |
|---|---|
| PM | Có số liệu cụ thể để xin nguồn lực chuẩn hoá, và biết thành phần nào có sẵn trước khi viết spec mới |
| Product Owner | Biến phần B thành việc có thứ tự trong backlog, và nhận ra khi một story sắp tạo thêm biến thể mới |
| BA | Ghi quy tắc nghiệp vụ đằng sau từng biến thể, để việc gộp không làm mất ràng buộc |
| Designer | Thấy toàn bộ biến thể cạnh nhau và quyết thiết kế chuẩn dựa trên nơi dùng thật |
| Kỹ sư front-end | Ước lượng việc gộp từ cột nơi dùng, và biết chính xác chỗ nào phải sửa |
Definition of done
- Phạm vi và ngoài phạm vi được ghi rõ, kèm thư mục ảnh chụp.
- Mỗi loại thành phần có cấp, số lần dùng và số biến thể.
- Mỗi biến thể có nơi dùng và quyết định giữ, gộp (vào đâu) hoặc bỏ.
- Mọi quyết định gộp đều đã điền quy tắc nghiệp vụ cần giữ, hoặc ghi "không có".
- Phần B có 5–7 thành phần, mỗi cái có chủ, hạn và cách đo.
- Có ngày đếm lại trên lịch của người giữ bảng.
Thảo luận & tài liệu thêm 0
Chia sẻ kinh nghiệm, đặt câu hỏi, hoặc đính kèm tài liệu/YouTube giúp người khác học kỹ năng này.