Khi nào nên làm User Research?

Dạo này mình bắt đầu viết lại sau một khoảng thời gian dài không viết bất cứ thứ gì, từ blog công việc tới journal và cả các blog dành cho mấy sở thích cá nhân khác.

Có lẽ vì thế mà mình thấy việc viết thật khó. Ngạc nhiên biết bao, bởi trước giờ nếu có thứ gì đối với mình thật là dễ dàng và tự nhiên như hơi thở, thì có lẽ đó là viết. Vậy mà trải qua bao ngày xa cách, ở cái thời điểm bắt đầu lại này, mọi thứ bỗng nhiên thật khó khăn và ngại ngần thấy ghê.

Nhưng thôi kệ, mình cứ đặt tay xuống và viết, mỗi khi mình sẵn sàng. Như sáng nay, khi ngồi chuẩn bị trước cho công việc tuần tới, trong đó có việc lên plan Usability Testing một tính năng mới ra mắt gần đây, mình chợt có cảm hứng để viết bài viết này. Từ lâu rồi, khi team mình chuẩn hóa lại quy trình làm việc và bổ sung thêm rất nhiều nhân sự cho các mảng còn thiếu ở Product Center (Sendo), thì việc làm Usability Testing nói riêng và thực hiện User Research nói chung đã trở thành một phần không thể thiếu trong việc xây dựng và phát triển sản phẩm.

Tuy nhiên, việc thực hiện User Research với tần suất như thế nào là hợp lý? Hay nói cụ thể hơn, khi nào thì chúng ta nên làm User Research? Mời các bạn xem hình vẽ bên dưới.

Sáng nay hơi lười xài tool nên mình vẽ tay cho nhanh. Ở hình trên, mình vẽ một timeline cho Product Development process ở dạng đơn giản nhất có thể (thực tế có nhiều milestone khác nữa). Anyway, product development process thì lúc nào cũng có 3 milestone chính như hình.

Trước, trong và sau ba giai đoạn này, ta sẽ có các loại User Research khác nhau phục vụ cho những mục đích khác nhau. Những mục đích này chia làm 3 loại chính:

1. Để đảm bảo bạn đang phát triển một sản phẩm thực sự liên quan tới người dùng
2. Để đảm bảo sản phẩm của bạn là một thứ dễ dàng và thuận tiện khi sử dụng 
3. Để đo lường kết quả (xem sản phẩm của bạn có thực sự đem lại giá trị cho người dùng, từ đó gián tiếp hoặc trực tiếp tạo ra giá trị cho công ty hay không)

Tương ứng với 3 mục đích trên, mình đánh số 1, 2, 3 (đại diện lần lượt cho 3 loại) vào product development timeline mình vẽ ban đầu.

1- Đảm bảo bạn đang phát triển một sản phẩm thực sự liên quan tới người dùng.

Các User Research cho mục đích này hầu hết thường được thực hiện ở giai đoạn đầu tiên, khi team product bắt đầu hình thành ý tưởng và lên concept cho sản phẩm (chưa dev). Lúc này, những gì team thường có là các bản phác thảo sơ khởi nhất về Conceptual Model và User Workflow.

Tại Sendo, User Research method mà team thường làm ở giai đoạn này là User Interview, trong đó sẽ sử dụng một question set gồm nhiều loại câu hỏi khác nhau để kiểm chứng lại nhu cầu thực sự của người dùng trên thị trường, tìm hiểu cách mà người dùng tưởng tượng họ sẽ làm gì với tính năng/ sản phẩm mới, hoặc kỳ vọng của họ vào nó.

Trong những buổi User Interview như thế, team cũng sẽ cố gắng tìm hiểu và phân tích suy nghĩ của người dùng về tính năng từ các đối thủ nếu đối thủ đã có tính năng này trước. Tất cả những chia sẻ của người dùng về những điểm họ tâm đắc, yêu thích; những thứ khiến họ thấy phiền toái khi sử dụng tính năng từ đối thủ có thể nói là những thông tin đầu vào vô cùng giá trị và đáng được cân nhắc khi xây dựng giải pháp cho chính mình. Trong nhiều trường hợp, bạn có thể tiết kiệm được kha khá thời gian khi học tập từ sai lầm của người khác, mà cụ thể là từ các đối thủ trực tiếp.

