Sau buổi thử MVP: sửa sản phẩm hay tiếp tục hướng hiện tại?

Một nhóm sinh viên vừa cho người dùng thử công cụ tìm và đặt chỗ học nhóm. Bản demo chạy được từ đầu đến cuối. Khi hỏi cảm nhận, vài người nói giao diện đẹp và ý tưởng tiện. Nếu chỉ nghe đến đây, nhóm có thể nghĩ mình đã chọn đúng giải pháp.

Nhưng trong ghi chép của buổi thử lại có những chi tiết khác: một người dừng khá lâu ở bước chọn giờ; một người bấm đặt phòng hai lần vì không thấy thông báo xác nhận; một người hoàn tất thao tác nhưng hỏi liệu đến nơi phòng có thực sự còn trống hay không. Cuộc họp sau đó chia thành hai ý kiến: “Phải thiết kế lại” và “Vài lỗi nhỏ thôi, cứ làm tiếp”.

Vậy nên sửa MVP, hay giữ hướng hiện tại? Câu trả lời nằm ở giả thuyết nhóm muốn kiểm tra, hành vi đã quan sát được và mức độ nghiêm trọng của khoảng cách giữa hai điều đó.

Ví dụ đặt chỗ trong bài là tình huống giả định để minh họa cách ra quyết định, không phải dữ liệu thử nghiệm của một dự án có thật.

Trước khi đọc phản hồi, hãy nhớ mình đã dự đoán gì

Một buổi thử dễ trở thành cuộc thu thập ý kiến lan man nếu nhóm không viết rõ câu hỏi từ trước. Với công cụ đặt chỗ, giả thuyết có thể là: “Sinh viên lần đầu sử dụng có thể tự tìm và đặt một chỗ phù hợp cho buổi học nhóm mà không cần người hướng dẫn.” Nhóm giao nhiệm vụ: “Chiều mai bạn cần chỗ cho bốn người; hãy thử đặt một phòng.”

Giả thuyết ấy cho biết phải nhìn vào đâu. Người thử có bắt đầu đúng chỗ không? Họ có hiểu khung giờ nào còn trống? Sau khi bấm xác nhận, họ có biết lượt đặt đã thành công? Nếu họ hoàn thành nhờ thành viên nhóm chỉ từng bước, nhiệm vụ đã hoàn tất nhưng giả thuyết “tự sử dụng” chưa được ủng hộ.

Lời khen về màu sắc hoặc nhận xét “ứng dụng này hay” vẫn có giá trị. Tuy nhiên, nó trả lời một câu hỏi khác với việc người dùng có tự hoàn thành tác vụ quan trọng hay không. Nhóm nên giữ cả hai loại thông tin, đồng thời không lấy lời khen để che đi hành vi bị kẹt.

Đọc ghi chép như một người điều tra

Sau buổi thử, hãy xem lại từng trường hợp trước khi vội đếm xem có bao nhiêu người “thích”. Điều gì đã xảy ra trên màn hình? Người thử nói gì ngay tại thời điểm đó? Người hướng dẫn có vô tình gợi ý không? Vấn đề lặp lại ở nhiều người hay chỉ xuất hiện khi một thiết bị gặp lỗi?

Nên tách ba lớp trong ghi chép. Quan sát: “Người thử bấm vào khung giờ đã kín và chờ phản hồi.” Diễn giải: “Có thể màu sắc chưa giúp họ phân biệt giờ trống với giờ kín.” Đề xuất: “Đổi nhãn và trạng thái hiển thị, rồi thử lại.” Nếu viết gộp thành “giao diện khó dùng”, nhóm sẽ khó biết phải sửa chính xác phần nào và vì sao.

Cũng cần nhìn người tham gia có phù hợp với nhóm khách hàng mục tiêu hay không. Nếu toàn bộ người thử là bạn bè đã nghe nhóm giới thiệu sản phẩm từ trước, họ có thể hiểu những thuật ngữ mà người dùng mới không hiểu. Ngược lại, một người không bao giờ cần tìm chỗ học nhóm sẽ khó giúp nhóm đánh giá nhu cầu thực tế. Những giới hạn ấy cần được nói thẳng khi trình bày kết quả.

Khi nào nên iterate: sửa điều đã được chỉ ra

Iterate là thay đổi một phần giải pháp dựa trên điều vừa học được, rồi cho người dùng thử phiên bản mới. Nếu nhiều người không nhận ra giờ nào còn trống, nhóm có thể thay màu, thêm nhãn bằng chữ và làm rõ trạng thái không thể chọn. Nếu người dùng đặt xong mà vẫn bấm lại, nhóm cần kiểm tra thông báo xác nhận, chứ chưa chắc phải viết thêm một tính năng mới.

Có những lỗi nằm sâu hơn giao diện. Giả sử ai cũng đặt phòng thành công nhưng khi đến nơi lại thấy phòng đã có người. Điểm hỏng nằm ở dữ liệu hoặc quy trình cập nhật của người quản lý. Việc làm nút “Đặt ngay” lớn hơn không khiến thông tin đáng tin hơn. Nhóm phải tìm cách cập nhật trạng thái kịp thời, hoặc thu hẹp phạm vi vận hành đến mức mình có thể kiểm soát.

Mỗi lần sửa nên trả lời được ba câu: Vấn đề nào đã được quan sát? Thay đổi này dự kiến giải quyết nó bằng cách nào? Buổi thử tiếp theo sẽ cho biết thay đổi có hiệu quả ra sao? Nếu không trả lời được, việc sửa rất dễ trở thành trang trí sản phẩm theo sở thích của nhóm.

