Wireframe, Mockup và Prototype khác nhau thế nào? Quy trình làm đúng thứ tự

Ba từ này bị dùng lẫn lộn ở khắp nơi, kể cả trong các buổi bảo vệ đồ án. Nhưng chúng là ba giai đoạn khác nhau, trả lời ba câu hỏi khác nhau, và làm sai thứ tự sẽ khiến bạn mất rất nhiều thời gian.

Cách nhớ đơn giản:

• Wireframe trả lời: Có những gì và sắp xếp ra sao?
• Mockup trả lời: Trông như thế nào?
• Prototype trả lời: Dùng thì cảm giác thế nào?

Bảng so sánh nhanh

Wireframe — khung xương

Wireframe là bản vẽ đơn giản chỉ gồm khối, đường và chữ đại diện. Không màu, không ảnh, không hiệu ứng — cố tình như vậy.

Vì sao phải xấu có chủ đích: khi bản vẽ trông thô sơ, người xem sẽ góp ý về cấu trúc ("thiếu bước xác nhận", "sao chức năng tìm kiếm lại nằm dưới cùng?"). Khi bản vẽ đã đẹp, họ chuyển sang góp ý về màu sắc và font — những thứ chưa cần bàn ở giai đoạn này.

Nên làm gì trong wireframe:

• Xác định các khối nội dung và vị trí của chúng.
• Ghi rõ nội dung thật (tiêu đề, nhãn nút), không dùng chữ giả kiểu "Lorem ipsum" — vì chữ giả che giấu vấn đề độ dài nội dung.
• Vẽ đủ các trạng thái quan trọng: danh sách rỗng, đang tải, có lỗi. Sinh viên gần như luôn quên ba trạng thái này.

Công cụ: giấy và bút là nhanh nhất cho vòng đầu. Sau đó chuyển sang Figma với các khối xám.

Mẹo: vẽ tay 8 phương án cho một màn hình trong 8 phút. Bạn sẽ thấy phương án thứ 6 thường tốt hơn phương án đầu tiên rất nhiều.

Mockup — bản mô phỏng giao diện

Mockup là bản tĩnh nhưng hoàn chỉnh về mặt thị giác: đúng màu, đúng font, đúng ảnh, đúng khoảng cách. Đây là thứ bạn đưa cho khách hàng xem để duyệt, hoặc đưa vào slide bảo vệ.

Cần chuẩn bị trước khi làm mockup:

• Bảng màu đã chốt (xem lý thuyết màu sắc).
• Thang cỡ chữ đã chốt (xem typography cơ bản).
• Hệ lưới và khoảng cách theo bội số 8 (xem bố cục và hệ lưới).

Lỗi thường gặp: làm mockup cho 20 màn hình rồi mới phát hiện cấu trúc sai và phải sửa cả 20. Đó chính là lý do phải làm wireframe trước.

Lưu ý về nội dung: dùng nội dung thật hoặc gần thật. Một danh sách sản phẩm với tên toàn 2 từ trông rất gọn trong mockup, nhưng sản phẩm thật có tên 15 từ sẽ phá vỡ bố cục.

Prototype — bản mẫu tương tác

Prototype là bản bấm được: nhấn nút này thì chuyển sang màn hình kia, có hiệu ứng chuyển cảnh, có thể nhập liệu giả.

Ba mức prototype:

Nguyên tắc quan trọng: prototype chỉ cần bấm được ở luồng bạn muốn kiểm tra. Đừng cố nối mọi nút của mọi màn hình — đó là công việc vô ích, vì người thử nghiệm chỉ đi theo một kịch bản.

Khi trình bày đồ án: một prototype bấm được luôn gây ấn tượng mạnh hơn 20 ảnh tĩnh, vì hội đồng thấy được sản phẩm vận hành.

Thứ tự chuẩn và những gì xảy ra khi làm sai

Thứ tự đúng: Nghiên cứu → Sơ đồ luồng → Wireframe → Kiểm thử nhanh → Mockup → Prototype → Kiểm thử → Bàn giao.

Hai lỗi thứ tự phổ biến:

1. Nhảy thẳng vào mockup. Bạn sẽ dành hàng chục giờ tô màu cho một cấu trúc chưa được kiểm chứng, và khi phát hiện sai, tâm lý "tiếc công" khiến bạn ngại sửa.
2. Làm prototype quá sớm. Nối liên kết cho bản wireframe thay đổi liên tục là công việc phải làm lại nhiều lần.