Đây cũng là cách mà ứng dụng gọi xe Be đã làm khi công ty này chuẩn bị để ra mắt tại thị trường Việt Nam, theo chia sẻ của anh Quang, Head of UX/UI của Be trong một buổi Product Talk vào năm ngoái mà mình đã tham dự. Thay vì chỉ tập trung vào việc thu thập phản hồi người dùng dựa trên các rough idea hoặc concept/ wireframe của chính mình, Be hỏi luôn người dùng về cách mà họ sử dụng tính năng của những đối thủ đã có mặt trước trên thị trường như Grab, cố gắng phân tích sâu những thứ khiến người dùng cảm thấy khó khăn khi sử dụng tính năng hoặc những thứ mà người dùng thấy không cần thiết ở các ứng dụng này. Việc đó giúp Be tiết kiệm rất nhiều thời gian nghiên cứu và từ đó rút ngắn time-to-market, đẩy nhanh tốc độ đưa ứng dụng ra thị trường một cách hiệu quả nhất.

2- Đảm bảo sản phẩm của bạn là một thứ dễ dàng và thuận tiện khi sử dụng

User Research thuộc nhóm này có thể thực hiện gần như xuyên suốt quá trình Product Development.

Tuy vậy, tần suất thực hiện User Research trong nhóm mục đích thứ hai này còn phụ thuộc vào nhiều yếu tố:

• Độ lớn/ độ phức tạp của tính năng/ sản phẩm
• Time-to-market timeline: thời gian mong muốn sản phẩm sẵn sàng để đưa ra thị trường
• Nguồn lực nhân sự: team có đội User Research riêng không hay Product Management team sẽ kiêm luôn User Research?
• Nguồn lực tài chính: việc thực hiện User Research khá tốn kém trong một số trường hợp, nên cũng cần có đủ tiền để đảm bảo việc này được diễn ra theo tần suất đáp ứng được nhu cầu thực tế.

Các User Research methods thường thấy trong nhóm này có thể gồm User Interview, Usability Testing hoặc Contextual Inquiry. Thường thì team sẽ dựa trên các bản low-fi/high-fi wireframe/ mock-up/ prototype/ beta-version nếu đang trong giai đoạn lên ý tưởng hoặc đang dev. Nếu User Research được thực hiện sau khi release, có thể dùng luôn bản đã release trên môi trường production để người dùng trải nghiệm.

Trong trường hợp việc phát triển tính năng hoặc sản phẩm được chia ra làm nhiều giai đoạn, User Research thực hiện trước khi release tính năng của mỗi giai đoạn thường có giá trị cực kỳ lớn trong việc phát triển sản phẩm thuộc giai đoạn đó. Nếu User Research xảy ra sau khi release, thì outputs (giá trị đầu ra) của User Research sẽ trở thành inputs (giá trị đầu vào) cho các giai đoạn tiếp theo.

Ở Sendo, sau khi release tính năng, team vẫn tiếp tục thực hiện thêm vài lần Usability Testing để kiểm tra xem sản phẩm có dễ sử dụng không, có những phần nào đang khiến người dùng khó hiểu hoặc gặp khó khăn khi dùng. Với những tính năng quan trọng (major feature) như Checkout, team sẽ làm Usability Testing khoảng 2 tới 3 lần. Với những tính năng ít quan trọng hơn (minor feature), thường sẽ chỉ có 1 lần Usability Testing.

Việc thực hiện Usability Testing đôi khi khá tốn kém như mình nói ở trên, vì cần lọc người dùng khá kỹ để đúng đối tượng cần test. Khâu tổ chức bao gồm địa điểm, thiết bị phụ trợ v.v… cũng sẽ cần đầu tư, vì để đảm bảo một Usability Testing cho ra kết quả khách quan nhất cũng đòi hỏi khá nhiều yếu tố, chuyện này mình sẽ nói trong một bài viết khác. Ngoài ra, cũng cần có một ngân sách để cảm ơn người dùng vì những đóng góp của họ (nhất là về mặt thời gian), và tùy theo tính chất quan trọng của tính năng hoặc “độ khan hiếm” của người dùng với đúng những đặc điểm đáp ứng yêu cầu testing, mà mình sẽ cần một ngân sách linh hoạt tương ứng.

3- Để đo lường và đánh giá lợi ích thu về trên giá trị đầu tư (ROI)

