4 loại thử nghiệm sản phẩm ít (hoặc không) cần code

Posted by

Lời mở đầu

Thử nghiệm là một trong những công việc quan trọng nhất cần thực hiện để đánh giá không chỉ sự phát triển của một sản phẩm mà đối với bất kỳ sự sáng tạo hay thay đổi nào liên quan tới sản phẩm. Tuy nhiên, thử nghiệm sẽ là một công việc cực kỳ tốn kém và mất thời gian nếu như chúng ta đề nghị đội dev code ra tính năng hoàn chỉnh rồi mới đem đi thử nghiệm. Thử nghiệm xong nếu dùng luôn thì không nói làm gì, còn nếu có thay đổi hoặc bỏ luôn phương án được thử nghiệm thì sẽ cực kỳ lãng phí, đặc biệt là không phải công ty nào cũng có tiềm lực đủ lớn để không bị ảnh hưởng bởi những việc lãng phí như thế này.

Thử nghiệm thì vẫn phải làm, vì có rất nhiều vấn đề không thể làm rõ được nếu không thử nghiệm (có chăng cũng chỉ là đoán mò). Làm sao để bạn biết được:

  • Phương án 1 sẽ tốt hơn phương án 2?
  • Luồng hoạt động mới sẽ hiệu quả hơn luồng cũ, giúp tăng tỷ lệ chuyển đổi?
  • Giao diện của bạn đã tốt cho người dùng, don’t make them think?

và còn nhiều câu hỏi khác nữa… nếu không thử nghiệm?

Trước khi đi vào nội dung, chúng ta cần thống nhất và lưu ý 3 nguyên tắc trước khi thực hiện thử nghiệm:

  • Các cuộc thử nghiệm không nên diễn ra quá dài (không quá 1 tháng). Vì về bản chất, việc thực hiện thử nghiệm là để chứng minh tính đúng sai và cần được thực hiện nhanh nhất có thể. Trong trường hợp thành công, thì phải sớm chuyển sang tìm cách mở rộng quy mô để trở nên bền vững. Còn trong trường hợp thất bại thì bạn cũng đã không lãng phí quá nhiều thời gian và tài nguyên.
  • Cần xác định được một hoặc nhiều thông số có khả năng đánh giá hiệu quả của phương án thử nghiệm. Phương án thử nghiệm được đánh giá là hiệu quả/thành công khi phương án thử nghiệm giúp cải thiện những thông số đã chọn. Ví dụ: thử nghiệm A có làm tăng tỷ lệ visitor đăng ký tài khoản hay thử nghiệm B có làm giảm tỷ lệ exit khỏi trang hay không?,… Trước khi thử nghiệm, hãy chắc chắn rằng bạn đã chọn ra các thông số có thể đo lường được và có tính đại diện cho mục tiêu cần đạt để có thể đưa ra kết luận và đúc kết được bài học về kết quả đạt được.
  • Bản chất của việc thử nghiệm không nhằm mục tiêu thu lợi nhuận ngay hay đạt được thành công ngay. Các thử nghiệm đều là một quá trình học hỏi, tìm hiểu thêm về người dùng và kiểm chứng tính hiệu quả của một phương án giải quyết một vấn đề nào đó. Việc thu lại lợi nhuận chỉ là kết quả tất yếu nếu sau quá trình thử nghiệm, kết quả được tiếp thu và chỉnh sửa (có thể là rất nhiều lần) từ rất nhiều phản hồi và cả than phiền, thậm chí chửi bới 😣
Thử nghiệm cũng là một dạng quá trình phát triển sản phẩm, ở đó cũng cần có idea để BUILD, cần data để MEASURE và đưa ra được insight để LEARN (Ảnh: Lean Startup) 

A/B Testing

Đây chắc chắn là loại thử nghiệm được nhiều người biết đến nhất và được sử dụng phổ biến nhất. Hiểu một cách đơn giản, chúng ta sẽ sử dụng 2 phiên bản khác nhau để so sánh mức độ hiệu quả trên cùng một môi trường hoạt động khi thực hiện A/B Testing. Những ví dụ A/B Testing được áp dụng phổ biến thường là kiểm tra xem người dùng đọc đoạn text A hay đoạn text B xong sẽ có xu hướng thực hiện hành động tiếp theo hơn, hay xem mẫu form A hay mẫu form B có tỷ lệ drop (bỏ cuộc) khi nhập ít hơn,… Từ kết quả thu được sẽ dễ dàng đưa ra được đánh giá về tương quan hiệu quả giữa hai phiên bản.

