Bỏ qua tới nội dung
Kiến thức Website· ·12 phút đọc

Wireframe, mockup, prototype khác nhau ở chỗ nào và làm theo thứ tự nào

Nguyen Hien
Wireframe, mockup, prototype khác nhau ở chỗ nào và làm theo thứ tự nào
Cỡ chữ

Câu hỏi wireframe mockup prototype khác nhau ở đâu là câu nhiều chủ dự án hỏi ngay khi nhận file đầu tiên từ đội thiết kế.

Nếu bạn vừa nhận email từ đội thiết kế và thấy ba file tên “wireframe”, “mockup” và “prototype”, thì bạn đang nhận ba thứ rất khác nhau. Phân biệt được chúng giúp bạn biết mình đang ở đâu trong quy trình, nên phản hồi cái gì ở mỗi bước, và khi nào mới tới lúc bấm thử website.

Ba khái niệm, ba bước, ba mục đích khác nhau

Wireframe (khung sườn trang) là bước đầu tiên. Đây là phác thảo đen trắng, chỉ thể hiện bố cục: đặt menu ở đâu, nội dung chính chiếm bao nhiêu, ảnh ở vị trí nào, nút nằm chỗ nào. Chưa có màu sắc, chưa có ảnh thật, và không bấm được. Mục đích duy nhất của wireframe là thống nhất về cấu trúc trước khi đi vào thiết kế.

Mockup (bản thiết kế đầy đủ) là bước tiếp theo. Từ wireframe, đội thiết kế thêm màu sắc thương hiệu, font chữ, ảnh thật (hoặc ảnh giả), biểu tượng và toàn bộ chi tiết hình thức. Mockup trông gần như website thật nhưng vẫn là ảnh tĩnh, không bấm được.

Prototype (bản mẫu tương tác) là bước thêm tương tác vào. Người dùng bấm thử được: chuyển trang, mở menu, xem animation. Đây là cái đội thiết kế gửi link để bạn “bấm thử xem nhé”.

Bảng phân biệt wireframe mockup prototype khác nhau

Nhìn vào bảng dưới để thấy ngay điểm khác nhau giữa ba bước theo 5 tiêu chí quan trọng nhất:

Bảng so sánh wireframe, mockup và prototype theo 5 tiêu chí: mức chi tiết, màu sắc, tương tác, ai duyệt và chi phí sửa
Tiêu chíWireframeMockupPrototype
Mức chi tiếtThấp, đen trắngCao, đầy đủ màuCao, có tương tác
Có màu sắcChưa
Bấm đượcChưaChưa
Ai duyệtPM, UX, chủ dự ánDesigner, khách hàngKhách hàng, user test
Chi phí sửaThấp nhấtVừaCao hơn, nhưng vẫn rẻ hơn sau khi code
Thứ tự wireframe, mockup, prototype trong quy trình làm website: từ bố cục đến giao diện đến tương tác rồi code

Wireframe đặt câu hỏi về bố cục, không phải màu sắc

Dùng bản vẽ đơn giản, không màu, là cố ý: để ép tất cả mọi người tập trung vào cấu trúc thay vì bị phân tâm bởi màu xanh hay font chữ. Ở giai đoạn wireframe, câu hỏi cần trả lời là: nội dung quan trọng nhất đặt ở đâu, có bao nhiêu mục trong menu, trang đó cần mấy phần nội dung.

Phản hồi đúng ở giai đoạn này: “tôi muốn nút liên hệ nổi bật hơn”, “phần giới thiệu dịch vụ đặt trước phần về chúng tôi”, “thêm ô tìm kiếm ở header”. Không phải thời điểm để nói “tôi muốn màu xanh dương” hay “font này không hợp”, vì đó là câu hỏi của mockup.

Mockup hỏi về cách trông, không phải cách dùng

Khi nhận mockup, những điều cần nhìn vào là: màu sắc có đúng nhận diện thương hiệu không, font chữ có dễ đọc không, ảnh đại diện có phù hợp không, tổng thể trông có đàng hoàng không.

Điều không nên yêu cầu ở giai đoạn mockup: thay đổi cấu trúc trang lớn vì đó là việc của wireframe, hay hỏi về tốc độ tải hay cách hoạt động của form vì đó là việc của lập trình. Mockup chỉ trả lời câu hỏi “trông như thế nào”, không hơn không kém.

Một điểm thường bị bỏ qua khi duyệt mockup là tỉ lệ kích thước thực tế trên màn hình. File Figma khi mở trên laptop 14 inch trông khác với khi xem trên màn hình 27 inch, và khác nữa khi thu nhỏ để xem cùng lúc nhiều frame. Nếu có thể, hãy xem mockup ở kích thước 100% (full size) trên thiết bị bạn hay dùng nhất, vì đó mới là cảm giác người dùng thật sẽ có.

Prototype hỏi về trải nghiệm thật

Sau mockup, đội thiết kế thêm tương tác để bạn bấm thử. Lúc này bạn có thể kiểm tra: luồng điều hướng có tự nhiên không, CTA (call to action, nút kêu gọi hành động) đặt đúng chỗ chưa, bố cục trên điện thoại trông ra sao.

Prototype là cơ hội duy nhất để phát hiện vấn đề trước khi code. Sửa trong giai đoạn này không phát sinh thêm chi phí lập trình. Sau khi code xong rồi mới phát hiện luồng đặt lịch bị lỗi, chi phí sửa sẽ cao hơn nhiều tùy phạm vi thay đổi.

Phản hồi đúng loại ở từng bước thiết kế: câu hỏi nên hỏi khi duyệt wireframe, mockup và prototype

