Protect Users’ Work

Nhắc lại khái niệm usability căn bản: Đừng cản trở người dùng

Foody-update

(Hình 1: Ảnh chụp màn hình Foody app yêu cầu người dùng nâng cấp phiên bản mới)

Dạo này viết lách về Foody hơi nhiều, nhưng có lẽ mobile app của Việt Nam ít người review quá, nên nhân dịp gặp một case study mới, mình lại “tám” một chút về nó.

Case study

Tình huống người sử dụng lần này khá đơn giản: Tôi và bạn gái hẹn nhau đi ăn tối, và quyết định khám phá 1 chi nhánh mới mở của M2C cafe. Trong đầu không nhớ rõ địa chỉ, vì thế nên nhớ tới Foody app nên lấy điện thoại ra để tìm địa điểm. Hai người chúng tôi dùng một chiếc iPhone 5 và một chiếc iPhone 4, cả hai đều cài ứng dụng Foody từ AppStore. Tuy nhiên, khi bạn tôi mở foody app thì nhận được thông báo “yêu cầu phải nâng cấp phiên bản mới nhất“, nếu không bấm vào CTA “Launch AppStore” thì chỉ có nước thoát khỏi ứng dụng mà thôi. Tôi cũng thử lại một lần nữa với Foody app trên điện thoại của mình và cũng nhận được kết quả tương tự. Câu hỏi đặt ra là:

  • Nhu cầu của chúng tôi (users) là sử dụng app để tìm địa chỉ quán. Chúng tôi không muốn cập nhật vào lúc này, làm sao để đạt được mục đích?
  • Khi bạn đang đứng ở.. ngoài đường, thì khả năng update ứng dựng từ AppStore với mạng 3G của Việt Nam là không khả thi và tốn rất nhiều thời gian, trong khi đó thì bạn đang đói. Thứ mà ứng dụng “yêu cầu” không match với cái người dùng cần.  Mà nếu không update Foody app thì.. có ảnh hưởng gì tới hòa bình thế giới không?

Khái niệm usability căn bản

Tôi không biết bản Foody app v2.7 có gì nổi bật, ngay cả giờ đây sau khi đã cập nhật xong xuôi, thứ tôi cần vẫn chỉ là tìm địa điểm quán ăn / cafe một cách nhanh nhất, tiện nhất khi cần thiết (mà phần lớn tôi đoán rằng user behavior của người dùng sẽ diễn ra ở… ngoài đường). Tôi không thực hiện được điều tôi muốn, không thao tác được chức năng cơ bản nếu không update phiên bản mới, và điều này gọi là blocker bugs trong khái niệm phần mềm.

Prevents developers or testers from performing their jobs. Impacts the development process. – open SUSE – Bug definitions

Đối với interaction design thì điều này phạm phải 2 nguyên tắc cơ bản nhất đó là ngăn cản người dùng thao tác với sản phẩm / thiết bị / ứng dụng phần mềm và không cho phép người dùng ra quyết định đối với tương tác hệ thống. Nghe có vẻ to tát, nhưng thực chất từ chuyên môn gọi là Protect Users’ Work và Autonomy. Cụ thể hơn, 2 nguyên tắc này có thể được giải thích ngắn gọn như sau:

  1. Autonomy: Qui tắc này cho phép người dùng đưa ra quyết định của riêng họ, kể cả với những người kém về mặt thẩm mỹ hoặc yếu trong khâu thao tác với sản phẩm ( Nguyên văn: Enable users to make their own decisions, even ones aesthetically poor or behaviorally less efficient).
  2. Protect Users’ Work: Đây là qui tắc đầu tiên và căn bản của usability design. Ý nghĩa của nó là luôn luôn đảm bảo người sử dụng hoàn thành công việc của mình, đảm bảo công việc của họ được thực hiện thành công. Ngoài ra, nghĩa mở rộng của qui tắc này là đảm bảo người dùng không bị mất thông tin, dữ liệu trong trường hợp không thể tiếp tục thao tác với ứng dụng (vd: mất đường truyền internet, mất password…)

Cải tiến nho nhỏ?

