🇻🇳 Research lúc nào và như thế nào trong quá trình thiết kế sản phẩm? (Phần 1)

Nếu bạn thực hiện xong user interview và đi đến nói với những người làm business (Stakeholder, CEO, Marketing...) rằng: “User A nói vấn đề B đang làm cho họ khó chịu” thì 90% là stakeholder sẽ hỏi bạn câu hỏi như sau: “chỉ có vài user nói thế làm sao có thể đảm bảo mọi user đều có chung cảm nghĩ về vấn đề B?”

Mình chia sẻ bài viết này với những góc nhìn “thực chiến” hơn hi vọng rằng nó có thể giúp bạn vận dụng được vào trong công việc thực tế khi phải làm research, chứ không chỉ là “walk-through” research trong các case study để thực hành của bạn. Bài viết sẽ giúp bạn hiểu rõ hơn về việc làm research trong công ty và quá trình thiết kế sản phẩm, giúp bạn tự tin một cách hợp lý khi mang research report đi thuyết trình với mọi người.

Sẽ không có “silver bullet” nào để đảm bảo bạn đọc xong thì đi “thực chiến” luôn được, nhưng nếu bạn có thể thử áp dụng 1 số ý trong bài viết rồi ngẫm nghĩ lại, rất có thể bạn sẽ tìm ra silver bullet cho riêng mình. Một User Researcher giỏi sẽ luôn biết mình cần làm gì, tại sao mình làm điều đó và đi kèm với 1 kỹ năng phân tích đủ tốt. Tất cả gói gọn lại thành “tư duy suy nghĩ của researcher”

Tư duy suy nghĩ

Khi các bạn đi học về quy trình làm UX, Product Design ở nhiều nơi, một trong những bước đầu tiên các bạn được học đó chính là làm Research. Sau đó phải trải qua hàng loạt các bước như thấu hiểu, empathy, ideation, journey... rồi design, test và validation.

Quy trình này không hề sai, nhưng vô tình nó tạo cho các bạn 1 thứ tự suy nghĩ dễ bị lạc lối, đó là:

Tìm hiểu user → suy ra được gì từ những gì mình tìm hiểu → idea gì

Sau quy trình này một lỗi rất phổ biến mình thường thấy đó là đến khi design thực tế thì rất ít khi các bạn apply những gì tìm hiểu và idea vào trong design. Hay nói cách khác các bạn chưa ứng dụng được research vào design. Dẫn đến bài làm của các bạn chỉ là 1 trong triệu bài case study vô thưởng vô phạt.

Như vậy, thứ tự suy nghĩ phải là như thế nào

Nó nên là:

Chúng ta đang muốn làm gì? Tại sao phải design vấn đề này?

→ Cần phải tìm hiểu ai gặp vấn đề này, họ có thực sự gặp vấn đề này không? Liệu nó có thực sự là 1 vấn đề không?

→ Liệu đã có giải pháp nào trên thị trường? Giải pháp đó đủ tốt chưa? Tại sao chúng ta phải thiết kế lại?

Từ cách suy nghĩ này, chúng ta sẽ phải sử dụng các phương pháp research khác nhau để trả lời cho các câu hỏi trên, qua đó giúp đưa ra ý tưởng thiết kế hiệu quả hơn

Trong phần 1 này, mình sẽ tập trung nói về 2 phần câu hỏi đầu tiên trước, phần câu hỏi thứ 3 (liệu đã có giải pháp nào trên thị trường?) sẽ được miêu tả cụ thể ở phần 2

Tại sao chúng ta chọn design cho vấn đề nào đó?

Để trả lời câu hỏi này, bạn cần dùng một số phương pháp framing phù hợp để đưa ra được lời giải thích phù hợp nhất. Đây cũng thường là phần mà mình hay gọi là “Background” và “Objective” trong mỗi bài case study. Nó giống như bạn đang trình bày hoàn cảnh, nguồn gốc của câu chuyện trong một bài luận văn. Hãy bắt đầu từ một hoàn cảnh cụ thể nào đó, hoặc từ một câu chuyện trong công ty, thông thường nó có liên quan đến business.

Đây là một vài ví dụ của phần Background và Objectives này:

Lazada Seller Transparency

BACKGROUND

📌 Seller transparency makes seller information available to users so that they can make an informed decision. During the buying process, user goes through the seller information that helps him / her make a decision to buy or not buy something from a particular seller, especially when similar product is being offered by different sellers. Seller information is presented at various stages of user journey, mostly pre-purchase stage and is on catalogue, pdp, seller profile pages. Seller information helps with building trust , setting expectations and offers a way to compare and select the preferred seller

