Bài 40 — Mockup & wireframe annotation cho fresher

Mở đầu — vì sao bài này quan trọng

Bạn hãy tưởng tượng một buổi sáng thứ Hai tại một công ty fintech ở TP.HCM. Bạn — một BA fresher — vừa hoàn thành xong tài liệu requirement dài 12 trang, viết cực kỹ, câu chữ chỉn chu. Bạn tự tin gửi cho anh dev lead và anh designer. Ba mươi phút sau, anh dev nhắn: "Em ơi màn hình này cho anh xin cái hình được không? Đọc chữ anh không hình dung ra được layout." Còn anh designer thì hỏi: "Nút 'Xác nhận' nằm ở đâu, trên hay dưới danh sách? Khi trống thì hiện gì?"

Đó chính là khoảnh khắc bạn nhận ra: chữ viết một mình không đủ để mô tả giao diện. Con người xử lý hình ảnh nhanh hơn văn bản khoảng 60.000 lần. Một cái mockup có annotation (chú thích) rõ ràng sẽ tiết kiệm cho cả team hàng chục vòng hỏi-đáp qua lại, giảm hiểu nhầm, và quan trọng nhất — giúp bạn nắm quyền chủ động trong việc định nghĩa sản phẩm.

Nhiều bạn fresher nghĩ rằng vẽ mockup là việc của designer, còn viết requirement là việc của BA. Điều này chỉ đúng một nửa. Designer chịu trách nhiệm về thẩm mỹ và trải nghiệm hình ảnh, nhưng BA chịu trách nhiệm về hành vi, logic và ràng buộc của từng phần tử trên màn hình. Và cách BA truyền tải những thứ đó chính là thông qua annotation — những ghi chú gắn trực tiếp lên bản vẽ. Bài này sẽ dạy bạn phân biệt các mức độ chi tiết của bản vẽ (fidelity), cách annotate chuẩn nghiệp vụ, và cách biến một cái wireframe thô thành deliverable mà cả dev lẫn designer đều "đọc là hiểu, hiểu là làm được".

Khái niệm cốt lõi

Mockup, wireframe, prototype — đừng nhầm lẫn

Ba từ này bị dùng lẫn lộn rất nhiều, và một BA chuyên nghiệp cần phân biệt rạch ròi:

• Wireframe: bản vẽ khung xương của màn hình. Chỉ có bố cục (layout), vị trí các khối, không quan tâm màu sắc, font chữ hay hình ảnh thật. Giống như bản vẽ thiết kế nhà chỉ có tường và cửa, chưa sơn chưa nội thất.
• Mockup: bản vẽ tĩnh chi tiết hơn, đã có màu sắc, font, hình ảnh minh họa, gần giống giao diện thật. Nhưng vẫn không bấm được.
• Prototype: bản mô phỏng có tương tác — bấm nút này sẽ nhảy sang màn hình kia. Dùng để demo luồng và test với người dùng.

Với vai trò BA fresher, 80% thời gian bạn làm việc ở mức wireframe và đôi khi mockup. Bạn hiếm khi phải dựng prototype hoàn chỉnh (đó là việc designer). Điều bạn cần giỏi là annotation — lớp thông tin nghiệp vụ phủ lên trên bản vẽ.

Các mức độ chi tiết (Fidelity levels)

Fidelity nghĩa là "độ trung thực" — bản vẽ giống sản phẩm thật đến mức nào. Bạn chọn mức fidelity tùy theo giai đoạn dự án và đối tượng người xem.

Nguyên tắc vàng cho fresher: đừng dùng fidelity cao hơn mức cần thiết. Khi bạn đưa một bản hi-fi đẹp lộng lẫy vào buổi họp brainstorm sớm, stakeholder sẽ sa đà bàn màu nút xanh hay đỏ, thay vì bàn xem luồng nghiệp vụ đã đúng chưa. Ngược lại, một bản sketch tay lại "mời gọi" người xem góp ý thoải mái vì nó trông chưa hoàn thiện. Đây gọi là hiệu ứng "vẻ ngoài chưa hoàn thiện khuyến khích phản hồi".

Annotation là gì và tại sao nó là "chữ ký" của BA

Annotation là những chú thích đánh số, mũi tên, ghi chú gắn vào từng phần tử của bản vẽ để giải thích:

