Lắng nghe người dùng

Vì sao phải nghe, khi đã có số liệu

Số liệu trả lời cái gì: 40% người dùng bỏ dở ở bước thanh toán. Số liệu không trả lời vì sao: họ sợ, họ không hiểu, hay nút bấm không ăn.

Đoán sai lý do thì sửa sai chỗ, và số liệu tháng sau vẫn y nguyên. Năm cuộc trò chuyện 15 phút thường cho câu trả lời mà ba tuần phân tích dữ liệu không cho được.

Đây là dạng shift left sớm nhất trong toàn bộ hệ thống này: sửa hiểu lầm về nhu cầu trước khi nó kịp trở thành yêu cầu, rồi thành code, rồi thành thứ phải làm lại.

Các kênh nghe, và mỗi kênh cho gì

Kênh	Cho ta	Không cho ta
Phỏng vấn người dùng	Lý do, bối cảnh, cảm giác	Tỷ lệ, quy mô
Quan sát người dùng thao tác	Chỗ vướng thật, khác hẳn chỗ họ kể	Ý kiến tổng quát
Báo lỗi từ người dùng	Vấn đề cấp bách, cụ thể	Nhu cầu chưa ai nghĩ tới
Đánh giá trên cửa hàng ứng dụng	Cảm nhận tổng thể, điểm gây bực	Chi tiết đủ để sửa
Khảo sát trong app	Quy mô của một vấn đề đã biết	Vấn đề chưa biết
Đội hỗ trợ và kinh doanh	Vấn đề lặp lại, ngôn ngữ thật của người dùng	Tính đại diện

Kênh có giá trị cao nhất và bị dùng ít nhất là quan sát người dùng thao tác. Người dùng kể lại thường không khớp với việc họ làm — không phải vì họ nói dối, mà vì phần lớn khó khăn diễn ra quá nhanh để nhớ.

Phỏng vấn cho đúng

Mục tiêu là hiểu hành vi đã xảy ra, không phải lấy ý kiến về tương lai.

Đừng hỏi	Hỏi thay bằng
Anh có muốn tính năng X không?	Lần gần nhất anh gặp việc đó, anh làm thế nào?
Anh thấy màn hình này thế nào?	Anh hãy làm thử việc Y, vừa làm vừa nói anh đang nghĩ gì
Anh có dùng thường xuyên không?	Hôm qua anh mở app mấy lần, để làm gì?
Nếu có tính năng này anh có dùng không?	Hiện giờ anh đang xoay xở bằng cách nào?

Câu hỏi về tương lai luôn nhận được câu trả lời lịch sự và vô dụng. Gần như ai cũng nói "có" với một tính năng giả định, và gần như không ai dùng nó khi có thật.

Ba luật khi ngồi phỏng vấn:

1. Hỏi về quá khứ cụ thể, không hỏi về giả định.
2. Im lặng sau khi hỏi. Phần giá trị nhất thường nằm sau ba giây im lặng khó chịu.
3. Không bào chữa cho sản phẩm. Người dùng chê sai cũng cứ ghi lại, đừng giải thích — giải thích một lần là họ ngừng chê trong suốt phần còn lại.

Năm tới bảy người cho một nhóm đối tượng là đủ để thấy các vấn đề lớn. Không cần mẫu lớn, vì đây không phải khảo sát thống kê.

Nhận và xử lý báo lỗi

Người dùng báo lỗi là món quà — họ bỏ công thay vì lặng lẽ gỡ app. Luật xử lý:

Bước	Thời hạn	Ai
Xác nhận đã nhận	Trong ngày làm việc	Hỗ trợ
Phân loại mức độ	Trong ngày làm việc	Chủ module
Trả lời hướng xử lý	Trong 3 ngày làm việc	Chủ module
Báo lại khi đã sửa xong	Ngay khi release	Hỗ trợ

Bước cuối hay bị quên và đáng giá nhất: người dùng thấy lời của mình dẫn tới thay đổi thật sẽ tiếp tục báo, và kể lại cho người khác.

Mỗi báo lỗi cần ghi đủ: phiên bản app, nền tảng, các bước tái hiện, kết quả mong đợi và kết quả thực tế, thời điểm, ảnh chụp màn hình. Thiếu bước tái hiện là nguyên nhân số một khiến một báo lỗi nằm chết trong backlog.

Một vòng phản hồi khép kín

Nghe  ─▶  Gom nhóm  ─▶  Chọn việc  ─▶  Làm  ─▶  Đo  ─▶  Báo lại người đã nói
  ▲                                                              │
  └──────────────────────────────────────────────────────────────┘

Vòng này đứt ở bước cuối trong hầu hết các đội. Đứt ở đó thì lần sau không ai buồn nói nữa, và ta mất kênh thông tin rẻ nhất đang có.

Gom nhóm phản hồi

Phản hồi lẻ dễ dẫn tới quyết định sai. Một người hét to không đại diện cho ai cả.

Cách làm: mỗi phản hồi ghi vào một chỗ duy nhất, gắn nhãn theo vấn đề, không theo giải pháp người dùng đề nghị. Người dùng nói "cho tôi nút xuất Excel" — vấn đề thật có thể là "tôi không tin số liệu trong app nên phải đối chiếu tay". Sửa đúng vấn đề đó có khi không cần nút xuất nào.

Hằng tháng, xem nhóm nào nhiều lượt nhất, nhóm nào gắn với người dùng quan trọng nhất, và nhóm nào trùng với chỗ số liệu đang xấu. Chỗ ba thứ cắt nhau là việc phải làm.

Nghe sớm, trước khi viết code

Ba việc rẻ, làm trước khi code:

1. Đưa bản vẽ giao diện cho 3 người dùng xem trước khi dev bắt đầu. Nửa giờ, và thường phát hiện một hiểu lầm đáng cả tuần code.
2. Đọc acceptance criteria cho một người dùng nghe bằng ngôn ngữ thường. Họ gật đầu không phải là đạt; họ kể lại đúng bằng lời của họ mới là đạt.
3. Cho đội hỗ trợ và kinh doanh xem trước. Họ biết trước 80% câu hỏi sẽ phát sinh.

Người dùng nội bộ cũng là người dùng

Alliance App có một lợi thế: đội ngũ chính là người dùng. Dùng nó, nhưng cẩn thận với hai bẫy:

• Ta không giống người dùng thật. Ta biết chỗ nào không nên bấm, biết cách né lỗi. Người dùng thật thì không.
• Ta dễ dãi với chính sản phẩm mình làm. Một phiền toái ta đã quen thì người mới thấy là rào cản.

Vậy nên dùng đội nội bộ để bắt lỗi rõ ràng và thử sớm, nhưng quyết định về trải nghiệm thì vẫn phải dựa vào người ngoài.