Không phải dự án nào cũng cần đủ ba bước

Website đơn giản như trang giới thiệu 5 trang cho doanh nghiệp nhỏ đôi khi có thể bỏ qua giai đoạn wireframe riêng biệt, thiết kế thẳng vào mockup khi bố cục đã rõ ràng. Nhiều đội thiết kế gộp wireframe và mockup lại thành “thiết kế sơ bộ” rồi “thiết kế hoàn chỉnh”.

Ngược lại, ứng dụng phức tạp với nhiều luồng người dùng và trường hợp đặc biệt thì cả ba bước đều cần thiết. Dự án ecommerce (thương mại điện tử) với giỏ hàng, thanh toán nhiều bước, và trang tài khoản khách hàng thường cần prototype kỹ trước khi code vì một lỗi luồng ở đây ảnh hưởng trực tiếp tới doanh thu.

Khi nào dự án cần đủ ba bước wireframe, mockup, prototype và khi nào có thể rút ngắn

Chủ doanh nghiệp nên duyệt bước nào và cần chú ý gì

Ở bước wireframe, bạn chỉ cần trả lời câu hỏi về nội dung và bố cục. Tập trung vào: thứ tự nội dung có đúng ưu tiên không, mục nào đang thiếu, mục nào có thể bỏ. Đừng lo về màu sắc, vì nó chưa có ở đây.

Ở bước mockup, nhìn như một khách hàng mới vào lần đầu: ấn tượng đầu tiên có tốt không, màu sắc có phù hợp ngành không, chữ có dễ đọc không. Ở bước prototype, đi qua đúng luồng khách hàng thật, không phải chỉ nhìn từng màn hình rời. Mỗi bước có câu hỏi riêng, hỏi đúng chỗ giúp tiết kiệm thời gian sửa cho cả hai bên.

Ví dụ thực tế ba bước cho một trang đặt lịch khám nha khoa

Wireframe: vẽ bố cục trang bằng hình chữ nhật xám. Phần đầu trang có logo và menu. Bên dưới là tiêu đề lớn, bên phải là form chọn ngày và giờ. Dưới cùng là phần giới thiệu bác sĩ và nút liên hệ. Không màu sắc, không ảnh, không font chữ cụ thể. Bạn duyệt và nói: “Thêm một ô chọn loại dịch vụ (nhổ răng, trám răng…) vào form”.

Mockup: cùng bố cục đó nhưng nay đã có màu trắng và xanh mint (xanh nhạt) theo thương hiệu phòng khám, ảnh phòng khám thật, font chữ rõ, nút “Đặt lịch” màu xanh nổi. Bạn duyệt và nói: “Ảnh banner trông hơi tối, làm sáng lên một chút” hoặc “Font chữ tiêu đề quá nhỏ so với màn hình rộng”.

Prototype: file Figma cho phép bấm thử. Bạn chọn loại dịch vụ, chọn ngày từ lịch, chọn bác sĩ, điền tên và số điện thoại, bấm “Xác nhận” và thấy trang cảm ơn. Bạn phát hiện: “Trang chọn ngày giờ ở màn hình điện thoại bị chật, không bấm được lịch nhỏ vậy”, và đội thiết kế chỉnh lại trước khi code.

Ba bước đó diễn ra theo đúng thứ tự này. Phản hồi về bố cục ở wireframe, phản hồi về hình thức ở mockup, phản hồi về trải nghiệm ở prototype. Lẫn lộn thứ tự sẽ khiến đội thiết kế phải làm lại nhiều hơn cần thiết.

Câu hỏi thường gặp về sự khác nhau giữa wireframe, mockup và prototype

Duyệt wireframe và mockup, cái nào trước?

Wireframe trước, vì đó là lúc thay đổi bố cục ít tốn công nhất. Sau khi chốt wireframe mới sang mockup để duyệt hình thức. Duyệt ngược lại tốn công của cả hai bên vì khi đội thiết kế đã làm xong mockup đầy đủ màu rồi mới phát hiện bố cục cần đổi, phải làm lại nhiều hơn.

Tôi nhận file Figma, đó là wireframe, mockup hay prototype?

Tùy giai đoạn đội thiết kế gửi. Figma dùng được cho cả ba. Nếu file chỉ có màu xám đen trắng thì là wireframe. Nếu đầy đủ màu nhưng không bấm được thì là mockup. Nếu bấm được và chuyển trang được thì là prototype. Cách nhanh nhất: bấm thử một nút bất kỳ, nếu có gì xảy ra thì là prototype.

Sau khi duyệt prototype xong đội thiết kế mới code, vậy tôi còn duyệt thêm không?

Sau khi code xong, đội thiết kế thường cho bạn xem bản thật trước khi đưa lên server chính (gọi là staging site, máy chủ kiểm thử). Đây là lần kiểm tra cuối trước khi ra mắt. Lúc này tập trung vào nội dung, tốc độ và các tính năng kỹ thuật, vì giao diện đã được chốt từ prototype.

Nếu dự án nhỏ và chỉ có mockup, tôi cần hỏi thêm gì để đảm bảo?

Hỏi thẳng đội thiết kế: luồng điều hướng chính (khách vào trang chủ rồi đi đâu tiếp, tìm thông tin liên hệ bằng cách nào) đã được kiểm tra chưa. Nếu không có prototype thì đội thiết kế cần tự xem lại luồng đó trong đầu và xác nhận với bạn. Việc bỏ qua prototype chấp nhận được khi phạm vi nhỏ và rõ ràng, nhưng không phải lý do để bỏ qua kiểm tra luồng hoàn toàn.

Đọc tiếp

Bài viết
cùng chủ đề.

Tất cả bài viết