• Hành vi: khi bấm nút này thì điều gì xảy ra?
• Ràng buộc (validation): ô nhập này bắt buộc? tối đa bao nhiêu ký tự? định dạng gì?
• Trạng thái (states): khi danh sách trống thì hiện gì? khi đang tải thì sao? khi lỗi thì sao?
• Nguồn dữ liệu: con số này lấy từ đâu, tính thế nào?
• Phân quyền: ai được thấy nút này, ai không?
• Edge case: nếu người dùng nhập sai, mạng chậm, dữ liệu quá dài thì hệ thống ứng xử ra sao?

Một cái wireframe không annotation chỉ là bức tranh. Wireframe có annotation mới là tài liệu đặc tả. Đây chính là phần tạo ra giá trị của BA, và là thứ phân biệt một BA giỏi với người chỉ biết vẽ hộp.

Tình huống thực tế

Ví dụ 1: Màn hình đăng nhập tại một ví điện tử (bối cảnh Việt Nam)

Minh, BA fresher tại một công ty ví điện tử ở Hà Nội (giả định gọi là "PayGo"), được giao đặc tả màn hình đăng nhập. Bản đầu tiên Minh chỉ vẽ một wireframe low-fi: ô số điện thoại, ô mật khẩu, nút "Đăng nhập". Trông rất gọn. Nhưng khi review, anh dev lead hỏi liên tiếp: "Sai mật khẩu 5 lần thì sao? Số điện thoại nhập chữ thì báo gì? Có nút 'Quên mật khẩu' không? Đăng nhập bằng vân tay để đâu?"

Minh về sửa lại, thêm annotation đánh số:

• Ô số điện thoại — chỉ nhận 10 chữ số, bắt đầu bằng 0, hiển thị lỗi đỏ "Số điện thoại không hợp lệ" nếu sai định dạng.
• Ô mật khẩu — có icon con mắt để hiện/ẩn, tối thiểu 6 ký tự.
• Sau 5 lần sai — khóa 15 phút, hiện thông báo "Tài khoản tạm khóa, thử lại sau 15 phút".
• Link "Quên mật khẩu" — dẫn sang luồng OTP.
• Nút "Đăng nhập bằng vân tay/Face ID" — chỉ hiện nếu thiết bị đã bật sinh trắc học và user đã đăng nhập ít nhất 1 lần.

Bài học rút ra: Cùng một màn hình đơn giản, bản không annotation gây ra 8 câu hỏi và 2 ngày trễ. Bản có annotation được dev estimate và code luôn. Chi tiết nằm ở các trạng thái và edge case — chính là nơi BA tạo giá trị.

Ví dụ 2: Trang danh sách đơn hàng tại một sàn e-commerce (bối cảnh Đông Nam Á)

Lan làm BA tại một startup thương mại điện tử phục vụ thị trường Đông Nam Á. Cô đặc tả trang "Đơn hàng của tôi". Ban đầu cô chỉ vẽ một danh sách đơn hàng đầy đủ, đẹp đẽ — trạng thái mà designer gọi là "happy path". Khi bàn giao, mọi người tưởng xong. Nhưng đến lúc test, dev phát hiện: chưa ai định nghĩa màn hình khi user chưa có đơn hàng nào (empty state), khi đang tải (loading state), và khi mất mạng (error state).

Lan bổ sung annotation cho đủ 4 trạng thái của mọi màn hình danh sách:

• Empty state: minh họa giỏ hàng trống, dòng chữ "Bạn chưa có đơn hàng nào" + nút "Mua sắm ngay".
• Loading state: skeleton loading (khung xám nhấp nháy) trong lúc gọi API.
• Error state: "Không tải được đơn hàng. Kéo xuống để thử lại."
• Populated state: danh sách bình thường, phân trang 20 đơn/trang, sắp xếp mới nhất lên đầu.

Cô còn annotate rõ: mỗi đơn hiển thị mã đơn, ngày, tổng tiền (định dạng theo tiền tệ từng nước — VND không có phần thập phân, còn một số nước khác thì có), và badge trạng thái với màu quy ước (vàng = chờ xử lý, xanh = đã giao, đỏ = đã hủy).

