Mở đầu — vì sao bài này quan trọng
Đến bài học này, bạn đã có trong tay gần như toàn bộ "vũ khí" của một nhà nghiên cứu UX: phỏng vấn sâu, contextual inquiry, A/B testing, thẻ card sorting, thống kê, kho lưu trữ insight (repository), ResearchOps... Nhưng có một sự thật khiến nhiều nhà nghiên cứu giỏi vẫn mãi bị xem là "người chạy test" trong tổ chức: họ giỏi làm từng nghiên cứu (study), nhưng không biết thiết kế một chương trình nghiên cứu (research program).
Sự khác biệt này rất lớn. Một study là một dự án đơn lẻ trả lời một câu hỏi cụ thể — ví dụ "Người dùng có hiểu luồng thanh toán mới không?". Một program là một chuỗi nhiều study được sắp xếp, ưu tiên và liên kết với nhau để phục vụ một mục tiêu chiến lược trong suốt một quý, một năm, hoặc dài hơn — ví dụ "Trong 12 tháng tới, chúng ta phải hiểu tường tận hành vi tài chính của người dùng nông thôn để mở rộng sản phẩm ví điện tử ra 5 tỉnh mới".
Khi bạn chỉ làm study rời rạc, mỗi lần có yêu cầu bạn lại phản ứng thụ động, làm xong rồi bỏ đó, insight không tích lũy, và ban lãnh đạo không thấy rõ giá trị của research. Khi bạn thiết kế được một program, bạn chuyển từ vai trò "người thực thi" sang "đối tác chiến lược" — bạn chủ động định hình những gì tổ chức cần biết, và mỗi đồng chi cho research đều nằm trong một bức tranh lớn. Đây chính là ranh giới ngăn cách một UX Researcher với một Research Lead thực thụ.
Khái niệm cốt lõi
Program khác Project như thế nào
Hãy hình dung sự khác biệt bằng một phép so sánh: một project giống như bạn nấu một món ăn theo yêu cầu của khách; một program giống như bạn thiết kế cả thực đơn nhà hàng cho cả mùa, với logic về nguyên liệu, ngân sách, khẩu vị khách hàng và mục tiêu doanh thu.
Một research program có bốn đặc điểm không thể thiếu:
- Được neo vào mục tiêu chiến lược (strategic anchor): Mọi study trong program đều phải trả lời được câu hỏi "Nghiên cứu này giúp công ty đạt được mục tiêu kinh doanh nào?". Nếu không nối được sợi dây này, study đó không thuộc về program.
- Kéo dài theo thời gian (temporal horizon): Program vận hành theo quý hoặc năm, không phải theo tuần. Nó có nhịp (cadence) riêng.
- Tích lũy tri thức (cumulative knowledge): Study sau xây dựng trên study trước. Insight không mất đi mà được bồi đắp trong repository.
- Có quản trị ưu tiên (prioritization governance): Vì nhu cầu luôn nhiều hơn năng lực, program bắt buộc phải có cơ chế quyết định làm gì trước, làm gì sau, và từ chối cái gì.
Các thành phần cấu tạo nên một program
Một research program hoàn chỉnh gồm những khối xây dựng (building blocks) sau, và bạn nên xem đây như một checklist khi thiết kế:
1. Goal — Mục tiêu chiến lược. Đây là "ngôi sao Bắc Đẩu" của program. Nó phải xuất phát từ mục tiêu kinh doanh, không phải từ sự tò mò của researcher. Ví dụ: "Giảm tỷ lệ rời bỏ (churn) của khách hàng doanh nghiệp nhỏ từ 8% xuống 5% trong năm nay." Từ goal này, ta suy ra program cần trả lời: Vì sao SME rời bỏ? Ở giai đoạn nào? Điều gì giữ chân họ?
2. Research questions — Bộ câu hỏi nghiên cứu. Đây là cầu nối giữa goal (rất trừu tượng) và study (rất cụ thể). Một program thường có 3–6 câu hỏi lớn, mỗi câu hỏi lại được "vỡ" ra thành nhiều study.
3. Themes/Pillars — Các trụ cột nghiên cứu. Nhóm các câu hỏi liên quan thành các mảng chủ đề để dễ quản lý, ví dụ trụ cột "Onboarding", trụ cột "Trải nghiệm thanh toán", trụ cột "Hỗ trợ sau bán".
4. Study roadmap — Lộ trình nghiên cứu. Đây là bản đồ theo thời gian: study nào làm quý nào, dùng phương pháp gì, phụ thuộc vào study nào. Nó giống roadmap sản phẩm nhưng dành cho tri thức.
5. Cadence — Nhịp vận hành. Program cần một nhịp đều: ví dụ mỗi tháng một "insight review" với product team, mỗi quý một "state of the user" gửi ban lãnh đạo. Nhịp tạo ra thói quen tiêu thụ insight.
6. Resourcing — Nguồn lực. Ai làm? Ngân sách bao nhiêu? Có cần đối tác tuyển người tham gia (recruitment vendor) không? Có công cụ nào phải mua?
7. Success metrics — Thước đo thành công của chính program. Không phải "làm bao nhiêu study" mà là "insight đã tạo ra quyết định gì, thay đổi gì, tiết kiệm/kiếm được bao nhiêu".
Ba tầng của một program: Strategic — Tactical — Foundational
Một cách phân loại rất hữu ích để cân đối danh mục nghiên cứu (research portfolio) là chia study thành ba tầng:
- Strategic (chiến lược): nghiên cứu định hướng dài hạn, thường là generative, trả lời "Chúng ta nên đi về đâu?". Ví dụ: nghiên cứu thị trường mới, khám phá nhu cầu chưa được đáp ứng.
- Tactical (chiến thuật): nghiên cứu phục vụ quyết định sản phẩm cụ thể trong quý, thường là evaluative. Ví dụ: usability test một tính năng sắp ship.
- Foundational (nền tảng): nghiên cứu tạo tài sản dùng chung, sống lâu. Ví dụ: xây dựng persona, journey map tổng thể, mental model của người dùng.
Tình huống thực tế
Tình huống 1 — Ví điện tử "MoMo giả định" mở rộng về nông thôn
Giả sử một ví điện tử lớn tại Việt Nam (ta gọi là "PayViet" cho dễ hình dung) đặt mục tiêu chiến lược năm: tăng 2 triệu người dùng hoạt động mới ở khu vực nông thôn và tỉnh lẻ. Nếu đội research chỉ phản ứng thụ động, họ sẽ nhận từng yêu cầu lẻ tẻ từ product manager: "test màn hình đăng ký", "test tính năng nạp tiền"...
Thay vào đó, Research Lead thiết kế một program 12 tháng neo vào goal trên, gồm ba trụ cột:
- Trụ cột A — Hiểu bối cảnh (Foundational, Q1–Q2): Diary study và contextual inquiry tại Đồng Tháp, Nghệ An để hiểu thói quen tài chính, mức độ tin tưởng công nghệ, ai là người ảnh hưởng quyết định trong gia đình.
- Trụ cột B — Rào cản chuyển đổi (Strategic, Q2–Q3): Nghiên cứu vì sao người dùng nông thôn tải app nhưng không kích hoạt; phỏng vấn sâu + khảo sát định lượng 800 người.
- Trụ cột C — Tối ưu luồng (Tactical, Q3–Q4): Usability test và A/B test các phiên bản onboarding rút gọn dựa trên insight của trụ cột A và B.
Bài học rút ra: Program biến những study rời rạc thành một chuỗi có logic nhân quả. Insight tầng dưới nuôi study tầng trên. Đây là điều một loạt project riêng lẻ không bao giờ làm được.
Tình huống 2 — Sàn TMĐT khu vực và bài toán ưu tiên
Một sàn thương mại điện tử Đông Nam Á (kiểu Tiki/Shopee giả định) có đúng 3 researcher nhưng nhận được 47 yêu cầu nghiên cứu trong một quý từ 12 nhóm sản phẩm khác nhau. Nếu nhận hết, đội sẽ kiệt sức và mỗi study đều làm hời hợt.
Research Lead áp dụng một ma trận ưu tiên cho program: mỗi yêu cầu được chấm theo ba tiêu chí — (1) mức độ liên quan tới OKR công ty năm nay, (2) độ rủi ro nếu quyết định sai (reversibility), (3) mức độ đã biết trước đó (nếu repository đã có câu trả lời thì từ chối). Kết quả: chỉ 11/47 yêu cầu được đưa vào program quý đó; 20 yêu cầu được trả lời ngay bằng insight cũ trong repository; 16 yêu cầu bị hoãn hoặc chuyển sang self-service (dạy PM tự làm khảo sát nhỏ).
Diễn giải: Việc từ chối có nguyên tắc quan trọng ngang việc thực hiện. Vì có tiêu chí minh bạch, các PM không cảm thấy bị "chèn ép" mà hiểu rằng nguồn lực đang được dồn vào việc quan trọng nhất.
Bài học rút ra: Program không phải là "làm nhiều hơn", mà là "làm đúng việc". Quản trị ưu tiên (research governance) chính là trái tim vận hành của một program.
Tình huống 3 — Ngân hàng số và program đo lường tác động
Một ngân hàng số tại Việt Nam xây dựng research program nhưng gặp vấn đề kinh điển: ban lãnh đạo hỏi "Research đã mang lại gì?" và đội không trả lời được. Họ liền định nghĩa lại success metrics ở cấp program: mỗi study phải log lại "quyết định mà nó tác động" và "giá trị ước tính". Sau 2 quý, họ trình bày: research đã ngăn việc xây một tính năng chuyển khoản quốc tế mà chỉ 3% người dùng cần (tiết kiệm ~4 tháng effort của 6 kỹ sư), và giúp thiết kế lại luồng eKYC làm giảm 22% tỷ lệ bỏ dở hồ sơ.
Diễn giải: Con số "ngăn được việc làm sai" thường có giá trị lớn hơn "làm được việc đúng", nhưng lại hay bị bỏ quên. Program cần cơ chế bắt lại những giá trị này.
Bài học rút ra: Một program không đo lường tác động của chính nó sẽ luôn là nạn nhân đầu tiên khi công ty cắt ngân sách.
Hướng dẫn từng bước
Đây là quy trình 7 bước để bạn tự thiết kế một research program cho tổ chức của mình.
Bước 1 — Bắt đầu từ chiến lược kinh doanh, không phải từ research. Đọc kỹ OKR/chiến lược năm của công ty và của các product team. Tự hỏi: "Những mục tiêu này giả định điều gì về người dùng? Giả định nào rủi ro nhất nếu sai?". Chính những giả định rủi ro đó là mảnh đất cho program của bạn.
Bước 2 — Chuyển goal thành bộ câu hỏi nghiên cứu. Với mỗi mục tiêu chiến lược, viết 3–6 câu hỏi lớn dạng "Chúng ta cần hiểu... để...". Đảm bảo mỗi câu hỏi đủ rộng để chứa nhiều study nhưng đủ hẹp để có thể trả lời.
Bước 3 — Nhóm câu hỏi thành trụ cột (pillars). Gom các câu hỏi liên quan thành 3–5 trụ cột. Việc này giúp bạn kể câu chuyện program một cách mạch lạc với lãnh đạo và giúp phân bổ người phụ trách.
Bước 4 — Phân loại theo tầng và cân bằng danh mục. Đánh dấu mỗi study dự kiến là Strategic / Tactical / Foundational. Kiểm tra tỷ lệ — một điểm khởi đầu hợp lý cho nhiều đội là khoảng 20% strategic, 60% tactical, 20% foundational, rồi điều chỉnh theo mức trưởng thành của tổ chức.
Bước 5 — Vẽ study roadmap và xác định phụ thuộc. Đặt các study lên timeline theo quý. Vẽ rõ mũi tên phụ thuộc: study nào phải xong trước để study sau có dữ liệu đầu vào. Đây là lúc bạn phát hiện các "nút thắt cổ chai".
Bước 6 — Thiết lập nhịp và cơ chế quản trị. Định ra lịch cố định: insight review hằng tháng, báo cáo chiến lược hằng quý. Đồng thời lập một intake process (quy trình tiếp nhận yêu cầu) và ma trận ưu tiên để xử lý các yêu cầu phát sinh giữa chừng mà không phá vỡ program.
Bước 7 — Định nghĩa metric thành công và vòng phản hồi. Trước khi chạy, hãy chốt cách bạn sẽ chứng minh giá trị: mỗi study liên kết với quyết định nào, insight được tiêu thụ ra sao, tác động ước tính là gì. Cuối mỗi quý, rà soát và tái ưu tiên (re-prioritize) program cho quý sau.
Lỗi thường gặp & mẹo
Lỗi 1 — Xây program từ danh sách phương pháp thay vì từ mục tiêu. Nhiều người mới hào hứng với "quý này mình sẽ làm diary study, eye tracking, card sorting...". Đó là tư duy công cụ. Program phải bắt đầu từ câu hỏi cần trả lời, rồi mới chọn phương pháp phù hợp.
Lỗi 2 — Nhận hết mọi yêu cầu để làm hài lòng mọi người. Đây là con đường ngắn nhất dẫn đến kiệt sức và research chất lượng thấp. Mẹo: xây một intake form có sẵn câu hỏi "Quyết định nào sẽ thay đổi dựa trên kết quả này?". Nếu PM không trả lời được, yêu cầu đó chưa đủ chín.
Lỗi 3 — Program chỉ toàn tactical. Khi bị cuốn vào ship hàng tuần, đội research dễ trở thành "usability test service". Mẹo: bảo vệ một phần ngân sách cố định (ví dụ 20%) cho nghiên cứu strategic/foundational, coi đó là bất khả xâm phạm giống như "innovation time".
Lỗi 4 — Không tích lũy insight, làm xong bỏ đó. Program mất đi sức mạnh cộng dồn nếu mỗi study là một ốc đảo. Mẹo: gắn chặt program với repository (nhắc lại từ các bài trước) — mỗi study kết thúc bằng việc nạp insight vào kho, và study mới luôn bắt đầu bằng việc tra kho.
Lỗi 5 — Không có ai "sở hữu" bức tranh lớn. Nếu mỗi researcher chỉ lo phần của mình, program tan rã thành project. Mẹo: cần một người (Research Lead) chịu trách nhiệm cho toàn bộ roadmap và mối liên kết giữa các study.
Mẹo vàng: Hãy trình bày program của bạn như một sản phẩm. Nó có roadmap, có metric, có khách hàng (các stakeholder). Khi bạn nói ngôn ngữ này, lãnh đạo hiểu ngay và research được nhìn nhận như một khoản đầu tư chiến lược chứ không phải chi phí phát sinh.
Bài tập thực hành
Hãy chọn một sản phẩm/công ty bạn đang làm hoặc quen thuộc, rồi hoàn thành các nhiệm vụ sau:
- Xác định anchor: Viết ra 1 mục tiêu chiến lược của công ty đó trong năm nay (nếu không biết chính xác, hãy giả định hợp lý dựa trên bối cảnh). Chỉ rõ giả định về người dùng nào là rủi ro nhất nếu sai.
- Vỡ thành câu hỏi: Từ mục tiêu đó, viết 4 câu hỏi nghiên cứu lớn theo cấu trúc "Chúng ta cần hiểu... để...".
- Nhóm trụ cột: Gom 4 câu hỏi trên thành 2–3 trụ cột và đặt tên cho mỗi trụ cột.
- Vẽ roadmap 1 năm: Liệt kê 6 study cụ thể, đặt lên 4 quý. Với mỗi study, ghi rõ: phương pháp dự kiến, tầng (Strategic/Tactical/Foundational), và study nào nó phụ thuộc vào.
- Kiểm tra cân bằng danh mục: Đếm tỷ lệ ba tầng trong roadmap của bạn. Nó có đang lệch hẳn về tactical không? Nếu có, hãy điều chỉnh.
- Định nghĩa 3 metric: Viết 3 thước đo bạn sẽ dùng để chứng minh giá trị của program này với ban lãnh đạo cuối năm — nhớ rằng "số lượng study" không được tính là metric tốt.
Tóm tắt
Thiết kế research program là bước nhảy từ "người làm nghiên cứu" thành "người dẫn dắt chiến lược tri thức" cho tổ chức. Điểm cốt lõi cần nhớ:
- Program ≠ project: program là chuỗi nhiều study được neo vào một mục tiêu chiến lược, kéo dài theo quý/năm, tích lũy tri thức và có quản trị ưu tiên.
- Bảy khối xây dựng: Goal → Research questions → Pillars → Study roadmap → Cadence → Resourcing → Success metrics.
- Cân bằng ba tầng: Strategic, Tactical và Foundational — đừng để program trôi thành 100% tactical "chữa cháy".
- Quản trị ưu tiên là trái tim: biết từ chối có nguyên tắc quan trọng ngang việc thực thi; dùng ma trận ưu tiên và intake process.
- Đo lường tác động của chính program: research không chứng minh được giá trị sẽ là nạn nhân đầu tiên khi cắt ngân sách. Hãy log quyết định và giá trị mỗi study tạo ra.