Một người thử có thể đề xuất chatbot, tích điểm hoặc bản đồ toàn trường. Đừng vội thêm tất cả. Hãy hỏi đề xuất đó có giúp người dùng hoàn thành hành trình cốt lõi hoặc kiểm tra giả thuyết quan trọng hơn không. MVP càng nhiều phần, nhóm càng khó phân biệt tác động của thay đổi nào.

Khi nào có thể persevere: giữ hướng, tiếp tục kiểm chứng

Persevere là tiếp tục hướng giải pháp hiện tại vì những gì nhóm quan sát vẫn ủng hộ giả thuyết chính. Chẳng hạn, người thử thuộc nhóm khách hàng mục tiêu tự tìm được phòng, hoàn tất lượt đặt, hiểu xác nhận và cho thấy cách này hữu ích trong tình huống họ thường gặp. Nhóm có thể giữ hành trình đặt chỗ, xử lý các lỗi nhỏ và đưa bản tiếp theo đến một địa điểm khác hoặc một nhóm người dùng mới.

Điều đó không có nghĩa sản phẩm đã hoàn hảo hay thị trường chắc chắn sẽ trả tiền. Buổi thử khả năng sử dụng chủ yếu cho thấy con người tương tác với bản sản phẩm hiện tại ra sao. Câu hỏi về tần suất sử dụng, độ tin cậy khi vận hành và quyết định mua vẫn cần những phép thử riêng. Giữ hướng hiện tại là một quyết định có giới hạn, kèm điều kiện sẽ kiểm tra tiếp.

Đôi khi quyết định trung thực nhất lại là chưa đủ bằng chứng. Một buổi thử quá ngắn, thiết bị lỗi giữa chừng hoặc người tham gia chưa đúng đối tượng không cho phép nhóm kết luận mạnh. Khi ấy, đừng tô thành “đa số hài lòng”, cũng đừng đập bỏ ý tưởng. Hãy cải thiện cách thử và mời đúng người tham gia vòng tiếp theo.

Nếu người dùng hiểu cách thao tác nhưng không hề cần đặt chỗ trước, vấn đề có thể không nằm ở giao diện. Nhóm cần quay lại xem nhu cầu mình chọn có đủ quan trọng không, hoặc giải pháp có giải quyết đúng nhu cầu ấy không. Đó là câu hỏi lớn hơn việc sửa một màn hình: có thể phải điều chỉnh giả thuyết về khách hàng hay cách tạo giá trị.

Ghi quyết định để người khác thấy nhóm đã học gì

Sau mỗi vòng thử, nhóm nên lưu lại phiên bản đã được dùng, nhiệm vụ giao cho người thử, những quan sát quan trọng và quyết định của mình. Không cần một báo cáo dài. Một đoạn ngắn, rõ nguyên nhân, thường hữu ích hơn hàng chục ảnh chụp màn hình không có lời giải thích.

Ví dụ: “Ở phiên bản đầu, chúng tôi dự đoán người dùng tự chọn được khung giờ. Trong buổi thử, một số người nhầm giờ đã kín với giờ còn trống và cần được giải thích. Chúng tôi quyết định giữ chức năng đặt chỗ, nhưng đổi cách hiển thị trạng thái giờ. Ở vòng kế tiếp, chúng tôi sẽ giao cùng nhiệm vụ cho những người chưa xem bản cũ và quan sát họ có còn nhầm không.”

Đoạn ghi ấy phân biệt rõ giữ hướng sản phẩm với sửa cách thực hiện. Nó cũng biến lần thử tiếp theo thành một phép kiểm tra có mục tiêu. Nếu bản mới vẫn khiến người dùng hiểu nhầm, nhóm có căn cứ để thử cách thiết kế khác. Nếu lỗi biến mất nhưng phòng vẫn bị đặt trùng, ưu tiên tiếp theo phải là quy trình vận hành.

Khi trình bày dự án, đừng chỉ chiếu hai giao diện “trước” và “sau”. Hãy kể chuỗi quyết định: nhóm đã tin điều gì, người dùng thực sự làm gì, nhóm thay đổi phần nào, giữ phần nào và vì sao. Nếu kết quả trái kỳ vọng, cứ nói đúng. Một điểm yếu được phát hiện và xử lý có giá trị hơn một lời khẳng định chung rằng “người dùng phản hồi tích cực”.

Buổi thử MVP giúp nhóm bớt phải đoán. Iterate khi có bằng chứng cho thấy cần sửa; persevere khi hướng chính vẫn được ủng hộ; và thử thêm khi dữ liệu chưa đủ để chọn một trong hai. Điều quan trọng là sau mỗi quyết định, nhóm biết mình sẽ quan sát điều gì ở phiên bản tiếp theo.

Tài liệu tham khảo

• The Lean Startup — Methodology: vòng lặp xây dựng, đo lường, học hỏi và quyết định tiếp tục hay đổi hướng. theleanstartup.com

• GOV.UK — Phân tích một buổi nghiên cứu người dùng: dùng quan sát để chọn phần cần thay đổi hoặc nghiên cứu tiếp. www.gov.uk

• GOV.UK — Chia sẻ kết quả nghiên cứu người dùng: trình bày kết quả để cả nhóm có thể hành động. www.gov.uk