Cách đo lường tác động của tính năng với khung TARS

[PVS]

Cách đo lường tác động của tính năng với khung TARS

Bạn thiết kế và ra mắt một tính năng mới rất hào nhoáng. Nhưng làm sao để biết nó có hoạt động hiệu quả hay không? Làm thế nào để đo lường và theo dõi tác động của nó? Không thiếu các chỉ số UX (trải nghiệm người dùng), nhưng nếu bạn muốn thiết lập một chỉ số đơn giản, có thể lặp lại và đầy ý nghĩa — dành riêng cho các tính năng của mình thì sao? Hãy cùng xem cách thực hiện điều đó với khung TARS.

Tôi nghe nói về khung TARS lần đầu tiên từ bài viết tuyệt vời của Adrian H. Raudschl về “Cách đo lường tác động của các tính năng”. Tại đó, Adrian đã nêu bật cách nhóm của ông theo dõi và quyết định tính năng nào cần tập trung — sau đó so sánh chúng với nhau trong một ma trận 2x2.

Hóa ra đây là một khung rất hữu ích để trực quan hóa tác động của công việc UX qua lăng kính của các chỉ số kinh doanh. Hãy xem nó hoạt động như thế nào.

1. Target Audience - Khán giả mục tiêu (%)​

Chúng ta bắt đầu bằng việc định lượng khán giả mục tiêu bằng cách khám phá xem bao nhiêu phần trăm người dùng của sản phẩm gặp phải vấn đề cụ thể mà tính năng này nhắm đến giải quyết. Chúng ta có thể nghiên cứu các tính năng hiện có hoặc tương tự đang cố gắng giải quyết các vấn đề tương tự, và xem có bao nhiêu người dùng tương tác với chúng.

Tuy nhiên, khán giả mục tiêu không giống với mức độ sử dụng tính năng. Như Adrian đã lưu ý, nếu chúng ta biết rằng tính năng Export Button (Nút xuất) hiện tại được sử dụng bởi 5% tổng số người dùng, điều đó không có nghĩa là khán giả mục tiêu chỉ là 5%. Có thể nhiều người dùng hơn gặp vấn đề mà tính năng xuất này đang cố giải quyết, nhưng họ không tìm thấy nó.

Câu hỏi chúng ta đặt ra: “Bao nhiêu phần trăm trong tổng số người dùng sản phẩm của chúng ta gặp phải vấn đề cụ thể mà tính năng mới nhắm đến giải quyết?”

2. Adoption - Tỷ lệ chấp nhận (%)​

Tiếp theo, chúng ta đo lường mức độ hiệu quả trong việc “thu hút” khán giả mục tiêu. Để làm điều đó, chúng ta theo dõi xem có bao nhiêu người dùng thực sự tương tác thành công với tính năng đó trong một khoảng thời gian cụ thể.

Chúng ta không tập trung vào CTR (tỷ lệ nhấp) hay thời lượng phiên truy cập, mà là liệu người dùng có tương tác một cách có ý nghĩa với nó hay không. Ví dụ: bất cứ điều gì báo hiệu rằng họ thấy nó có giá trị, chẳng hạn như chia sẻ URL xuất, số lượng tệp đã xuất, hoặc việc sử dụng các bộ lọc và cài đặt.

Mức độ chấp nhận tính năng cao (>60%) cho thấy vấn đề đó có tác động lớn. Mức độ chấp nhận thấp (<20%) có thể ngụ ý rằng vấn đề đó có các giải pháp thay thế đơn giản mà mọi người đã quen dùng. Việc thay đổi thói quen cũng cần thời gian, vì vậy mức độ chấp nhận thấp trong thời gian đầu là điều bình thường.

Đôi khi, tỷ lệ chấp nhận thấp không liên quan gì đến bản thân tính năng, mà là do vị trí của nó trong giao diện người dùng (UI). Người dùng có thể không bao giờ khám phá ra nó nếu nó bị ẩn đi hoặc có nhãn tên gây nhầm lẫn. Nó phải đủ rõ ràng để mọi người tình cờ nhìn thấy.

Tỷ lệ chấp nhận thấp không phải lúc nào cũng đồng nghĩa với thất bại. Nếu một vấn đề chỉ ảnh hưởng đến 10% người dùng, nhưng đạt được 50–75% tỷ lệ chấp nhận trong nhóm người dùng ngách đó thì tính năng này vẫn được coi là thành công.

Câu hỏi chúng ta đặt ra: “Bao nhiêu phần trăm người dùng mục tiêu đang hoạt động thực sự sử dụng tính năng để giải quyết vấn đề đó?”

3. Retention - Tỷ lệ duy trì (%)​

Tiếp theo, chúng ta nghiên cứu xem liệu một tính năng có thực sự được sử dụng lặp lại hay không. Chúng ta đo lường tần suất sử dụng, hay cụ thể hơn, có bao nhiêu người dùng đã tương tác với tính năng thực sự tiếp tục sử dụng nó theo thời gian. Thông thường, đây là tín hiệu mạnh mẽ cho thấy tác động có ý nghĩa.

Nếu một tính năng có tỷ lệ duy trì trung bình >50%, chúng ta có thể khá tự tin rằng nó có tầm quan trọng chiến lược cao. Tỷ lệ duy trì 25–35% báo hiệu tầm quan trọng chiến lược trung bình, và tỷ lệ duy trì 10–20% là thấp.

Câu hỏi chúng ta đặt ra: “Trong số tất cả những người dùng đã chấp nhận tính năng một cách có ý nghĩa, có bao nhiêu người quay lại sử dụng nó lần nữa?”

4. Satisfaction - Mức độ hài lòng (CES)​