OBJECTIVES

⛳ How might we improve and optimize the seller information/metrics to help users make a better comparison and smart buying decision?

BAEMIN Case Study: Reduce Cancellation rate at checkout:

BACKGROUND

📌 Many users canceled the order (more than 30%) because the deliver address is wrong at checkout step. This is due to many reasons such as:

Users had set default delivery address to their pre-saved address (home) but they were at their office at the time they made the order.

Users explored the food and were ready to make order but then closed app – address saved at this location, users then moved to another location and continued ordering, the location was wrong at this point

OBJECTIVES ⛳

Reduce user’s cancelation rate because of wrong address to below 15%

Also aim to provide better experience by reduce the rate of correcting the delivery location address

User thực sự là ai? Họ có đang gặp vấn đề mà chúng ta nghĩ hay không?

Câu hỏi này giúp các bạn lựa chọn được phương pháp research hợp lý và tìm hiểu vấn đề chính xác hơn. Trước khi nói cụ thể cách research, chúng ta cần phải hiểu có những loại phương pháp research nào thường được dùng trong quá trình design sản phẩm

Generative vs. Evaluative Research

• Generative (hay còn gọi là Exploratory, Discovery) Research: giúp bạn xác định được vấn đề cụ thể và đưa ra ý tưởng cho sản phẩm. Đây là loại research rất hay dùng trong giai đoạn đầu của quy trình design

• Evaluative Research: cung cấp các feedback về cách hoạt động của một tính năng nào đó, thường được dùng để thu thập insight trước khi launch sản phẩm hoặc để đưa ra các đánh giá về sản phẩm hiện tại và thực hiện redesign.

Generative research dives into “What problem might we solve?” while evaluative research asks, “How well is our solution working?” Erika Hall, Co-founder of Mule Design Studio

Generative Research

Như đã nói, Generative research rất phù hợp để trả lời câu hỏi User thực sự là ai và họ có đang thực sự gặp phải những vấn đề chúng ta đang muốn design hay không.

Hai phương pháp thường thấy nhất đó là Field Study và User Interview. Chúng ta hãy nói về phương pháp mà mọi người sử dụng nhiều nhất và cơ bản nhất: User Interview

USER INTERVIEW

Như chính tên gọi của mình, user interview là hoạt động của researcher đưa ra một loạt các câu hỏi được lên kịch bản sẵn (Lưu ý điểm này). Các câu hỏi thường là dạng câu hỏi “Open-ended”, ví dụ:

• Hãy miêu tả lần cuối mà bạn...

• Hãy giải thích tại sao bạn...

• Bạn thường làm việc A, B, C như thế nào?

Để đảm bảo insights bạn thu thập được có hiệu quả cao, quan trọng là bạn phải lên được kịch bản câu hỏi giúp gợi mở vấn đề cụ thể hơn, bạn có thể tìm hiểu thêm về cách frame question qua 1 framework đơn giản mà mình đã có post ở đây:

Cách đặt câu hỏi

FIELD STUDY

Phương pháp field study thường được thực hiện bởi các bạn researcher nhiều hơn là các bạn UX designer hay Product Designer. Phương thức này đòi hỏi Researcher phải ở trong môi trường mà user đang thực hiện một task nào đó, qua đó researcher có thể trực tiếp theo dõi diễn biến tâm lý, thói quen của user khi họ thực hiện công việc của mình, và có thể thu thập được nhiều insight hơn so với việc hỏi user về cảm nhận của họ (What they think vs what they do)

Để hiểu rõ hơn về các bước thực hiện field study, các bạn có thể xem thêm ở đây:

Steps to Field Study

Qualitative vs. Quantitative

Một khía cạnh thứ 2 của research đó là Quali vs Quanti: hay nói cách khách, Tại sao hay là Cái gì

Nếu bạn đang có những câu hỏi liên quan đến “tại sao”, ví dụ: tại sao user lại drop out ở bước này nhiều như vậy? Tại sao user không điền ngày tháng năm sinh? Thì bạn nên thực hiện các research có tính Qualitative (User Interview là điển hình)

Nhưng nếu bạn lại đang xoay quanh câu hỏi: Cái gì, ví dụ: Có vấn đề gì xảy ra trong quá trình checkout hay không? User cảm thấy không hài lòng với điều gì khi sử dụng sản phẩm? Thì thông thường bạn nên thực hiện Quantitative research (Survey).