Bài học rút ra: Fresher hay chỉ vẽ "happy path". BA giỏi luôn tự hỏi bốn câu: Trống thì sao? Đang tải thì sao? Lỗi thì sao? Đầy dữ liệu thì sao? Đây là checklist bạn nên dán lên màn hình máy tính.

Ví dụ 3: Sự cố "mockup quá đẹp" tại một dự án ngân hàng

Tại một dự án nội bộ của một ngân hàng ở TP.HCM, một BA có kinh nghiệm lỡ đưa bản hi-fi cực kỳ trau chuốt cho ban lãnh đạo trong buổi họp thống nhất luồng nghiệp vụ mở tài khoản. Kết quả: cả buổi họp 90 phút, lãnh đạo tranh luận về việc logo nên to hay nhỏ, nút màu xanh navy hay xanh dương — trong khi luồng xác thực eKYC (định danh điện tử) có một lỗ hổng logic thì không ai để ý. Hai tuần sau lỗi đó mới lộ ra và phải làm lại.

Bài học rút ra: Chọn sai fidelity làm lệch trọng tâm cuộc họp. Ở giai đoạn chốt luồng, hãy dùng low-fi để mọi người tập trung vào logic nghiệp vụ, không phải thẩm mỹ. Đẹp là chuyện của giai đoạn sau.

Hướng dẫn từng bước

Đây là quy trình 7 bước để đi từ zero đến một wireframe có annotation trở thành deliverable:

Bước 1 — Xác định mục tiêu màn hình và người dùng. Trước khi vẽ, trả lời: Màn hình này giúp ai làm gì? Ví dụ "giúp khách hàng xem lại lịch sử giao dịch trong 90 ngày". Một câu này định hướng toàn bộ layout.

Bước 2 — Liệt kê nội dung cần có (content inventory). Ghi ra mọi phần tử: tiêu đề, ô tìm kiếm, bộ lọc, danh sách, nút hành động. Đừng vẽ vội — cứ list ra trước bằng gạch đầu dòng.

Bước 3 — Sketch tay nhanh. Cầm bút vẽ 2-3 phương án bố cục trong 10 phút. Đừng cầu toàn. Mục tiêu là chọn hướng, không phải sản phẩm cuối.

Bước 4 — Dựng wireframe low-fi trên tool. Mở Figma hoặc Balsamiq, dựng lại phương án đã chọn bằng khối xám. Sắp xếp theo thứ bậc thị giác: quan trọng nhất ở trên/to hơn.

Bước 5 — Thêm annotation đánh số. Đây là bước quan trọng nhất. Đặt các con số 1, 2, 3... cạnh từng phần tử, rồi viết bảng chú thích bên cạnh hoặc bên dưới. Mỗi annotation nên gồm: phần tử → hành vi → ràng buộc → trạng thái đặc biệt.

Bước 6 — Bổ sung các state. Với mỗi màn hình, vẽ hoặc mô tả bốn trạng thái: empty, loading, error, populated. Với form, thêm trạng thái validation lỗi.

Bước 7 — Review với dev và designer. Ngồi cùng anh dev hỏi "chỗ nào chưa rõ để code?" và designer hỏi "chỗ nào bất khả thi về UX?". Ghi nhận, sửa, chốt phiên bản.

Một mẹo trình bày: đánh số annotation theo hướng đọc tự nhiên (trái sang phải, trên xuống dưới). Dùng màu khác nhau cho các loại chú thích — ví dụ vàng cho ràng buộc validation, xanh cho hành vi điều hướng, đỏ cho quy tắc phân quyền. Điều này giúp dev quét nhanh.

Lỗi thường gặp & mẹo

Lỗi 1: Vẽ đẹp quá sớm. Fresher hay khoe kỹ năng Figma bằng bản hi-fi từ đầu, khiến người xem bàn màu sắc thay vì logic. Mẹo: giai đoạn chốt luồng, cố tình để bản trông "thô" — dùng khối xám, font mặc định.

Lỗi 2: Chỉ vẽ happy path. Quên empty/loading/error state. Mẹo: dán checklist "Trống — Tải — Lỗi — Đầy" cạnh màn hình, kiểm mọi màn hình danh sách và form.

Lỗi 3: Annotation mơ hồ. Viết "validate ô này" mà không nói validate cái gì. Mẹo: annotation phải đo lường được — "tối đa 100 ký tự", "chỉ nhận số", "bắt buộc nhập" — chứ không phải "kiểm tra hợp lệ" chung chung.

