Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn đã bỏ ra bốn ngày trời cùng đội ngũ: đặt mục tiêu dài hạn, vẽ bản đồ hành trình người dùng, phỏng vấn chuyên gia, phác thảo giải pháp, bỏ phiếu chọn ý tưởng và dựng nguyên mẫu (prototype) trong Figma. Tất cả công sức đó dồn vào một ngày duy nhất: thứ Sáu — ngày bạn đưa nguyên mẫu ra trước năm người dùng thật để xem nó có "sống sót" ngoài đời hay không.
Nhưng đây là sự thật phũ phàng mà nhiều facilitator (người điều phối) mới vào nghề học được theo cách đau đớn nhất: một buổi phỏng vấn thứ Sáu chỉ có giá trị khi nó được cấu trúc bài bản. Nếu bạn ứng biến (improvise), tự nghĩ ra câu hỏi ngay tại chỗ, dẫn dắt người dùng theo cảm hứng, thì kết quả bạn thu về sẽ không phải là dữ liệu — mà là ảo tưởng. Bạn sẽ vô tình đặt những câu hỏi mớm ý (leading questions), khiến người dùng gật đầu cho vừa lòng bạn, bỏ sót những tín hiệu quan trọng, và cuối buổi cả đội quay ra tranh cãi xem "họ nói vậy nghĩa là gì".
Trong Design Sprint theo phương pháp Google Ventures, thứ Năm không chỉ dành để dựng prototype. Một phần công việc cực kỳ quan trọng của thứ Năm là chuẩn bị kịch bản phỏng vấn (interview script) — bản thảo mà người phỏng vấn (Interviewer) sẽ đọc theo vào ngày hôm sau. Bài học này tập trung hoàn toàn vào việc viết ra kịch bản đó: cấu trúc năm phần kinh điển, cách viết từng phần, những cái bẫy về ngôn từ, và cách chuẩn bị để buổi test thứ Sáu cho ra tín hiệu sạch thay vì nhiễu.
Lưu ý: Bài này KHÔNG dạy cách thực sự tiến hành phỏng vấn hay cách ghi chép quan sát — đó là nội dung của Bài 18 và Bài 19. Ở đây, chúng ta chỉ tập trung vào việc soạn thảo kịch bản trước khi ngày test diễn ra.
Khái niệm cốt lõi
Vì sao phải có kịch bản viết sẵn?
Não người có một xu hướng tự nhiên rất nguy hiểm trong bối cảnh phỏng vấn: chúng ta muốn được xác nhận rằng công sức của mình có ý nghĩa. Sau bốn ngày đổ mồ hôi vào prototype, người phỏng vấn rất dễ (một cách vô thức) hỏi những câu như "Anh thấy nút này dễ dùng đúng không?" thay vì "Anh sẽ làm gì tiếp theo ở màn hình này?". Câu đầu tiên là một cái bẫy — nó gợi ý sẵn câu trả lời "đúng". Câu thứ hai để người dùng tự bộc lộ hành vi thật.
Kịch bản viết sẵn giải quyết vấn đề này bằng cách loại bỏ ứng biến. Khi bạn đọc theo một văn bản đã được cả đội cân nhắc kỹ trong trạng thái đầu óc tỉnh táo (thứ Năm), bạn không còn cơ hội để "trượt tay" đặt câu hỏi mớm ý khi đang căng thẳng trước mặt người lạ (thứ Sáu).
Kịch bản còn đảm bảo tính nhất quán giữa năm buổi phỏng vấn. Nếu mỗi người dùng được hỏi theo một cách khác nhau, bạn không thể so sánh phản hồi của họ để tìm mẫu hình (pattern). Trong Sprint, sức mạnh nằm ở việc quan sát: khi 3/5 người cùng vấp ở một chỗ, đó là tín hiệu mạnh. Nhưng bạn chỉ nhận ra "3/5" khi cả năm người đi qua cùng một lộ trình.
Cấu trúc năm phần của kịch bản phỏng vấn (Five-Act Interview)
Jake Knapp và đội GV gọi đây là "cuộc phỏng vấn năm màn". Đây là khung sườn đã được chứng minh qua hàng trăm sprint. Kịch bản của bạn nên đi theo đúng năm phần này:
Phần 1 — Chào hỏi thân thiện (Friendly welcome). Mục tiêu là làm người dùng thoải mái. Bạn giới thiệu bản thân, cảm ơn họ đã đến, và quan trọng nhất: nói rõ rằng đây là bài test sản phẩm chứ không phải test họ. Câu chốt kinh điển: "Không có câu trả lời đúng hay sai. Chúng tôi đang thử nghiệm một ý tưởng còn rất sơ khai, nên nếu có chỗ nào khó dùng, đó là lỗi của chúng tôi chứ không phải của anh/chị."
Phần 2 — Câu hỏi bối cảnh (Context questions). Trước khi đưa prototype ra, bạn hỏi vài câu nhẹ nhàng, mở, về cuộc sống và thói quen của người dùng liên quan đến lĩnh vực sản phẩm. Ví dụ với app tài chính: "Bình thường anh/chị quản lý chi tiêu hằng tháng như thế nào?". Phần này vừa để "làm nóng", vừa cho bạn hiểu bối cảnh để diễn giải hành vi của họ sau đó.
Phần 3 — Giới thiệu prototype (Introduce the prototype). Bạn đặt kỳ vọng: nhắc lại rằng đây là bản chưa hoàn thiện, có thể vài chỗ chưa chạy được, và — cực kỳ quan trọng — yêu cầu họ nghĩ thành tiếng (think aloud). Bạn cũng phải trấn an rằng bạn không thể "giúp" họ trong lúc thử, vì ngoài đời họ cũng sẽ dùng một mình.
Phần 4 — Nhiệm vụ và động lực chi tiết (Tasks & nudges). Đây là trái tim của kịch bản. Bạn giao cho người dùng những nhiệm vụ cụ thể để họ tự trải nghiệm prototype, thay vì bạn "trình diễn" cho họ xem. Từng nhiệm vụ được viết dưới dạng tình huống ("Giả sử anh muốn chuyển 2 triệu cho bạn..."), rồi để họ tự mò. Kèm theo là các câu hỏi thăm dò (probing questions) để hỏi khi họ dừng lại hoặc bối rối.
Phần 5 — Tổng kết nhanh (Quick debrief). Cuối buổi, bạn hỏi vài câu tổng hợp để nắm ấn tượng chung: "Điều gì anh/chị thích nhất? Điều gì gây khó chịu? Nếu có một cây đũa thần, anh/chị sẽ thay đổi điều gì?". Rồi cảm ơn và kết thúc.
Nguyên tắc vàng khi viết từng câu hỏi
Ba nguyên tắc bạn phải khắc cốt ghi tâm khi soạn kịch bản:
- Hỏi mở, không hỏi đóng. Tránh câu chỉ trả lời được có/không. Thay "Nút này rõ ràng chứ?" bằng "Anh nghĩ nút này sẽ làm gì?".
- Không mớm ý. Đừng chèn ý kiến của bạn vào câu hỏi. "Màn hình này hơi rối phải không?" đã tự trả lời hộ người dùng rồi.
- Hỏi về hành vi, hoãn hỏi về ý kiến. Trong lúc họ thao tác, bạn quan tâm họ làm gì và tại sao, chứ không phải họ thích hay không. Ý kiến để dành cho Phần 5.
Tình huống thực tế
Ví dụ 1 — Fintech "MoMo-style" và câu hỏi mớm ý suýt phá hỏng cả tuần
Một đội sản phẩm giả định tên VíXanh (một ví điện tử tại TP.HCM) chạy sprint để test luồng "chia hóa đơn" (split bill) mới. Ngày thứ Năm, người phỏng vấn — vốn là Product Manager rất tâm huyết — tự soạn kịch bản và viết câu: "Tính năng chia hóa đơn này tiện đúng không anh, chỉ cần một chạm là xong?".
May mắn là facilitator đọc lại kịch bản trước khi in ra và phát hiện ra vấn đề. Câu này vi phạm cả ba nguyên tắc cùng lúc: nó đóng (đúng/không), nó mớm ý ("tiện"), và nó hỏi ý kiến ngay giữa nhiệm vụ. Họ sửa lại thành: "Giả sử anh vừa đi ăn với ba người bạn, tổng hóa đơn 800 nghìn. Anh hãy dùng app để đòi lại phần của từng người xem sao. Anh cứ nói ra suy nghĩ trong đầu khi làm nhé."
Kết quả thứ Sáu: 4/5 người dùng loay hoay ở bước chọn số người, vì họ tưởng phải nhập từng số điện thoại thủ công. Nếu giữ câu hỏi cũ, gần như chắc chắn cả năm người sẽ gật "tiện đấy" cho xong, và đội sẽ mang một prototype có lỗi nghiêm trọng đi phát triển tiếp.
Bài học: Một câu chữ sai trong kịch bản có thể xóa sạch tín hiệu của cả một ngày test. Việc rà soát ngôn từ vào thứ Năm quan trọng ngang với việc dựng prototype.
Ví dụ 2 — Grab-for-Business và nhiệm vụ mơ hồ
Một đội tại một công ty gọi xe (giả định tên DiChung Business) test tính năng đặt xe theo lô cho doanh nghiệp. Kịch bản ban đầu của họ giao nhiệm vụ rất chung chung: "Anh hãy thử đặt xe cho công ty xem." Trong buổi review thứ Năm, một thành viên phản biện: nhiệm vụ mơ hồ quá, mỗi người dùng sẽ hiểu một kiểu, và ta không so sánh được.
Họ viết lại thành một tình huống cụ thể có ràng buộc rõ: "Giả sử anh là trợ lý giám đốc. Sếp và hai khách hàng cần đi từ văn phòng ở Quận 1 ra sân bay Tân Sơn Nhất lúc 3 giờ chiều mai, và chi phí phải xuất hóa đơn công ty. Anh hãy đặt chuyến này." Bây giờ mọi người dùng đều đi qua cùng một kịch bản: chọn nhiều điểm đón, đặt trước theo giờ, và xử lý hóa đơn VAT.
Kết quả: cả năm người đều tìm được cách đặt xe, nhưng 3/5 không hề nhận ra có tùy chọn xuất hóa đơn VAT — họ bỏ qua hoàn toàn phần đó. Đây chính là tín hiệu vàng, và nó chỉ nổi lên vì nhiệm vụ đủ cụ thể để buộc mọi người chạm tới cùng một tính năng.
Bài học: Nhiệm vụ trong Phần 4 phải là tình huống cụ thể, có ràng buộc, chứ không phải lời mời chung chung. Cụ thể hóa nhiệm vụ = cụ thể hóa tín hiệu thu về.
Ví dụ 3 — EdTech và cái bẫy "người phỏng vấn giúp đỡ"
Một nền tảng học tiếng Anh (giả định tên HocMai English) test luồng đăng ký khóa học. Facilitator nhấn mạnh trong kịch bản một câu tưởng nhỏ nhưng cứu cả buổi test, đặt ở Phần 3: "Trong lúc anh dùng thử, tôi sẽ ngồi im quan sát. Nếu anh bị kẹt, tôi sẽ không giúp ngay đâu — vì ở nhà anh cũng phải tự làm một mình. Cứ thử mọi cách anh nghĩ ra nhé."
Nhờ câu này viết sẵn trong kịch bản, người phỏng vấn đã kìm được bản năng "cứu người dùng" khi thấy một bạn học viên loay hoay 40 giây tìm nút "Đăng ký học thử miễn phí". Chính 40 giây im lặng đó cho thấy nút CTA (call-to-action) bị chìm trong thiết kế. Nếu người phỏng vấn buột miệng "nút ở góc trên bên phải kìa anh", tín hiệu này sẽ biến mất.
Bài học: Kịch bản không chỉ chứa câu hỏi, mà còn chứa cả hướng dẫn hành vi cho chính người phỏng vấn — đặc biệt là quy tắc "không giúp đỡ".
Hướng dẫn từng bước
Đây là quy trình soạn kịch bản phỏng vấn vào chiều thứ Năm, sau khi prototype đã cơ bản xong:
Bước 1 — Nhìn lại câu hỏi Sprint và mục tiêu. Mở lại danh sách "Sprint Questions" đã viết từ thứ Hai. Kịch bản của bạn tồn tại để trả lời những câu hỏi này. Ví dụ nếu câu hỏi là "Người dùng có tin tưởng giao thông tin thẻ cho ta không?", thì kịch bản phải có nhiệm vụ dẫn họ tới màn hình nhập thẻ.
Bước 2 — Viết Phần 1 (Chào hỏi). Giữ ngắn gọn, ấm áp, 3–4 câu. Bắt buộc có câu "test sản phẩm chứ không test bạn" và "nghĩ gì nói nấy, không có đúng sai".
Bước 3 — Viết 3–5 câu hỏi bối cảnh (Phần 2). Chọn câu mở, liên quan đến thói quen của người dùng trong lĩnh vực sản phẩm. Đi từ chung tới cụ thể dần.
Bước 4 — Viết đoạn giới thiệu prototype (Phần 3). Gồm ba ý bắt buộc: (a) đây là bản chưa hoàn thiện, (b) hãy nghĩ thành tiếng, (c) tôi sẽ không giúp bạn trong lúc thử.
Bước 5 — Thiết kế các nhiệm vụ (Phần 4). Đây là bước tốn nhiều thời gian nhất. Với mỗi nhiệm vụ:
- Viết dưới dạng tình huống cụ thể, có ràng buộc rõ ("Giả sử... anh hãy...").
- KHÔNG chỉ dẫn cách làm. Để người dùng tự tìm.
- Chuẩn bị sẵn 2–3 câu thăm dò trung lập để hỏi khi họ dừng lại: "Anh đang nghĩ gì vậy?", "Anh mong điều gì sẽ xảy ra khi bấm cái đó?", "Sao anh lại chọn chỗ này?".
- Sắp xếp nhiệm vụ theo đúng thứ tự người dùng thật sẽ gặp trong hành trình.
Bước 7 — Đọc to và diễn tập. Cả đội đọc lướt kịch bản. Người sẽ phỏng vấn ngày mai nên đọc thành tiếng ít nhất một lượt để phát hiện câu nào bị cứng, khó nói, hoặc vô tình mớm ý.
Bước 8 — Đối chiếu với prototype. Kiểm tra từng nhiệm vụ có thực sự chạy được trên prototype không. Không có gì tệ hơn việc thứ Sáu mới phát hiện nhiệm vụ số 3 dẫn tới một màn hình chưa được dựng.
Bước 9 — In ra và chuẩn bị bản ghi chú. In kịch bản (hoặc để trên máy tính bảng), kèm khoảng trống để người phỏng vấn ghi chú nhanh. Chuẩn bị luôn cấu trúc để cả phòng bên kia theo dõi (nhưng cách ghi quan sát chi tiết thuộc Bài 19).
Lỗi thường gặp & mẹo
Lỗi 1 — Đặt câu hỏi mớm ý (leading questions). Đây là lỗi số một. Bất kỳ câu nào chứa tính từ đánh giá ("dễ", "tiện", "rõ ràng", "đẹp") đều nguy hiểm. Mẹo: Sau khi viết xong, quét lại kịch bản và gạch bỏ mọi tính từ mang tính khen/chê trong câu hỏi.
Lỗi 2 — Nhiệm vụ quá mơ hồ. "Thử dùng app đi" không cho tín hiệu so sánh được. Mẹo: Mỗi nhiệm vụ phải bắt đầu bằng "Giả sử..." và kết thúc bằng một mục tiêu cụ thể có thể quan sát được đã hoàn thành hay chưa.
Lỗi 3 — Người phỏng vấn "diễn" prototype thay vì để người dùng tự làm. Nếu bạn cầm chuột và click hộ, bạn chỉ thu được ý kiến chứ không phải hành vi. Mẹo: Trong kịch bản, thêm ghi chú in đậm cho người phỏng vấn: "ĐƯA CHUỘT CHO NGƯỜI DÙNG. KHÔNG CLICK HỘ."
Lỗi 4 — Hỏi câu tiên đoán tương lai. "Anh có dùng cái này không?" cho câu trả lời vô giá trị, vì con người rất dở trong việc dự đoán hành vi tương lai của chính mình. Mẹo: Chuyển sang hỏi về hành vi hiện tại và quá khứ: "Lần gần nhất anh làm việc này, anh làm thế nào?".
Lỗi 5 — Kịch bản quá dài. Buổi phỏng vấn Sprint thường gói gọn trong 45–60 phút. Nhồi 15 nhiệm vụ sẽ khiến người dùng mệt và tín hiệu cuối buổi bị loãng. Mẹo: Ưu tiên những nhiệm vụ trả lời trực tiếp các Sprint Questions quan trọng nhất; cắt phần còn lại.
Mẹo bonus — Chuẩn bị "câu thăm dò dự phòng". Người dùng đôi khi im lặng, không nghĩ thành tiếng. Hãy có sẵn trong kịch bản vài câu nhắc nhẹ trung lập: "Anh đang nghĩ gì trong đầu vậy?" — đủ để họ tiếp tục nói mà không bị dẫn dắt.
Bài tập thực hành
Hãy chọn một sản phẩm số bạn quen thuộc (ví dụ: app ngân hàng bạn đang dùng, hoặc một tính năng trên Shopee/Lazada). Giả định bạn vừa dựng prototype cho một tính năng mới của nó và cần soạn kịch bản test thứ Sáu.
- Viết Phần 1 (Chào hỏi) đầy đủ, gồm câu "test sản phẩm chứ không test bạn".
- Viết 3 câu hỏi bối cảnh ở Phần 2, đảm bảo cả ba đều là câu hỏi mở.
- Thiết kế 2 nhiệm vụ cho Phần 4, mỗi nhiệm vụ bắt đầu bằng "Giả sử..." và có mục tiêu quan sát được rõ ràng. Với mỗi nhiệm vụ, viết kèm 2 câu thăm dò trung lập.
- Viết câu "đũa thần" cho Phần 5.
- Tự kiểm tra: Đọc to toàn bộ kịch bản. Gạch chân mọi tính từ khen/chê và mọi câu có thể trả lời bằng có/không. Viết lại chúng thành câu mở, trung lập.
Tóm tắt
Kịch bản phỏng vấn được soạn vào thứ Năm là cầu nối biến bốn ngày làm việc thành tín hiệu có giá trị vào thứ Sáu. Không có nó, buổi test biến thành một cuộc trò chuyện ngẫu hứng đầy thiên kiến (bias) và bỏ sót tín hiệu.
Những điểm cốt lõi cần nhớ:
- Improvise là kẻ thù. Ứng biến dẫn tới câu hỏi mớm ý, thiếu nhất quán, và dữ liệu không so sánh được. Viết sẵn kịch bản để loại bỏ điều đó.
- Cấu trúc năm màn: Chào hỏi → Câu hỏi bối cảnh → Giới thiệu prototype → Nhiệm vụ & thăm dò → Tổng kết. Đây là khung sườn đã được kiểm chứng.
- Ba nguyên tắc vàng: hỏi mở không hỏi đóng, không mớm ý, hỏi hành vi trước ý kiến.
- Nhiệm vụ phải cụ thể, dạng "Giả sử... anh hãy...", để mọi người dùng đi qua cùng một lộ trình và bạn có thể đếm mẫu hình (3/5, 4/5).
- Kịch bản cũng chứa hướng dẫn cho người phỏng vấn: không giúp đỡ, không click hộ, để người dùng tự nghĩ thành tiếng.
- Rà soát ngôn từ trước khi in: gạch bỏ mọi tính từ khen/chê và mọi câu có/không.