Sự lẫn lộn giữa insight có được từ user interview với vấn đề thực sự của user

⚠️ Nếu bạn thực hiện xong user interview và đi đến nói với những người làm business (Stakeholder, CEO, Marketing...) rằng: “User A nói vấn đề B đang làm cho họ khó chịu” thì 90% là stakeholder sẽ hỏi bạn câu hỏi như sau: “chỉ có vài user nói thế làm sao có thể đảm bảo mọi user đều có chung cảm nghĩ?”

Đây là 1 vấn đề rất thường gặp, và thậm chí là thỉnh thoảng chính bạn thân bạn cũng sẽ nghi ngờ điều trên. Lý do là bởi vì như đã nói, User interview chỉ trả lời cho câu hỏi tại sao, một khi bạn đã xác định cụ thể bạn muốn tìm hiểu lý do cho việc gì, và bạn có thể xác định rõ ai đang gặp vấn đề đó. Các insights đến từ User Interview chỉ có thể giúp bạn xây dựng nên 1 vài giả thuyết về nguyên nhân mà user cảm thấy về 1 vấn đề, chứ ko phải là một statement (khẳng định) có tính thuyết phục về hành vi của họ. Cho nên các insights lấy được từ user interview trong giai đoạn research đầu tiên trước khi design nên được sử dụng như một dạng assumption và chỉ thật sự chứng minh được khi bạn launch sản phẩm cuối cùng của mình đến với user, hoặc khi bạn thực hiện evaluate research để kiểm chứng.

Hãy nhớ rằng

✅ Interviews do not produce reliable data about user behavior (Interviews sẽ không cho ra các dữ liệu đáng tin cậy về behviour của người dùng)

Trái lại, survey (quantitative) sẽ giúp bạn có được cái nhìn tổng quan hơn về đâu mới là những user đang gặp vấn đề và họ đang gặp cụ thể vấn đề gì, ở đâu.

SURVEY

Tuy nhiên để thực hiện được survey cũng không phải là dễ, vì survey cần 1 mẫu số tự tin nhất định (bao nhiêu users mới đủ?) Cho nên thông thường nếu bạn không đang làm dự án trong công ty mà chỉ tự làm cá nhân, thì khả năng bạn thực hiện được survey hoàn chỉnh trong khoảng thời gian vừa đủ là rất khó. Lúc này bạn chỉ có thể dựa trên User Interview, và như mình đã nói, user interview vẫn là 1 phương pháp hợp lý, chỉ là bạn phải hiểu rằng tạm thời đây là những assumption, giả thuyết hợp lý nhất mà bạn có thể có được đến từ chính user.

Mở rộng thêm: Cách tổng hợp và phân tích insights từ User Interview (Qualitative)

Để có thể đưa ra kết luận phù hợp từ sau buổi user interview, ít nhất chúng ta cần nắm được cách phân tích, tổng hợp các data (dữ liệu) thành các main themes (chủ đề) và đưa ra INSIGHTS. Cách làm này được gọi là Thematic Analysis

Data vs. Insights

Data là những gì bạn thu thập được trực tiếp từ phỏng vấn người dùng, chưa qua phân tích, chưa qua suy luận. Insights là những gì bạn đúc kết và trình bày với các business stakeholders. Trong bài mình sẽ sử dụng data và insights, bạn nên lưu ý phân định rõ 2 khái niệm này để nắm rõ hơn cách làm nhé

Theme là gì?

Theme là sự tương đồng hoặc lặp đi lặp lại của các thông tin tìm thấy sau quá trình phỏng vấn user, mà có thể giúp chúng ta nhóm các loại thông tin này vào các phân loại khác nhau

Tại sao phải tiến hành Thematic Analysis

Khi bạn làm nhiều research, đặc biệt là user interview, bạn sẽ thấy một số vấn đề thường gặp như sau:

• Quá nhiều dữ liệu, phải nghe user nói rất nhiều, có quá nhiều ý từ những gì user nói → dẫn đến bạn chỉ focus vào những đại ý chính, những gì đáng nhớ nhất mà bỏ qua phần lớn data còn lại

• Dữ liệu nào cũng có vẻ là đáng giá → ngược lại, có lúc bạn lại thấy rằng có vẻ như những gì user nói ra cũng hợp lý, cũng đáng consider, và dẫn đến việc bạn chỉ trình bày mọi thứ mình thu thập được mà không có đúc kết, cô đọng lại từ những dữ liệu trên