Cuối cùng, chúng ta đo lường mức độ hài lòng mà người dùng có đối với tính năng mà chúng ta đã phát hành. Chúng ta không hỏi tất cả mọi người — chúng ta chỉ hỏi những người dùng “đã được duy trì” (retained users). Điều này giúp chúng ta phát hiện những rắc rối tiềm ẩn có thể không được phản ánh trong điểm số duy trì.

Khi người dùng thực sự sử dụng một tính năng nhiều lần, chúng ta hỏi họ xem việc giải quyết vấn đề dễ dàng như thế nào sau khi sử dụng tính năng đó — thang điểm từ “khó hơn nhiều” đến “dễ hơn nhiều so với mong đợi”.

Sử Dụng TARS Cho Chiến Lược Tính Năng​

Khi bắt đầu đo lường với TARS, chúng ta có thể tính toán điểm số S/T — tỷ lệ phần trăm Người dùng Hài lòng (Satisfied) chia cho Người dùng Mục tiêu (Target). Nó cho chúng ta cảm nhận về việc tính năng đang hoạt động tốt như thế nào đối với đối tượng khán giả dự kiến. Khi thực hiện điều đó cho mọi tính năng, chúng ta có thể lập bản đồ tất cả các tính năng trên 4 góc phần tư trong ma trận 2x2.

Các nhóm tính năng:​

• Overperforming (Vượt trội): Đáng để chú ý; chúng có tỷ lệ duy trì thấp nhưng mức độ hài lòng cao. Có thể đơn giản là những tính năng người dùng không cần sử dụng thường xuyên, nhưng khi dùng thì cực kỳ hiệu quả.
• Liability (Gánh nặng): Có tỷ lệ duy trì cao nhưng mức độ hài lòng thấp, vì vậy có lẽ chúng ta cần cải thiện chúng.
• Sau đó, chúng ta cũng có thể xác định các Core features (Tính năng cốt lõi) và Project features (Tính năng dự án) — và thảo luận với các nhà thiết kế, PM và kỹ sư về những gì nên làm tiếp theo.

Tỷ Lệ Chuyển Đổi Không Phải Là Một Chỉ Số UX​

TARS không bao gồm tỷ lệ chuyển đổi (conversion rate), và có lý do chính đáng cho việc đó. Như Fabian Lenz đã lưu ý, chuyển đổi thường được coi là chỉ số thành công cuối cùng — nhưng trong thực tế, rất khó để trình bày mối liên hệ rõ ràng giữa các sáng kiến thiết kế nhỏ và các mục tiêu chuyển đổi lớn.

Sự thật là hầu hết mọi người trong nhóm đều đang làm việc để hướng tới chuyển đổi tốt hơn. Một sự gia tăng có thể liên quan đến nhiều sáng kiến khác nhau — từ bán hàng và tiếp thị đến tăng tốc độ web, hiệu ứng theo mùa cho đến các sáng kiến UX.

UX tất nhiên có thể cải thiện chuyển đổi, nhưng đó không thực sự là một chỉ số UX. Thường thì mọi người đơn giản là không thể chọn sản phẩm họ đang sử dụng. Và thường thì kết quả kinh doanh mong muốn đến từ sự cần thiết và sự cố gắng xoay sở của người dùng, thay vì sự tin tưởng và đánh giá cao.

Chuyển đổi cao dù UX tệ​

Như Fabian viết, tỷ lệ chuyển đổi cao có thể xảy ra bất chấp UX kém, bởi vì:

• Sức mạnh thương hiệu lớn thu hút mọi người.
• Các chiến thuật tạo sự khẩn cấp tuy "hung hăng" nhưng hiệu quả.
• Giá cả cực kỳ hấp dẫn.
• Tiếp thị hoạt động xuất sắc.
• Lòng trung thành của khách hàng trong quá khứ.
• Người dùng đơn giản là không có sự thay thế nào khác.

Chuyển đổi thấp dù UX tuyệt vời​

Đồng thời, tỷ lệ chuyển đổi thấp có thể xảy ra mặc dù UX tuyệt vời, bởi vì:

• Ưu đãi không phù hợp với khán giả.
• Người dùng không tin tưởng thương hiệu.
• Mô hình kinh doanh kém hoặc rủi ro thất bại cao.
• Tiếp thị không tiếp cận đúng đối tượng.
• Các yếu tố bên ngoài (giá cả, thời điểm, đối thủ cạnh tranh).

Chuyển đổi được cải thiện là kết quả tích cực của các sáng kiến UX. Nhưng công việc UX tốt thường cải thiện việc hoàn thành tác vụ, giảm thời gian thực hiện tác vụ, giảm thiểu lỗi và tránh tình trạng tê liệt khi ra quyết định. Và có rất nhiều chỉ số thiết kế khả thi mà chúng ta có thể sử dụng để theo dõi UX và thúc đẩy thành công bền vững.

Lời Kết​

Chỉ riêng các chỉ số sản phẩm không phải lúc nào cũng cung cấp cái nhìn chính xác về hiệu suất của sản phẩm. Doanh số có thể tốt, nhưng người dùng có thể đang cực kỳ kém hiệu quả và thất vọng. Tuy nhiên, tỷ lệ rời bỏ (churn) thấp vì người dùng không thể chọn công cụ khác.

Chúng ta cần các chỉ số UX để hiểu và cải thiện trải nghiệm người dùng. Điều tôi thích nhất ở TARS là nó là một cách gọn gàng để kết nối việc sử dụng của khách hàng và trải nghiệm của khách hàng với các chỉ số sản phẩm có liên quan. Cá nhân tôi sẽ mở rộng TARS với các chỉ số và KPI tập trung vào UX — tùy thuộc vào nhu cầu của dự án.