Mở đầu — vì sao bài này quan trọng
Đến thứ Năm, đội sprint của bạn đã trải qua ba ngày rất căng: Thứ Hai vẽ bản đồ, đặt mục tiêu dài hạn và chọn điểm ngắm; thứ Ba phác thảo giải pháp; thứ Tư bỏ phiếu chọn ý tưởng thắng cuộc và dựng storyboard. Bây giờ, trước mặt bạn là một tấm storyboard với 10–15 khung hình mô tả từng bước trải nghiệm mà người dùng sẽ đi qua. Nhiệm vụ của thứ Năm nghe có vẻ đơn giản nhưng lại là nơi rất nhiều đội sprint đi chệch hướng: biến tấm storyboard đó thành một prototype đủ thật để mai (thứ Sáu) đưa cho người dùng thật test.
Từ khóa quan trọng nhất của cả ngày thứ Năm nằm ở hai chữ: "đủ thật". Không phải thật hoàn toàn, không phải sản phẩm chạy được, không phải code production. Trong sách "Sprint" của Jake Knapp, đội Google Ventures gọi cái bạn xây hôm nay là một "facade" — một mặt tiền. Giống như phim trường Hollywood: từ phía camera nhìn vào, đó là một thị trấn miền Tây hoành tráng; nhưng đi vòng ra sau, bạn chỉ thấy những tấm ván chống đỡ. Người dùng thứ Sáu sẽ nhìn vào "phía camera" — họ sẽ tin đó là thật, và phản ứng của họ với cái facade đó chính là dữ liệu vàng bạn cần.
Bài này dạy bạn tư duy chiến lược của ngày prototype: quyết định xây cái gì, xây bằng công cụ nào, chia việc thế nào để cả đội xong trước 6 giờ chiều, và quan trọng nhất là giữ đúng "triết lý facade" để không rơi vào cái bẫy chết người của mọi kỹ sư — làm cho nó thật hơn mức cần thiết. Đây là bài về chiến lược prototype, không phải bài hướng dẫn dùng Figma (đó là Bài 16) hay viết kịch bản phỏng vấn (Bài 17).
Khái niệm cốt lõi
Mục tiêu duy nhất của thứ Năm: một facade đủ thật để test
Hãy khắc sâu định nghĩa này. Prototype của Design Sprint không phải để bán, không phải để gọi vốn, không phải để chuyển giao cho đội dev. Nó tồn tại đúng một ngày với đúng một mục đích: tạo ra một tình huống đủ chân thật để 5 người dùng thứ Sáu phản ứng một cách tự nhiên, như thể họ đang dùng sản phẩm thật. Mọi quyết định trong ngày thứ Năm đều phải quy chiếu về câu hỏi: "Cái này có cần thiết để người dùng phản ứng thật không?" Nếu không, đừng làm.
Triết lý "prototype mindset" — bốn nguyên tắc
Knapp đưa ra bốn nguyên tắc tư duy giúp cả đội giữ được tốc độ:
- Bạn có thể prototype bất cứ thứ gì. Dù là app, dịch vụ, phần cứng, quy trình khám bệnh hay một cuốn brochure — luôn có cách dựng facade. Đừng để "cái này khó prototype lắm" trở thành cái cớ.
- Prototype là thứ dùng một lần rồi bỏ (disposable). Bạn xây nó để học, không phải để giữ. Nếu ý tưởng sai, bạn vứt nó đi mà không tiếc — vì bạn chỉ tốn một ngày, không phải sáu tháng.
- Chỉ xây đủ để học, không hơn. Đây là ranh giới giữa "prototype" và "sản phẩm". Chất lượng phải đủ cao để người dùng tin, nhưng không cao đến mức lãng phí thời gian vào những thứ họ sẽ không bao giờ nhìn thấy hay chạm vào.
- Prototype phải tạo được ảo giác thật (the illusion). Người dùng cần cảm giác đây là thật thì họ mới phản ứng thật. Đây là lý do "chất lượng bề mặt" (nội dung, ngôn từ, hình ảnh) lại quan trọng hơn "chất lượng kỹ thuật" (nó có thật sự chạy được không).
"Goldilocks quality" — vừa đủ, không nhiều không ít
Có một khái niệm rất hay gọi là "Goldilocks quality" — mức chất lượng vừa vặn như bát cháo trong truyện cổ tích: không quá nóng, không quá nguội. Prototype quá thô sơ (ví dụ bản vẽ giấy nguệch ngoạc) thì người dùng không nhập tâm, họ cứ nhắc mình "à đây là bản nháp" và không phản ứng thật. Prototype quá hoàn thiện (đã code, đã có animation mượt) thì bạn tốn quá nhiều thời gian, và tệ hơn, người dùng ngại chê vì trông nó "đã xong rồi". Điểm ngọt nằm ở giữa: một prototype trông xong xuôi ở bề mặt nhưng thực chất rỗng ở bên trong.
Facade là "bề mặt", không phải "chiều sâu"
Cách hiểu thực dụng nhất: prototype của bạn chỉ cần dày đúng một lớp — đúng những màn hình, đúng những bước mà kịch bản phỏng vấn thứ Sáu sẽ đi qua. Người dùng sẽ đi theo một "con đường vàng" (happy path) đã được sắp đặt. Bất cứ nút bấm nào nằm ngoài con đường đó đều không cần hoạt động. Bạn không xây một cái cây với đầy đủ mọi nhánh; bạn xây một hành lang thẳng.
Tình huống thực tế
Ví dụ 1: MoMo thử nghiệm tính năng "hũ tiết kiệm tự động"
Một đội sản phẩm giả định tại một ví điện tử lớn kiểu MoMo chạy sprint cho tính năng "hũ tiết kiệm" — mỗi lần người dùng thanh toán, hệ thống làm tròn số tiền lên và bỏ phần lẻ vào hũ tiết kiệm. Sang thứ Năm, một kỹ sư trong đội đề xuất "để em kết nối API ngân hàng thật cho nó chạy luôn, test mới chuẩn". Facilitator ngăn lại ngay.
Lý do: người dùng thứ Sáu sẽ không quan tâm tiền có thực sự chuyển hay không — họ quan tâm là họ có hiểu tính năng này không, có thấy nó hấp dẫn không, có tin tưởng giao tiền cho nó không. Đội quyết định dựng facade trong Figma: các màn hình on-boarding hũ tiết kiệm, màn hình chọn quy tắc làm tròn, và một màn hình "hũ của bạn đã có 47.000đ" với con số được gắn cứng (hardcode). Không có API, không có database, không có logic làm tròn thật.
Kết quả thứ Sáu: 3/5 người dùng bối rối ở màn hình chọn quy tắc làm tròn vì không hiểu "làm tròn lên bội số 10.000" nghĩa là gì. Đó chính là insight quý nhất — và nó chẳng liên quan gì đến API. Nếu đội đã dành cả ngày thứ Năm nối API thật, họ sẽ vừa cạn thời gian vừa không phát hiện được vấn đề nằm ở ngôn ngữ và cách giải thích.
Bài học: Chất lượng cần đầu tư nằm ở bề mặt (ngôn từ, cách trình bày), không phải ở kỹ thuật bên dưới.
Ví dụ 2: Tiki thử nghiệm dịch vụ "đổi trả tại nhà" — prototype cả một dịch vụ, không chỉ app
Một đội tại một sàn thương mại điện tử kiểu Tiki chạy sprint cho dịch vụ "shipper đến tận nhà nhận hàng đổi trả". Vấn đề: đây không chỉ là màn hình app, mà là cả một trải nghiệm dịch vụ có con người tham gia. Nhiều người trong đội hoang mang: "Cái này làm sao mà prototype trong một ngày?"
Facilitator áp dụng nguyên tắc "bạn có thể prototype bất cứ thứ gì". Đội chia facade thành hai lớp: (1) phần app — các màn hình đặt lịch đổi trả, chọn khung giờ, theo dõi shipper — dựng bằng Figma; và (2) phần con người — họ chuẩn bị một kịch bản để thứ Sáu, khi người dùng "đặt lịch" xong, một thành viên đội đóng vai tổng đài gọi điện xác nhận, và mô tả bằng lời "shipper sẽ đến trong 30 phút". Đây là kỹ thuật dựng cảnh dịch vụ bằng con người thật đứng sau tấm màn (chi tiết kỹ thuật Wizard of Oz sẽ học kỹ ở Bài 23; ở đây bạn chỉ cần thấy rằng dịch vụ vẫn prototype được).
Bài học: Khi sản phẩm không phải màn hình thuần túy, hãy phân tách trải nghiệm thành các mảnh và dựng facade cho từng mảnh — kể cả bằng con người đóng vai.
Ví dụ 3: Startup EdTech Singapore và cái bẫy "làm cho nó chạy được"
Một startup EdTech ở Singapore chạy sprint cho tính năng "lộ trình học cá nhân hóa bằng AI". Đội có hai kỹ sư giỏi và họ hào hứng: "Chúng ta có sẵn model rồi, để tôi wire nó vào cho lộ trình sinh ra thật!" Đến 4 giờ chiều thứ Năm, họ vẫn đang debug lỗi tích hợp, các màn hình khác chưa ai đụng tới, và cả đội đối mặt nguy cơ không có gì để test vào sáng hôm sau.
Facilitator phải ra một quyết định cứng rắn: dừng toàn bộ phần AI thật, thay bằng ba lộ trình mẫu viết sẵn bằng tay cho ba "chân dung" người dùng mà họ đã tuyển cho thứ Sáu. Nghĩa là họ biết trước bạn A là người mới bắt đầu, bạn B đã có nền tảng, bạn C muốn ôn thi — và họ soạn sẵn ba lộ trình tương ứng, gắn cứng vào prototype. Với người dùng, nó trông như AI vừa sinh ra lộ trình riêng cho họ.
Thứ Sáu diễn ra suôn sẻ, và insight lớn là: người dùng không tin lộ trình "do AI tạo" vì thiếu phần giải thích "vì sao lại đề xuất bước này". Một lần nữa, vấn đề nằm ở niềm tin và cách giao tiếp, không phải ở việc AI có chạy thật hay không.
Bài học: Đừng bao giờ để "làm cho nó chạy thật" nuốt mất thời gian của cả ngày. Mọi thứ có thể "giả" thì hãy giả (fake it), miễn là người dùng không phân biệt được.
Hướng dẫn từng bước
Ngày thứ Năm chạy theo một nhịp khá chuẩn từ 9 giờ sáng đến 6 giờ chiều. Đây là các bước chiến lược cần làm trước khi tay bạn chạm vào công cụ:
Bước 1 — Chọn công cụ (fetch the right tools), khoảng 15–30 phút đầu. Câu hỏi cốt lõi: đâu là công cụ giúp đội bạn dựng facade nhanh nhất mà vẫn đủ thật? Với sản phẩm số, câu trả lời thường là Figma (dựng màn hình rồi nối thành flow bấm được). Với brochure, tờ rơi hoặc bao bì, có thể là Keynote/PowerPoint hoặc Canva. Với dịch vụ, có thể là kịch bản kèm con người đóng vai. Nguyên tắc: chọn công cụ mà đội đã quen, đừng học công cụ mới trong ngày sprint.
Bước 2 — Chọn "phong cách" và độ trung thực (fidelity). Quyết định prototype của bạn sẽ trông "thật" đến đâu về mặt hình ảnh. Nếu bạn đã có design system hoặc thư viện component sẵn, tận dụng để nhanh hơn. Nếu chưa, một bộ khung xám (wireframe) chỉn chu với nội dung thật (không dùng "Lorem ipsum") thường đã đủ tạo ảo giác. Nhớ: nội dung thật quan trọng hơn màu mè.
Bước 3 — Phân chia storyboard thành các mảnh và giao việc (divide and conquer). Đây là bước then chốt để kịp giờ. Nhìn vào storyboard, cắt nó thành các cụm màn hình logic, rồi phân cho từng người: người làm phần đăng ký, người làm phần trải nghiệm chính, người làm phần kết thúc. Song song, chỉ định các vai:
- Maker (người dựng): hai hoặc nhiều người, mỗi người phụ trách một cụm màn hình.
- Stitcher (người ghép): MỘT người duy nhất chịu trách nhiệm ghép tất cả các mảnh lại thành một luồng liền mạch, thống nhất font, màu, khoảng cách. Đây là vai bị bỏ quên nhiều nhất và là nguyên nhân số một khiến prototype trông chắp vá.
- Writer (người viết chữ): người lo toàn bộ nội dung, ngôn từ, microcopy. Vì "chất lượng bề mặt" chính là chữ, vai này cực kỳ quan trọng, thường bị coi nhẹ.
- Asset collector (người gom tài nguyên): đi tìm ảnh, icon, logo, dữ liệu mẫu để các maker không phải dừng lại tìm kiếm.
- Interviewer (người phỏng vấn thứ Sáu): người này KHÔNG nên nhúng tay vào dựng prototype, mà dành thời gian bắt đầu soạn kịch bản phỏng vấn (nội dung Bài 17), để đến chiều có thể chạy thử prototype bằng con mắt của người ngoài.
Bước 5 — 3 giờ chiều: ghép sơ bộ (first stitch). Đây là mốc kiểm tra bắt buộc. Đừng đợi đến 5 giờ mới ghép. Ghép sớm để phát hiện lỗ hổng: thiếu màn hình, luồng đứt đoạn, nội dung chưa khớp. Còn nguyên buổi chiều để vá.
Bước 6 — Trial run (chạy thử), khoảng 4–5 giờ chiều. Có người đóng vai người dùng, đi qua toàn bộ prototype theo đúng kịch bản phỏng vấn dự kiến. Đây là lúc phát hiện nút không bấm được, con đường vàng bị lệch, chữ khó hiểu. Sửa nốt.
Bước 7 — Kết ngày: xác nhận prototype đã sẵn sàng và người phỏng vấn đã nắm luồng. Trước khi ra về, cả đội phải chắc chắn rằng vào 9 giờ sáng mai không còn gì phải dựng nữa. Thứ Sáu là ngày quan sát, không phải ngày sửa code.
Lỗi thường gặp & mẹo
Lỗi 1 — Kỹ sư "vô thức" xây thật. Đây là bẫy lớn nhất. Người quen viết code sẽ có phản xạ nối database, gọi API, viết logic. Mẹo: facilitator nên nói rõ ngay đầu ngày rằng "hôm nay chúng ta không viết một dòng code production nào" và biến nó thành luật. Nếu đội có kỹ sư mạnh, hãy giao họ vai stitcher hoặc asset collector để năng lượng đó không đổ vào việc sai.
Lỗi 2 — Đặt fidelity quá cao. Dành hai tiếng chỉnh shadow và bo góc cho đẹp. Người dùng không test cái bo góc. Mẹo: hỏi "cái này ảnh hưởng đến việc người dùng có phản ứng thật không?" — nếu không, bỏ qua.
Lỗi 3 — Dùng nội dung giả (Lorem ipsum, "Sản phẩm A", "abc@gmail.com"). Nội dung giả phá vỡ ảo giác thật nhanh nhất. Người dùng đọc "Lorem ipsum" là lập tức biết đây là hàng nháp và ngừng nhập tâm. Mẹo: đầu tư vào chữ thật, tên sản phẩm thật, con số hợp lý. Đây là lý do vai Writer quan trọng.
Lỗi 4 — Không có stitcher, mỗi người một kiểu. Prototype trông như năm người xa lạ ghép lại: font khác nhau, nút khác nhau, khoảng cách lộn xộn. Mẹo: chỉ định stitcher ngay từ đầu và thống nhất một bộ style tối thiểu (một font, một màu chính, một kích thước nút).
Lỗi 5 — Ghép quá muộn. Đợi 5 giờ chiều mới ghép rồi phát hiện thiếu ba màn hình. Mẹo: mốc "first stitch lúc 3 giờ" là bất di bất dịch.
Lỗi 6 — Xây cả cây thay vì một hành lang. Cố làm mọi nút bấm đều hoạt động. Mẹo: chỉ dựng đúng con đường vàng mà kịch bản thứ Sáu sẽ đi qua. Mọi thứ ngoài con đường đó để "chết" cũng không sao.
Mẹo tổng: Nếu đến 3 giờ chiều bạn thấy nguy cơ không kịp, hãy cắt bớt phạm vi (scope) chứ đừng cắt chất lượng bề mặt hay bỏ trial run. Thà test một luồng ngắn hoàn chỉnh còn hơn một luồng dài đầy lỗ hổng.
Bài tập thực hành
- Xác định facade tối thiểu. Lấy một tính năng bạn đang muốn thử (thật hoặc giả định). Viết ra: đâu là con đường vàng người dùng sẽ đi? Liệt kê chính xác các màn hình/bước cần dựng, và gạch bỏ mọi thứ nằm ngoài con đường đó. Mục tiêu: danh sách càng ngắn càng tốt.
- Bài tập "fake it". Với tính năng trên, hãy chỉ ra ít nhất ba thứ mà bạn định "làm thật" nhưng thực ra có thể "làm giả" (hardcode con số, viết sẵn kết quả, dùng người đóng vai). Ghi rõ cách giả cho từng thứ.
- Phân vai cho đội 5 người. Giả sử đội bạn có 5 người. Hãy phân họ vào các vai Maker, Stitcher, Writer, Asset collector, Interviewer dựa trên thế mạnh từng người. Giải thích vì sao bạn giao kỹ sư mạnh nhất vào vai bạn chọn.
- Dựng lịch giờ. Viết ra timeline chi tiết của ngày thứ Năm từ 9 giờ sáng đến 6 giờ chiều cho đội bạn, đánh dấu rõ mốc "first stitch lúc 3 giờ" và "trial run lúc 4–5 giờ".
Tóm tắt
Ngày thứ Năm của Design Sprint có một mục tiêu duy nhất: dựng một facade — một mặt tiền đủ thật để người dùng thứ Sáu phản ứng tự nhiên, chứ không phải một sản phẩm chạy được. Hãy khắc ghi bốn nguyên tắc prototype mindset: prototype được mọi thứ, dùng một lần rồi bỏ, chỉ xây đủ để học, và phải tạo được ảo giác thật. Nhắm tới "Goldilocks quality" — vừa đủ, không thô cũng không quá hoàn thiện — và nhớ rằng chất lượng nằm ở bề mặt (nội dung, ngôn từ) chứ không ở kỹ thuật bên dưới.
Về mặt tổ chức, thành công của ngày phụ thuộc vào việc chia storyboard thành các mảnh, phân vai rõ ràng (đặc biệt là stitcher và writer — hai vai hay bị quên), ghép sớm lúc 3 giờ chiều, và chạy thử trước khi ra về. Cái bẫy lớn nhất luôn là bản năng "làm cho nó chạy thật" — hãy chống lại nó bằng cách fake mọi thứ có thể fake. Khi bạn giữ đúng triết lý facade, bạn sẽ bước vào sáng thứ Sáu với một prototype đủ thuyết phục và một buổi chiều thứ Năm không kiệt sức. Ngày mai, bạn sẽ để người dùng thật cho bạn biết facade đó đứng vững hay sụp đổ.