• Mâu thuẫn dữ liệu quá nhiều → kết quả research không thể thuyết phục được bạn, một số researcher sẽ vướng phải confirmation bias mà bỏ đi những data không như ý

Cách làm

Có một vài cách làm nhưng trong phạm vi bài viết, mình sẽ nói về 1 cách dễ áp dụng và luyện tập nhất: Affinity Diagram

Lưu ý là, từ ngữ thì có vẻ cao siêu, nhưng khi bạn đã quen dần, thì diagram nào cũng sẽ trở thành mindset của bạn, lúc đó tự mọi thứ bạn làm sẽ đi ra từ đầu của bạn. Vậy nên, đừng quá quan trọng terminology trong UX, mà hãy nhìn nhận nó như 1 lối suy luận, 1 cách thực hành suy nghĩ và biến nó thành của mình nhé.

Hãy sử dụng sticky notes để có thể thực hiện thao tác nhanh hơn (Hoặc digital thì dùng Miro hoặc Figjam nhé)

Bước 1: Đọc hết mọi thứ

Sẽ không có cách nào phân tích dữ liệu interview mà không đọc lại những gì user nói với bạn. Chỉ lưu ý rằng trong quá trình đọc, cố gắng lưu ý các vấn đề, data có tính lặp lại hoặc có vẻ thuộc về một chủ đề nào đó

Bước 2: Coding

Bạn bóc tách các phần user nói có liên quan ở trên, và đưa vào 1 nhóm, bạn đưa ra 1 định nghĩa cho nhóm các chủ đề này (coding), ví dụ bên dưới là hình ảnh researcher nhóm các data (sticker vàng) thành từng nhóm và code 1 topic cho các nhóm (sticker màu hồng)

Bước 3: Xây dựng nên các themes

Hãy nhìn lại các group và code trên, đặt các câu hỏi như sau:

• Có gì đang diễn ra ở trong các nhóm?

• Các codes có liên quan gì với nhau hay ko?

• Nó liên quan thế nào đến chủ đề chúng ta muốn research?

Sau đó, tìm cách diễn giải thành các theme, và đúc kết thành Insights

VÍ DỤ

Đây là 1 research phỏng vấn 3 người dùng về trải nghiệm nấu ăn tại nhà, trong các phỏng vấn này, có 2 người nói rằng họ thích một số nguyên liệu đã được chuẩn bị sẵn có thể dễ dàng pha chế cùng với những loại nguyên liệu khác. Trong khi đó người còn lại nói rằng họ thích có 1 loại nguyên liệu có thể dùng cho nhiều món ăn khác nhau trong tuần, thay vì phải mua quá nhiều nguyên liệu khác nhau. Qua 3 dữ liệu này, researcher có thể đúc kết nên 1 theme là: “1 nguyên liệu dùng được cho mọi thứ”

Từ theme này, Researcher có thể xem lại các topic khác và từ đó sẽ đúc kết ra 1 insights cụ thể nào đó để có thể trả lời cho câu hỏi của Research

Bước 4: Nếu có thể, hãy kiểm chứng insights với các dữ liệu đã có

Đây sẽ là bước optional nhưng bạn có thể củng cố hoặc thậm chí mở rộng insights của mình, hoặc đưa ra gợi ý cho team sản phẩm bằng cách đặt thêm một số câu hỏi sau:

• Đã có những data quantitative nào hỗ trợ thêm cho các insights này chưa? Nếu chưa thì bạn có thể tìm thêm được hay không?

• Các đồng môn của bạn có đồng ý với một số insights mà bạn đưa ra không?

The research report done right.

Research report cũng như khi bạn thuyết trình design, bạn không nên xem nhẹ việc trình bày insights 1 cách cô đọng và dễ hiểu nhất. Cách tốt nhất chính là trình bày report theo diễn tiến như sau: Background → objective → research questions (assumption) → research method (giải thích tại sao lại chọn method nào) → insights → backup data → suggestion và cuối cùng là appendix: các loại dữ liệu dành cho ai thật sự quan tâm chi tiết)

Mời bạn xem thử một vài research report mình đã có chia sẻ:

https://community.uxvn.org/c/tai-lieu-research/research-report-lazada-case-study

https://www.dropbox.com/s/3kwpeuryi28gh7x/Appv5-UsabilityTest-InsightsReport.pdf?dl=0

---

Hết phần 1

I’m Lam Thai, a Product Designer and a Community Builder for UX Vietnam. Read more about me.