Mở đầu — vì sao bài này quan trọng
Bạn đã viết một PRD chỉn chu: problem rõ ràng, goals sắc bén, user stories đầy đủ. Designer dựa vào đó dựng ra một bộ màn hình đẹp lung linh. Rồi tới ngày demo cho leadership, một người buông một câu: "Sao flow này lại bắt user nhập OTP hai lần?" — và cả phòng im lặng. Designer nhìn PM, PM nhìn designer. Hóa ra không ai từng ngồi xuống review thiết kế một cách có cấu trúc. Mọi người chỉ "thấy đẹp là duyệt".
Đây chính là lỗ hổng mà Design Review Process lấp vào. Nếu PRD là tài liệu mô tả cái gì và tại sao, thì design (wireframe, mock, prototype) là hiện thân trông như thế nào và user tương tác ra sao. Một quy trình review thiết kế tốt là cây cầu nối giữa hai thứ đó — nó đảm bảo cái designer dựng ra đúng với cái PM viết trong spec, đúng với nhu cầu user, và đủ chất lượng để ship.
Với vai trò PM, bạn không phải designer và không cần biết vẽ. Nhưng bạn là người chủ trì sự thống nhất giữa spec và design. Bạn là người đặt câu hỏi "màn hình này map với acceptance criteria nào?", "empty state ở đâu?", "khi mất mạng thì sao?". Nếu bạn không tổ chức được một quy trình review thiết kế mạch lạc, sản phẩm sẽ ship với những lỗ hổng mà lẽ ra phát hiện được trong 30 phút họp.
Bài này sẽ dạy bạn cách thiết lập và vận hành một Design Review Process bài bản — từ giai đoạn wireframe co-create cùng designer, tới mock review, tới critique, và cuối cùng là sign-off. Lưu ý: bài này tập trung riêng vào quy trình review thiết kế (design), khác với Engineering Review (bài 45) và PRD Review Meeting (bài 47). Đây là một mắt xích cụ thể trong chuỗi review trước khi ship.
Khái niệm cốt lõi
Design Review Process là chuỗi các buổi làm việc có cấu trúc giữa PM, designer và các bên liên quan, nhằm đảm bảo thiết kế: (1) giải đúng problem trong PRD, (2) phủ đủ các state và edge case đã spec, (3) đạt chất lượng hình ảnh/tương tác đủ để ship. Nó không phải là một buổi họp đơn lẻ, mà là nhiều phase với mục tiêu khác nhau.
Ba phase chính
Phase 1 — Wireframe (PM + designer co-create). Đây là giai đoạn phác thảo cấu trúc, chưa quan tâm màu sắc, font, pixel. Mục tiêu: chốt flow và information architecture. PM và designer ngồi cùng nhau, thường trên whiteboard (Figma FigJam, Miro, hoặc giấy), vẽ các khung xám đơn giản. Câu hỏi ở phase này là "user đi từ A tới B qua mấy bước?", "thông tin nào hiển thị ở màn hình nào?". Vì wireframe rẻ và nhanh, đây là lúc thử nghiệm nhiều phương án và vứt bỏ phương án dở mà không tốn công.
Phase 2 — Mock review (designer present hi-fi, get feedback). Sau khi flow đã chốt, designer dựng hi-fidelity mock — màn hình hoàn chỉnh với màu, font, spacing, component thật từ design system. Designer trình bày, các bên cho feedback. Đây là lúc PM đối chiếu từng màn hình với PRD: "Acceptance criteria số 3 nói khi user chưa có đơn hàng nào thì hiển thị empty state có nút 'Mua sắm ngay' — empty state đâu rồi?". Mock review thường có 1–2 vòng lặp.
Phase 3 — Critique (design critique). Critique là buổi review chuyên sâu giữa các designer với nhau (peer review), tập trung vào chất lượng thủ công nghề thiết kế: hệ thống phân cấp thị giác, tính nhất quán với design system, accessibility, micro-interaction. PM có thể tham dự để nghe và đặt câu hỏi về sản phẩm, nhưng critique về bản chất là designer giúp designer làm tốt hơn. Văn hóa critique tốt là "phản biện ý tưởng, không công kích con người".
Sign-off — chốt hạ
Sau ba phase, cần một bước sign-off: PM, design lead, và (tùy tổ chức) eng lead cùng xác nhận bằng văn bản rằng design này đã sẵn sàng để build. Sign-off không phải thủ tục hành chính — nó là điểm cam kết. Sau sign-off, mọi thay đổi design phải qua change request, không được sửa lén. Điều này bảo vệ engineer khỏi việc "design cứ đổi liên tục trong lúc tôi đang code".
Phân biệt với các review khác
Đừng nhầm Design Review với Engineering Review (xét tính khả thi kỹ thuật, effort, rủi ro hệ thống) hay PRD Review Meeting (duyệt toàn bộ tài liệu sản phẩm với stakeholder rộng). Design Review hẹp hơn và chuyên biệt: nó chỉ xoay quanh phần trải nghiệm và giao diện. Một feature có thể qua Design Review nhưng vẫn fail ở Engineering Review vì quá nặng để build — và ngược lại.
Vai trò của PM trong từng phase
PM không cầm bút vẽ, nhưng PM là "người gác cổng spec". Trong mỗi phase, công việc của PM là: mang theo PRD và acceptance criteria như một checklist sống, đối chiếu từng state, đặt câu hỏi về edge case, đảm bảo design không "trôi" khỏi scope đã chốt (scope creep qua đường thiết kế là cực kỳ phổ biến — designer hứng lên thêm tính năng "cho đẹp").
Tình huống thực tế
Ví dụ 1 — Ví MoMo: bỏ qua phase wireframe và cái giá phải trả
Một team giả định tại một ví điện tử lớn ở Việt Nam (gọi là "Ví M") làm tính năng "Chia hóa đơn" (split bill) cho nhóm bạn đi ăn. PM nóng lòng, bảo designer: "Em cứ làm hi-fi luôn cho nhanh, flow đơn giản mà". Designer bỏ qua wireframe, dựng thẳng 8 màn hình hi-fi mất 5 ngày.
Tới mock review, PM mới nhận ra flow sai căn bản: thiết kế cho phép người tạo nhóm tự chia tiền cho từng người, nhưng PRD ghi rõ mỗi thành viên phải tự xác nhận số tiền của mình trước khi chuyển (để tránh tranh chấp). Cả luồng phải làm lại — thêm bước xác nhận của từng người, đổi cả information architecture. 5 ngày công hi-fi gần như vứt đi, dự án trễ một sprint.
Bài học: Wireframe tồn tại để fail rẻ. Nếu Ví M làm wireframe trước, lỗi flow này lộ ra trong 2 tiếng phác thảo whiteboard chứ không phải sau 5 ngày dựng hi-fi. Đừng bao giờ nhảy thẳng vào hi-fi khi flow chưa được PM xác nhận khớp với PRD. Phase wireframe rẻ chính là vũ khí kiểm soát rủi ro của PM.
Ví dụ 2 — Tiki: critique cứu một màn hình "đẹp nhưng sai"
Một team sàn TMĐT giả định ("sàn T") thiết kế lại trang chi tiết sản phẩm trên mobile. Designer làm một bản hi-fi rất bóng bẩy: hình sản phẩm full màn hình, nút "Thêm vào giỏ" là một icon giỏ hàng tinh tế ở góc.
Trong buổi critique, một designer senior chỉ ra: nút CTA quan trọng nhất của trang (mua hàng) lại nhỏ và mờ nhạt nhất về mặt phân cấp thị giác — vi phạm nguyên tắc "hành động chính phải nổi bật nhất". Đồng thời, icon giỏ hàng đứng một mình không có nhãn chữ sẽ gây khó cho user lớn tuổi và fail tiêu chí accessibility. Họ chạy thử với một số liệu nội bộ: các nút CTA dạng "full-width có chữ" ở các trang khác có tỷ lệ chạm cao hơn khoảng 18% so với icon-only.
Designer chỉnh lại: nút "Thêm vào giỏ" thành thanh full-width màu thương hiệu, có chữ rõ ràng, ghim đáy màn hình. Khi A/B test sau này, biến thể mới tăng add-to-cart rate đáng kể.
Bài học: Critique không phải "chê cho vui". Nó là cơ chế để bắt những lỗi mà người dựng ra (vì quá yêu đứa con của mình) không thấy. PM nên ủng hộ văn hóa critique và tham dự để hiểu vì sao một quyết định thiết kế được đưa ra — đừng coi đó là "việc của designer".
Ví dụ 3 — Một startup SaaS B2B ở Singapore: sign-off lỏng lẻo gây hỗn loạn
Một startup SaaS giả định ở Singapore ("Co. S") làm dashboard phân tích cho khách doanh nghiệp. Design qua review, ai cũng gật đầu trong họp nhưng không có bước sign-off chính thức. Engineer bắt đầu code. Tuần sau, designer "tiện tay" cập nhật file Figma: đổi layout từ 3 cột sang 2 cột, đổi cả component biểu đồ.
Engineer vẫn đang code theo bản 3 cột vì không ai báo. Tới sprint review, sản phẩm build ra không khớp Figma, đổ lỗi qua lại. Mất gần một tuần để đồng bộ lại và làm lại phần frontend.
Sau sự cố, Co. S áp dụng quy tắc: design phải có sign-off bằng comment chính thức trên Figma ("Approved for build — [tên PM], [ngày]"), và file được khóa version. Mọi thay đổi sau sign-off phải tạo một thread change request, gắn người duyệt, và thông báo cho engineer. Số lần "build sai vì design đổi" giảm hẳn.
Bài học: Sign-off không phải thủ tục rườm rà — nó là hợp đồng. Nó tạo ra một "đường ranh giới" rõ ràng giữa "design đang được hoàn thiện" và "design đã chốt để build". Thiếu ranh giới này, engineer luôn bắn vào mục tiêu di động.
Hướng dẫn từng bước
Dưới đây là quy trình bạn có thể áp dụng ngay cho feature tiếp theo.
Bước 1 — Chuẩn bị trước khi review (PM làm). Trước khi gọi bất kỳ buổi review nào, hãy chắc PRD đã ổn định: problem, goals, user stories, acceptance criteria, và đặc biệt là danh sách các state (empty, loading, error, success) cùng edge case. Đây là checklist sống bạn mang vào mọi buổi review. Không có checklist này, review sẽ trôi theo cảm tính.
Bước 2 — Wireframe co-create. Đặt một buổi 60–90 phút với designer (và 1–2 engineer nếu flow phức tạp). Cùng phác thảo các luồng chính trên FigJam/Miro. Mục tiêu cụ thể: chốt số bước trong flow và thông tin trên từng màn hình. Đầu ra: wireframe được PM xác nhận "flow này khớp PRD". Tuyệt đối chưa bàn màu sắc.
Bước 3 — Designer dựng hi-fi. Để designer làm việc độc lập, dựa trên wireframe đã chốt. PM không can thiệp vào chi tiết pixel, nhưng sẵn sàng trả lời câu hỏi về logic sản phẩm.
Bước 4 — Mock review. Buổi 45–60 phút. Designer trình bày từng màn hình. PM cầm acceptance criteria, đối chiếu từng dòng: "AC1 — màn nào? AC2 — màn nào? Empty state — đâu? Error state khi API fail — đâu?". Ghi lại feedback dưới dạng action item có người chịu trách nhiệm và deadline. Lặp lại bước này nếu cần (thường tối đa 2 vòng).
Bước 5 — Design critique. Designer chủ trì, mời các designer khác phản biện chất lượng nghề: phân cấp thị giác, nhất quán design system, accessibility, micro-interaction. PM tham dự để lắng nghe và bảo vệ ràng buộc sản phẩm. Giữ tinh thần "phản biện ý tưởng, không công kích người".
Bước 6 — Sign-off. Khi mọi feedback đã xử lý, tổ chức sign-off. PM, design lead (và eng lead nếu cần) xác nhận bằng văn bản — comment trên Figma hoặc một dòng trong PRD: "Design approved for build — [tên], [ngày], [link version Figma]". Khóa version file.
Bước 7 — Quản lý thay đổi sau sign-off. Thiết lập quy tắc: mọi thay đổi design sau sign-off phải qua change request — mô tả thay đổi, lý do, người duyệt, và thông báo cho engineer. Không sửa lén file Figma.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhảy thẳng vào hi-fi, bỏ qua wireframe. Như ví dụ Ví M, đây là lỗi tốn kém nhất. Mẹo: luôn yêu cầu một bản wireframe được xác nhận trước khi cho phép dựng hi-fi, kể cả với feature "đơn giản".
Lỗi 2 — PM review thiết kế bằng cảm tính "đẹp/xấu". PM không phải designer; đừng tranh cãi về màu nút xanh hay xanh đậm. Việc của bạn là đối chiếu design với spec và user need. Mẹo: mỗi nhận xét của bạn nên gắn với một acceptance criteria, một edge case, hoặc một mục tiêu sản phẩm — không phải gout cá nhân.
Lỗi 3 — Quên các state phụ. Designer thường chỉ làm "happy path" — màn hình khi mọi thứ hoàn hảo. PM phải chủ động hỏi: empty, loading, error, partial, offline, no-permission. Mẹo: mang theo một checklist state cố định vào mọi mock review.
Lỗi 4 — Critique biến thành công kích cá nhân. Văn hóa critique độc hại sẽ khiến designer thủ thế và che giấu vấn đề. Mẹo: dùng ngôn ngữ "Tôi lo rằng user sẽ bối rối ở chỗ này vì..." thay vì "Cái này làm sai rồi". Phản biện artefact, không phản biện người.
Lỗi 5 — Không có sign-off rõ ràng. Như Co. S, thiếu ranh giới chốt design dẫn tới build sai. Mẹo: biến sign-off thành một dấu mốc bắt buộc, ghi lại version, và truyền thông rõ cho engineer.
Lỗi 6 — Scope creep qua đường design. Designer hứng lên thêm tính năng "cho đẹp" không có trong PRD. Mẹo: PM phải bắt được và hỏi "tính năng này map với goal nào trong PRD?". Nếu không có, đẩy sang backlog, không nhét vào scope hiện tại.
Mẹo tổng quát — async review. Với team phân tán hoặc nhiều múi giờ (phổ biến ở các công ty Đông Nam Á làm việc với đối tác nước ngoài), kết hợp review bất đồng bộ: designer ghi một video Loom 5 phút walkthrough, mọi người comment trực tiếp trên Figma, chỉ họp live cho những điểm tranh cãi. Tiết kiệm thời gian và để lại dấu vết quyết định.
Bài tập thực hành
Hãy chọn một feature bạn đang hoặc sắp làm (nếu chưa có, dùng feature giả định: "thêm tính năng đánh giá sao cho đơn hàng đã giao trong app giao đồ ăn").
- Lập checklist review từ PRD. Liệt kê tất cả acceptance criteria và toàn bộ các state (empty, loading, error, success, edge case) mà design phải phủ. Đây là tài liệu bạn sẽ cầm vào buổi review.
- Viết agenda cho buổi mock review. Soạn agenda 45 phút: ai trình bày, thứ tự màn hình, và 10 câu hỏi cụ thể bạn sẽ hỏi designer (mỗi câu gắn với một AC hoặc một edge case).
- Soạn mẫu sign-off. Viết một template comment sign-off chuẩn cho team bạn, bao gồm: trạng thái duyệt, người duyệt, ngày, link version Figma, và quy tắc thay đổi sau sign-off.
- Đóng vai critique. Lấy một màn hình bất kỳ trong app bạn đang dùng hàng ngày (Shopee, Grab, MoMo...). Viết 3 nhận xét critique theo đúng tinh thần "phản biện ý tưởng": mỗi nhận xét nêu vấn đề, lý do (gắn với user hoặc nguyên tắc thiết kế), và gợi ý hướng giải quyết.
Tóm tắt
Design Review Process là cây cầu nối giữa PRD (cái gì/tại sao) và sản phẩm thật (trông thế nào/tương tác ra sao). Nó gồm các phase rõ ràng: Wireframe (PM + designer co-create để chốt flow một cách rẻ), Mock review (đối chiếu hi-fi với từng acceptance criteria và state), Critique (designer phản biện nhau về chất lượng nghề), và Sign-off (chốt hạ bằng văn bản, khóa version, kiểm soát thay đổi).
Vai trò của PM không phải vẽ đẹp, mà là người gác cổng spec: mang PRD và checklist state vào mọi buổi review, đảm bảo design không trôi khỏi scope, không bỏ sót edge case, và được chốt rõ ràng trước khi engineer bắt đầu build. Như ba ví dụ đã thấy — bỏ qua wireframe khiến Ví M trễ một sprint, critique cứu màn hình của sàn T, và sign-off lỏng lẻo gây hỗn loạn ở Co. S — mỗi mắt xích đều có cái giá thật nếu làm ẩu.
Hãy nhớ nguyên tắc cốt lõi: fail rẻ ở wireframe, đối chiếu kỷ luật ở mock review, phản biện thẳng thắn ở critique, và chốt dứt khoát ở sign-off. Một quy trình review thiết kế tốt không làm chậm bạn — nó cứu bạn khỏi việc làm lại, và đó mới là thứ thực sự tốn thời gian.