Bản thân mình cũng đã nhiều lần thực hiện A/B Testing nên thấy được đây là loại thử nghiệm rất hiệu quả và dễ nắm bắt mà không cần nhiều kiến thức về tech. Điều quan trọng ở đây là mẫu thử phải được chia rõ ràng, và có thể đo đếm. Ví dụ, nếu thực hiện mẫu thử trên mobile, ứng dụng định danh tất cả người dùng qua số điện thoại (như ví MoMo, Grab,…) thì ta có thể chia lưu lượng ra làm hai phần để thử, có thể kể một số cách như sau:

  1. Mẫu A dành cho 50% user, mẫu B dành cho 50% còn lại
  2. Mẫu A dành cho user có hai chữ số điện thoại cuối từ 01 đến 50, mẫu B dành cho user có hai chữ số điện thoại cuối từ 51 đến 00

Mấu chốt ở đây là, chúng ta không nhất thiết phải chia đôi lưu lượng sử dụng như (1), dù trên thực tế đây là cách dễ tính nhất vì có thể so sánh số lượng được tính trên hai mẫu (numeric value), mà miễn là bạn có thể so sánh dựa vào tỷ lệ được tính trên mỗi mẫu (percent value).

Ví dụ từ (2): Bạn muốn thử nghiệm mẫu giao diện A hay giao diện B (cùng một mục đích sử dụng) sẽ có số lượng người dùng đi tiếp nhiều hơn?

  • Mẫu A: giả sử bạn có 1000 users có hai chữ số điện thoại cuối từ 01 đến 50. Kết quả có 300 users (numeric value) thực hiện hành động, tỷ lệ 30% (percent value).
  • Mẫu B: giả sử bạn có 500 users có hai chữ số điện thoại cuối từ 51 đến 00. Kết quả cũng có 300 users (numeric value) thực hiện hành động, tỷ lệ 60% (percent value).
  • Mặc dù hai mẫu có cỡ mẫu khác nhau, ta vẫn có thể đi đến kết luận là mẫu B hiệu quả hơn mẫu A. 

Điều quan trọng nhất cần chú ý đối với A/B Testing là tập người dùng sử dụng phải đủ lớn (từ vài nghìn trở lên) thì độ tin cậy và hiệu quả mới cao.

chi tiết về thử nghiệm A/B

Hiện nay, có rất nhiều tool hỗ trợ thực hiện A/B Testing mà không cần sự tham gia (hoặc cần rất ít) của team dev, cụ thể là tool nào thì tiến sĩ Google rất rành, bạn có thể hỏi thử bác ấy. Mình thì thường dùng Google Optimize (kết hợp với Google Tag Manager, Google Analytics) vì có thể chủ động gần như mọi thứ.

Idea Testing

Idea Testing cũng là một loại thử nghiệm phổ biến, tập trung vào việc khai thác thông tin từ người dùng hơn là việc cho họ tương tác trực tiếp trên sản phẩm. Khi thực hiện loại thử nghiệm này, Product Owner hoặc UX Researcher (hoặc cả hai) sẽ cố gắng minh hoạ các ý tưởng mà họ nghĩ tới, trình bày cho người dùng để đánh giá phản hồi dưới dạng một user interview.

Có nhiều cách để minh hoạ: làm wireframe hoặc UI có độ chính xác cao, thậm chí là tạo ra các graphic motion video để mô tả cách thức tính năng đó hoạt động như thế nào. Mục tiêu ở đây là đưa ra ý tưởng một cách nhanh nhất và dễ hiểu nhất để truyền tải cho người dùng.

Gần đây, mình có nhận được lời mời phỏng vấn trải nghiệm sản phẩm mới từ Elsa (chắc là vì mình là một paid active user của họ). Một bạn UX Researcher thực hiện idea testing với mình. Sau phần đầu tìm hiểu các vấn đề từ mình, bạn ấy bắt đầu đưa ra cho mình những options khác nhau và cho mình chọn, hỏi mình lý do vì sao lại chọn option này hoặc option kia.

chi tiết về thử nghiệm ý tưởng

Idea testing cần bạn có một khả năng giao tiếp và dẫn dắt người dùng khi trao đổi. Khi làm được điều này, bạn không chỉ thu hoạch được các feedback về tính năng đang muốn thử nghiệm mà còn tìm ra được rất nhiều insight về cách người dùng sử dụng sản phẩm nói chung.

Concierge Testing

