Dựng Prototype Nhanh Trước Khi Xây Backend Thật

Dựng Prototype Nhanh Trước Khi Xây Backend Thật

Chín lesson vừa rồi là các quyết định thiết kế: confidence signaling, steerability, error state, onboarding... Nhưng có một vấn đề thực tế cản trở việc thử nghiệm những quyết định đó: build một AI feature thật (data pipeline, model integration, backend logic) tốn thời gian hơn nhiều so với build một form CRUD thông thường. Nếu PM chờ đến khi có backend hoàn chỉnh mới test được UX, thì các sai lầm ở Lesson 27-35 (spinner tĩnh, accept/reject cứng, không có fallback...) chỉ lộ ra sau khi đã tốn công build - quá muộn để sửa rẻ.

Ví dụ xuyên suốt bài: quay lại MedSort (Lesson 29) - hệ gợi ý ưu tiên cấp cứu tại phòng khám.

1. Ba kỹ thuật, từ giả nhiều nhất đến giả ít nhất

Rapid prototyping cho AI feature tách trải nghiệm ra khỏi engine thật đứng sau nó, để test được cảm giác dùng sản phẩm trước khi engine đó tồn tại:

• (a) Wizard of Oz - UI trông như một AI feature thật, nhưng phía sau là một người thật đang gõ/chọn câu trả lời theo thời gian thực (qua bảng điều khiển ẩn). User test không biết mình đang nói chuyện với người. Mạnh nhất để test tương tác (luồng hội thoại, cách đặt câu hỏi làm rõ, tốc độ phản hồi cảm nhận được) mà không cần một dòng model integration nào.
• (b) Mock response - dựng UI thật, nhưng trả về response đã soạn sẵn (cố định hoặc chọn ngẫu nhiên trong tập mẫu) để test riêng UI pattern: streaming trông thế nào, confidence badge hiện ra sao, nút steerability bấm có mượt không - tách hẳn khỏi câu hỏi "model có trả lời đúng không".
• (c) Thin LLM wrapper - gọi thẳng model có sẵn qua API với prompt viết tay, bỏ qua data pipeline/retrieval phức tạp của bản production. Chân thực hơn (a) và (b) vì output thật sự do model sinh ra, nhưng chưa phải hệ thống cuối vì thiếu retrieval/data thật.

2. Ví dụ: MedSort chạy 3 giai đoạn trước khi đầu tư data pipeline thật

Trước khi đầu tư data pipeline thật (thu thập, gán nhãn hàng nghìn ca bệnh), đội chạy prototype theo 3 giai đoạn: (1) Wizard of Oz trong 1 tuần - một bác sĩ ngồi sau màn hình đọc mô tả triệu chứng y tá gõ vào, tự gõ ra mức ưu tiên + độ tự tin, để xác định luồng tương tác nào y tá thấy hữu ích; (2) Mock response - dựng UI 3 tầng confidence (đã thiết kế ở Lesson 29) với dữ liệu giả cố định, để test riêng việc y tá có đọc/hiểu đúng ý nghĩa 3 tầng màu hay không, tách khỏi câu hỏi model có chính xác không; (3) Thin LLM wrapper - gọi thẳng một model ngôn ngữ tổng quát với prompt mô tả bài toán, chưa có data y tế chuyên biệt, để xem chất lượng gợi ý "thô" tới đâu. Chỉ sau khi xác nhận cả UX lẫn chất lượng output đều đủ hứa hẹn, đội mới bắt đầu đầu tư data pipeline thật.

3. Ba kỹ thuật không loại trừ nhau, chọn theo câu hỏi đang muốn trả lời

Mục tiêu của cả 3 kỹ thuật là giảm chi phí học được điều gì đó sai sớm, không phải để tạo ra một bản demo đẹp cho leadership xem. Một prototype Wizard of Oz đủ để bộc lộ 2-3 lỗi UX nghiêm trọng trong 1 buổi test, đáng giá hơn nhiều so với 2 tuần build backend thật rồi mới phát hiện ra lỗi đó.

4. Ẩn dụ: ba giai đoạn thử một vở kịch trước khi dàn dựng full

Giống 3 giai đoạn thử một vở kịch trước khi dàn dựng full: đầu tiên đạo diễn tự đọc lời thoại tạm để xem nhịp kịch có ổn không (Wizard of Oz) - chưa cần diễn viên thật. Sau đó dựng sân khấu thật với vài đoạn hội thoại mẫu cố định để test ánh sáng, âm thanh (mock response) - chưa cần kịch bản hoàn chỉnh. Cuối cùng mới đưa diễn viên thật vào diễn ứng biến (LLM wrapper) - lúc này mới thấy được sự "sống động không đoán trước" thật sự, nhưng vẫn chưa phải buổi công diễn chính thức.

Bài tập 36.1: Quay lại RefundBot (Lesson 32). Trước khi build hệ thống thật, chọn 1 trong 3 kỹ thuật prototyping để test riêng nhánh "đơn hàng trên 2 triệu hoặc lý do mơ hồ" - nhánh đã xác định cần ở mức human-in-the-loop (a) review-before-execute. Giải thích vì sao kỹ thuật bạn chọn phù hợp để test đúng câu hỏi đang cần trả lời ở nhánh này (không phải nhánh dưới 200k).