Mở đầu — vì sao bài này quan trọng
Bạn đã dành hai tuần để hoàn thiện một màn hình thanh toán trong Figma. Mọi thứ đều hoàn hảo: spacing đúng bội số 8, màu sắc lấy chuẩn từ token, typography scale chuẩn từng pixel. Rồi sản phẩm lên staging, bạn mở lên xem và... nút "Thanh toán" bị lệch 6px, màu nền error là một sắc đỏ khác hoàn toàn với thiết kế, và khi nhập sai OTP thì chẳng có thông báo lỗi nào hiện ra vì đơn giản bạn chưa từng thiết kế trạng thái đó.
Đây chính là khoảng cách giữa "thiết kế trông đẹp trong file Figma" và "sản phẩm thực sự hoạt động đúng như thiết kế". Design QA (Design Quality Assurance) là quy trình lấp đầy khoảng cách đó. Nó không phải là công đoạn "chốt hạ" cuối cùng trước khi ship, mà là một chuỗi kiểm tra chất lượng diễn ra ở nhiều thời điểm — trước khi dev bắt đầu, trong lúc dev code, và trước khi release.
Nhiều bạn designer junior nghĩ rằng công việc của mình kết thúc khi bấm nút "Share" file Figma. Sai lầm này khiến bạn mất uy tín rất nhanh: engineer sẽ phàn nàn thiết kế thiếu trạng thái, PM sẽ hỏi tại sao sản phẩm khác thiết kế, và bản thân bạn thì bực bội vì "code không giống design". Design QA chính là kỹ năng phân biệt một designer làm việc chuyên nghiệp với một người chỉ biết vẽ. Trong bài này, chúng ta sẽ đi sâu vào việc: QA lúc nào, QA cái gì, làm thế nào để QA có hệ thống thay vì "nhìn qua thấy ổn".
Khái niệm cốt lõi
Design QA là quá trình kiểm tra có chủ đích để đảm bảo sản phẩm thực tế phản ánh đúng ý định thiết kế — cả về mặt hình ảnh (visual) lẫn hành vi (behavior). Điểm mấu chốt cần nhớ: Design QA không chỉ diễn ra một lần ở cuối, mà trải dài theo ba mốc thời gian.
QA ở ba thời điểm
1. Trước khi dev bắt đầu (Design Review / Self-QA). Đây là lúc bạn review chính thiết kế của mình để đảm bảo nó đầy đủ và không có lỗ hổng. Câu hỏi lớn nhất: "Liệu một engineer chưa từng nói chuyện với mình có thể build toàn bộ tính năng này chỉ bằng file Figma không?" Nếu câu trả lời là không, thiết kế của bạn chưa sẵn sàng. Ở giai đoạn này bạn kiểm tra tính đầy đủ: đủ mọi trạng thái (empty, loading, error, success), đủ mọi edge case (tên dài 200 ký tự, giá tiền lên tới hàng tỷ, danh sách 0 phần tử), đủ responsive cho các breakpoint.
2. Trong lúc dev (Live Review / Staging QA). Khi engineer đã code xong một phần và deploy lên môi trường staging, bạn mở sản phẩm thật lên và so sánh trực tiếp với thiết kế. Đây là lúc bắt lỗi visual: sai spacing, sai màu, sai font, component không đúng state. Việc QA sớm trong lúc dev quan trọng vì sửa lỗi lúc code đang viết dở dễ và rẻ hơn nhiều so với sửa sau khi tính năng đã "xong".
3. Trước khi ship (Final QA / Pre-release). Đây là lần kiểm tra cuối trên môi trường gần production nhất, thường theo một checklist chuẩn hóa. Mục tiêu là chặn những lỗi nghiêm trọng lọt ra tay người dùng thật.
Phân biệt Design QA với QA thông thường (functional QA)
Đội QA/tester truyền thống kiểm tra "chức năng có chạy đúng không" — bấm nút có gọi API không, form có validate không. Design QA kiểm tra "trải nghiệm có đúng ý định thiết kế không" — khoảng cách, màu, chuyển động, cảm giác. Hai việc này bổ sung cho nhau chứ không thay thế. Một nút có thể "chạy đúng" (functional pass) nhưng vẫn "sai thiết kế" (design fail) vì lệch màu và thiếu hiệu ứng hover. Chính vì thế Design QA là trách nhiệm của designer, không thể khoán trắng cho đội tester.
Ba nhóm tiêu chí cần soi
Khi QA, bạn nên soi theo ba trục để không bỏ sót:
- Visual fidelity (độ trung thực hình ảnh): spacing, alignment, màu sắc, typography, border radius, shadow, icon size, asset export có sắc nét không.
- Interaction & states (tương tác và trạng thái): hover, focus, active, disabled, loading, error, empty, success — mỗi component có đủ và đúng state chưa; transition/animation có mượt không.
- Responsive & edge cases: hiển thị trên mobile/tablet/desktop, nội dung dài/ngắn bất thường, text tiếng Việt có dấu bị vỡ layout không (đây là lỗi rất hay gặp ở sản phẩm Việt vì dấu tiếng Việt làm dòng cao hơn).
Tình huống thực tế
Ví dụ 1 — Sàn thương mại điện tử Tiki: lỗi trạng thái bị bỏ quên
Giả định một đội design tại một sàn TMĐT lớn như Tiki đang làm lại màn hình giỏ hàng. Designer giao thiết kế "đẹp long lanh" cho trạng thái giỏ hàng có 3 sản phẩm. Engineer build đúng y hệt, QA functional pass, tính năng lên production.
Vấn đề nổ ra ngay ngày đầu: khi người dùng có giỏ hàng trống, màn hình chỉ hiển thị một khoảng trắng mênh mông vì thiết kế không có empty state. Khi một sản phẩm hết hàng trong lúc đang ở giỏ, không có trạng thái báo lỗi nào. Khi mạng chậm, danh sách nhảy giật vì thiếu loading skeleton. Trong một tuần, tỷ lệ thoát ở màn giỏ hàng tăng 12%.
Diễn giải: Đây không phải lỗi của engineer — họ build đúng những gì được giao. Đây là lỗi Self-QA ở giai đoạn trước dev: designer đã không liệt kê đủ các trạng thái. Bài học: trước khi giao thiết kế, hãy lập một ma trận trạng thái (state matrix) cho mọi màn hình có dữ liệu động: empty, loading, error, partial, full, và các edge case về số lượng. Nếu bạn không thiết kế một trạng thái, engineer sẽ hoặc bỏ qua nó, hoặc tự bịa ra — và cả hai đều tệ.
Ví dụ 2 — Fintech Momo: "gần đúng" nhưng cộng dồn thành thảm họa
Giả định đội thiết kế tại một ví điện tử như Momo release một luồng chuyển tiền mới. Khi QA staging, designer phát hiện một loạt sai lệch nhỏ: padding nút bấm là 12px thay vì 16px, màu primary bị dùng sắc #3B4CCA thay vì token chuẩn #2E3BB0, khoảng cách giữa các dòng trong danh sách giao dịch là 10px thay vì 8px, và icon bị export ở kích thước 22px thay vì 24px.
Mỗi lỗi riêng lẻ đều "nhỏ đến mức gần như không ai để ý". Nhưng cộng dồn cả màn hình, sản phẩm trông "sai sai", thiếu chỉn chu, không giống thiết kế đã được duyệt. Tệ hơn, việc dùng sai màu khiến contrast tụt xuống dưới ngưỡng WCAG AA, gây khó đọc cho người dùng lớn tuổi — một nhóm khách hàng quan trọng của ví điện tử.
Diễn giải: Lỗi kiểu "gần đúng" (pixel drift) là loại lỗi nguy hiểm nhất vì nó không gây crash, không bị functional QA bắt, nhưng bào mòn chất lượng cảm nhận của sản phẩm. Bài học: hãy QA bằng công cụ đo, không QA bằng mắt. Dùng Figma Dev Mode để lấy giá trị chính xác, dùng extension so sánh overlay (như PerfectPixel) chồng thiết kế lên trang thật, và luôn kiểm tra giá trị màu bằng token name chứ không bằng cảm giác "trông giống đỏ rồi".
Ví dụ 3 — Startup SaaS Base.vn: quy trình QA có hệ thống giúp giảm vòng lặp
Giả định một startup SaaS nội bộ như Base.vn từng có quy trình lộn xộn: designer QA ngẫu hứng, báo lỗi rải rác qua tin nhắn Slack, engineer sửa xong lại phát sinh lỗi mới, mỗi tính năng phải QA đi QA lại 4–5 vòng, kéo dài lịch release thêm cả tuần.
Đội quyết định chuẩn hóa: mọi lỗi Design QA được ghi vào một bảng chung (dùng một cột riêng trên Jira), mỗi lỗi có ảnh chụp thiết kế đối chiếu với ảnh chụp staging, gắn mức độ nghiêm trọng (blocker / major / minor / nice-to-have), và link tới đúng frame trong Figma. Sau ba tháng áp dụng, số vòng QA trung bình giảm từ 4,5 xuống còn 1,8 vòng mỗi tính năng, và thời gian từ "code done" tới "ship" rút ngắn khoảng 40%.
Diễn giải: Vấn đề trước đây không phải engineer làm ẩu, mà là cách báo lỗi mơ hồ ("cái nút trông chưa ổn") khiến engineer đoán mò và sửa sai. Bài học: một báo cáo Design QA tốt phải cụ thể, có bằng chứng hình ảnh, có mức độ ưu tiên và có tham chiếu tới nguồn thiết kế. Định dạng chuẩn giúp engineer sửa đúng ngay lần đầu, cắt giảm vòng lặp.
Hướng dẫn từng bước
Dưới đây là quy trình Design QA bạn có thể áp dụng ngay cho một tính năng bất kỳ.
Bước 1 — Self-QA thiết kế trước khi giao (trước dev). Trước khi bấm "handoff", tự soi lại file của mình bằng ba câu hỏi: (a) Đã có đủ mọi trạng thái chưa? (b) Đã xử lý mọi edge case về nội dung chưa? (c) Đã có bản responsive cho mọi breakpoint mục tiêu chưa? Lập ma trận trạng thái cho từng component động và điền cho đầy.
Bước 2 — Chuẩn bị "nguồn chân lý" (source of truth). Xác định rõ frame nào trong Figma là bản cuối cùng được duyệt. Đặt tên rõ ràng, đánh dấu "Ready for Dev", khóa các frame nháp lại. Nếu bạn QA mà không chắc bản nào là bản đúng, mọi so sánh đều vô nghĩa.
Bước 3 — Live QA trên staging (trong lúc dev). Khi engineer báo "phần này xong rồi", mở staging và so sánh song song với Figma. Đi theo checklist ba trục: visual fidelity → interaction & states → responsive. Kiểm tra từng component một cách hệ thống, đừng lướt qua toàn màn hình.
Bước 4 — Ghi lỗi có cấu trúc. Mỗi lỗi ghi theo mẫu: tên màn hình/component → ảnh thiết kế → ảnh staging → mô tả chênh lệch cụ thể (kèm số đo) → mức độ nghiêm trọng → link Figma frame. Gom tất cả vào một nơi thống nhất, không rải rác qua chat.
Bước 5 — Phân loại mức độ ưu tiên. Không phải lỗi nào cũng chặn release. Blocker (sai luồng chính, thiếu state quan trọng) phải sửa trước khi ship; minor (lệch 2px, sai nhẹ shadow) có thể xếp lịch sau. Việc phân loại giúp đội không tranh cãi và không trì hoãn release vì lỗi nhỏ.
Bước 6 — Retest và Final QA. Sau khi engineer sửa, QA lại đúng những lỗi đã báo (đừng bỏ qua bước này). Trước khi ship, chạy Final QA theo checklist chuẩn trên môi trường gần production, tập trung vào các luồng chính và các blocker đã từng xuất hiện.
Lỗi thường gặp & mẹo
Lỗi: QA bằng mắt thay vì bằng công cụ. "Nhìn thấy ổn" là kẻ thù của chất lượng. Mắt người rất kém trong việc phát hiện lệch 2–4px hay hai sắc đỏ gần giống nhau. Mẹo: luôn dùng Dev Mode để đối chiếu số đo, dùng công cụ overlay để chồng ảnh, và kiểm tra màu bằng token name.
Lỗi: Báo lỗi mơ hồ. "Nút trông chưa đẹp" khiến engineer không biết sửa gì. Mẹo: mỗi báo cáo phải trả lời được "cụ thể sai ở đâu, đúng phải như thế nào, con số bao nhiêu".
Lỗi: Chỉ QA một lần ở cuối. Dồn toàn bộ QA vào phút chót khiến bạn phát hiện hàng loạt lỗi nghiêm trọng khi không còn thời gian sửa, buộc phải ship kèm lỗi hoặc delay. Mẹo: QA sớm và liên tục — bắt lỗi khi code đang viết dở rẻ hơn nhiều.
Lỗi: Quên các trạng thái "không vui". Designer thường chỉ vẽ happy path. Empty, loading, error là nơi bị bỏ quên nhiều nhất và cũng là nơi trải nghiệm dễ vỡ nhất. Mẹo: mỗi màn hình có dữ liệu động đều phải có ma trận trạng thái đầy đủ.
Lỗi: Bỏ qua tiếng Việt và nội dung thật. Thiết kế với chữ Lorem Ipsum ngắn gọn rồi vỡ layout khi gặp tên tiếng Việt có dấu dài. Mẹo: luôn QA với dữ liệu thật, tiếng Việt thật, số tiền lớn thật.
Mẹo về thái độ: Design QA không phải là "bắt lỗi engineer" mà là "cùng nhau đạt chất lượng". Cách bạn báo lỗi quyết định việc engineer coi bạn là đối tác hay là kẻ soi mói. Luôn ghi nhận phần làm tốt, báo lỗi khách quan bằng bằng chứng, và ưu tiên rõ ràng để không làm engineer ngợp.
Bài tập thực hành
- Lập ma trận trạng thái. Chọn một màn hình có dữ liệu động (ví dụ: danh sách đơn hàng). Liệt kê đầy đủ mọi trạng thái cần thiết kế: empty, loading, error, một phần tử, nhiều phần tử, edge case về độ dài nội dung và số lớn. Đối chiếu với thiết kế hiện có của bạn — bạn đang thiếu bao nhiêu trạng thái?
- Viết một Design QA report chuẩn. Lấy một sản phẩm thật đang chạy (một app Việt Nam bất kỳ), chụp một màn hình, và giả định thiết kế gốc. Viết 5 mục lỗi QA theo đúng mẫu: ảnh đối chiếu, mô tả kèm số đo, mức độ nghiêm trọng, tham chiếu nguồn. Tự đánh giá: engineer đọc report này có sửa đúng ngay không?
- QA bằng công cụ. Cài một extension so sánh overlay (như PerfectPixel), chồng một thiết kế Figma lên trang web thật tương ứng, và ghi lại mọi chênh lệch bạn tìm được. So sánh số lỗi tìm bằng công cụ với số lỗi bạn tưởng mình thấy bằng mắt.
Tóm tắt
Design QA là quy trình đảm bảo sản phẩm thực tế phản ánh đúng ý định thiết kế, và nó diễn ra ở ba thời điểm: trước dev (self-QA để kiểm tra tính đầy đủ), trong lúc dev (live QA trên staging để bắt lỗi visual sớm), và trước khi ship (final QA theo checklist). Ba trục cần soi là visual fidelity, interaction & states, và responsive & edge cases. Các lỗi nguy hiểm nhất không phải là lỗi to gây crash mà là những lỗi "gần đúng" cộng dồn và những trạng thái "không vui" bị bỏ quên. Chìa khóa để QA hiệu quả là: dùng công cụ đo thay vì QA bằng mắt, báo lỗi cụ thể có bằng chứng và phân loại ưu tiên, QA sớm và liên tục thay vì dồn vào phút chót, và luôn giữ tinh thần hợp tác với engineer. Làm chủ Design QA chính là bước biến bạn từ một người "vẽ đẹp" thành một designer thực sự chuyên nghiệp, người chịu trách nhiệm tới tận lúc sản phẩm chạm tay người dùng.