Trường hợp của Foody app không phải là quá khó cải tiến, mà có lẽ ai trong chúng ta cũng biết, với 1 thay đổi nhỏ nhưng sẽ mang lại hiệu quả tích cực hơn với người dùng, ví dụ như: Bổ sung nút lựa chọn “Later” bên cạnh nút CTA “Launch AppStore” để người dùng có quyền lựa chọn cài đặt bản nâng cấp hay tiếp tục sử dụng phiên bản cũ.

Vấn đề ở đây không lớn, nhưng thuộc về khái niệm cơ bản mà có lẽ những người ở vị trí nhân viên phụ trách sản phẩm (Product manager / UX manager ) nên có một checklist để kiểm tra trước khi để sản phẩm go live.

Tham khảo:

  • 10 Usability Heuristics for User Interface Design [URL]
  • First Principles of Interaction Design (Revised & Expanded) [URL] => Cái này rất rất chi là cơ bản 🙂

 

Xin chào, Bạn vừa bị từ chối!

Gamification Design: Trải nghiệm với Foody.vn – Liệu bạn có được tạo hứng thú để tham gia cuộc chơi?

foody-reject

(Hình 1: Nội dung email Foody.vn tự động gửi cho người dùng)

Một buổi sáng đẹp trời tôi kiểm tra hòm thư Gmail và nhận được một “loạt” những email với nội dung: “Xin chào! Bạn vừa bị từ chối… do vi phạm quy định…”. Những email này được lặp đi lặp lại với cùng nội dung, chỉ thay đổi địa điểm ăn uống. Sau khi định hình, tôi nhận ra đó là một dạng newsletter từ hệ thống Foody.vn, một social network với niche market là các địa điểm ẩm thực.

Cảm giác ban đầu của sự trải nghiệm này đơn giản là: Tôi không biết mình đã làm gì sai để “vi phạm quy định” và tôi không biết tôi cần gì từ hệ thống này để rồi bị “từ chối”?. Sau khi cố gắng nhớ lại, hành vi (user behavior) của tôi trong ngày hôm trước bao gồm các bước như sau:

  • Lang thang một số quán ăn ở quận Tân Bình, quận 7
  • Mở ứng dụng Foody trên iPhone 4
  • Comment một số địa chỉ quán ăn bị sai, cũng như nhận xét về 1 vài món ăn.
  • Với tôi, tại thời điểm này, Foody là một công cụ tìm kiếm địa điểm ăn uống. Chưa phải là 1 mạng xã hội mà tôi sống với nó từng ngày.

Sau khi nhận được 1 loạt email của Foody, cảm giác (user feeling) của tôi khá rõ rệt:

  • Đây là cái quái gì?
  • Tôi xin xỏ gì mà bị từ chối?
  • Tôi làm gì sai mà bảo tôi “vi pham quy định”?
  • Có cần phải make it (copy-write) serious thế không?

Đó là cảm nhận của người dùng khi “chưa biết đến hệ thống tính điểm” của Foody.vn, cảm nhận đầu tiên khi hệ thống này cố gắng tương tác với tôi. Tất nhiên tôi hiểu đây là một dạng Gamification của Foody, nhưng cách tương tác này khiến tôi…không muốn chơi với (Foody point system).

Why People Play?

Có thể nói áp dụng Gamification khá phổ biến trong thiết kế ứng dụng mobile app ngày nay. Hầu như ai cũng biết về những kiến thức cơ bản của thiết kế Gamification như: point, level, badges, leader board… nhưng đây là những thứ (artifacts) có tác dụng sau khi người dùng đã tham gia vào trò chơi của bạn. Vậy trước đó thì sao? Làm sao để lôi kéo, hoặc tìm hiểu động cơ của người dùng? Làm thế nào để khuyến khích user trở thành player trong trò chơi của bạn?

Trong lý thuyết trò chơi, qua nhiều năm thống kê, có 04 nguyên nhân / lý do chính tạo ra động lực cho người dùng tham gia vào các cuộc chơi, đó là:

  1. For mastery: Tạo dựng cảm giác làm chủ như chủ ngôi nhà, chủ thành phố, nhập vai siêu anh hùng…
  2. To destress: Giải trí, giải tỏa stress, căng thẳng đến từ công việc, cuộc sống.
  3. To have fun: Tìm kiếm niềm vui, niềm hạnh phúc thông qua trò chơi.
  4. To socialize: Đơn giản là… socialize 🙂 là xây dựng hoặc tham gia vào một cộng đồng, giao tiếp với những người có cùng đam mê, sở thích…

