Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa hoàn thành một bản đặc tả yêu cầu (requirement) dài 12 trang cho tính năng "đối soát công nợ tự động". Bạn gửi cho team dev và stakeholder. Hai ngày sau, anh trưởng phòng kế toán — người duyệt cuối — nhắn lại: "Anh đọc không hiểu, em vẽ ra cho anh xem được không?". Còn bạn dev thì hỏi: "Cái nút Export này nằm ở đâu trên màn hình? Click vào thì ra cái gì?".
Đây chính là khoảnh khắc người làm Finance chuyển sang BA nhận ra một sự thật: chữ viết không đủ. Trong nghề Finance/Kế toán, bạn quen với việc trình bày mọi thứ bằng con số và bảng biểu — bút toán, báo cáo, đối soát đều là dạng văn bản và số liệu. Nhưng khi làm BA cho một sản phẩm phần mềm, có những điều chỉ có thể truyền đạt rõ ràng qua hình ảnh của giao diện — đó là wireframe.
Wireframe là bản phác thảo khung sườn của một màn hình: nó cho biết các thành phần nằm ở đâu, người dùng tương tác thế nào, dữ liệu hiển thị ra sao — mà không bận tâm đến màu sắc, font chữ hay hình ảnh đẹp xấu. Nhưng riêng wireframe thôi chưa đủ. Thứ khiến wireframe trở thành công cụ giao tiếp mạnh mẽ của BA chính là annotation — phần chú thích đi kèm, giải thích logic, quy tắc nghiệp vụ (business rule), điều kiện hiển thị và hành vi của từng thành phần. Một wireframe không annotation giống như một báo cáo tài chính chỉ có con số mà không có thuyết minh: người xem đoán mò.
Bài này tập trung vào kỹ năng vẽ wireframe và đặc biệt là annotation wireframe dành riêng cho người nền Finance. Bạn sẽ học khi nào cần wireframe, chọn mức độ chi tiết (fidelity) nào, và cách viết annotation chặt chẽ như cách bạn từng viết thuyết minh báo cáo tài chính.
Khái niệm cốt lõi
Wireframe là gì và không là gì
Wireframe là bản vẽ bố cục (layout) của màn hình ở mức "khung xương". Nó trả lời ba câu hỏi: Màn hình này có những thành phần gì? Chúng được sắp xếp ở đâu? Người dùng làm gì trên đó?
Wireframe không phải là thiết kế đồ họa (UI design) — đó là việc của designer, lo về màu sắc, thương hiệu, khoảng cách pixel. Wireframe cũng không phải prototype tương tác hoàn chỉnh. Là BA, bạn dùng wireframe để thể hiện yêu cầu, không phải để thiết kế đẹp. Đây là điểm nhiều người mới chuyển nghề hiểu sai: họ sa đà vào việc chọn màu, căn lề, làm cho đẹp — trong khi giá trị thực của BA nằm ở việc làm rõ logic đằng sau giao diện.
Khi nào BA cần vẽ wireframe
Không phải yêu cầu nào cũng cần wireframe. Bạn vẽ wireframe trong ba tình huống chính:
- Spec phức tạp về giao diện và luồng tương tác. Khi một màn hình có nhiều trạng thái (state), nhiều điều kiện hiển thị, hoặc nhiều bước nhập liệu, mô tả bằng chữ sẽ rối. Ví dụ: màn hình tạo phiếu chi có 5 loại chi phí, mỗi loại bật/tắt các trường khác nhau — vẽ ra dễ hiểu hơn liệt kê.
- Stakeholder cấp C-level review qua hình. Giám đốc tài chính, trưởng phòng — những người duyệt yêu cầu — thường không có thời gian đọc tài liệu kỹ thuật. Họ "đọc" bằng mắt. Một wireframe cho họ cảm giác cụ thể về sản phẩm sẽ ra sao, giúp họ duyệt nhanh và phát hiện thiếu sót sớm.
- Workshop user testing / lấy phản hồi sớm. Trước khi dev code, bạn đưa wireframe cho người dùng thật (kế toán viên, thu ngân) xem và hỏi: "Anh/chị thao tác thế này có thuận không?". Phát hiện vấn đề ở giai đoạn wireframe rẻ hơn rất nhiều so với khi đã code xong.
Fidelity matrix — chọn mức độ chi tiết phù hợp
"Fidelity" là mức độ chi tiết/giống thật của wireframe. Chọn sai fidelity là lỗi phổ biến: vẽ quá chi tiết từ sớm gây lãng phí và làm stakeholder tranh cãi màu sắc thay vì logic; vẽ quá sơ sài thì dev không đủ thông tin để code. Dưới đây là ma trận giúp bạn chọn:
| Giai đoạn | Fidelity | Công cụ | Dùng để làm gì | Annotation cần |
|---|---|---|---|---|
| Khám phá ý tưởng (discovery) | Lo-fi (giấy, bút, hoặc Balsamiq) | Giấy A4, Balsamiq | Brainstorm luồng, thống nhất bố cục lớn với stakeholder | Ít — ghi chú nhanh ý chính |
| Làm rõ yêu cầu (definition) | Mid-fi (khối xám, Figma wireframe) | Figma, Whimsical | Đặc tả cho dev, review với C-level | Nhiều — business rule, điều kiện, validation |
| Bàn giao / handoff | Hi-fi (gần giống UI thật) | Figma + designer | Designer và dev triển khai, UAT | Vừa — bổ sung edge case, lỗi |
Annotation — trái tim của wireframe BA
Annotation là các chú thích đánh số gắn vào từng thành phần trên wireframe, giải thích những gì mắt không nhìn thấy được. Một annotation tốt trả lời:
- Business rule: Quy tắc nghiệp vụ áp dụng cho thành phần này. Ví dụ: "Số tiền không được vượt hạn mức phê duyệt của user".
- Validation: Điều kiện hợp lệ. Ví dụ: "Mã số thuế phải đủ 10 hoặc 13 chữ số".
- Điều kiện hiển thị (conditional logic): Khi nào thành phần xuất hiện/ẩn. Ví dụ: "Trường 'Lý do điều chỉnh' chỉ hiện khi user chọn loại giao dịch = Điều chỉnh".
- Hành vi (behavior): Click vào thì gì xảy ra, dữ liệu lấy từ đâu. Ví dụ: "Click Export sinh file Excel theo template mẫu, gửi về email người yêu cầu".
- Nguồn dữ liệu & định dạng: Ví dụ: "Cột Số dư lấy từ bảng GL, hiển thị định dạng #,##0 VND, làm tròn về đơn vị đồng".
Tình huống thực tế
Tình huống 1 — Màn hình tạo đề nghị thanh toán tại một fintech cho vay tiêu dùng
Linh, kế toán tổng hợp 4 năm, mới chuyển sang BA tại một công ty fintech ở TP.HCM (giả định: FinCredit). Nhiệm vụ đầu tiên của cô là đặc tả màn hình "Tạo đề nghị giải ngân". Ban đầu Linh viết 8 trang Word mô tả từng trường. Dev đọc xong họp 45 phút vẫn hỏi tới tấp: "Trường lãi suất nhập tay hay tự tính? Khi nào hiện nút Phê duyệt?".
Linh quay lại vẽ một wireframe mid-fi trên Figma: một form với các khối xám đại diện trường nhập, kèm 9 annotation đánh số. Ví dụ annotation số 4 gắn vào trường "Lãi suất": "Tự động lấy từ bảng sản phẩm vay theo gói khách chọn (BR-12). Read-only, không cho sửa. Nếu là khách VIP (hạng A), trừ thêm 0,5%/năm — xem BR-13." Annotation số 7 gắn vào nút Phê duyệt: "Chỉ hiện khi user có role = Trưởng nhóm tín dụng VÀ số tiền ≤ 200 triệu. Trên 200 triệu, ẩn nút này, hiển thị thông báo 'Cần cấp Giám đốc phê duyệt'."
Kết quả: buổi review tiếp theo chỉ mất 15 phút. Dev gật đầu vì mọi điều kiện đã rõ. Bài học: annotation biến wireframe từ "bức tranh đẹp" thành "hợp đồng yêu cầu" — mỗi con số, mỗi điều kiện đều có chỗ neo.
Tình huống 2 — Review với CFO qua wireframe lo-fi
Tại một chuỗi bán lẻ (giả định: GreenMart, 40 cửa hàng), BA Tuấn — cựu kế toán trưởng — cần xin CFO duyệt dự án "Dashboard dòng tiền theo cửa hàng". CFO cực kỳ bận, từng từ chối đọc tài liệu dài. Tuấn không gửi spec. Anh in một wireframe lo-fi một trang: vài khối biểu đồ, một bảng xếp hạng cửa hàng, ba ô chỉ số lớn (tổng thu, tổng chi, dòng tiền ròng). Bên cạnh mỗi khối là annotation viết tay ngắn gọn: "Ô này hiển thị dòng tiền ròng hôm nay, so sánh % với hôm qua; đỏ nếu âm."
Trong cuộc họp 20 phút, CFO nhìn hình và lập tức phản hồi: "Anh muốn thêm cột dự báo cuối tháng, và phải lọc được theo vùng miền". Đây là hai yêu cầu quan trọng mà nếu chỉ đọc tài liệu, CFO sẽ không bao giờ nghĩ ra. Tuấn cập nhật wireframe ngay tại chỗ.
Bài học: với C-level, fidelity thấp lại tốt hơn — vẽ càng thô, họ càng tập trung vào nội dung và logic nghiệp vụ thay vì soi giao diện. Và annotation ngắn gọn đủ để dẫn dắt suy nghĩ của họ.
Tình huống 3 — Workshop user testing với kế toán viên về màn hình đối soát
Một công ty ví điện tử (giả định, bối cảnh tương tự MoMo) cần xây tính năng "Đối soát giao dịch với ngân hàng". BA Hà tổ chức workshop với 5 kế toán viên vận hành. Cô chuẩn bị wireframe mid-fi mô phỏng màn hình đối soát: danh sách giao dịch lệch, bộ lọc, nút "Đánh dấu đã xử lý".
Hà cố tình để annotation ở dạng câu hỏi mở cho một số chỗ: "Khi giao dịch lệch số tiền, anh/chị muốn xử lý từng dòng hay xử lý hàng loạt?". Trong workshop, các kế toán viên chỉ vào màn hình giấy và nói: "Bọn em xử lý hàng loạt theo lô, nhưng phải ghi lý do chung được". Một người khác phát hiện: "Thiếu cột mã tham chiếu ngân hàng, không có cột đó bọn em không tra được". Đây là yêu cầu sống còn mà spec ban đầu bỏ sót.
Bài học: wireframe trong workshop không phải để "khoe", mà để kích thích phản hồi. Khi người dùng thật nhìn thấy thao tác cụ thể, họ phát hiện ra những thứ mà phỏng vấn bằng lời không bao giờ moi được. Annotation dạng câu hỏi biến wireframe thành công cụ elicitation (khai thác yêu cầu).
Hướng dẫn từng bước
Đây là quy trình thực dụng để bạn vẽ và annotate một wireframe:
Bước 1 — Xác định mục đích và đối tượng xem. Hỏi: wireframe này để làm gì (review C-level / handoff dev / user testing) và ai xem? Câu trả lời quyết định fidelity. Đừng vẽ Figma hi-fi nếu chỉ cần phác giấy cho buổi brainstorm.
Bước 2 — Liệt kê các thành phần và dữ liệu trước khi vẽ. Dùng kỹ năng Finance: lập một "bảng kê" các trường dữ liệu cần hiển thị/nhập, kèm nguồn dữ liệu và định dạng. Bước này tránh việc vẽ xong mới phát hiện thiếu trường.
Bước 3 — Phác bố cục khối (block layout). Chia màn hình thành các vùng: header, bộ lọc, vùng nội dung chính, vùng hành động (nút bấm). Dùng khối xám trung tính. Chưa cần đẹp.
Bước 4 — Đặt annotation và đánh số. Gắn một con số (1, 2, 3...) vào từng thành phần cần giải thích. Bên lề phải hoặc trang riêng, viết nội dung annotation theo cấu trúc: thành phần → business rule → validation → điều kiện hiển thị → hành vi.
Bước 5 — Liên kết annotation với requirement ID và business rule. Mỗi annotation nên trỏ về mã yêu cầu hoặc mã quy tắc nghiệp vụ (ví dụ BR-12). Điều này giúp truy vết và tránh mâu thuẫn — đúng tinh thần đối soát của dân Finance.
Bước 6 — Bổ sung các trạng thái và edge case. Đừng chỉ vẽ trạng thái "mọi thứ ổn". Thêm: trạng thái rỗng (chưa có dữ liệu), trạng thái lỗi (nhập sai), trạng thái loading, trạng thái phân quyền (user không đủ quyền thấy gì).
Bước 7 — Review nội bộ rồi mới phát hành. Tự kiểm tra: một người chưa biết gì đọc wireframe + annotation có hiểu được không? Nếu có chỗ phải giải thích miệng, nghĩa là annotation còn thiếu.
Lỗi thường gặp & mẹo
Lỗi 1 — Sa đà làm đẹp. Người mới hay mất hàng giờ chỉnh màu, font. Mẹo: ép mình dùng tông xám và một công cụ lo-fi như Balsamiq để không bị cám dỗ. Giá trị BA nằm ở logic, không ở thẩm mỹ.
Lỗi 2 — Wireframe "câm", không có annotation. Bản vẽ đẹp nhưng dev phải đoán hành vi. Mẹo: quy ước mọi nút bấm, mọi trường có điều kiện đều bắt buộc có ít nhất một annotation.
Lỗi 3 — Quên các trạng thái phụ. Chỉ vẽ "happy path". Khi dev gặp dữ liệu rỗng hoặc lỗi, họ tự chế giao diện sai ý. Mẹo: lập checklist 5 trạng thái (mặc định, rỗng, lỗi, loading, phân quyền) cho mỗi màn hình quan trọng.
Lỗi 4 — Annotation mơ hồ. Viết "hiển thị số tiền phù hợp" là vô nghĩa. Mẹo: dùng ngôn ngữ định lượng như khi viết thuyết minh báo cáo — "định dạng #,##0 VND, làm tròn đến đồng, âm hiển thị trong ngoặc đỏ".
Lỗi 5 — Sai fidelity với đối tượng. Đưa wireframe hi-fi cho C-level khiến họ bắt bẻ màu sắc; đưa lo-fi cho dev khiến họ thiếu thông tin. Mẹo: luôn quay lại fidelity matrix trước khi bắt đầu.
Lỗi 6 — Không đồng bộ wireframe với spec chữ. Khi yêu cầu thay đổi, chỉ sửa Word mà quên sửa wireframe, gây mâu thuẫn. Mẹo: coi wireframe và spec là một cặp phải khớp nhau, như sổ cái và sổ chi tiết — luôn đối chiếu.
Bài tập thực hành
Bài tập 1 — Vẽ và annotate màn hình "Tạo phiếu chi". Giả sử bạn đặc tả màn hình tạo phiếu chi nội bộ cho một công ty 200 nhân viên. Yêu cầu: phiếu trên 10 triệu phải có cấp phê duyệt thứ hai; loại chi "Tạm ứng" bắt buộc nhập ngày hoàn ứng dự kiến; số tiền hiển thị định dạng VND. Hãy vẽ wireframe mid-fi (Figma hoặc giấy) và viết tối thiểu 6 annotation đánh số, mỗi annotation nêu rõ business rule, validation hoặc điều kiện hiển thị.
Bài tập 2 — Chọn fidelity. Cho ba tình huống: (a) brainstorm ý tưởng dashboard với đồng nghiệp; (b) trình CFO duyệt ngân sách dự án; (c) bàn giao cho team dev coding sprint tới. Với mỗi tình huống, chọn fidelity phù hợp, nêu công cụ và giải thích trong 2–3 câu vì sao.
Bài tập 3 — Bổ sung edge case. Lấy lại wireframe ở bài tập 1, vẽ thêm 3 trạng thái: khi user không đủ quyền tạo phiếu, khi nhập số tiền vượt hạn mức, và khi danh sách phòng ban chưa tải xong. Viết annotation cho từng trạng thái.
Bài tập 4 — Annotation dạng câu hỏi cho workshop. Soạn 3 annotation ở dạng câu hỏi mở để dùng trong workshop user testing với kế toán viên, nhằm khai thác yêu cầu còn ẩn về cách họ muốn xử lý phiếu chi.
Tóm tắt
Wireframe là công cụ giúp BA ex-Finance vượt qua giới hạn của văn bản thuần, biến những yêu cầu phức tạp về giao diện thành hình ảnh dễ hiểu. Bạn cần wireframe trong ba tình huống: spec phức tạp, review với C-level qua hình, và workshop user testing. Chọn đúng fidelity theo giai đoạn — lo-fi để brainstorm và làm việc với lãnh đạo, mid-fi cho phần lớn công việc đặc tả, hi-fi khi bàn giao — và đừng sa đà làm đẹp.
Quan trọng nhất, sức mạnh thật của wireframe BA nằm ở annotation: phần chú thích giải thích business rule, validation, điều kiện hiển thị, hành vi và nguồn dữ liệu. Đây chính là nơi kỹ năng viết thuyết minh chặt chẽ từ nghề Finance của bạn tỏa sáng. Một wireframe có annotation tốt là một "hợp đồng yêu cầu" rõ ràng, giúp dev code đúng, stakeholder duyệt nhanh, và người dùng phản hồi sớm — tiết kiệm hàng tuần làm lại. Hãy nhớ: vẽ để làm rõ logic, không phải để khoe đẹp; và mỗi nút bấm, mỗi điều kiện đều xứng đáng có một dòng annotation.