Visual QA: so giao diện với Figma có hệ thống, không cảm tính
Chuẩn bị môi trường so sánh, thứ tự soát 7 lớp từ layout tới responsive, cách xếp mức Critical/Major/Minor và phân biệt lỗi code với design chưa cập nhật.
“Nhìn cũng giống mà?” — câu này là lý do nhiều lỗi giao diện lọt lên production. So giao diện với design bằng cảm giác thì mỗi người thấy một kiểu, và Designer sẽ là người phát hiện lỗi thay bạn.
Bài này là quy trình Visual QA để việc so sánh trở nên lặp lại được và ai làm cũng ra kết quả giống nhau.
Chuẩn bị trước khi so
Phần lớn “lỗi giao diện” bị báo sai là do so trong điều kiện khác với design. Kiểm 5 điều sau trước:
- Đúng frame Figma: link có
node-id, đúng phiên bản design mới nhất mà team đã duyệt. - Độ rộng màn hình: ghi lại viewport bạn đang test (ví dụ 1440px, 1280px, 390px). So với frame có cùng độ rộng.
- Zoom trình duyệt 100% (
Ctrl/Cmd + 0). - Giao diện sáng/tối: nếu design có cả hai, so từng chế độ riêng.
- Dữ liệu tương đương: design dùng dữ liệu mẫu ngắn gọn, môi trường test có thể có dữ liệu dài hơn. Lệch do dữ liệu thì chưa chắc là lỗi.
Soát theo 7 lớp, từ lớn tới nhỏ
Đi từ tổng thể vào chi tiết giúp bạn không bị cuốn vào việc đo từng pixel trong khi bỏ sót một khối bị thiếu.
1. Bố cục (layout)
Các khối có đúng vị trí, đúng thứ tự, đúng số cột? Có khối nào thiếu hoặc thừa?
2. Khoảng cách (spacing)
Khoảng cách giữa các khối, padding trong card, khoảng cách giữa tiêu đề và nội dung. Dùng Dev Mode của Figma để đọc số đo, và DevTools của trình duyệt để đo trên trang thật.
3. Chữ (typography)
Font, cỡ chữ, độ đậm, chiều cao dòng, căn lề. Lỗi hay gặp: dùng font dự phòng vì font chính chưa tải, cỡ chữ lệch 1–2px.
4. Màu sắc
Màu chữ, nền, viền, màu trạng thái (thành công, lỗi, cảnh báo), màu từng series trên chart. Dùng công cụ hút màu để lấy mã màu chính xác thay vì nhìn bằng mắt.
5. Nội dung
Chính tả, viết hoa, đơn vị, định dạng số và ngày, nhãn trục, chú thích. Phần này thường bị coi là “không phải UI” nhưng lại là thứ người dùng thấy đầu tiên.
6. Trạng thái
Hover, đang chọn, vô hiệu hoá, đang tải, không có dữ liệu, lỗi. Design thường có vẽ những trạng thái này ở frame riêng — đừng quên so.
7. Responsive
Thu nhỏ cửa sổ dần và quan sát: chữ có bị cắt, card có tràn khỏi màn hình, chart có co lại hợp lý, menu có chuyển thành dạng thu gọn? Ngoài các độ rộng chuẩn, hãy thử cả những độ rộng “lửng lơ” như 1100px — nơi layout hay vỡ nhất.
Xếp mức độ nghiêm trọng
Không phải lệch nào cũng đáng một bug khẩn. Một thang 3 mức đơn giản giúp Dev ưu tiên:
| Mức | Khi nào | Ví dụ |
|---|---|---|
| Critical | Vỡ layout, che hoặc mất nội dung, hiển thị sai thông tin | Card tràn khỏi màn hình ở 1280px, nút bị che không bấm được |
| Major | Lệch rõ ràng, người dùng dễ nhận ra | Sai màu chính, sai font, khoảng cách lệch nhiều |
| Minor | Lệch nhỏ, chỉ thấy khi so kỹ | Lệch vài pixel, bo góc khác một chút |
Lỗi code hay design chưa cập nhật?
Không phải mọi chênh lệch đều là lỗi của Dev. Có ba khả năng:
- Lỗi code: Dev làm sai so với design đã duyệt → ghi bug.
- Design chưa cập nhật: team đã thống nhất thay đổi nhưng chưa sửa Figma → hỏi Designer, không ghi bug.
- Design chưa rõ: Figma không vẽ trường hợp này (ví dụ dữ liệu dài) → đặt câu hỏi, ghi lại quyết định.
Với trường hợp 2 và 3, hãy ghi lại điểm đã chốt để vòng test sau không báo lỗi lại.
Viết lỗi giao diện
Một lỗi giao diện tốt có:
- Vị trí: trang nào, khối nào, viewport bao nhiêu, chế độ sáng hay tối.
- Design: mô tả ngắn hoặc ảnh frame Figma.
- Thực tế: ảnh chụp trang, khoanh vùng lỗi.
- Mức độ: Critical / Major / Minor.
Ví dụ:
[Major] Tiêu đề card “Theo ngành” dùng cỡ 14px, design 16px Trang Tổng quan · viewport 1440px · giao diện sáng. Design: 16px / Semibold. Thực tế: 14px / Regular (xem ảnh).
Khi một màn hình có nhiều lỗi nhỏ, gom vào một bug tổng hợp, đánh số theo khối (1. Header, 2. Card Theo ngành, 3. Responsive 1280px…) để Dev sửa một lượt và đánh dấu từng mục đã xong.
Phần nào giao cho máy?
Chụp màn hình ở nhiều độ rộng, đặt cạnh design, liệt kê chỗ khác nhau, đo màu — đều là việc lặp lại, máy làm tốt và không mỏi mắt. Việc quyết định chỗ nào là lỗi thật, mức độ ra sao và có cần hỏi Designer không thì vẫn nên để bạn duyệt trước khi ghi lên Jira.
Kết
Visual QA có hệ thống không làm bạn khó tính hơn — nó làm kết quả của bạn đáng tin hơn. Khi Designer và Dev thấy mỗi lỗi bạn báo đều có viewport, có ảnh, có mức độ rõ ràng, họ sẽ sửa thay vì tranh luận.