Concierge nghĩa gốc là những người thực hiện tất cả các nhiệm vụ hỗ trợ khách hàng. Thuật ngữ này được dùng nhiều trong ngành dịch vụ, đặc biệt là ở các khách sạn. Ý tưởng của thử nghiệm này trong ngành phần mềm cũng sẽ là việc chúng ta giúp người dùng làm mọi thứ nhưng không phải dưới dạng một tính năng được code hoàn chỉnh, mà là một phiên bản thô sơ, chưa hoàn chỉnh.

Thử nghiệm này được hiểu là đơn giản là việc cung cấp cho người dùng kết quả mà họ mong muốn theo một cách cực kỳ THỦ CÔNG và đó chắc chắn ko phải là giải pháp cuối cùng nếu giải pháp này thành công. Nghe có vẻ hơi khó hiểu đúng không nào? Mình sẽ giải thích qua ví dụ sau:

Công ty bạn muốn làm một cái tính năng để quản lý những sản phẩm đang nằm trong kho (Data Warehouse Management System). Các sản phẩm sẽ được trình bày dưới dạng table-list, kèm theo các tính năng cơ bản như tìm kiếm, bộ lọc, … Nghe qua có vẻ đơn giản, nhưng để những người quản lý kho — người dùng chính của tính năng này — sử dụng HIỆU QUẢ là một điều không dễ dàng. Nếu bạn đề nghị đội dev viết code luôn rồi sau khi release để những người quản lý kho sử dụng luôn thì quả thật là rất tốn thời gian và công sức vì rủi ro rất cao là những thông tin được hiển thị không phải là mối quan tâm của đối tượng sử dụng.

Cách nhanh nhất là bạn hãy tạo trước một file excel chẳng hạn, mỗi column chứa một thông tin mà bạn nghĩ là nên hiển thị, kèm theo đó là những dummy data trên mỗi row (lưu ý: dummy data có thể không hoàn toàn đúng nhưng nên phù hợp với thực tế), kèm theo các bộ lọc (bạn có thể sử dụng hàm QUERY trên Google Spreadsheet để tạo các bộ lọc, let’s google để tìm hiểu thêm về hàm này nhé). Sau đó, bạn chuyển file spreadsheet này cho người quản lý kho để họ dùng thử và nhận phản hồi. Dựa trên phản hồi, bạn biết được các thông tin mà người quản lý kho quan tâm nhất, những số liệu, bộ lọc mà họ muốn sử dụng nhất để giúp công việc dễ dàng hơn. Sau khi chỉnh sửa từ phản hồi, công việc tiếp theo sẽ đơn giản và ít rủi ro hơn rất nhiều.

Minh hoạ một mẫu excel đơn giản để thử nghiệm tính năng quản lý sản phẩm trong kho

Đây là một loại thử nghiệm mình rất thích và cũng thường xuyên sử dụng trong quá trình làm việc. Trong trường hợp giống ví dụ trên hoặc bạn còn đắn đo với một giải pháp mà một team nào đó đưa ra, bạn có thể thực hiện nó, hoặc đề nghị team đó chứng minh rằng giải pháp sẽ hiệu quả. Thử nghiệm này sẽ giúp chúng ta đánh giá được tính khả thi để quyết định bước tiếp theo sẽ làm gì.

chi tiết về thử nghiệm Concierge

Tuy nhiên, thử nghiệm Concierge này sẽ không thể mở rộng quy mô vì nó tốn quá nhiều thời gian dành cho công việc tay chân. Vì vậy, chỉ nên sử dụng nó với một lượng người dùng ít, đủ để chúng ta nhận phản hồi và tiến hành cải thiện.

Nếu, kết hợp Idea Testing & Concierge Testing lại với nhau thì chúng ta sẽ có một mô hình hoàn hảo, người dùng sẽ có một phiên bản vừa hoàn chỉnh, dễ hình dung thông qua các thao tác thực tế.

Wizard of Oz Testing

Đây là loại thử nghiệm “lừa tình” nhất mọi thời đại 😆 Wizard of Oz Testing là phương pháp thử nghiệm làm cho người sử dụng cứ tưởng rằng mình sử dụng một tính năng hoàn chỉnh nhưng họ không biết rằng ở phía bên dưới hệ thống, mọi việc được thực hiện hoàn toàn thủ công => Treo đầu 🐐, bán thịt 🐕‍🦺

Bản chất của Wizard of Oz là không có hệ thống gì đằng sau cả,toàn là con người thực hiện không đấy! (Ảnh: NYU Startup School)

