PM: Soạn kịch bản usability test cho luồng đăng ký và thanh toán
Cách chuyển mục tiêu của khách hàng thành kịch bản usability test cho luồng đăng ký và thanh toán: có bối cảnh, khuyến khích thao tác thật và không vô tình chỉ sẵn đường đi trên giao diện.
Một người dùng dừng ở màn hình tạo tài khoản và hỏi: “Tôi có cần làm bước này không?” Nếu người điều phối đáp ngay: “Anh/chị bấm nút ở góc trên là được”, đội sản phẩm vừa đánh mất dữ liệu quý giá.
Có thể nhãn nút chưa rõ. Có thể người dùng không thấy lợi ích của việc tạo tài khoản. Cũng có thể họ chỉ muốn hoàn tất việc mua hàng trước.
Usability test không nhằm chứng minh giải pháp đội đã nghĩ ra là đúng. Nó giúp PM quan sát người dùng thật cố gắng đạt mục tiêu của họ như thế nào, vấp ở đâu và kỳ vọng điều gì.
Bài này là khung soạn kịch bản cho hai hoạt động thường gặp: tạo tài khoản và hoàn tất thanh toán.
Bắt đầu từ mục tiêu người dùng, không phải từ màn hình
Trong usability test, người điều phối giao cho người tham gia một hoạt động trên giao diện, quan sát hành vi và lắng nghe phản hồi. Ba thành phần cốt lõi là:
Người điều phối
Nhiệm vụ
Người tham gia
Trước khi viết kịch bản, hãy phân biệt hai lớp thường bị lẫn với nhau:
Mục tiêu người dùng: điều họ muốn đạt được trong đời thực.
Kịch bản nhiệm vụ: bối cảnh và yêu cầu được đưa cho họ trong buổi test.
Ví dụ, với một sản phẩm thương mại điện tử, mục tiêu của người dùng có thể là:
Tìm sản phẩm phù hợp.
Hiểu tổng chi phí trước khi mua.
Hoàn tất đơn theo cách họ thấy phù hợp.
Theo dõi đơn hàng sau khi mua.
“Người dùng phải tạo tài khoản” không nhất thiết là mục tiêu của người dùng. Đó có thể là yêu cầu của sản phẩm. Người dùng có thể chỉ muốn mua nhanh, lưu thông tin cho lần sau hoặc kiểm tra khả năng giao hàng.
Sự khác biệt này quyết định bạn đang quan sát khả năng sử dụng giao diện hay đang buộc người tham gia đi theo một luồng đã định.
Ba tiêu chí của một kịch bản tốt
Theo NN/g, kịch bản nhiệm vụ hiệu quả cần đáp ứng ba tiêu chí.
1. Thực tế
Người tham gia cần thấy tình huống đủ gần với nhu cầu thật để họ có động lực thao tác như bình thường.
Một nhiệm vụ quá cụ thể có thể khiến họ làm theo chỉ dẫn thay vì đưa ra lựa chọn tự nhiên.
Không nên nói:
> “Mua một đôi giày chạy bộ màu cam của Nike.”
Nên nói:
> “Bạn muốn mua một đôi giày với ngân sách dưới 40 đô la.”
Câu thứ hai vẫn có mục tiêu rõ ràng, nhưng cho người tham gia quyền lựa chọn theo tiêu chí của họ.
2. Có hành động
Hãy yêu cầu người tham gia thực hiện hoạt động trên giao diện, thay vì hỏi họ sẽ làm gì.
Không nên nói:
> “Bạn sẽ tìm giờ chiếu phim như thế nào?”
Nên nói:
> “Hãy tìm một bộ phim mà bạn muốn xem vào chiều Chủ nhật.”
Khi chỉ hỏi “bạn sẽ làm gì?”, người tham gia dễ mô tả bằng lời. Khi yêu cầu họ thao tác, bạn mới quan sát được họ tìm gì, chọn gì, do dự ở đâu và có hoàn thành được hay không.
3. Không tiết lộ con đường thực hiện
Tên nút, tên menu và các bước có sẵn trong câu nhiệm vụ đều có thể vô tình dẫn dắt người tham gia.
Nếu bạn nói “hãy vào giỏ hàng”, bạn không còn kiểm tra được liệu họ có tự tìm thấy giỏ hàng hay không.
Tránh gợi ý không có nghĩa là viết mơ hồ. Kịch bản vẫn cần có bối cảnh và điều kiện đủ rõ để người tham gia hiểu việc cần làm.
Mẫu nhiệm vụ cho luồng tạo tài khoản
Phiên bản dễ dẫn dắt
> “Hãy bấm Đăng ký và tạo tài khoản bằng email.”
Câu này đã tiết lộ nhãn giao diện và cách thực hiện. Bạn sẽ không biết liệu người dùng có tự tìm được điểm bắt đầu, hay có hiểu vì sao họ nên tạo tài khoản.
Phiên bản phù hợp hơn
> “Bạn muốn lưu thông tin để lần mua sau thao tác nhanh hơn và theo dõi các đơn đã đặt. Hãy làm những gì anh/chị thấy cần thiết để chuẩn bị cho việc đó.”
Kịch bản này nêu mục đích, nhưng không nói người tham gia phải tìm nút nào hoặc phải dùng phương thức nào.
Sau khi họ thao tác, bạn có thể hỏi:
“Điều gì khiến anh/chị chọn cách này?”
“Ở đây anh/chị đang mong chờ điều gì?”
“Có điều gì khiến anh/chị phân vân trước khi tiếp tục không?”
“Nếu đang tự dùng ở nhà, anh/chị sẽ làm gì tiếp?”
Mẫu nhiệm vụ cho luồng thanh toán
Phiên bản dễ dẫn dắt
> “Vào giỏ hàng, nhập mã giảm giá rồi thanh toán bằng thẻ.”
Câu này kiểm tra khả năng làm theo hướng dẫn. Nó cũng làm lộ những khu vực và tính năng mà bạn có thể muốn kiểm tra khả năng tìm thấy.
Phiên bản phù hợp hơn
> “Bạn đã chọn được một sản phẩm phù hợp. Bạn muốn đặt hàng đến địa chỉ của mình và chỉ xác nhận khi đã hiểu rõ số tiền cần trả cùng thông tin giao nhận. Hãy tiếp tục theo cách anh/chị thường làm.”
Kịch bản này cho người tham gia một mục tiêu rõ ràng: đặt hàng khi đã hiểu chi phí và thông tin giao nhận. Nhưng cách đi đến đó vẫn do họ quyết định.
Khi họ dừng lại hoặc đến bước xác nhận, hãy dùng câu hỏi trung tính như:
“Trước khi xác nhận, anh/chị cần kiểm tra điều gì?”
“Ở bước này, anh/chị đang mong chờ thông tin nào?”
“Điều gì khiến anh/chị muốn tiếp tục hoặc dừng lại?”
Cách điều phối mà không dẫn dắt
Dẫn dắt không chỉ xuất hiện trong câu nhiệm vụ. Nó cũng xuất hiện trong phản ứng của người điều phối.
| Thay vì hỏi | Hãy hỏi |
|---|---|
| “Anh/chị có thấy nút này rõ không?” | “Anh/chị đang tìm gì ở đây?” |
| “Form này có quá dài không?” | “Anh/chị cảm thấy thế nào khi đến bước này?” |
| “Anh/chị có thích cách thanh toán này không?” | “Trong lúc thanh toán, điều gì quan trọng với anh/chị?” |
Một dấu hiệu cho thấy nhiệm vụ chưa đủ tính hành động là người tham gia ngừng thao tác và nói: “Tôi sẽ bấm chỗ này, rồi chắc sẽ có…”.
Khi đó, bạn có thể nhắc nhẹ:
> “Anh/chị cứ thử thao tác như bình thường nhé.”
Mục tiêu là quan sát hành vi trên giao diện, không phải nghe một lời giải thích giả định về hành vi.
Khuyến khích người tham gia nói ra suy nghĩ
Trong usability test, người tham gia thường được mời nói ra suy nghĩ khi thao tác. Cách này giúp đội nghiên cứu hiểu thêm mục tiêu, kỳ vọng và lý do đằng sau hành vi.
Bạn có thể mở đầu bằng lời nhắc ngắn:
> “Trong lúc sử dụng, anh/chị hãy nói ra điều mình đang tìm, điều khiến mình phân vân hoặc điều mình mong sẽ xảy ra. Không có câu trả lời đúng hay sai; chúng tôi đang kiểm tra giao diện, không kiểm tra anh/chị.”
Nếu người tham gia im lặng, hãy nhắc lại một cách trung tính. Tránh giải thích giao diện hoặc chỉ họ bước tiếp theo.
Ghi nhận phát hiện: tách quan sát khỏi diễn giải
Sau mỗi phiên, hãy ghi tách biệt những gì người dùng đã làm và điều đội suy ra từ hành vi đó.
| Nhiệm vụ | Quan sát | Bằng chứng lời nói | Diễn giải cần kiểm tra |
|---|---|---|---|
| Chuẩn bị cho lần mua sau | Người dùng tìm trong menu rồi quay lại trang sản phẩm | “Tôi chưa biết phải bắt đầu từ đâu.” | Điểm bắt đầu hoặc lợi ích của việc tạo tài khoản có thể chưa rõ |
| Hoàn tất đơn | Người dùng dừng trước bước xác nhận | “Tôi muốn biết tổng tiền trước.” | Thông tin tổng chi phí có thể chưa xuất hiện đúng lúc hoặc chưa dễ thấy |
Đừng vội viết: “Người dùng không thích form đăng ký” nếu bằng chứng chỉ là một người dừng ở một trường thông tin. Hãy bắt đầu bằng điều đã quan sát, sau đó nêu diễn giải như một giả thuyết cần kiểm tra tiếp.
Cần bao nhiêu người tham gia?
Với một nghiên cứu usability định tính điển hình cho một nhóm người dùng, NN/g khuyến nghị sử dụng năm người tham gia để phát hiện phần lớn các vấn đề phổ biến.
Con số này phù hợp với mục tiêu tìm và hiểu vấn đề trải nghiệm. Nếu mục tiêu là tạo benchmark, bạn có thể đo các chỉ số như:
Tỷ lệ hoàn thành nhiệm vụ.
Thời gian hoàn thành nhiệm vụ.
Đừng dùng một nhóm nhỏ của nghiên cứu định tính để suy rộng thành tỷ lệ cho toàn bộ khách hàng.
Checklist trước khi chạy test
[ ] Mỗi nhiệm vụ bắt đầu từ mục tiêu thật của người dùng.
[ ] Kịch bản có bối cảnh rõ ràng và đủ thực tế.
[ ] Nhiệm vụ yêu cầu người tham gia thao tác, không chỉ mô tả họ sẽ làm gì.
[ ] Câu chữ không chứa tên nút, tên menu hoặc chỉ dẫn từng bước.
[ ] Câu hỏi theo sau làm rõ hành vi, kỳ vọng và lý do.
[ ] Ghi chú tách quan sát khỏi diễn giải.
[ ] Các đề xuất thay đổi được đối chiếu lại với hành vi và phản hồi đã ghi nhận.
Một kịch bản ngắn, thực tế và trung tính thường hữu ích hơn danh sách câu hỏi dài. Mục tiêu không phải là giúp người dùng “qua được” luồng đăng ký hay thanh toán, mà là hiểu giao diện đang hỗ trợ hoặc cản trở họ hoàn thành việc họ đến để làm.