Bỏ qua tới nội dung
Phạm Thủy
Quay lại

Prototype cho Elicitation

Note này giúp BA dùng prototype để khai thác feedback về flow và interaction trước khi dev build. Prototype là công cụ elicitation, không phải UI design — mục tiêu không phải đẹp, mà là phát hiện gap sớm.

Note này dùng để làm gì

Mở note khi bạn có requirement nhưng chưa chắc flow sẽ hoạt động trong thực tế, hoặc khi stakeholder khó hình dung interaction nếu không có gì để “sờ”. Đọc sau Elicitation Technique Selection.

Quan trọng: note này nói về prototype cho elicitation (khám phá nhu cầu). Wireframe cho specification thuộc nhóm 02. Không trộn hai mục đích.

1. Khi nào dùng và không dùng

Dùng khiKhông dùng khi
cần feedback sớm về flow/interaction trước khi codeproblem chưa rõ (dùng interview/observation trước)
stakeholder khó diễn đạt nhu cầu bằng lờiđã có wireframe/spec đầy đủ từ designer (lúc đó không cần prototype thô nữa)
cần kiểm tra hypothesis “liệu user có hiểu flow này không?“cần chốt UI aesthetic (màu sắc, font) — đó là mockup, không phải prototype
muốn phát hiện missing step, confusion sớmcần đo performance với real data (dùng pilot/MVP)

Weakness chính: anchoring bias (stakeholder tưởng prototype = sản phẩm cuối, chỉ góp ý về màu sắc thay vì flow), và premature solution lock (BA/team yêu prototype quá, bỏ qua option khác). Bù bằng: ghi rõ fidelity/hypothesis, dùng paper prototype cho flow, để UI cho giai đoạn sau.

2. Fidelity levels

MứcLàm bằng gìDùng khiKhông dùng khi
Paper / Whiteboardgiấy, bút, sticky notekhám phá flow tổng quan, chưa biết màn hình nào cầncần test mobile interaction thực tế
Low-fi wireframeBalsamiq, PlantUML Salt, vẽ tay scancần feedback về bố cục và luồng, chưa quan tâm UIstakeholder chỉ quan tâm “nó phải đẹp”
Clickable prototypeFigma, Penpot (chỉ link màn hình)cần test interaction “bấm vào đây → ra gì”chưa có flow rõ (lãng phí thời gian dựng)
Hi-fi mockupFigma với real UIcần test phản ứng với giao diện thậtđây là UI design, không còn là elicitation nữa

Quy tắc: thấp nhất có thể để trả lời câu hỏi. Giấy → wireframe → clickable. Đừng nhảy lên Figma hi-fi nếu câu hỏi chỉ là “có cần màn hình X không?“

3. Prototype plan

Thành phầnCâu hỏi cần trả lời
Hypothesis”Tôi tin rằng nếu có màn hình X với flow Y, user sẽ làm được Z”
Fidelitypaper, wireframe, hay clickable? Vì sao chọn mức này?
Scenariouser sẽ làm gì với prototype? (task cụ thể, không phải “nhìn đi”)
Feedback cần thuflow nào gây confused? step nào thiếu? user mong đợi gì mà không thấy?
Không feedback vềmàu sắc, font, animation (trừ khi đang test hi-fi mockup)

4. Dẫn prototype session

  1. Nói rõ đây là prototype: “Đây là bản phác, chưa có code, chưa có màu thật.”
  2. Đưa task, không đưa tour: “Bạn hãy thử đặt một món hàng” — đừng “Bạn bấm vào đây, rồi bấm vào đây…”
  3. Quan sát, không giải thích: nếu user bối rối, hỏi “Bạn đang tìm gì?” — đừng “À, nút đó ở đây nè.”
  4. Ghi nhận: chỗ nào user dừng, chỗ nào user hỏi, chỗ nào user làm khác dự đoán.
  5. Kết thúc bằng câu hỏi mở: “Còn thiếu gì? Bạn mong thấy gì mà không có?”

Running case: ShopFlow

BA dùng low-fi wireframe để khai thác feedback cho SF-3 Create Order trước khi dev bắt đầu Sprint 1.

Prototype plan:

Thành phầnNội dung
Hypothesis”Nếu khách hàng thấy catalog → bấm Đặt hàng → thấy form xác nhận → bấm OK, họ sẽ không cần gọi điện nữa”
FidelityLow-fi wireframe (SF-38 Sketch trên giấy, scan)
Scenario”Bạn là khách hàng, hãy thử đặt 2 món hàng từ catalog”
Participant3 khách quen (đã interview trước đó)

Kết quả session (Khách A, nữ, 28t, hay mua hàng qua Zalo):

Quan sátInterpretationImpact
Khách A bấm vào ảnh sản phẩm (không thấy nút “Đặt hàng”)Mong đợi bấm vào ảnh = xem chi tiết → thêm vào giỏ. Wireframe hiện tại chỉ có nút nhỏ dưới ảnhSF-2 Browse Catalog: thêm “bấm vào ảnh → trang chi tiết sản phẩm”
Tới form xác nhận, khách A hỏi “tiền ship đâu?”Wireframe không có field phí shipOpen question: “Có cần hiển thị phí ship không? Ai tính? Mock hay thật?” → ghi cho Sprint 2
Khách A bấm “Đặt hàng” xong, hỏi “vậy giờ sao?”Thiếu feedback sau khi đặt — không có màn hình “Đặt hàng thành công, mã đơn XYZ”SF-3 AC bổ sung: “Sau khi order tạo thành công, hiển thị order ID và trạng thái Pending Payment”

Sửa prototype sau session 1: thêm màn hình “Order Confirmation” với order ID

Bài học: Prototype phát hiện 2 gap không có trong AC ban đầu (thiếu trang chi tiết sản phẩm, thiếu feedback sau order) và 1 unexpected need (phí ship). Cả 3 đều không lộ ra trong interview vì khách không biết “cái gì có thể có” cho tới khi thấy prototype. Đây chính là sức mạnh của prototype: làm cho cái thiếu trở nên nhìn thấy được.

Anti-patterns

Anti-patternVì sao nguy hiểmCách sửa
Prototype quá đẹp quá sớmstakeholder chỉ góp ý màu sắc, không góp ý flowgiữ low-fi tới khi flow confirmed
Coi prototype = commitmentstakeholder nói “tôi tưởng đây là app thật”mở đầu session: “Đây là bản phác, chưa có code”
Không có hypothesis rõ ràngsession không có focus, feedback lan manghi hypothesis trước: “Tôi tin X, tôi cần kiểm tra Y”
BA tự làm prototype, không cho team xemprototype không reflect feasibilitydev xem prototype trước khi test với user
Test với sai ngườifeedback từ người không phải user thậttest với actual user hoặc ít nhất SME
Prototype không để lại artifactmất evidence, không trace được requirementlưu ảnh/scan prototype + ghi observation

Checklist nhanh

References


Chia sẻ bài viết:

Bài trước
Observation & Contextual Inquiry cho BA
Bài sau
Survey cho BA