Thử nghiệm sản phẩm là gì?

Có một nghịch lý dễ chịu: khi không thử nghiệm bạn thường nghĩ rằng bạn biết sản phẩm, người dùng của sản phẩm và họ nên làm gì để đạt được kết quả mong muốn. Ngược lại, khi áp dụng việc thử nghiệm, bạn có thể biết rất ít về sản phẩm và người dùng của mình.
Sản phẩm thành công rất giống với việc khám phá khoa học: Bạn đi từ giả thuyết đến thử nghiệm và rút ra kết luận dựa trên dữ liệu của mình.

Không có thử nghiệm, việc tạo ra sản phẩm sẽ giống như đặt niềm tin vào những giả thuyết chưa được kiểm chứng (và thường là sai). Công việc khó khăn của bạn có khả năng thất bại. Tuy nhiên, với các thiết kế thử nghiệm phù hợp, bạn có thể hiểu rõ hơn về người dùng và sản phẩm của mình, nhanh chóng phát hiện ra các logic bị lỗi, sửa các hiển thị về UI và hướng sản phẩm của bạn đi đúng hướng hơn.

Bài viết này sẽ không nói về việc “Có nên làm thử nghiệm hay không?”, mà chỉ tập trung vào việc nói về bản chất của thử nghiệm sản phẩm, kèm theo đó là các ví dụ minh họa.

Sự khác biệt giữa Giả thuyết (Hypothesis) và Thực tế (Fact)

Chúng ta sẽ đều đồng ý với nhau rằng, khi phát triển một sản phẩm mới, những ý tưởng ban đầu về thị trường và nhu cầu của người dùng thường khác xa với thực tế mà chúng ta sẽ đối diện sau đó.

Bản chất vấn đề ở đây chính là quá trình tích luỹ thông tin để chuyển hoá cái Biết, cái Suy đoán của chúng ta thành cái Hiểu, cái gọi là Khái niệm sản phẩm của mình. Quá trình này rất giống với cách nhận thức của loài người về Trái đất phát triển.

Diễn giải theo cách bình dân hơn, bạn tưởng tượng những đứa trẻ chơi với đồ đạc của chúng, lúc đầu chúng cần thử nhiều thứ và trong quá trình đó chúng tích lũy thông tin mới, từ đó tạo ra các hành vi để thích nghi với thông tin mới đó. Ban đầu đứa trẻ này sẽ đưa ra các giả định (assumptions), sau đó dần dần thì đứa trẻ sẽ nhận được các phản hồi thực tế để có các hành vi tương ứng.

Nếu bạn lập ra các kế hoạch phát triển sản phẩm của mình dựa trên các giả thuyết chưa được kiểm chứng, thì tất cả các kết luận và kế hoạch đều gặp rủi ro. Các giả thuyết chưa được chứng minh nếu được nhận định là các dữ liệu thực tế (fact) có thể rất nguy hiểm.

Mục đích của việc thử nghiệm là loại bỏ các rủi ro lớn càng sớm càng tốt, nhằm biến tất cả các giả thuyết chính thành các kết quả thực tế mà người dùng có thể nhận được.

Thử nghiệm có rất nhiều cách, và sẽ tuỳ thuộc vào 2 yếu tố chính:

• Văn hoá thử nghiệm sản phẩm của nơi bạn đang làm việc.
• Ngân sách, thời gian, nhân lực cho việc thử nghiệm.

Bạn có thể sử dụng các hình thức như A/B Testing, MVP, Usability Testing, Event Tracking tuỳ vào mục đích thử nghiệm của bạn.

Một vài nhầm lẫn phổ biến về Fact

Dưới đây là những điều thường bị nhầm lẫn với giải pháp thực tế:

1. Thông tin tính năng tương tự từ các sản phẩm khác. Những gì đang hoạt động tốt trên một sản phẩm A có thể không nhất thiết phải hoạt động tốt trên một sản phẩm B.
2. Thông tin từ một bài viết trên blog. Bạn có thể đã đọc các bài viết khẳng định các tuyên bố như: “Thêm biểu tượng cảm xúc vào push noti sẽ thúc đẩy giúp tăng tỷ lệ click lên 40%”. Những tuyên bố như thế này nghe giống như thực tế rằng chúng ta cứ áp dụng thì sẽ ra số, nhưng những dữ kiện thế này có thể không nhất thiết đúng trong trường hợp của bạn. Trong nhiều trường hợp chúng ta dù sao cũng nên thử và phải kiểm chứng lần nữa.
3. Giả sử bạn làm trong 1 ngành đủ lâu, bạn đã quá quen với hành vi của người dùng của bạn, họ có xu hướng rời bỏ giỏ hàng lên đến 30%. Tuy nhiên tỷ lệ này vẫn có thể không đúng thực tế với ngành nghề khác.
4. Một số insights về UX như: người dùng không được phép click quá nhiều nếu không họ sẽ dễ rời bỏ flow mua hàng. UX có liên quan đến tâm lý người dùng, nhưng tâm lý đó cũng sẽ bị tác động bởi nhiều yếu tố khác từ các chiến lược của Marketing, các kênh quảng bá trên mạng xã hội. Giữa tâm lý và thực tế sử dụng cũng cần phải kiểm chứng.
5. Bất kỳ thông tin nào không được hỗ trợ bởi dữ liệu chính xác.

