Treat the client like 2-year-old child

(Mang lại cho khách hàng những thứ đơn giản, dễ hiểu)

Capture

(Hình 1: user’s guessing. Nguồn: www.satukyrolainen.com)

Làm việc trong lĩnh vực digital production  mà cụ thể hơn là offshore development hay outsourcing thì communication is the key. Mỗi dự án từ lúc lên ý tưởng, cho tới lúc bàn giao sản phẩm cho khách hàng luôn cần giao tiếp liên tục để chắc chắn rằng các bên tham gia hiểu ý nhau. Nghe thì đơn giản, nhưng đây luôn là nguồn gốc của mọi vấn đề. Mà thường là các bên không hiểu nhau. Users không hiểu phần mềm, nghiệp vụ (business process) dẫn đến bực tức và “ghét” phần mềm một cách tự nhiên. Lâu này thành định kiến là “phần mềm khó sử dụng”.

Case study: How to test?

 UX xuất hiện khắp mọi nơi, và nói một cách đơn giản là một người có UX mindset sẽ chú trọng vào bất cứ thứ gì mình đưa ra (kể cả là lời nói – UX có dính tới psychology cũng 1 phần là như vậy). Câu truyện của sáng nay rất đơn giản và phổ biến, nhưng tôi ấn tượng với câu nói của boss. Nôm na là như sau:

  • Boss: Khách hàng muốn test toàn bộ qui trình đăng ký, thanh toán credit card mà ko bị charge phí, nhận email confirmation. Mình có cung cấp được chưa?
  • PM (Project Manager): Mình đã làm 1 tools migrate khách hàng cũ, với khách hàng mới thì không cần lo vì hệ thống tự generate confirmation code, khách hàng cũ chạy tools, ngoài ra cần migrate data demo sang server staging, làm sạch dữ liệu test, by pass thẻ visa…
  • Boss: I don’t fucking care. Please treat me like 2-year-old child. Client even likes 1-year-old child. I don’t know and don’t understand whatever you do behind the scenes.
  • PM: Chúng ta sẽ cung cấp sandbox để test, migrate dữ liệu cần khách hàng confirm migrate những gì, blah blah..
  • Boss: Những thứ đằng sau đó không cần giải thích với người dùng, đưa cho họ cái họ cần để test được hệ thống như một người dùng cuối (end-user).

Cá nhân mình thấy hợp lý. Bởi đơn giản những thứ kỹ thuật, thiết kế.v.v… là việc của mình, khách hàng thuê mình vì điều đó, còn với họ, họ cần tiếp cận với sản phẩm như một đứa trẻ, tiếp cận và học hỏi, test một cách dễ dàng nhất. Điều muốn nói ở đây là giao tiếp. Communication is the key in UX. Lắng nghe, rồi hiểu đúng cái mà khách hàng cần, đưa cho họ thông tin/câu trả lời đơn giản và dễ hiểu nhất. Họ không quan tâm bạn là ai, thương hiệu của bạn là gì? bạn sử dụng công nghệ gì? All bullshit things. Cái họ cần là vấn đề của họ được giải quyết.

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 🙂

 

Khởi đầu với UX?

Những nguyên lý cơ bản của UX, và để có thể đi xa hơn…

ux-discussion

(Ảnh: thảo luận về UX, nguồn: Internet)

Đã 20 năm kể từ khi cuốn sách kinh điển với tựa đề “Usability Engineering” (1) của Nielsen ra mắt năm 1993, đánh dấu việc xuất bản, nghiên cứu và là một trong những tài liệu đầu tiên về usability trên Thế Giới. Kể từ đó cho tới nay, việc nghiên cứu tối ưu cách thức giao tiếp giữa con người và hệ thống máy móc, công nghệ cũng có nhiều thay đổi.

Nếu như usability engineering trên thực tế là quá trình rút ngắn khoảng cách giao tiếp giữa con người và máy tính nói riêng hay thiết bị công nghệ nói chung, tạo ra các sản phẩm có tính khả dụng (usable) cao thì cuối thập niên 90s, đầu thế kỷ 21 các trường đại học tại Mỹ và châu Âu cũng đưa vào giảng dạy chuyên sâu hơn bộ môn HCI (Human Computer Interaction), hay còn gọi là “giao tiếp người – máy” (2). Theo thời gian, việc thiết kế một sản phẩm công nghệ, một hệ thống thông tin được giao thoa giữa thiết kế công nghiệp và thiết kê tương tác, thậm chí công việc này còn quan trọng hơn và được thực hiện tỉ mỉ trước khâu thiết kế đồ họa. Cái đẹp được đặt sau tính khả dụng, bởi 1 sản phẩm được làm ra thì trước tiên phải có khả năng sử dụng được bởi người dùng, nếu không muốn nói là dễ sử dụng. Đó là sự ra đời của bộ môn Interaction Design ngày hôm nay.

