Mở đầu — vì sao bài này quan trọng
Một trong những hiểu lầm tốn kém nhất mà tôi thấy ở các PM mới vào nghề là tin rằng "spec đẹp = spec có mock thật đẹp". Họ mở Figma lên, chăm chút từng pixel, chọn màu, đổ shadow, canh khoảng cách, rồi dán cái mock lung linh đó vào PRD draft và gửi cho cả team. Kết quả? Buổi review biến thành một cuộc tranh luận về việc nút màu xanh hay tím, font size 14 hay 16, trong khi câu hỏi quan trọng nhất — "luồng này có giải quyết đúng vấn đề của người dùng không?" — chưa ai chạm tới.
Wireframe và hi-fi mock là hai công cụ hình ảnh phục vụ hai mục đích hoàn toàn khác nhau trong vòng đời của một spec. Dùng sai thời điểm, bạn không chỉ lãng phí thời gian của chính mình mà còn kéo cả designer, engineer vào những cuộc thảo luận lệch trọng tâm. Ngược lại, khi bạn biết chính xác lúc nào nên vẽ ô vuông xám, lúc nào cần mock pixel-perfect, bạn sẽ rút ngắn đáng kể thời gian từ ý tưởng đến quyết định, và quan trọng hơn — giữ cho mọi người tranh luận đúng thứ cần tranh luận ở đúng giai đoạn.
Bài này tập trung riêng vào việc phân biệt và lựa chọn giữa wireframe và hi-fi mock trong spec/PRD: bản chất từng loại, khi nào dùng cái nào, và cách đưa chúng vào tài liệu một cách hiệu quả. Đây là một kỹ năng "meta" — nó không dạy bạn vẽ đẹp, mà dạy bạn vẽ đủ cho mục đích đang cần.
Khái niệm cốt lõi
Hãy hình dung một thước đo gọi là độ trung thực (fidelity). Một bên là bản phác càng sơ sài càng tốt, bên kia là bản mô phỏng giống hệt sản phẩm thật. Wireframe nằm ở đầu thấp, hi-fi mock nằm ở đầu cao. Hiểu được trục này, bạn sẽ tự biết mình đang cần đứng ở đâu.
Wireframe — bản phác độ trung thực thấp
Wireframe (đôi khi gọi là low-fi, lo-fi) là bản vẽ bố cục bằng các khối đơn giản: hộp xám đại diện cho ảnh, gạch ngang đại diện cho text, ô vuông cho nút. Đặc trưng của wireframe:
- Grayscale: không màu, hoặc chỉ dùng vài sắc xám. Việc bỏ màu là có chủ đích — nó buộc người xem không bị phân tâm bởi thẩm mỹ mà tập trung vào cái gì nằm ở đâu.
- Tập trung vào layout và content hierarchy: phần tử nào quan trọng nhất, đặt ở đâu, theo thứ tự nào. Header trước hay search bar trước? CTA nằm trên hay dưới fold?
- Iterate nhanh: vẽ một wireframe chỉ tốn vài phút. Bạn có thể vẽ năm phương án bố cục khác nhau trong một buổi sáng và vứt bỏ bốn cái mà không thấy tiếc.
- Không có chi tiết tương tác tinh tế: không animation, không micro-interaction, không state đẹp. Chỉ là xương sống.
Hi-fi mock — bản mô phỏng độ trung thực cao
Hi-fi mock (high-fidelity mockup) là bản thiết kế gần như giống hệt sản phẩm cuối: đúng màu thương hiệu, đúng font, đúng icon, đúng ảnh thật, đúng khoảng cách. Đặc trưng:
- Final visual: đây là cái mà engineer sẽ nhìn vào để code ra giao diện thật. Nó thể hiện ngôn ngữ thiết kế của sản phẩm.
- Đầy đủ chi tiết: state hover, state disabled, màu lỗi, độ tương phản, responsive breakpoint — tất cả đều được thể hiện hoặc ít nhất được gợi ý rõ.
- Tốn công: làm một hi-fi mock tốn nhiều giờ, đôi khi nhiều ngày, vì mỗi pixel đều có chủ đích.
- Khó iterate: thay đổi một quyết định bố cục lớn ở giai đoạn hi-fi nghĩa là làm lại nhiều thứ.
Mối liên hệ với spec/PRD
Đây là điểm mấu chốt cho PM. Trong PRD, vai trò của mỗi loại rất khác:
- Trong PRD draft / giai đoạn khám phá vấn đề: dùng wireframe. Lúc này bạn đang muốn cả team đồng thuận về hướng giải pháp, không phải về thẩm mỹ. Wireframe vừa đủ để minh họa ý tưởng, vừa đủ "xấu" để mọi người tự nhiên góp ý về luồng thay vì màu sắc.
- Trong PRD bản chốt / giai đoạn chuẩn bị build: tham chiếu đến hi-fi mock (thường do designer làm trong Figma), thường dưới dạng link kèm các annotation về hành vi. PRD không nên chứa hi-fi mock như nguồn chân lý duy nhất — nó nên trỏ tới file thiết kế và mô tả hành vi bằng chữ.
Một bậc trung gian: mid-fi
Thực tế có một mức ở giữa gọi là mid-fi (medium fidelity), thường là wireframe có thêm chút cấu trúc thật, dùng component có sẵn nhưng vẫn grayscale hoặc màu tối giản. Nhiều team dùng mid-fi như điểm cân bằng: đủ rõ để demo cho stakeholder không quen đọc wireframe thô, nhưng vẫn nhanh để sửa. Bạn không cần phân biệt quá cứng nhắc — quan trọng là hiểu trục fidelity và chọn điểm phù hợp.
Tình huống thực tế
Ví dụ 1 — Tính năng "ví trả sau" của một ví điện tử Việt Nam
Một PM tại ví điện tử (giả định tên MoMoPay) phụ trách tính năng "trả sau" (buy-now-pay-later). Ở sprint đầu, anh ấy mở Figma và mất hai ngày làm một bộ hi-fi mock cực đẹp cho cả 6 màn hình: onboarding, xét duyệt hạn mức, chọn kỳ hạn, xác nhận, lịch trả, nhắc nợ.
Khi mang vào buổi PRD review, chuyện xảy ra đúng như dự đoán: trưởng nhóm rủi ro hỏi "tại sao bước xét duyệt hạn mức lại nằm sau khi người dùng đã chọn món hàng? Nếu bị từ chối thì trải nghiệm rất tệ". Đây là một vấn đề về luồng, và nó khiến toàn bộ thứ tự màn hình phải đảo lại. Hai ngày làm mock đẹp gần như vứt đi.
Bài học: nếu anh ấy bắt đầu bằng wireframe grayscale vẽ trong 30 phút, vấn đề thứ tự luồng sẽ lộ ra ngay trong buổi đầu, sửa chỉ tốn vài phút. Hi-fi mock chỉ nên xuất hiện sau khi luồng đã được chốt. Quy tắc: vấn đề càng dễ phát hiện sớm, càng nên dùng công cụ rẻ tiền để phát hiện nó.
Ví dụ 2 — Tính năng tìm chỗ ở của một nền tảng du lịch Đông Nam Á
Một PM ở nền tảng đặt phòng (giả định tên Traveloka-clone) cần thiết kế lại trang kết quả tìm kiếm khách sạn. Cô ấy làm đúng quy trình: bắt đầu bằng việc vẽ bốn wireframe cho bốn cách sắp xếp khác nhau — danh sách dọc kèm bản đồ bên phải, danh sách full-width, lưới thẻ 2 cột, và bản đồ toàn màn hình có thẻ trượt ngang.
Cô ấy dán cả bốn wireframe vào PRD draft, mỗi cái kèm một dòng giải thích trade-off: phương án bản đồ tốn dữ liệu hơn nhưng tốt cho người chưa rõ điểm đến; phương án lưới 2 cột tốt cho mobile nhưng giảm thông tin mỗi thẻ. Buổi review tập trung đúng vào trade-off này, team chọn được phương án danh sách dọc kèm bản đồ trong vòng 40 phút.
Chỉ sau đó, designer mới dựng hi-fi mock cho phương án đã chốt, với màu thương hiệu, ảnh khách sạn thật, badge "Còn 2 phòng", giá gạch ngang khuyến mãi. PRD bản cuối chứa link tới Figma hi-fi kèm các annotation: "Khi hết phòng, thẻ chuyển grayscale và badge đổi thành 'Hết phòng'" — phần hành vi này được mô tả bằng chữ trong spec, không chỉ dựa vào hình.
Bài học: wireframe để khám phá và quyết định, hi-fi để truyền đạt cái đã quyết. Và PRD nên mô tả hành vi bằng chữ song song với hình, vì hình tĩnh không bao giờ thể hiện hết các state động.
Ví dụ 3 — Cái bẫy "mock đẹp khiến stakeholder tưởng đã xong"
Tại một startup edtech ở TP.HCM, một PM trình hi-fi mock rất chỉn chu cho tính năng "lớp học trực tiếp" trong buổi họp với ban giám đốc — chỉ để xin phản hồi định hướng. Vì mock quá đẹp và thật, CEO tưởng tính năng "gần xong rồi", liền hứa với một đối tác lớn rằng sẽ ra mắt trong 3 tuần. Thực tế lúc đó engineer còn chưa viết một dòng code, và luồng kỹ thuật (đặc biệt phần streaming video) còn nhiều câu hỏi mở.
Bài học: độ trung thực của hình ảnh tạo ra kỳ vọng về độ hoàn thiện. Khi trình bày ở giai đoạn sớm, dùng wireframe không chỉ tiết kiệm công mà còn là một tín hiệu trung thực với stakeholder rằng "đây mới là ý tưởng, chưa phải sản phẩm". Hình càng thật, người xem càng tin nó sắp xong — hãy dùng đặc tính này một cách có chủ đích.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên dùng khi đưa yếu tố hình ảnh vào spec.
- Xác định bạn đang ở giai đoạn nào của quyết định. Hỏi: "Câu hỏi lớn nhất chưa được trả lời là gì?" Nếu đó là câu hỏi về vấn đề, luồng, cấu trúc thông tin → bạn đang ở giai đoạn cần wireframe. Nếu luồng đã chốt và câu hỏi còn lại là trông thế nào, build ra sao → giai đoạn cần hi-fi.
- Nếu là wireframe: vẽ nhiều phương án, đừng chỉ một. Sức mạnh của low-fi là cho phép so sánh. Vẽ 2–4 bố cục, mỗi cái kèm một dòng trade-off. Giữ grayscale, dùng placeholder cho text và ảnh. Đừng để bản thân sa đà vào căn chỉnh.
- Đưa wireframe vào PRD draft kèm câu hỏi mở. Đừng dán hình rồi để đó. Mỗi wireframe nên đi kèm: mục tiêu của màn hình, giả định đang đặt ra, và câu hỏi bạn muốn team trả lời. Ví dụ: "Phương án B đặt CTA dưới fold — liệu tỉ lệ chuyển đổi có giảm không?"
- Chốt luồng trong buổi review trước khi nâng fidelity. Đảm bảo team đồng thuận về hướng trước khi bất kỳ ai bỏ giờ làm hi-fi. Đây là cổng kiểm soát quan trọng nhất.
- Chuyển giao cho designer làm hi-fi cho phương án đã chốt. Cung cấp wireframe đã duyệt + mô tả hành vi. Designer sẽ áp ngôn ngữ thiết kế, component thật, state đầy đủ.
- Trong PRD bản cuối, trỏ tới hi-fi bằng link sống và bổ sung annotation hành vi bằng chữ. Đừng nhúng ảnh tĩnh làm nguồn chân lý — file Figma sẽ thay đổi và ảnh sẽ lỗi thời. Link tới frame cụ thể, và viết rõ những thứ hình không thể hiện: state rỗng, lỗi, loading, edge case.
- Đánh dấu rõ độ trung thực và trạng thái của mỗi hình. Ghi nhãn "Wireframe — đang thảo luận" hay "Hi-fi — đã chốt v2". Người đọc cần biết họ đang nhìn thứ có thể thay đổi hay thứ đã đóng băng.
Lỗi thường gặp & mẹo
Lỗi: Nhảy thẳng vào hi-fi mock. Đây là lỗi phổ biến nhất. Hi-fi đẹp khiến ta thấy "làm việc năng suất", nhưng nó khóa cứng các quyết định trước khi chúng được kiểm chứng. Mẹo: tự đặt luật cá nhân "không mở color picker cho đến khi luồng được duyệt".
Lỗi: Wireframe quá đẹp đến mức bị tưởng là hi-fi. Nếu wireframe của bạn có màu, có font đẹp, người xem sẽ phản hồi về thẩm mỹ. Mẹo: cố tình giữ nó "xấu" — grayscale, dùng font Comic Sans hoặc nét vẽ tay nếu cần, để báo hiệu rõ "đây mới là bản nháp".
Lỗi: Coi mock là spec đầy đủ. Hình ảnh không bao giờ mô tả hết hành vi — đặc biệt là các state động, edge case, lỗi. Mock đẹp tới đâu cũng không nói cho engineer biết chuyện gì xảy ra khi mất mạng. Mẹo: luôn có phần chữ mô tả hành vi song song với hình.
Lỗi: Nhúng ảnh tĩnh thay vì link sống. Ảnh dán vào doc sẽ lỗi thời ngay khi designer chỉnh Figma, tạo ra "hai nguồn chân lý" mâu thuẫn. Mẹo: luôn link tới frame Figma cụ thể; chỉ nhúng ảnh khi cần minh họa nhanh và ghi rõ "ảnh chụp ngày X, xem link để biết bản mới nhất".
Mẹo về công cụ: với wireframe, ưu tiên công cụ nhanh — Excalidraw, Balsamiq, hoặc thậm chí vẽ tay chụp ảnh. Với hi-fi, đó là sân chơi của Figma do designer dẫn dắt. Đừng để PM tự ôm hi-fi nếu team đã có designer; vai trò của PM là mô tả hành vi và mục tiêu, không phải pixel.
Mẹo về văn hóa team: thống nhất trước với team ngôn ngữ chung về fidelity. Khi mọi người hiểu "đây là wireframe" nghĩa là "đừng bàn màu", các buổi review sẽ trôi chảy hơn rất nhiều.
Bài tập thực hành
- Phân loại fidelity. Lấy ba tài liệu thiết kế bất kỳ bạn từng thấy (trong công ty, trên Dribbble, hay screenshot một app). Với mỗi cái, xác định nó đang ở đâu trên trục fidelity (low / mid / high) và viết một câu lý giải nó phù hợp cho giai đoạn quyết định nào.
- Vẽ wireframe đa phương án. Chọn một tính năng đơn giản (ví dụ: màn hình "lịch sử giao dịch" của một app ngân hàng). Vẽ tay hoặc dùng Excalidraw để tạo ba wireframe grayscale với ba cách bố cục khác nhau. Mỗi cái kèm đúng một dòng trade-off. Tự giới hạn 20 phút.
- Viết annotation hành vi cho hi-fi. Tưởng tượng bạn vừa nhận hi-fi mock cho màn hình kết quả tìm kiếm. Viết 5 annotation bằng chữ mô tả những điều hình không thể hiện: state rỗng (không có kết quả), state loading, lỗi mất mạng, state khi chỉ còn 1 item, và hành vi khi người dùng kéo refresh.
- Tự kiểm điểm. Nhìn lại spec gần nhất bạn viết. Bạn đã dùng đúng fidelity cho giai đoạn đó chưa? Nếu được làm lại, bạn sẽ thay đổi điều gì về cách dùng hình ảnh?
Tóm tắt
Wireframe và hi-fi mock không phải là hai mức độ "nháp" và "hoàn thiện" của cùng một thứ — chúng là hai công cụ cho hai mục đích khác nhau. Wireframe là low-fi, grayscale, tập trung vào layout và content hierarchy, iterate nhanh, dùng trong PRD draft để khám phá và quyết định luồng. Hi-fi mock là final visual, đầy đủ chi tiết, tốn công, dùng để truyền đạt và build chính xác cái đã chốt.
Nguyên tắc vàng: độ trung thực của hình nên tỉ lệ thuận với độ chắc chắn của quyết định. Đừng đốt giờ vào pixel khi luồng còn mơ hồ; và khi đã chốt, hãy trỏ tới hi-fi bằng link sống kèm annotation hành vi bằng chữ, vì hình tĩnh không bao giờ kể hết câu chuyện. Nắm vững việc chọn đúng công cụ ở đúng thời điểm, bạn sẽ giữ cho mỗi buổi review tranh luận đúng thứ cần tranh luận — và đó là một trong những kỹ năng âm thầm nhưng tạo khác biệt lớn nhất của một PM giỏi.