Một ví dụ cụ thể: chắc bạn biết đến email marketing chứ? Thông thường, các email sẽ được gửi một cách tự động theo nguyên tắc được doanh nghiệp mong muốn. Khi người dùng lên một website của bạn và đăng ký nhận tin thì việc họ cần làm đơn đơn giản chỉ là nhập email và submit. Bằng một hệ thống in-house hoặc dùng service của bên khác (Hubspot chẳng hạn) thì hệ thống của bạn có thể gửi email tự động theo quy luật đặt ra (hằng ngày hoặc hằng tuần, hằng tháng, …)

Nhưng email marketing phiên bản Wizard of Oz thì hệ thống chỉ là một field thông tin và một cái button. Khi nhấn button này thì nội dung trong field thông tin sẽ gửi đến database của website. Vậy là xong, không làm bất cứ gì thêm!

Hệ thống của bạn cam kết gửi email cho người dùng dù bạn chẳng có hệ thống nào để tự động làm việc đó. Vì thế, bạn sẽ cần một người (hoặc cả một đội) ngồi…soạn và gửi email cho người dùng hằng ngày. Như thế, người dùng vẫn nhận được email mà không biết rằng, quy trình này hoàn toàn do con người thực hiện (dù thực tế việc thực hiện thế nào, người dùng cũng không cần quan tâm).

chi tiết về thử nghiệm Wizard of Oz

Nghe qua thật dễ dàng. Nhưng đối với những công ty vừa thành lập, chưa có nhiều nguồn lực và kinh phí để phát triển hệ thống in-house hoặc sử dụng service của bên khác, chưa có nhiều người dùng thì đôi khi việc vận hành thủ công sẽ giúp chúng ta hiểu được các pain points ở cả người vận hành và người dùng, từ đó, đôi khi có thể cải tiến luôn được cả luồng xử lý vận hành bên trong.

Tuy nhiên, thử nghiệm này có một nguy hiểm tiềm tàng! Đó là khi đã thực hiện được một thời gian và thấy ổn rồi thì lại muốn…sử dụng lâu dài. Đây không phải là một ý tưởng hay vì suy cho cùng nó được thực hiện rất thủ công và không phù hợp ở quy mô lớn. Thử nghiệm này giúp cho chúng ta ít nhiều biết được mức độ quan tâm và sử dụng của người dùng đối với một tính năng nào đó mà không cần phải làm backend hoàn chỉnh rồi mới release, tránh được rủi ro hao tốn nhân lực làm một tính năng nào đó khi vẫn chưa chắc chắn về tính khả dụng của nó. Vì vậy, khi đã kiểm chứng được hiệu quả tốt, hãy hoàn toàn tự động hoá nó dựa vào quy trình tuyệt vời bạn đã xây dựng/thay đổi từ thử nghiệm này.

Kết luận

Có 4 loại thử nghiệm được đề cập phía trên:

  • A/B Testing: kiểm nghiệm giữa hai mẫu thử trên cùng một môi trường
  • Idea Testing: kiểm nghiệm dựa trên những trao đổi và khai thác thông tin từ người dùng
  • Concierge Testing: kiểm nghiệm bằng cách cho khách hàng trải nghiệm sử dụng luôn giải pháp nhưng dựa trên một phiên bản thô sơ, chưa hoàn chỉnh
  • Wizard of Oz Testing: kiểm nghiệm dựa trên một frontend hoàn chỉnh nhưng backend thì hoàn toàn thủ công.

Bản chất của tất cả những cách thử nghiệm trên là để thu được dữ liệu cần thiết để lựa chọn phương án hiệu quả nhất cho người dùng, cho nên quá trình cầu thị tiếp thu và học hỏi là vô cùng quan trọng.

Trên đây chỉ là 4 cách trong số rất nhiều cách thần kỳ để kiểm nghiệm các tính năng trong việc phát triển sản phẩm mà không cần (hoặc cần rất ít) sự tham gia của đội dev. Vì mỗi nơi có tiềm lực phục vụ cho việc thử nghiệm khác nhau, chúng ta cần lựa chọn phương pháp thử nghiệm phù hợp với năng lực thực thi của đội ngũ. Cách tốt nhất là trước khi đưa requirement cho đội dev, hãy chắc chắn rằng đó là phương án phù hợp nhất đã được kiểm chứng qua các thử nghiệm non-code (hoặc less-code).

Bài viết là nội dung hợp tác giữa Careerly và anh Bùi Châu Minh Tùng. Bạn có thể đọc bài viết trên blog của anh. Bài viết thể hiện quan điểm và kiến thức học hỏi được từ trải nghiệm cá nhân của tác giả, không đại diện cho bất kỳ tổ chức hay cá nhân nào khác. Mọi ý kiến phản biện xin vui lòng gửi về email bcminhtung@gmail.com. Xin cảm ơn!

Để lại bình luận