Một bước hay bị bỏ quên: sơ đồ luồng (user flow). Trước khi vẽ màn hình, hãy vẽ sơ đồ các bước người dùng đi qua bằng hình hộp và mũi tên. Bước này mất 30 phút nhưng tiết kiệm được nhiều ngày, vì nó cho bạn biết cần bao nhiêu màn hình và màn hình nào nối với màn hình nào.

Bàn giao cho lập trình viên

Nếu đồ án của bạn có nhóm lập trình, bản thiết kế cần kèm:

• Đủ trạng thái: mặc định, hover, đang tải, rỗng, lỗi, thành công.
• Quy tắc co giãn: phần tử nào giãn, phần tử nào giữ nguyên khi màn hình rộng ra.
• Bản mobile: ít nhất cho các màn hình chính.
• Thông số cụ thể: màu, cỡ chữ, khoảng cách — tốt nhất là dưới dạng style/variable trong Figma để lập trình viên đọc trực tiếp.
• Tài nguyên xuất sẵn: icon dạng SVG, ảnh đúng độ phân giải.

Thiếu các trạng thái là nguyên nhân số một khiến sản phẩm cuối cùng khác xa thiết kế: lập trình viên buộc phải tự đoán, và họ sẽ đoán theo cách nhanh nhất.

Câu hỏi thường gặp

Có bắt buộc làm cả ba không?

Không. Với một trang đơn giản, wireframe giấy rồi làm luôn mockup là đủ. Nhưng với sản phẩm có nhiều bước và nhiều màn hình, bỏ qua wireframe gần như chắc chắn sẽ phải làm lại.

Wireframe có cần đẹp không?

Không, nhưng cần rõ. Đủ rõ để người khác nhìn vào biết mỗi khối là gì. Wireframe được vẽ tay nguệch ngoạc nhưng có ghi chú rõ ràng vẫn tốt hơn wireframe đẹp mà mơ hồ.

Dùng công cụ nào để làm prototype?

Figma là lựa chọn phổ biến nhất và miễn phí cho sinh viên: dựng thiết kế và nối prototype trong cùng một file. Với bản mẫu giấy thì chỉ cần điện thoại quay lại quá trình thao tác.

Mockup và high-fidelity prototype khác nhau ra sao?

Mockup là ảnh tĩnh hoàn chỉnh về thị giác. High-fidelity prototype là các mockup đó được nối lại và bấm được. Nói cách khác, prototype mức cao là mockup cộng thêm tương tác.

Nên dành bao nhiêu thời gian cho mỗi giai đoạn?

Một tỷ lệ tham khảo cho đồ án 4 tuần: 25% nghiên cứu và luồng, 25% wireframe và thử nhanh, 35% mockup, 15% prototype và kiểm thử. Nếu bạn thấy mình dành hơn một nửa thời gian cho mockup, nhiều khả năng bạn đang làm đẹp thay vì giải quyết vấn đề.

Có nên dùng thư viện giao diện có sẵn không?

Nên, đặc biệt khi thời gian gấp. Dùng bộ component có sẵn giúp bạn tập trung vào cấu trúc và luồng thay vì vẽ lại từng nút bấm. Chỉ cần ghi rõ trong báo cáo là bạn đã sử dụng thư viện nào.

Nguồn tham khảo

• Nielsen Norman Group – Paper Prototyping
• Interaction Design Foundation – Prototyping
• Figma Learn – Prototyping

Kết luận

Ba giai đoạn này tồn tại vì một lý do kinh tế đơn giản: sửa một bản vẽ tay mất 2 phút, sửa một mockup mất 2 giờ, sửa một sản phẩm đã lập trình mất 2 tuần. Càng phát hiện sai sót sớm, chi phí càng thấp.

Lần tới khi bắt đầu một đồ án, hãy ép cả nhóm dành trọn ngày đầu tiên chỉ với giấy và bút. Đó là ngày rẻ nhất và có giá trị nhất trong toàn bộ dự án.

Bài viết liên quan

• Design Thinking là gì
• 10 nguyên tắc usability của Jakob Nielsen
• Học Figma cho người mới bắt đầu
• Design System là gì