Lỗi 4: Không định nghĩa nguồn dữ liệu. Vẽ ra một con số "Tổng: 1.250.000đ" mà không nói nó tính từ đâu. Mẹo: annotate "= tổng giá trị các đơn ở trạng thái Đã thanh toán, chưa gồm phí ship".

Lỗi 5: Bỏ qua responsive. Chỉ vẽ bản desktop mà quên mobile, trong khi ở Việt Nam đa số dùng điện thoại. Mẹo: với sản phẩm mobile-first, vẽ bản mobile trước, rồi mới suy ra desktop.

Lỗi 6: Coi mình là designer. BA sa đà chỉnh pixel, chọn font, phối màu — lấn sân designer và bỏ bê phần logic. Mẹo: nhớ ranh giới — BA lo hành vi, ràng buộc, dữ liệu; designer lo thẩm mỹ, trải nghiệm thị giác.

Mẹo bonus: Luôn để một ô "Ghi chú chung" (General notes) ở góc bản vẽ cho các quy tắc áp dụng toàn màn hình — ví dụ "mọi số tiền định dạng có dấu chấm phân cách hàng nghìn", "mọi ngày theo định dạng dd/mm/yyyy". Tránh lặp lại chú thích ở từng phần tử.

Bài tập thực hành

Bài 1 — Phân biệt fidelity (10 phút). Tìm 3 ảnh chụp màn hình app bạn hay dùng (Shopee, MoMo, Grab). Với mỗi ảnh, xác định nó tương ứng fidelity nào nếu bạn phải tái tạo cho các giai đoạn khác nhau, và giải thích khi nào bạn sẽ dùng bản sketch vs low-fi vs hi-fi.

Bài 2 — Wireframe có annotation (60 phút). Chọn một màn hình "Đăng ký tài khoản" cho một app giả định. Dùng Figma (bản miễn phí) hoặc Balsamiq, dựng wireframe low-fi rồi thêm ít nhất 8 annotation đánh số. Bắt buộc phải có: 3 ràng buộc validation, 1 quy tắc phân quyền hoặc điều kiện hiển thị, và mô tả trạng thái lỗi.

Bài 3 — Bốn trạng thái (30 phút). Lấy màn hình "Danh sách thông báo". Mô tả (vẽ hoặc viết annotation) đầy đủ cả bốn trạng thái: empty, loading, error, populated. Ghi rõ nội dung text hiển thị trong từng trạng thái.

Bài 4 — Review chéo (nếu học nhóm). Đổi bản wireframe với một bạn học. Đóng vai dev, đặt ít nhất 5 câu hỏi "chỗ này em chưa rõ để code". Người kia phải bổ sung annotation để trả lời hết. Đây là cách rèn tư duy anticipate câu hỏi của dev.

Tóm tắt

• Wireframe, mockup, prototype khác nhau: khung xương — bản tĩnh chi tiết — bản có tương tác. BA fresher chủ yếu làm ở mức wireframe và mockup.
• Chọn đúng fidelity theo giai đoạn: sketch để brainstorm, low-fi để chốt luồng, mid/hi-fi để bàn giao. Đừng dùng fidelity cao hơn cần thiết, kẻo lệch trọng tâm cuộc họp.
• Annotation là giá trị cốt lõi của BA: gắn chú thích về hành vi, ràng buộc, trạng thái, nguồn dữ liệu và phân quyền lên từng phần tử. Wireframe không annotation chỉ là bức tranh; có annotation mới là đặc tả.
• Luôn kiểm bốn trạng thái: Trống — Đang tải — Lỗi — Đầy dữ liệu. Đây là điểm fresher hay bỏ sót nhất.
• Annotation phải đo lường được: "tối đa 100 ký tự" thay vì "validate ô này".
• Giữ đúng ranh giới với designer: BA lo logic và hành vi, designer lo thẩm mỹ. Đừng lấn sân.

Nắm vững kỹ năng annotate wireframe, bạn sẽ thấy các cuộc họp với dev và designer trở nên trơn tru hẳn — vì bạn đã trả lời câu hỏi của họ ngay trên bản vẽ, trước cả khi họ hỏi. Đó chính là dấu hiệu của một BA đang trưởng thành.