Đó là câu hỏi từ đồng nghiệp hay hỏi mỗi lần team làm một feature mới cho web. Và đi theo đó là những cái nhíu mày vì sợ feature sẽ làm giảm conversion rate, doanh thu sẽ bị tụt.
Vâng, A/B test là một phương pháp nghiên cứu rất phổ biến và minh bạch. Nhưng hãy biết rằng đó không phải là một phương pháp duy nhất, cũng không thể áp dụng vào tất cả các trường hợp.
Vậy vấn đề ở A/B Test là gì?
Hãy xem quy trình để làm được A/B Test:
- Bạn có ý tưởng một feature mới.
- Design và code feature này
- Bạn chạy A/B test để chứng minh ý tưởng này thật tuyệt vời.
- Khui bia và party.
Nghe có vẻ có lý nhưng có một số vấn đề như thế này:
Metric nào để so sánh?
Điểm chính của A/B test là chọn một metric để so sánh và xác định phiên bản nào sẽ chiến thắng. Bản năng của chính ta có thể mách bảo ta dựa vào thông số trong việc sử dụng feature đó, nhưng thông số này lại không có ở phiên bản cũ. Bài test đã thất bại khi nó còn chưa bắt đầu.
Một thông số khác có thể lựa chọn là doanh thu. Nhưng con số này quá tổng quát, vì có rất nhiều yếu tố khác ảnh hưởng đến doanh thu của một dịch vụ.
Nếu nó thất bại thì sao?
Thì tất nhiên sẽ không thể khui bia và party được.
Nhưng điểm chính ở đây là chúng ta đã bỏ rất nhiều thời gian vào việc xây dựng feature đó, hàng tuần, thậm chí hàng tháng, hàng năm. Không chỉ của một người mà là cả của nhóm.
Căn bản, A/B Test rất thích hợp cho việc cải thiện những thay đổi nhỏ. Có thể so sánh A/B Test với việc leo núi. Mỗi lần test là một bước để leo lên đỉnh.
Xây dựng một feature giống như việc khám phá một ngọn núi mới, một chổ mình chưa biết đến bao giờ. Bạn đưa cho người dùng một thứ mà họ chưa bao giờ làm trước đó.
Bạn thấy chưa, việc leo một ngọn núi đã có và việc khám phá một ngọn núi mới rất khác nhau. A/B test cũng không phù hợp để so sánh ngọn núi này với núi kia.
Nói nhiều vậy thì túm lại là tôi nên làm gì đây?
Xem lại quy trình xây dựng sản phẩm.
Điều mà đồng nghiệp của chúng ta thật sự muốn biết khi họ đặt câu hỏi trên là họ muốn biết rằng chúng ta có dữ liệu nào để quyết định feature có đáng để xây dựng hay không. Đối với họ, A/B Test là cách duy nhất. Nhưng với một người làm UX, chúng ta biết có rất nhiều phương pháp khác để thu thập dữ liệu.
Hãy thay đổi quy trình xây dựng sản phẩm mới như thế này:
- Bạn có một ý tưởng mới.
- Bạn kiểm nghiệm giả thuyết của mình có thiết thực hay không dựa vào việc phỏng vấn người dùng, survey và một số phương pháp nghiên cứu khác.
- Bạn tạo một prototype và đưa cho người dùng sử dụng.
- Bạn nhận feedback từ họ và điều chỉnh prototype.
- Bạn lặp lại bước 3 và 4 cho đến khi bạn thấy tự tin với giải pháp của mình.
- Bạn làm việc với developer để build feature này.
- Bạn tiến hành usability test và update những vấn đề về usability.
- Một khi bạn tin rằng feature này hoạt động tốt giống như mong đợi, phát hành nó cho tất cả mọi người.
- Giờ thì khui bia được rồi.
- Tối ưu feature bằng những A/B Test khác.
Quy trình này được gọi là user-centered design, chúng ta thu thập dữ liệu từ người dùng qua mỗi bước.
Một quy trình dài hơn? Đúng. Thành phẩm chất lượng hơn? Đúng. Ít rủi ro hơn? Đúng luôn.
Và giờ khi đồng nghiệp của bạn hỏi mình đã làm A/B test chưa, bạn có thể trả lời rằng: “Chưa, nhưng mỗi quyết định của chúng tôi đều dự trên data, và nó nói rằng người dùng thật sự rất thích feature này, hãy để tôi chỉ cho bạn những data chúng tôi có”.
Tuy nhiên, cũng có những công ty dùng A/B Test rất tốt. Một case study rất thú vị từ Etsy về việc dùng A/B Test để xây dựng một feature mới: Design for Continuous Experimentation
Các bạn tham khảo nhé!