Tôi còn nhớ vào những năm 1998 – 1999, khẩu hiệu của Microsoft hay những người làm phần mềm luôn là “easy to use” (dễ sử dụng). Chính vì thế mà hệ điều hành Windows hay những ứng dụng windows base một thời làm mưa làm gió, được người dùng đón nhận bởi người ta cần rất ít thời gian bỏ ra để học cách sử dụng. 5 năm trở lại đây, Apple cũng là một công ty áp dụng triệt để phương châm đó.

Ngày nay thì UX dường như là một “buzz word”. Tính phổ biến và độ “hot” của nó cũng tương đương với từ “start-up”. Người người nói về UX, nhà nhà nghĩ về UX khi làm sản phẩm, vâng, đặc biệt là với các công ty dạng “tech start-up” chuyên làm production. Ai cũng biết UX là viết tắt của cụm từ User Experience. Nghĩa là tạo ra các trải nghiệm cho người dùng. Wikipedia thì định nghĩa là “feeling” của người dùng trong quá trình sử dụng sản phẩm, dịch vụ. Tất nhiên, UX không chỉ dành cho Web app / mobile app mà còn áp dụng cho các ngành dịch vụ, sản phẩm công nghệ, chăm sóc khách hàng, v.v…

Có rất nhiều blog nói hoặc định nghĩa UX là gì. Nhưng khởi đầu với UX thì như thế nào? Nếu ngày mai, công ty của bạn lập ra một nhóm UX để làm sản phẩm, và các sản phẩm sẽ đa dạng bao gồm web app, mobile app, tablet và desktop thì bạn sẽ bắt đầu ra sao? Với mobile app, web app thì bạn có thể bắt đầu bằng cách xem các sản phẩm của đối thủ cạnh tranh, trở thành người dùng của họ và “test”. Hoặc bạn có thể đọc các tiêu chuẩn về Landing pages, CTA (Call to Action), các “UX rules” dễ áp dụng và so sánh… Tuy nhiên, để “không lạc lối”, có một vài điểm mà bạn, hay những ai định “nhảy vào” làm UX, cần ghi nhớ (3):

  • Be goal-directed. Phải xác định mục tiêu ngay từ đầu. Nghĩa là sản phẩm được thiết kế ra phục vụ đối tượng nào? Mục đích là gì? dành cho ai? Bạn muốn người dùng sẽ thao tác như thế nào? Muốn mang lại điều gì (lợi ích hay giải quyết vấn đề gì) cho người dùng và muốn thu lượm được gì từ họ?
  • Use your common sense. Hãy trở thành một người dùng, sử dụng sản phẩm của bạn và của các đối thủ cạnh tranh. Sử dụng cảm nhận của chính mình chứ đừng áp dụng cứng nhắc lý thuyết nào cả. Lý thuyết chỉ để tham khảo, người dùng + trải nghiệm và cảm nhận của họ mới quyết định tất cả. (Nếu tôi nhớ không nhầm thì Bill Gates hay Microsoft cũng có câu nói “eat your own dog food”).
  • Context is everything. Context được hiểu là bối cảnh, hoàn cảnh mà sản phẩm của bạn sẽ được sử dụng. Ví dụ mobile sẽ khác với desktop application. Máy ATM và phần mềm của nó sẽ khác với giao dịch thương mại trực tuyến. (Tôi cũng đã có bài viết về Mobile context).
  • The answer to most questions is “it depends”. Cái này quan trọng. Nôm na là tính linh hoạt của thiết kế cũng như sự thích nghi với đối tượng người dùng, hoàn cảnh. Tùy thuộc từng tình huống và hoàn cảnh (bao gồm cả văn hóa – cross culture) mà có những sản phẩm phù hợp. Văn hóa và thói quen của người châu Á sẽ khác với người châu Âu, Mỹ.v.v… Điều này tôi đã trực tiếp trải nghiệm khi ở Mauritius, dân văn phòng ở đây dùng foursquare nhiều hơn facebook rất nhiều, nói đúng hơn thì đa phần ít dùng hoặc không dùng facebook.
  • It’s about the people. User Experience thì đương nhiên là trải nghiệm của user. Toàn bộ các tính năng, thiết kế đều xoay quanh user và các experiences của user đó. Trong UX gọi là personas. Hay có thể nói, cốt lõi của UX chính là personas. (Tôi sẽ viết chuyên sâu về personas ở các blog sau này).
  • Everything should be evaluated in its own way. Bạn cần biết, cần lưu ý và thoải mái đón nhận sự thay đổi trong quá trình vận hành và phát triển sản phẩm. Không có một thiết kế nào có thể hoàn hảo ngay từ đầu. Đặc biệt là khi áp dụng UX. Cũng giống như đi làm vậy, sinh viên mới ra trường thì làm gì có kinh nghiệm làm việc. Sản phẩm cũng thế, chừng nào người dùng chưa đăng ký tài khoản và sử dụng web / mobile app của bạn thì lấy đâu ra experiences của users. Vì vậy, khi sản phẩm của bạn “go live”, bạn cần theo dõi hành vi của người dùng, từ đó tổng hợp, đúc rút ra những điểm cần cải tiến. Đó chính là quá trình “tiến hóa” đối với sản phẩm của bạn (4). Một điểm quan trọng nữa ở đây chính là evaluate. Phải luôn đánh giá nghiêm túc sản phẩm của bạn trước và sau khi “go live” cũng như trong suốt quá trình vận hành.
  • Improvise, adapt, and overcome. Ứng biến, thích nghi và vượt qua những khó khăn, thay đổi. Đây chính là công việc cần thực hiện, thay đổi và thích nghi với phản hồi của người dùng. Trong ngành IT, cụ thể là thiết kế phần mềm, việc này rất hay gặp phải. Các lập trình viên, thậm những người làm solution architect thường tỏ ra khó chịu khi người dùng “phản hồi” về các chức năng của phần mềm. Có những tính năng được thiết kế, xây dựng rất công phu nhưng người dùng lại “không cần” nó, hoặc sử dụng rất ít. Và ngược lại, những chức năng đơn giản, đôi khi người dùng lại rất vất vả để thao tác hoặc không tìm thấy sau khi cài đặt phần mềm của bạn. Đó là thực tế. Ai làm phần mềm cũng từng trải qua.

