Mở đầu — vì sao bài này quan trọng
Bạn đã từng mất ba tuần để thiết kế một màn hình hoàn hảo trên Figma: spacing chuẩn từng pixel, màu sắc đúng token, animation mượt mà. Rồi đến ngày sản phẩm lên production, bạn mở app ra và... tim hơi chùng xuống. Nút bấm bị lệch 8px, font weight sai, trạng thái hover biến mất, và cái animation tâm huyết thì không thấy đâu. Bản thiết kế của bạn và bản thực tế người dùng nhìn thấy là hai thứ khác nhau.
Đây chính xác là khoảng cách mà Design QA sinh ra để lấp đầy. Trong nghề Product Designer, có một sự thật phũ phàng: thiết kế đẹp trên Figma không có nghĩa lý gì nếu nó được code ra một cách cẩu thả. Người dùng không bao giờ nhìn thấy file Figma của bạn — họ chỉ trải nghiệm sản phẩm thật. Vì vậy, công việc của một designer không kết thúc ở handoff (bàn giao cho engineer), mà còn kéo dài đến tận lúc kiểm tra sản phẩm đã build xong.
Nhiều bạn designer trẻ ở Việt Nam thường nghĩ QA (Quality Assurance — đảm bảo chất lượng) là việc của tester hoặc QC. Đúng là họ kiểm tra chức năng (bấm nút này có chạy không, form này submit được không), nhưng họ thường KHÔNG kiểm tra độ trung thực về mặt thị giác và trải nghiệm. Một nút bấm lệch màu vẫn "chạy đúng chức năng" — tester sẽ cho pass, nhưng với con mắt designer thì đó là lỗi. Đó là lý do Design QA tồn tại và là một kỹ năng phân biệt giữa designer nghiệp dư và chuyên nghiệp.
Khái niệm cốt lõi
Phân biệt Design Review và Design QA
Hai khái niệm này rất hay bị nhầm lẫn, nhưng chúng diễn ra ở hai thời điểm hoàn toàn khác nhau trong vòng đời sản phẩm.
Design Review (đánh giá thiết kế) diễn ra trước khi build. Đây là lúc designer trình bày bản thiết kế của mình cho stakeholder — có thể là design lead, Product Manager, hoặc cả team. Mục tiêu là trả lời câu hỏi: "Chúng ta có nên build cái này không? Thiết kế này đã giải quyết đúng vấn đề chưa?" Review tập trung vào ý tưởng, luồng người dùng, tính khả thi, và sự phù hợp với mục tiêu kinh doanh. Nó xảy ra khi sản phẩm vẫn còn nằm trên Figma, chưa một dòng code nào được viết.
Design QA diễn ra sau khi build. Đây là lúc designer mở sản phẩm đã được engineer code xong (thường trên môi trường staging hoặc preview) và đối chiếu từng chi tiết với bản thiết kế gốc. Mục tiêu là trả lời câu hỏi: "Bản code này có khớp với bản thiết kế không?" Nó tập trung vào độ trung thực của implementation (cách hiện thực hóa) — spacing, màu sắc, typography, trạng thái tương tác, responsive.
Hãy nhớ công thức đơn giản:
- Design Review = trước build = đánh giá Ý TƯỞNG.
- Design QA = sau build = xác minh THỰC THI.
Bốn lớp cần kiểm tra trong Design QA
Khi làm Design QA, đừng kiểm tra một cách ngẫu hứng kiểu "nhìn qua thấy ổn là được". Hãy chia nhỏ thành các lớp để không bỏ sót:
Lớp 1 — Visual (Thị giác): Đây là lớp quen thuộc nhất. Kiểm tra màu sắc có đúng token không, font family/size/weight/line-height có khớp không, spacing và padding có chuẩn không, border-radius và shadow có đúng không, hình ảnh và icon có đúng kích thước và độ phân giải không.
Lớp 2 — Interaction (Tương tác): Lớp này hay bị bỏ quên nhất. Kiểm tra các trạng thái: hover, focus, active, disabled, pressed. Một nút bấm có thể đẹp ở trạng thái mặc định nhưng khi hover lại không đổi màu, hoặc khi disabled vẫn cho phép click. Kiểm tra cả animation và transition — chúng có đúng tốc độ và easing không.
Lớp 3 — Responsive & Adaptive: Kiểm tra giao diện ở các kích thước màn hình khác nhau: mobile, tablet, desktop. Ở Việt Nam, lưu lượng truy cập mobile thường chiếm 70-80%, nên đừng bao giờ bỏ qua màn hình nhỏ. Kiểm tra cả trường hợp nội dung dài (tên người dùng quá dài có bị tràn không) và nội dung ngắn.
Lớp 4 — Edge cases & States: Kiểm tra empty state (chưa có dữ liệu), loading state, error state, và các trường hợp dữ liệu cực đoan. Phần này tôi sẽ chỉ nhắc lướt vì nó là chủ đề sâu của các bài sau, nhưng trong Design QA bạn cần xác nhận chúng đã được build đúng như đã thiết kế.
Định nghĩa "khớp" như thế nào cho hợp lý
Một sai lầm phổ biến là yêu cầu khớp 100% từng pixel một cách cứng nhắc. Thực tế, có những khác biệt nhỏ là chấp nhận được do giới hạn kỹ thuật của trình duyệt hay nền tảng. Một designer chuyên nghiệp biết phân biệt: cái nào là lỗi thật sự ảnh hưởng trải nghiệm, cái nào là chi tiết vụn vặt không đáng tranh cãi. Hãy phân loại lỗi theo mức độ ưu tiên: P0 (chặn release — ví dụ layout vỡ hoàn toàn), P1 (nghiêm trọng — sai màu thương hiệu), P2 (nhỏ — lệch 2px). Điều này giúp engineer biết phải sửa gì trước.
Tình huống thực tế
Ví dụ 1 — Startup fintech tại TP.HCM và nút "Chuyển tiền" lệch màu
Một startup fintech (giả định tên MoMoney) ở TP.HCM chuẩn bị ra mắt tính năng chuyển tiền mới. Designer tên Linh đã thiết kế nút "Chuyển tiền" với màu cam thương hiệu chính xác là #FF6B00. Khi build xong lên staging, Linh làm Design QA và phát hiện engineer đã hardcode màu #FF7A1A — lệch một chút, mắt thường gần như không nhận ra trên một màn hình.
Nhiều người sẽ tặc lưỡi cho qua. Nhưng Linh đối chiếu bằng công cụ color picker và phát hiện ra vấn đề gốc rễ: engineer không lấy màu từ design token mà tự gõ tay một mã hex theo trí nhớ. Điều này có nghĩa là toàn bộ các nút primary khác trong app cũng có thể bị sai tương tự, và mỗi lần thương hiệu đổi màu, sẽ phải sửa thủ công hàng chục chỗ.
Bài học rút ra: Design QA không chỉ là bắt lỗi bề mặt mà còn giúp phát hiện vấn đề hệ thống. Một lỗi nhỏ về màu hé lộ rằng quy trình dùng token chưa được tuân thủ. Linh đã ghi chú lại và làm việc với team để engineer luôn tham chiếu token thay vì gõ hex, tiết kiệm vô số giờ sửa lỗi về sau.
Ví dụ 2 — Sàn thương mại điện tử và trạng thái hover biến mất
Một sàn thương mại điện tử khu vực Đông Nam Á (giả định) đang làm lại trang chi tiết sản phẩm. Designer đã thiết kế các thẻ sản phẩm (product card) với hiệu ứng hover rất tinh tế: khi rê chuột vào, thẻ nâng lên 4px kèm shadow đậm hơn, tạo cảm giác "có thể click". Hiệu ứng này quan trọng vì nó báo hiệu sự tương tác.
Khi build xong, team chỉ kiểm tra trên môi trường mô phỏng mobile (nơi không có hover) và cho pass. Đến khi lên production, người dùng desktop — chiếm 35% doanh thu — không thấy bất kỳ phản hồi nào khi rê chuột. Các thẻ trông "chết cứng". Phải đến khi designer tự mình mở trên laptop và làm Design QA đầy đủ trên cả desktop, lỗi mất hover mới được phát hiện. Hóa ra engineer đã quên implement state :hover vì nó không có trong spec bàn giao rõ ràng.
Bài học rút ra: Phải làm Design QA trên đúng thiết bị và đủ các trạng thái tương tác. Đừng giả định "build xong là xong". Lớp Interaction (tương tác) là lớp dễ bị bỏ sót nhất vì nó không hiện ra trong ảnh chụp tĩnh. Sau vụ này, team bổ sung checklist bắt buộc kiểm tra hover/focus/active cho mọi thành phần có thể click.
Ví dụ 3 — App đặt lịch và nỗi đau của tên tiếng Việt có dấu
Một app đặt lịch khám bệnh tại Hà Nội thiết kế màn hình hồ sơ bệnh nhân rất gọn gàng. Trong Figma, designer dùng tên mẫu "Nguyễn Văn A" — ngắn gọn, vừa khít. Khi build và làm Design QA với dữ liệu thật, designer thử nhập một tên dài thực tế: "Nguyễn Hoàng Phương Thảo Linh". Lập tức layout vỡ — tên bị tràn ra ngoài card, đè lên avatar, và phần chữ có dấu (như "ờ", "ả") bị cắt mất phần dấu phía trên do line-height quá chật.
Đây là lỗi rất đặc thù cho thị trường Việt Nam: tiếng Việt có dấu thanh và dấu mũ chồng lên nhau, cần line-height rộng hơn tiếng Anh. Nếu chỉ QA bằng dữ liệu mẫu tiếng Anh hay tên ngắn, lỗi này sẽ lọt lưới.
Bài học rút ra: Design QA phải dùng dữ liệu thực tế và cực đoan, đặc biệt với bối cảnh ngôn ngữ địa phương. Designer Việt Nam cần chủ động kiểm tra tên dài, chữ có dấu, số tiền lớn (hàng tỷ đồng), và ngày tháng theo định dạng Việt. Đây là chi tiết mà các template thiết kế từ nước ngoài thường không lường trước.
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ọi dự án:
Bước 1 — Chuẩn bị môi trường đối chiếu. Mở song song hai cửa sổ: một bên là bản thiết kế Figma gốc, một bên là sản phẩm đã build trên staging/preview. Lý tưởng nhất là dùng hai màn hình hoặc chia đôi màn hình. Đảm bảo bạn QA trên đúng phiên bản code mới nhất, không phải bản cũ.
Bước 2 — Đi từ tổng thể đến chi tiết. Đầu tiên nhìn tổng quan cả màn hình: bố cục có đúng không, có thành phần nào thiếu hoặc thừa không. Sau đó mới zoom vào từng thành phần. Đừng sa vào chi tiết một nút bấm khi cả layout đang sai.
Bước 3 — Quét theo bốn lớp. Lần lượt kiểm tra Visual → Interaction → Responsive → States như đã nói ở trên. Dùng công cụ hỗ trợ: extension đo pixel (như PerfectPixel), color picker để so màu, DevTools của trình duyệt để kiểm tra font và spacing thực tế.
Bước 4 — Ghi chú lỗi một cách hành động được. Mỗi lỗi cần có: ảnh chụp màn hình (kèm khoanh vùng), mô tả ngắn gọn ("Padding nút primary là 12px, thiết kế là 16px"), mức ưu tiên (P0/P1/P2), và link tới phần thiết kế gốc. Đừng viết chung chung kiểu "nút này nhìn sai sai".
Bước 5 — Bàn giao lỗi qua đúng kênh. Tổng hợp lỗi vào một nơi engineer dễ theo dõi — thường là ticket trên Jira, hoặc comment trực tiếp trên công cụ như những bình luận gắn vào màn hình. Phân loại để engineer biết sửa gì trước.
Bước 6 — Kiểm tra lại (re-QA). Sau khi engineer báo đã sửa, đừng tin lời, hãy tự mở lại và xác nhận. Vòng lặp này có thể lặp 1-2 lần là bình thường. Chỉ đánh dấu "done" khi bạn đã tận mắt thấy lỗi được khắc phục.
Lỗi thường gặp & mẹo
Lỗi: QA quá muộn. Nhiều designer chỉ làm QA vào phút chót trước khi release, khiến không đủ thời gian sửa. Mẹo: làm QA sớm và liên tục — ngay khi engineer build xong một phần, hãy QA phần đó luôn thay vì đợi build hết toàn bộ.
Lỗi: Chỉ QA trên một thiết bị. Build trên laptop của designer trông ổn, nhưng trên điện thoại Android tầm trung — thiết bị phổ biến nhất ở Việt Nam — lại vỡ. Mẹo: luôn QA tối thiểu trên một mobile thật, một desktop, và nếu được thì cả trình duyệt khác nhau (Chrome, Safari).
Lỗi: Báo lỗi với thái độ phán xét. Viết kiểu "engineer làm ẩu quá" sẽ phá vỡ quan hệ làm việc. Mẹo: báo lỗi dựa trên dữ liệu khách quan, đối chiếu với thiết kế, không công kích cá nhân. "Chỗ này lệch 8px so với spec" tốt hơn nhiều so với "code sai rồi".
Lỗi: Không phân biệt lỗi với giới hạn kỹ thuật. Đôi khi engineer không thể làm khớp 100% vì giới hạn nền tảng. Mẹo: lắng nghe lý do kỹ thuật, và cùng tìm phương án thay thế hợp lý thay vì khăng khăng đòi đúng từng pixel.
Mẹo vàng: Hãy xây dựng một Design QA checklist chuẩn cho team và tái sử dụng cho mọi dự án. Một checklist tốt giúp việc QA không phụ thuộc vào trí nhớ và đảm bảo không ai bỏ sót lớp tương tác hay edge case.
Bài tập thực hành
- Tự QA một sản phẩm thật. Chọn một website hoặc app bạn hay dùng (ví dụ một sàn TMĐT Việt Nam). Mở trên cả desktop và mobile, rồi liệt kê ít nhất 5 điểm không nhất quán về thị giác hoặc tương tác (ví dụ: nút thiếu hover state, spacing lệch, tên dài bị tràn). Phân loại chúng theo P0/P1/P2.
- Tạo Design QA checklist của riêng bạn. Viết một checklist gồm 4 lớp (Visual, Interaction, Responsive, States) với ít nhất 3 mục kiểm tra cụ thể cho mỗi lớp. Lưu lại để dùng cho dự án thực tế.
- Mô phỏng bàn giao lỗi. Lấy một lỗi bạn tìm được ở bài tập 1, viết một "QA ticket" hoàn chỉnh gồm: ảnh chụp khoanh vùng, mô tả khác biệt cụ thể (giá trị thực tế vs giá trị mong muốn), mức ưu tiên, và đề xuất cách sửa. Luyện viết sao cho engineer đọc xong là làm được ngay.
Tóm tắt
Design QA là bước cuối nhưng không kém quan trọng để đảm bảo những gì người dùng thấy đúng với những gì bạn đã thiết kế. Hãy ghi nhớ:
- Design Review trước build (đánh giá ý tưởng) khác với Design QA sau build (xác minh thực thi). Dự án tốt cần cả hai.
- QA theo bốn lớp: Visual, Interaction, Responsive, States — lớp Interaction là lớp dễ bị bỏ sót nhất.
- Làm QA trên thiết bị thật và với dữ liệu thực tế, cực đoan — đặc biệt với tên tiếng Việt có dấu và tên dài.
- Báo lỗi khách quan, có ưu tiên, hành động được, và luôn re-QA sau khi sửa.
- Một lỗi nhỏ có thể hé lộ vấn đề hệ thống (như không dùng token) — QA là cơ hội cải thiện quy trình, không chỉ vá lỗi.