Mở đầu — vì sao bài này quan trọng
Có một sự thật mà nhiều BA mới vào nghề học được theo cách đau đớn: một bản mô tả yêu cầu dài 20 trang viết bằng văn bản thuần túy thường tạo ra ít sự đồng thuận hơn một bản phác thảo giao diện nguệch ngoạc trên giấy A4. Lý do rất con người — stakeholder không sống trong tài liệu, họ sống trong màn hình. Khi bạn nói "hệ thống sẽ hiển thị danh sách đơn hàng kèm bộ lọc theo trạng thái", mỗi người trong phòng họp đang tưởng tượng một màn hình khác nhau. Wireframe biến những hình dung mơ hồ đó thành một vật thể chung để mọi người cùng chỉ tay vào và tranh luận.
Wireframe là bản vẽ khung của một màn hình — bố cục các khối thông tin, vị trí nút bấm, luồng chuyển trang — mà chưa quan tâm đến màu sắc, font chữ hay hình ảnh đẹp. Nó nằm ở tầng giữa: cao hơn một danh sách requirements khô khan, nhưng thấp hơn một bản thiết kế UI hoàn chỉnh. Với vai trò BA, wireframe là vũ khí để bạn validate yêu cầu trước khi đội dev viết một dòng code nào, và đó chính là nơi chi phí sửa sai rẻ nhất.
Trong bài này, chúng ta tập trung hẹp vào hai công cụ wireframing được dùng nhiều nhất trên thị trường — Balsamiq và Figma — khi nào chọn cái nào, cách dùng từng cái ở mức một BA cần, và những cái bẫy khiến wireframe phản tác dụng. Bài này không bàn về lý thuyết prototyping nói chung (đó là việc của các bài lân cận), mà đi sâu vào kỹ năng tay nghề với hai tool cụ thể.
Khái niệm cốt lõi
Wireframe khác gì mockup và prototype
Trước khi bàn công cụ, cần phân biệt rạch ròi ba khái niệm hay bị lẫn lộn. Wireframe là khung xương — bố cục và nội dung, thường ở dạng đen trắng hoặc xám, mức độ chi tiết thấp (low-fidelity). Mockup là wireframe đã được khoác lên màu sắc, font, hình ảnh — tức bản thiết kế tĩnh có độ trung thực cao (high-fidelity) nhưng chưa bấm được. Prototype là bản có thể tương tác — bấm nút này nhảy sang màn hình kia, mô phỏng luồng thật.
Balsamiq và Figma đều có thể tạo ra cả ba loại, nhưng mỗi tool có "vùng sở trường" riêng. Hiểu được điều này là chìa khóa để chọn đúng.
Balsamiq — cố tình trông xấu để stakeholder không bị phân tâm
Đặc điểm nhận diện của Balsamiq là phong cách "sketchy" — mọi thứ trông như vẽ tay bằng bút chì, dùng font giống chữ viết tay (Comic-style). Đây không phải hạn chế kỹ thuật, mà là một triết lý thiết kế có chủ đích.
Ưu điểm cốt lõi: vì wireframe trông rõ ràng là bản nháp, stakeholder sẽ không "fixate" — không bị dính chặt — vào các chi tiết hình ảnh. Họ sẽ không hỏi "sao nút này màu xanh nhạt quá" hay "logo nên to hơn" trong khi điều bạn cần thảo luận là "luồng đặt hàng có thiếu bước xác nhận địa chỉ không". Phong cách thô mộc gửi đi một thông điệp ngầm: đây mới là ý tưởng, hãy góp ý về cấu trúc, đừng góp ý về thẩm mỹ. Ngoài ra Balsamiq học rất nhanh — một BA chưa từng thiết kế bao giờ có thể dựng một màn hình trong 15 phút nhờ thư viện UI control kéo-thả sẵn (button, dropdown, table, tab, breadcrumb...).
Nhược điểm: Balsamiq tương tác hạn chế — bạn có thể link các màn hình để click chuyển trang, nhưng không làm được những hiệu ứng động tinh vi. Nó cũng không pixel-precise — bạn không kiểm soát được khoảng cách chính xác từng điểm ảnh, nên không phù hợp khi cần bàn giao thiết kế chuẩn cho developer dựng UI thật. Và vì luôn trông sketchy, nó không dùng được để trình bày với khách hàng cuối muốn thấy sản phẩm "trông như thật".
Use case lý tưởng của Balsamiq: giai đoạn sớm của dự án, workshop với stakeholder nội bộ, khi bạn cần phác nhanh nhiều phương án bố cục để chọn hướng. Đây là tool để suy nghĩ bằng hình ảnh, không phải để giao sản phẩm.
Figma — linh hoạt, cộng tác thời gian thực, từ wireframe đến hi-fi
Figma là công cụ thiết kế chạy trên trình duyệt (cũng có app desktop), nổi tiếng nhờ khả năng cộng tác real-time giống Google Docs — nhiều người cùng mở một file, thấy con trỏ của nhau, comment trực tiếp lên thiết kế.
Ưu điểm cốt lõi: Figma trải dài toàn bộ phổ độ trung thực. Bạn có thể bắt đầu bằng wireframe xám đơn giản, rồi nâng cấp chính file đó thành mockup màu mè, rồi thành prototype bấm được — tất cả trong một công cụ. Tính năng Component và Auto Layout giúp tái sử dụng phần tử (sửa một nút "master" thì mọi nơi dùng nút đó tự cập nhật), cực kỳ tiện khi dự án lớn. Quan trọng với BA: Figma có chế độ comment, và developer có thể "inspect" thiết kế để lấy thông số chính xác — nên nó là cầu nối tự nhiên giữa BA, designer và dev.
Nhược điểm: chính vì đẹp và mạnh, Figma dễ khiến stakeholder fixate vào màu sắc, font, pixel — đúng cái bẫy mà Balsamiq tránh được. Một wireframe Figma làm sạch sẽ quá dễ bị hiểu nhầm là "thiết kế đã chốt". Figma cũng có đường học (learning curve) dốc hơn Balsamiq — Auto Layout, constraints, component variants cần thời gian làm quen. Với một BA chỉ cần phác nhanh ý tưởng, Figma đôi khi là dao mổ trâu giết gà.
Bảng so sánh nhanh để quyết định
Hãy ghi nhớ nguyên tắc chọn tool: dùng Balsamiq khi mục tiêu là khơi gợi tranh luận về cấu trúc và yêu cầu; dùng Figma khi mục tiêu là tiến tới một thiết kế sẽ được dev triển khai, hoặc cần cộng tác real-time với designer. Nhiều đội dùng cả hai: Balsamiq cho giai đoạn discovery, rồi chuyển sang Figma khi yêu cầu đã ổn định.
Tình huống thực tế
Tình huống 1 — Sàn TMĐT nội địa và cái bẫy "logo to hơn được không"
Một startup TMĐT ở TP.HCM, gọi là ChợViệt, đang xây tính năng "đặt hàng theo nhóm" (group buy). BA tên Linh nhận yêu cầu từ phòng kinh doanh và quyết định làm wireframe để chốt luồng trước khi giao cho đội dev 6 người.
Lần đầu, Linh dùng Figma vì nghĩ "làm cho đẹp để sếp dễ hình dung". Cô dành 2 ngày dựng màn hình màu mè chỉn chu. Kết quả buổi review thảm họa: trong 60 phút họp, 40 phút trôi qua với những câu như "màu cam này hơi chói", "font tên sản phẩm nên đậm hơn", "banner nên đặt ảnh người mẫu". Câu hỏi nghiệp vụ quan trọng nhất — nhóm mua cần đủ bao nhiêu người thì chốt đơn, và ai chịu trách nhiệm khi nhóm không đủ số — gần như không ai đụng tới.
Sprint sau, Linh làm lại bằng Balsamiq, dựng đúng 4 màn hình sketchy trong nửa ngày. Buổi review lần này, vì giao diện rõ ràng là nháp, không ai bình luận thẩm mỹ. Thay vào đó stakeholder lao thẳng vào logic: "Nếu nhóm 5 người mà chỉ có 3 người trả tiền thì sao?", "Cần có màn hình thông báo hoàn tiền". Linh phát hiện thêm 2 màn hình bị thiếu hoàn toàn trong yêu cầu ban đầu.
Bài học: độ trung thực của wireframe phải khớp với loại phản hồi bạn muốn nhận. Muốn bàn nghiệp vụ thì làm xấu một cách có chủ đích.
Tình huống 2 — Ngân hàng số và sức mạnh cộng tác real-time của Figma
Một ngân hàng số tại Việt Nam (đặt tên Bank A) phát triển luồng eKYC mở tài khoản online. Đội có BA, một designer ở Hà Nội, và team dev outsource ở Đà Nẵng — ba nơi khác nhau. Ở giai đoạn này yêu cầu đã rõ, cần tiến tới thiết kế dev triển khai được, có quy định pháp lý về thông tin bắt buộc hiển thị (cảnh báo rủi ro, điều khoản).
BA chọn Figma đúng đắn. Wireframe ban đầu được nâng dần lên hi-fi ngay trong cùng file. Khi luật sư yêu cầu thêm dòng cảnh báo bắt buộc theo quy định, BA comment trực tiếp lên đúng vị trí màn hình trong Figma, tag designer; designer sửa trong 10 phút, comment được resolve. Dev ở Đà Nẵng mở chế độ Inspect lấy đúng khoảng cách, màu, kích thước — không phải hỏi qua hỏi lại. Một thay đổi mà nếu làm bằng email kèm ảnh chụp màn hình có thể mất 3 ngày, thì xong trong một buổi chiều.
Bài học: khi cần phối hợp đa địa điểm và tiến tới bàn giao chính xác cho dev, khả năng cộng tác real-time và inspect của Figma tạo ra giá trị mà Balsamiq không có.
Tình huống 3 — Phòng khám tư và wireframe trên... giấy ăn
Một phòng khám tư ở Cần Thơ muốn số hóa việc đặt lịch khám. Ngân sách nhỏ, người ra quyết định là bác sĩ chủ phòng khám — không rành công nghệ. BA freelance được thuê đã thử mở Balsamiq cho bác sĩ xem, nhưng bác sĩ vẫn bối rối. BA bèn quay lại nguyên tắc gốc nhất của wireframing: ngồi cạnh bác sĩ, vẽ tay luồng đặt lịch lên giấy, hỏi từng bước. Sau khi luồng đã rõ trên giấy, BA mới về dựng lại bằng Balsamiq để lưu trữ và chia sẻ với dev.
Bài học: công cụ chỉ là phương tiện. Với stakeholder không quen công nghệ, đôi khi giấy bút là "wireframe tool" hiệu quả nhất ở bước đầu, rồi mới số hóa bằng Balsamiq/Figma sau. Đừng để công cụ trở thành rào cản giao tiếp.
Hướng dẫn từng bước
Dưới đây là quy trình thực tế để một BA tạo wireframe, áp dụng được cho cả hai công cụ.
Bước 1 — Xác định mục tiêu và độ trung thực. Trước khi mở tool, tự hỏi: wireframe này để làm gì? Khơi gợi tranh luận nghiệp vụ → chọn Balsamiq, low-fidelity. Bàn giao cho dev / cộng tác với designer → chọn Figma. Đừng mở tool trước khi trả lời câu hỏi này.
Bước 2 — Liệt kê các màn hình và luồng. Vẽ trên giấy hoặc liệt kê text: người dùng đi từ màn hình nào sang màn hình nào. Ví dụ luồng đặt hàng: Trang sản phẩm → Giỏ hàng → Địa chỉ → Thanh toán → Xác nhận. Mỗi mũi tên là một màn hình cần wireframe.
Bước 3 — Dựng khung từng màn hình. Với mỗi màn hình, bắt đầu bằng các khối lớn (header, vùng nội dung chính, footer), rồi thêm dần control. Trong Balsamiq, kéo-thả từ thư viện UI Library (gõ tên control để tìm nhanh). Trong Figma, dùng các frame và rectangle xám, hoặc cài plugin wireframe kit. Quy tắc vàng: dùng dữ liệu giả thực tế — đừng viết "Tên sản phẩm 1" mà viết "Áo thun cotton nam size L", vì dữ liệu thật sẽ lộ ra vấn đề bố cục (tên dài tràn dòng chẳng hạn).
Bước 4 — Liên kết các màn hình thành luồng. Cả hai tool đều cho phép gán link: bấm nút "Tiếp tục" thì nhảy sang màn hình kế. Việc này giúp stakeholder "đi thử" luồng thay vì nhìn từng ảnh rời rạc, và thường lộ ra các bước bị thiếu.
Bước 5 — Chú thích (annotation). Đây là phần BA hay quên nhưng cực quan trọng. Thêm ghi chú giải thích quy tắc nghiệp vụ mà hình ảnh không thể hiện được: "Nút này chỉ hiện khi đơn > 500k", "Trường này bắt buộc, validate định dạng email". Balsamiq có sticky note và callout sẵn; Figma dùng comment hoặc text bên cạnh frame.
Bước 6 — Review và lặp. Trình bày với stakeholder, ghi nhận phản hồi, sửa, lặp lại. Wireframe rẻ chính là để lặp nhiều lần — đừng tiếc công sửa, vì sửa wireframe rẻ hơn sửa code hàng chục lần.
Lỗi thường gặp & mẹo
Lỗi 1 — Chọn sai độ trung thực cho mục tiêu. Như tình huống ChợViệt: dùng Figma hi-fi quá sớm khiến stakeholder bàn màu sắc thay vì nghiệp vụ. Mẹo: ở giai đoạn discovery, cố tình giữ wireframe xấu và xám.
Lỗi 2 — Quên annotation. Một wireframe không có chú thích chỉ kể được một nửa câu chuyện. Developer nhìn hình sẽ không biết quy tắc ẩn (khi nào nút bị disable, validate ra sao). Luôn ghi chú quy tắc nghiệp vụ ngay trên wireframe.
Lỗi 3 — Dùng dữ liệu giả không thực tế. "Lorem ipsum" hoặc "Item 1, Item 2" che giấu các vấn đề thật. Hãy dùng dữ liệu sát thực tế Việt Nam: tên dài có dấu, số tiền lớn ("12.500.000đ"), địa chỉ thật ("123 Nguyễn Văn Cừ, P.4, Q.5").
Lỗi 4 — Wireframe quá chi tiết cho mọi trạng thái. Bạn không cần vẽ 50 màn hình. Hãy ưu tiên các luồng chính và các trạng thái rủi ro (lỗi, rỗng, loading). Mẹo: luôn wireframe ít nhất 3 trạng thái cho màn hình có dữ liệu — trạng thái có dữ liệu, trạng thái rỗng (empty state), và trạng thái lỗi.
Lỗi 5 — Để công cụ ngáng giao tiếp. Như phòng khám Cần Thơ: với người không quen công nghệ, đừng ép họ vào tool. Giấy bút trước, số hóa sau.
Mẹo cộng tác: Trong Figma, tạo một "review board" — đặt tất cả màn hình lên một trang, đánh số luồng, để stakeholder comment trực tiếp. Trong Balsamiq, dùng tính năng Project Comments và export PDF gửi kèm khi họp offline.
Mẹo năng suất: học phím tắt cơ bản (Figma: phím R vẽ rectangle, T thêm text, K scale; Balsamiq: gõ tên control vào thanh quick-add). Tốc độ dựng wireframe ảnh hưởng trực tiếp đến số lần bạn dám lặp lại.
Bài tập thực hành
Bài tập 1 — Cùng một màn hình, hai độ trung thực. Chọn một màn hình quen thuộc (ví dụ: form đăng ký tài khoản có họ tên, email, số điện thoại, mật khẩu). Dựng nó bằng Balsamiq ở mức sketchy, rồi dựng lại bằng Figma ở mức hi-fi. Viết 3 câu so sánh: loại phản hồi nào bạn nghĩ mỗi phiên bản sẽ khơi gợi từ stakeholder.
Bài tập 2 — Wireframe một luồng đầy đủ với annotation. Lấy luồng "đặt lịch khám tại phòng khám" (chọn dịch vụ → chọn bác sĩ → chọn khung giờ → nhập thông tin → xác nhận). Dùng Balsamiq dựng đủ 5 màn hình, link chúng thành luồng bấm được, và thêm ít nhất 5 annotation về quy tắc nghiệp vụ (ví dụ: "Khung giờ đã đầy thì hiển thị xám, không bấm được").
Bài tập 3 — Bổ sung các trạng thái rủi ro. Lấy màn hình "danh sách đơn hàng" của một sàn TMĐT. Wireframe 3 trạng thái: có nhiều đơn, chưa có đơn nào (empty state với CTA "Mua sắm ngay"), và lỗi tải dữ liệu. Tự đánh giá: ban đầu bạn có nghĩ tới 3 trạng thái này không, hay chỉ nghĩ tới trạng thái có dữ liệu?
Bài tập 4 — Cộng tác thử trên Figma. Mời một bạn cùng học mở chung một file Figma, một người dựng wireframe, người kia đóng vai stakeholder comment trực tiếp. Trải nghiệm vòng lặp comment → sửa → resolve để cảm nhận giá trị cộng tác real-time.
Tóm tắt
Wireframe là cách BA biến yêu cầu trừu tượng thành một vật thể chung để stakeholder cùng nhìn và tranh luận — và nó rẻ, nên là nơi sửa sai lý tưởng trước khi viết code. Hai công cụ chủ lực phục vụ hai mục đích khác nhau: Balsamiq cố tình trông sketchy để stakeholder tập trung vào cấu trúc và nghiệp vụ thay vì thẩm mỹ, học nhanh, hợp giai đoạn discovery — đổi lại nó hạn chế tương tác và không pixel-precise. Figma linh hoạt trải dài từ wireframe tới hi-fi prototype, mạnh ở cộng tác real-time và bàn giao chính xác cho dev — đổi lại dễ khiến stakeholder fixate vào hình ảnh và có đường học dốc hơn.
Nguyên tắc quyết định gói gọn trong một câu: chọn độ trung thực khớp với loại phản hồi bạn muốn nhận. Muốn bàn nghiệp vụ thì giữ wireframe xấu; muốn tiến tới thiết kế dev triển khai thì dùng Figma. Và đừng quên: công cụ chỉ là phương tiện — annotation rõ ràng, dữ liệu giả thực tế, và việc bao phủ cả các trạng thái rủi ro mới là thứ phân biệt một wireframe nghiệp dư với một wireframe của BA chuyên nghiệp.