Đối với lĩnh vực software development, cụ thể là web/mobile app design thì tôi muốn nhấn mạnh vào yếu tố “have fun” trong việc xây dựng Gamification. Đó là yếu tố chủ đạo và phổ biến nhất trong việc thúc đẩy hành vi người sử dụng. Nói đơn giản hơn là có vui thì mới gắn bó lâu dài, không vui thì không chơi 🙂

foody-trudiem-rule

(Hình 2: Quy chế trừ điểm của Foody)

Different kinds of fun

Khi nói về yếu tố “have fun” trong Gamification design thì chúng ta thường nhắc tới bài viết nghiên cứu có tựa đề “Why We Play Games,” của Nicole Lazzaro – chuyên gia nghiên cứu về hành vi, trải nghiệm cũng như cảm xúc của người chơi trong games – , được viết năm 2004. Qua đó, bà chỉ rõ 4 cấp độ “niềm vui” (fun levels) của người tham gia trò chơi như sau:

  1. Hard fun: Mức độ khó nhất, thường yêu cầu người dùng phải bỏ ra nhiều nỗ lực (thời gian, công sức) để đạt được điều mình muốn như điểm thưởng, cấp độ thành viên, giảm giá, v.v… Những nỗ lực này thường được “giới hạn” bởi những điều kiện như: số lượng bài viết tối thiểu, số lượng tài nguyên cần đạt được, số hình ảnh upload, số giờ chơi cũng như điểm tích lũy theo thời gian v.v..
  2. Easy fun: Xây dựng môi trường trò chơi, ứng dụng thật đơn giản, chủ yếu lôi kéo người dùng tò mò, khám phá trò chơi hơn là “đánh đố”.
  3. Altered state fun: Người chơi tham gia trò chơi để được trải nghiệm một hoặc nhiều cảm giác khác nhau. Ví dụ như những trò chơi thực địa tìm kho báu, các trò chơi mạo hiểm, môi trường 3D, 4D v.v..
  4. Social fun: Tạo môi trường để người chơi tham gia trò chơi, qua đó xây dựng và kết nối mạng xã hội. Về bản chất giống socialize.

OK, giờ thì sao? Có chơi tiếp trò chơi tính điểm của Foody hay không? Để có câu trả lời, tôi phải tìm hiểu tại sao tôi bị từ chối, và vi phạm quy định gì?

Lọ mọ tìm kiếm một lúc thì cũng ra cái quy định trừ điểm của Foody (Hình 2), trong đó điều nổi bật nhất, và có lẽ là điều tôi đã vi phạm đó là: “Bình luận quá ngắn (dưới 100 từ)“. Dưới 100 từ nghĩa là phải viết bình luận từ 100 từ trở lên. 100 từ chứ không phải 100 ký tự. Confuse? (Tất nhiên tôi hiểu mục đích là trống scam/spam lấy điểm thưởng) Lưu ý rằng Twitter giới hạn 140 ký tự để hạn chế người dùng viết lan man, Foody thì ngược lại. Và với ứng dụng mobile, người dùng sẽ không có thói quen viết bình luận 100 từ trên thiết bị cầm tay để rồi kiếm… điểm tích lũy. Cái này quả là hard fun đối với người dùng.

Người dùng có thể sẽ nản với hard fun nhưng vẫn có thể sẽ tiếp tục “chơi” với ứng dụng của bạn nếu họ vẫn cảm thấy thoái mái khi không tích lũy được gì. Nghĩa là họ phải có easy fun hoặc social fun để tiếp tục tham gia cuộc chơi, để vẫn thấy thích thú khi sử dụng sản phẩm của bạn (ở đây là mobile app). Nhưng khi tôi “bỗng nhiên” bị từ chối, bị thông báo mình “vi phạm” điều gì đó, có lẽ tôi sẽ chỉ tiếp dụng sử dụng Foody App như một công vụ tìm kiếm chứ không muốn tiếp tục comment hay cảnh báo địa chỉ sai một cách tích cực nữa. Tôi không muốn bị từ chối, cũng không muốn bị làm phiền. Tôi cần niềm vui, To have fun.

Tham khảo:

  • Nicole Lazzaro: The Future of Work is Play [Clip]