Wireframe
Bản vẽ xám của một màn hình: chỗ nào đặt cái gì, bấm vào thì đi đâu, chưa quan tâm màu sắc hay font chữ. Dùng để chốt bố cục và luồng thao tác trước khi ai đó bỏ công tô vẽ.
Định nghĩa
Bản vẽ xám của một màn hình: chỗ nào đặt cái gì, to nhỏ ra sao, bấm vào thì nhảy đi đâu. Không màu, không font đẹp, không ảnh thật, chữ có khi còn để lorem ipsum. Ở khá nhiều team VN, người vẽ wireframe đầu tiên là BA chứ chưa tới lượt designer — vẽ để chốt luồng với khách trước, rồi mới giao cho designer tô.
Wireframe trả lời câu hỏi màn này có gì và bấm đi đâu, chứ chưa trả lời màn này đẹp chưa.
Wireframe vs Mockup vs Prototype
| Tiêu chí | Wireframe | Mockup | Prototype |
|---|---|---|---|
| Độ chi tiết | Khung xám, chữ giả, ô vuông thay ảnh | Nội dung thật, đúng icon, đúng khoảng cách | Tuỳ bản gốc: nối wireframe ra bản lo-fi, nối mockup ra bản hi-fi |
| Màu sắc | Không, hoặc chỉ đen - trắng - xám | Đúng bảng màu và nhận diện thương hiệu | Kế thừa từ bản được đem đi nối |
| Tương tác | Không có | Không, đây là ảnh tĩnh | Có: bấm, chuyển màn, đôi khi nhập liệu |
| Công cụ | Balsamiq, draw.io, Whimsical, giấy A4 | Figma, Sketch, Penpot | Figma prototype, Axure, ProtoPie |
| Giai đoạn | Đầu phân tích, khi luồng còn đổi mỗi ngày | Sau khi chốt luồng, trước khi dev code | Trước buổi demo khách hoặc trước usability test |
| Ai làm | BA hoặc PO, đôi khi vẽ tay ngay trong họp | Designer | Designer là chính, BA ghép link trong Figma cũng được |
Adobe XD từng nằm trong danh sách công cụ ở dòng thứ tư, nhưng Adobe đã ngừng bán từ 2023 và chỉ còn vá lỗi, đừng chọn cho dự án mới.
Đọc bảng trên theo trục chi phí sửa thì dễ nhớ hơn: sửa một wireframe mất mười phút, sửa mockup mất nửa buổi, sửa cái đã code xong mất cả sprint. Đó là toàn bộ lý do người ta chịu khó vẽ xấu trước.
Ai làm, làm lúc nào
- Sau khi có user story hoặc use case ở mức luồng, trước khi viết chi tiết field-level.
- Vẽ ngay trong buổi họp với người dùng nghiệp vụ. Vẽ tay lên bảng trắng rồi chụp lại vẫn tính là wireframe.
- Mỗi màn một wireframe, kèm chú thích đánh số: 1 - nút này ẩn khi đơn đã duyệt, 2 - danh sách phân trang 20 dòng. Phần chú thích mới là phần BA đóng góp giá trị, cái hộp xám thì ai vẽ cũng được.
Ví dụ thực tế
Chuỗi spa, mười mấy chi nhánh, đang đặt lịch bằng sổ và điện thoại bàn. Lễ tân ghi tay rồi tối nhập lại vào một file Excel dùng chung — hôm nào hai người nhập cùng lúc là mất một nửa. Yêu cầu ban đầu gói gọn trong một câu: "khách chọn dịch vụ rồi đặt giờ". BA vẽ wireframe màn đặt lịch trong 20 phút, đưa cho quản lý chi nhánh xem. Chị quản lý nhìn ba giây rồi hỏi: chọn kỹ thuật viên ở đâu, khách quen toàn đặt theo tên người làm.
Câu hỏi đó làm phát sinh một bước mới trong luồng, thêm màn chọn kỹ thuật viên, thêm ràng buộc lịch bận của từng người. Nếu phát hiện ở giai đoạn wireframe thì chỉ là vẽ thêm một hộp xám. Nếu phát hiện sau khi designer đã làm xong 14 màn high-fidelity và dev đã code hai màn thì đó là một CR, kèm họp, kèm re-estimate, kèm mặt nặng mày nhẹ.
Lỗi hay gặp
- Vẽ wireframe đẹp quá. Đổ màu, chọn font, canh pixel. Khách nhìn vào là bắt đầu góp ý màu nút thay vì góp ý luồng, còn designer thì thấy bị lấn sân. Wireframe xấu là cố tình xấu.
- Wireframe không có chú thích. Dev nhận được một bức ảnh, không biết trạng thái rỗng hiển thị gì, không biết lỗi validate nằm chỗ nào. Bốn tuần sau sẽ có câu quen thuộc: "cái này spec không có".
- Chỉ vẽ đường hạnh phúc: thiếu màn hết dữ liệu, thiếu trạng thái đang tải, thiếu lỗi mất mạng. Ba màn đó chiếm phần lớn bug UI ở giai đoạn SIT.
Lỗi thứ tư khó thấy hơn ba lỗi trên, vì nó không nằm trên bản vẽ: vẽ xong rồi cất trong máy. Wireframe chưa ai xác nhận thì vẫn là bản nháp cá nhân, và nếu lại không đánh số bản thì đến lúc có người nói "hôm trước chốt kiểu khác mà", bạn chẳng lôi ra được bằng chứng nào. Gửi kèm biên bản họp, ghi ngày, ghi số bản.
Khi khách khó tính về thẩm mỹ, cứ dùng bản vẽ tay chụp bằng điện thoại cho vòng đầu. Nó phát tín hiệu rất rõ rằng đây là bản nháp và mọi người được phép đập đi, thứ mà một file Figma sạch sẽ không bao giờ nói được.