User Research phục vụ cho mục đích thứ ba xảy ra sau khi đã release sản phẩm/ tính năng ra thị trường.

Nói cho cùng thì, mục đích tối thượng của việc phát triển sản phẩm vẫn là khiến cho sản phẩm được sử dụng và đạt được lượng người dùng nhất định. Và không chỉ dừng lại ở đó, sản phẩm phải đem lại giá trị cho người dùng, từ đó mới có thể gián tiếp hoặc trực tiếp đem lại giá trị (lợi nhuận) cho công ty đứng sau sản phẩm ấy. Với việc thực hiện User Research sau khi release, ta sẽ đo lường được ROI (Return of Investment), giá trị thu về trên những gì đã đầu tư trước đó.

Theo Interaction Design Foundation (IDF), khái niệm ROI trong Product Development bao gồm nhiều yếu tố trực tiếp và gián tiếp liên quan đến lợi nhuận. Các yếu tố này có thể là:

• Overall revenue growth
• Conversion boost (willing to purchase)
• Development budget/ development waste
• Customer Satisfaction (recommendation rate, complaint rate)
• Customer Loyalty (defection rate)
• Retention rate (intention to return)
• etc.

Hồi mình học để thi chứng chỉ PSPOI của Scrum.org, có một câu quote rất hay trong học phần về evaluation mà mình vẫn nhớ tới bây giờ.

If you can’t measure it, you can’t improve it. – Peter Drucker, chuyên gia hàng đầu thế giới về tư vấn quản trị, người được xem là cha đẻ của Quản trị kinh doanh hiện đại.

\\\”Nếu bạn không thể đo lường nó, bạn sẽ không thể cải thiện nó\\\” – quan điểm này cũng là thứ mà toàn bộ team Product Management đề cao chú trọng hơn suốt thời gian gần đây, khi số lượng tính năng được ra mắt ngày càng nhiều và đôi khi team quên mất tầm quan trọng của việc phân tích, đo lường các chỉ số giúp theo dõi sức khỏe sản phẩm, nhìn nhận và đánh giá những gì đã làm. Việc đánh giá kết quả không chỉ giúp người quản lý sản phẩm lượng hóa được những đóng góp của mình vào mục tiêu chung của công ty, mà còn giúp hạn chế tối đa Product Debt (những tính năng/ sản phẩm sinh ra không để làm gì hoặc không thực sự đem lại giá trị gì ngoài việc tiêu tốn resource của tất cả các bên).

Một điều cần lưu tâm cuối cùng về ROI, đó là việc hiểu nhầm và nhìn nhận ROI chỉ dưới một nghĩa đen hạn hẹp về lợi nhuận thu được (NMV). Như mình đã note ở trên, ROI không chỉ thể hiện qua NMV, mà còn bao gồm rất nhiều yếu tố gián tiếp tạo nên nó. Mình ví dụ về một dự án mình là owner khi mới vào Sendo cách đây 3 năm, lúc ấy, các chỉ số liên quan đến User Complaint Rate (tỷ lệ khiếu nại từ người dùng) cực kỳ cao. Anh Hoàng, CTO của Sendo giao cho team nhiệm vụ review và tối ưu lại UX/UI cho toàn sàn để giảm tỷ lệ khiếu nại này. Bằng việc update lại UX/UI của những phần chưa hợp lý trong các user workflows chính, dự án này đã giảm tỷ lệ khiếu nại từ người mua xuống hơn 30%, từ người bán xuống hơn 50% so với trước khi tối ưu. Việc giảm các case khiếu nại đã trực tiếp giảm tỷ lệ nhân sự cần tuyển dụng cho bộ phận Chăm sóc khách hàng (đồng nghĩa với giảm chi phí nhân sự), và khi xét mối tương quan giữa chi phí – lợi nhuận ở góc nhìn tài chính, việc giảm chi phí này cũng chính là một phần của việc tăng ROI.

—

Hy vọng bài viết của mình đã giúp bạn có thêm nhiều góc nhìn về việc triển khai User Research, cũng như hiểu được thêm về tầm quan trọng của việc thực hiện User Research trong quản lý và phát triển sản phẩm. Hẹn gặp bạn trong những bài viết tiếp theo.

Phương

Đọc thêm bài viết về UX Researcher: The team series – UX Researcher