Mở Input Từ Form Cứng Sang Ngôn Ngữ Tự Nhiên Và Đa Phương Thức
Hiểu vì sao mở input sang ngôn ngữ tự nhiên/đa phương thức kéo theo vấn đề discoverability, và khi nào structured input vẫn là lựa chọn rẻ hơn.
Mở Input Từ Form Cứng Sang Ngôn Ngữ Tự Nhiên Và Đa Phương Thức
Lesson 27 nói về output: khi model đứng sau feature, output không còn cố định hình dạng/thời gian/độ chắc chắn. Cùng logic đó áp ngược lại cho input. UI truyền thống ép input vào cấu trúc cố định (dropdown, checkbox) vì rule-based chỉ hiểu hữu hạn trạng thái định nghĩa trước. Model-based thì ngược lại: nó nhận được input mở (text tự do, giọng nói, ảnh) vì nó suy luận ý định từ pattern, không match với case cứng.
Ví dụ xuyên suốt bài: ClaimWise - app xử lý yêu cầu bồi thường bảo hiểm xe.
1. Cái giá ẩn của việc mở input: discoverability
Mở input ra nghe như một nâng cấp thuần túy, nhưng kéo theo vấn đề form cứng không có: discoverability. Dropdown tự nó nói cho user biết "đây là những gì bạn có thể chọn". Một ô text trống thì không - user phải tự đoán họ được phép nói gì, nói tới đâu là đủ.
Structured Input vs. Open-Ended Input
So sánh 4 khía cạnh - và cái giá ẩn của việc mở input ra tự do.
Dropdown tự nó nói cho user biết "đây là những gì bạn có thể chọn". Một ô text trống thì không - user phải tự đoán họ được phép nói gì, nói tới đâu là đủ.
2. Ví dụ: ClaimWise đổi 15 field thành 1 câu tự do, và cái giá phải trả
Bản cũ của ClaimWise: 15 field bắt buộc (loại xe, biển số, ngày xảy ra, mô tả thiệt hại chọn từ 8 hạng mục có sẵn...). Bản AI-native: user chụp 1 ảnh xe hư + gõ một câu tự do "xe tui đậu bị người ta quẹt lúc sáng nay ở bãi gửi xe". Model tự trích loại thiệt hại, ước tính vị trí va chạm từ ảnh, hỏi lại nếu thiếu thông tin bắt buộc (biển số).
Vấn đề phát sinh: bản đầu tiên chỉ đưa user một ô text trống với placeholder "Mô tả sự cố..." - user không biết có cần nói ngày tháng không, có cần đính kèm ảnh không, gõ 5 từ rồi bấm gửi, model thiếu dữ kiện phải hỏi lại 3 vòng, trải nghiệm tệ hơn hẳn form cũ dù input "tự do hơn".
3. Structured input vs. open-ended input: đánh đổi theo tình huống
| Structured input (form/dropdown) | Open-ended input (NL, đa phương thức) | |
|---|---|---|
| User có biết mình được nói gì không | Có - lựa chọn hiện sẵn trên màn hình | Không mặc định - phải thiết kế thêm để lộ ra |
| Xử lý input thiếu/sai | Chặn ngay tại field (validation cứng) | Phải suy luận thiếu gì rồi hỏi lại (clarification loop) |
| Tốc độ với case đơn giản | Nhanh (vài cú click) | Có thể chậm hơn nếu user không biết bắt đầu từ đâu |
| Tốc độ với case phức tạp/nhiều ngữ cảnh | Chậm, phải điền nhiều field rời rạc | Nhanh - 1 câu chứa nhiều thông tin cùng lúc |
Khoảng trống discoverability sẽ được xử lý sâu ở Lesson 35 (onboarding) - ở đây chỉ cần nắm nguyên tắc: mở input ra thì phải thiết kế cách lộ khả năng ra cùng lúc, không thể chỉ vứt một ô trống rồi coi là xong.
4. Ẩn dụ: tủ hồ sơ vật lý và người quản thủ thư
Structured input giống tủ hồ sơ vật lý - mỗi tài liệu phải biết trước nằm ngăn nào, nhãn gì, mới tìm ra được. Open-ended input giống hỏi thẳng một người quản thủ thư đang đứng đó: bạn chỉ cần mô tả thứ mình cần bằng lời tự nhiên, người đó tự dịch câu mơ hồ của bạn thành đúng tài liệu. Nhưng nếu người quản thủ thư đứng im không gợi ý gì, không hỏi lại, bạn cũng chẳng biết nên bắt đầu câu hỏi thế nào - đó chính là khoảng trống discoverability ở trên.
Bài tập 28.1: DeskBuddy - app đặt phòng họp nội bộ. Bản cũ có 6 dropdown (tòa nhà, tầng, sức chứa, thiết bị, giờ bắt đầu, giờ kết thúc). Đề xuất chuyển sang 1 ô input tự do kiểu "họp brainstorm 5 người chiều mai, cần màn hình chiếu". Thiết kế ô input đó cần thêm ít nhất 1 cơ chế gì để giải quyết vấn đề discoverability đã nêu ở trên - không được để y nguyên "1 ô text trống + placeholder".