Tuy nhiên, nếu có thông tin, giả thuyết có vẻ phù hợp, bạn có thể thêm thông tin đó vào danh sách thử nghiệm. Đây là cách duy nhất để chứng minh giả thuyết có thể trở thành 1 giải pháp thực tế cho người dùng.

Lên kế hoạch thử nghiệm sản phẩm

Tất cả các thử nghiệm luôn bắt đầu với một giả thuyết. Về bản chất, khái niệm về giả thuyết phải được suy nghĩ cẩn thận ngay từ đầu. Điều này rất hữu ích để ước tính hiệu quả dự kiến của một thử nghiệm. Bạn cũng cần xác định tỷ lệ thay đổi dự kiến cho ngưỡng thành công. Ví dụ: nếu thay đổi trong chỉ số X nhỏ hơn N%, thì thử nghiệm được coi là thất bại và tính năng này không đáng để thêm vào.

Bước tiếp theo trong quy trình này là xác định phương pháp cụ thể để kiểm tra giả thuyết. Bạn cần hiểu thử nghiệm sẽ thực sự chạy trên cái gì, hình hài ra sao. Sau đó, bạn cũng phải chọn tập người dùng tham gia thử nghiệm. Bạn cần chia người dùng thành 2 nhóm Test và Control. Người dùng trong danh mục Test sẽ chạy một loạt thử nghiệm do bạn cung cấp, trong khi những người dùng trong danh mục Control sẽ tiếp tục sử dụng các tính năng sẵn có.

Và sau đó bạn sẽ thử nghiệm ngẫu nhiên 2 nhóm người dùng này.

Cuối cùng, bạn cần xác định các số liệu sẽ sử dụng để đo lường tác động của thay đổi. Sau khi thử nghiệm kết thúc, bạn cũng cần tìm hiểu nguyên nhân chi tiết về cách các thay đổi ảnh hưởng đến các số liệu đó.

Các câu hỏi quan trọng trước khi thử nghiệm sản phẩm

1. Giả thuyết của bạn là gì?
2. Bạn có bao nhiêu giả thuyết?
3. Tính năng nào được thay đổi trong sản phẩm? Và tính năng nào sẽ nằm bên nhóm Test?
4. Tập người dùng nào sẽ được đưa vào thử nghiệm?
5. Các số liệu để đo lường sự thay đổi của thử nghiệm?
6. Lấy mẫu người dùng bao nhiêu là vừa đủ với thử nghiệm?
7. Kế hoạch cụ thể sau khi thu thập được kết quả của thử nghiệm?

Lấy mẫu bao nhiêu là phù hợp?

Để xem kết quả có ý nghĩa thống kê phù hợp, bạn cần ước tính kích thước mẫu (sample size) cần thiết để kiểm tra giả thuyết của mình. Khi biết số lượng mẫu cần test, bạn có thể xác định thời gian và nguồn lực cần thiết để đạt được kết quả.

Bạn có thể sử dụng tool này để lấy mẫu tương đối: https://www.evanmiller.org/ab-testing/sample-size.html

Trong hình là ví dụ, bạn chỉ cần quan tâm đến 3 chỗ:

• Conversion rate: ví dụ 18%
• Minimum detectable effect: sai số xung quanh conversion rate của bạn. Ví dụ 18% +/- 2%
• Độ tin cậy mong muốn: bạn để mặc định chỗ dòng Significant level alpha là 5%. Nghĩa là độ tin cậy mong muốn của bạn sẽ là 100% – 5% = 95%.
• Kết quả cho thấy bạn cần lấy mẫu khoảng 5.800 và tiến hành thử nghiệm trên Test và Control ngẫu nhiên.

Hy vọng là bài viết này giúp bạn hình dung được phần nào ý nghĩa của việc Thử nghiệm sản phẩm.