Đã có thời, những người làm sản phẩm phần mềm hay làm dự án phần mềm phục vụ end-user thường đổ tại người dùng khó tính, thay đổi yêu cầu (change request) so với mong muốn ban đầu. Tôi cũng từ tỏ ra khó chịu vào thời điểm ti toe làm dự án phần mềm năm 2004. Nhiều người cho rằng cần thắt chặt khâu “quản lý yêu cầu” (Requirement Management) nhưng rồi mọi thứ phải thay đổi. UX là thứ mà người dùng của bạn phải sử dụng sản phẩm thì mới có. Cho dù ban đầu họ (users) có thể đã sử dụng các phần mềm tương tự, họ mong muốn những tính năng khá cụ thể, mô phỏng rõ ràng… nhưng khi sử dụng, họ mới nhận thấy mình thực sự cần những gì. Agile ra đời để đáp ứng sự thay đổi đó. Chấp nhận thay đổi nhưng phải quản lý và theo dõi nó. Sản phẩm có UX tốt là sản phẩm được áp dụng đúng qui trình dành cho UX, áp dụng các qui tắc Usability, UI… nhưng cũng linh hoạt để tối ưu với những phản hồi của người dùng, hoặc sau quá trình theo dõi hành vi của họ. Hy vọng rằng, dù làm việc trong 1 nhóm UX mạnh hay hoạt động độc lập, với việc áp dụng những nguyên lý cơ bản nêu trên, bạn vẫn có thể hoàn thành tốt công việc của mình và cho ra mắt những sản phẩm hữu ích trong tương lai.

Ghi chú:

(1) Tham khảo cuốn Usability Engineering, Jacob Nielsen, 1993

(2) Nói là “giảng dạy chuyên sâu” hơn bởi ngành HCI có từ những năm 1979 – 1980 tại Mỹ.

(3) Tôi tóm tắt các phát biểu (quan điểm) của Rex Hartson, một người làm UX trên 30 năm và là tác giả của một số cuốn sách UX nổi tiếng. Sáng lập và phụ trách giảng dạy bộ môn HCI tại đại học Virginia Tech.

(4) Việc theo dõi hành vi người dùng còn gọi là Observing user experience.