Mở đầu — vì sao bài này quan trọng
Có một câu nói thường được gán cho Einstein: "Nếu tôi có một giờ để cứu thế giới, tôi sẽ dành 55 phút để định nghĩa vấn đề và 5 phút để tìm giải pháp." Dù chưa chắc Einstein thực sự nói câu này, tinh thần của nó là điều mọi Product Designer phải khắc cốt ghi tâm: giải pháp sai cho đúng vấn đề thì còn vớt vát được, nhưng giải pháp hoàn hảo cho sai vấn đề thì là công cốc.
Trong các bài trước, bạn đã hiểu Design Thinking là một quy trình lặp (Bài 5 — IDEO Process), và bạn đã phân biệt được vai trò Product Designer so với UI/UX Designer (Bài 4). Bài 6 này đào sâu vào một giai đoạn cụ thể nhưng cực kỳ then chốt nằm giữa "Empathize" và "Ideate": Problem Framing — đóng khung vấn đề. Đây là cây cầu nối giữa những gì bạn quan sát được từ người dùng và những ý tưởng bạn sắp tạo ra. Nếu cây cầu này xây lệch, mọi thứ phía sau — wireframe, prototype, design system — đều xây trên nền móng nghiêng.
Tôi gặp rất nhiều bạn designer trẻ ở Việt Nam giỏi Figma, dựng UI đẹp long lanh, nhưng khi sản phẩm ra mắt lại không ai dùng. Lý do gần như luôn giống nhau: họ nhảy thẳng vào việc vẽ trước khi hiểu mình đang giải quyết điều gì. Bài học hôm nay sẽ trang bị cho bạn hai công cụ tư duy mạnh nhất để tránh cái bẫy đó: cách đóng khung vấn đề (problem framing) và kỹ thuật "How Might We" (HMW) — câu thần chú biến một vấn đề bế tắc thành lời mời gọi sáng tạo.
Khái niệm cốt lõi
Problem Framing là gì?
Problem framing là hành động diễn đạt lại một tình huống mơ hồ thành một phát biểu vấn đề rõ ràng, đúng phạm vi, và có thể giải quyết được bằng thiết kế. Hãy hình dung như một nhiếp ảnh gia: cùng một cảnh vật, nhưng bạn chọn khung hình (frame) nào, cắt cúp ra sao, sẽ quyết định bức ảnh kể câu chuyện gì. Đóng khung vấn đề cũng vậy — bạn đang chọn nhìn vấn đề từ góc nào.
Điểm mấu chốt: một "frame" không phải là sự thật khách quan, mà là một góc nhìn có chủ đích. Cùng một hiện tượng "người dùng bỏ giỏ hàng" có thể được đóng khung theo nhiều cách:
- "Người dùng không tìm thấy nút thanh toán" (frame về điều hướng)
- "Người dùng bị sốc vì phí ship hiện ra phút chót" (frame về tính minh bạch)
- "Người dùng chưa đủ tin tưởng để nhập thẻ" (frame về niềm tin)
Symptom vs Root cause — Triệu chứng và Gốc rễ
Sai lầm phổ biến nhất là đóng khung quanh triệu chứng thay vì nguyên nhân gốc. "Tỷ lệ đăng ký thấp" là một triệu chứng. Nó có thể bắt nguồn từ form quá dài, từ việc người dùng không hiểu giá trị sản phẩm, hay từ việc họ chưa sẵn sàng cam kết. Một kỹ thuật kinh điển để đào xuống gốc là "5 Whys" (5 lần hỏi Tại sao) của Toyota: cứ mỗi câu trả lời, lại hỏi "tại sao" thêm một lần cho đến khi chạm tới nguyên nhân thật sự.
Phân biệt Problem Space và Solution Space
Một nguyên tắc vàng: khi đang frame vấn đề, đừng nói về giải pháp. Có hai không gian tư duy:
- Problem space (không gian vấn đề): ai gặp khó khăn gì, trong bối cảnh nào, vì sao điều đó quan trọng.
- Solution space (không gian giải pháp): ta sẽ xây cái gì để giải quyết.
"How Might We" — biến vấn đề thành lời mời
Sau khi đã đóng khung vấn đề, bạn cần một cách mở cánh cửa sang giai đoạn tìm ý tưởng. Đó là lúc kỹ thuật "How Might We" (HMW) xuất hiện — được phổ biến bởi IDEO và Google. Đây là cách viết lại vấn đề thành một câu hỏi bắt đầu bằng "Làm thế nào để chúng ta có thể...".
Mỗi từ trong "How Might We" đều có dụng ý:
- How (Làm thế nào): giả định rằng có giải pháp, ta chỉ cần tìm ra.
- Might (có thể): hạ thấp áp lực — ta đang khám phá các khả năng, chưa cam kết. "Might" cho phép ý tưởng điên rồ được sống.
- We (chúng ta): đây là việc của cả nhóm, sáng tạo mang tính tập thể.
Goldilocks — không quá rộng, không quá hẹp
Một câu HMW tốt phải nằm ở "vùng vừa phải" (giống cô bé Goldilocks chọn bát cháo không quá nóng cũng không quá nguội):
- Quá rộng: "Làm thế nào để chúng ta tạo ra trải nghiệm mua sắm tốt hơn?" — không gợi mở được gì cụ thể, nó như một khẩu hiệu.
- Quá hẹp: "Làm thế nào để chúng ta đổi nút 'Mua' sang màu cam?" — đã chứa sẵn giải pháp, không còn chỗ cho sáng tạo.
- Vừa phải: "Làm thế nào để chúng ta giúp người dùng tin tưởng nhập thông tin thẻ ở bước cuối?" — đủ tập trung để hành động, đủ mở để brainstorm nhiều hướng.
Tình huống thực tế
Ví dụ 1 — Tiki và bài toán "giỏ hàng bị bỏ rơi"
Giả sử một sàn thương mại điện tử như Tiki phát hiện tỷ lệ bỏ giỏ hàng (cart abandonment) ở mức 68% trên mobile. Phản xạ đầu tiên của đội ngũ là đóng khung: "Nút thanh toán chưa đủ nổi bật, cần thiết kế lại trang giỏ hàng." Họ chi hai sprint để làm lại UI giỏ hàng — nút to hơn, màu nóng hơn. Kết quả: tỷ lệ bỏ giỏ chỉ giảm từ 68% xuống 66%. Gần như không nhúc nhích.
Khi quay lại làm research nghiêm túc — xem session recording và phỏng vấn 12 người dùng — đội ngũ phát hiện 70% người rời đi ngay tại bước nhập địa chỉ, vì form bắt nhập tay tỉnh/huyện/phường qua ba dropdown dài dằng dặc. Frame đúng phải là: "Người dùng nản lòng vì việc nhập địa chỉ giao hàng quá tốn công trên màn hình nhỏ." Câu HMW: "Làm thế nào để chúng ta giúp người dùng cung cấp địa chỉ giao hàng nhanh và ít sai sót nhất có thể?" Từ đó họ làm tính năng tự động gợi ý địa chỉ và lưu địa chỉ cũ — tỷ lệ bỏ giỏ giảm xuống còn 54%.
Bài học rút ra: Frame đầu tiên đến từ trực giác thường là triệu chứng. Đầu tư vào research trước khi đóng khung sẽ tiết kiệm hàng tháng làm sai hướng.
Ví dụ 2 — Grab và "tài xế từ chối cuốc xe"
Đây là một bài toán có thật trong ngành gọi xe Đông Nam Á. Khi Grab thấy nhiều tài xế hủy hoặc không nhận cuốc, frame ban đầu dễ rơi vào: "Tài xế lười, cần phạt nặng hơn để buộc họ nhận cuốc." Đây là một frame nguy hiểm vì nó đổ lỗi cho người dùng thay vì hiểu họ.
Nếu áp dụng "5 Whys": Tại sao tài xế từ chối? Vì điểm đón quá xa. Tại sao xa mà vẫn hiện ra? Vì thuật toán ưu tiên cuốc giá trị cao. Tại sao tài xế ngại đi xa? Vì quãng đường tới điểm đón không được trả tiền và dễ kẹt xe giờ cao điểm. Frame đúng trở thành: "Tài xế tránh những cuốc mà công sức bỏ ra để tới điểm đón không tương xứng với thu nhập." Câu HMW: "Làm thế nào để chúng ta giúp tài xế cảm thấy mỗi cuốc xe được đề xuất là xứng đáng để nhận?"
Từ frame này nảy ra nhiều hướng: hiển thị trước khoảng cách tới điểm đón, thưởng thêm cho cuốc xa, hoặc gom cuốc theo khu vực. Tất cả đều hướng tới sự công bằng cảm nhận được, chứ không phải trừng phạt.
Bài học rút ra: Một frame đổ lỗi cho người dùng ("họ lười", "họ ngu") gần như luôn là frame sai. Frame tốt luôn đặt người dùng vào vị trí một con người có lý do hợp lý.
Ví dụ 3 — Nền tảng học trực tuyến và "học viên không hoàn thành khóa học"
Hãy lấy chính bối cảnh gần gũi: một nền tảng học online ở Việt Nam thấy chỉ 23% học viên hoàn thành khóa học đã mua. Frame cám dỗ: "Cần thêm tính năng nhắc nhở, gửi email mỗi ngày." Nhưng nếu nhắc nhở dồn dập, có khi học viên còn khó chịu và bỏ hẳn.
Đội ngũ tổ chức một workshop framing. Họ viết nhiều câu HMW song song để khám phá nhiều góc:
- "Làm thế nào để chúng ta giúp học viên cảm thấy mỗi buổi học đều có tiến triển rõ ràng?"
- "Làm thế nào để chúng ta giúp học viên quay lại học sau khi đã gián đoạn vài ngày?"
- "Làm thế nào để chúng ta biến việc học thành một thói quen vừa sức?"
Bài học rút ra: Viết nhiều câu HMW cho cùng một vấn đề rồi chọn câu giàu tiềm năng nhất là một kỹ thuật mạnh. Đừng dừng ở câu HMW đầu tiên bạn nghĩ ra.
Hướng dẫn từng bước
Đây là quy trình thực hành tôi khuyên bạn áp dụng mỗi khi bắt đầu một bài toán thiết kế:
Bước 1 — Thu thập tín hiệu thô. Tập hợp mọi dữ liệu bạn có: insight từ phỏng vấn người dùng, số liệu analytics, phản hồi support, session recording. Đừng vội kết luận, chỉ ghi lại những gì quan sát được.
Bước 2 — Tách triệu chứng khỏi gốc rễ bằng 5 Whys. Viết triệu chứng ra giấy, rồi hỏi "tại sao" liên tiếp 3–5 lần. Dừng lại khi câu trả lời chạm tới một nhu cầu hoặc rào cản con người thực sự, không thể đào sâu thêm.
Bước 3 — Viết phát biểu vấn đề theo công thức. Dùng khung: "[Đối tượng người dùng] cần [nhu cầu] vì [insight/lý do], nhưng [rào cản hiện tại]." Ví dụ: "Học viên đi làm cần học vào buổi tối vì ban ngày bận, nhưng họ thường quá mệt để tập trung quá 15 phút."
Bước 4 — Kiểm tra frame có rơi vào solution space không. Đọc lại phát biểu: nếu nó chứa tên một tính năng cụ thể (nút, popup, email), bạn đã vô tình giả định giải pháp. Viết lại để chỉ mô tả vấn đề.
Bước 5 — Chuyển sang HMW. Viết ít nhất 3–5 câu "Làm thế nào để chúng ta có thể..." cho cùng một vấn đề, mỗi câu nhìn từ một góc khác (góc cảm xúc, góc chức năng, góc bối cảnh).
Bước 6 — Kiểm tra độ Goldilocks. Với mỗi câu HMW, hỏi: nó có quá rộng đến mức vô nghĩa không? Có quá hẹp đến mức đã chứa giải pháp không? Giữ lại những câu ở vùng vừa phải.
Bước 7 — Chọn 1–2 câu HMW làm "đề bài" cho giai đoạn ideation. Đây chính là cầu nối sang Bài 7 (Crazy 8s & Brainstorming) — bạn sẽ brainstorm dựa trên đúng câu HMW đã chọn.
Lỗi thường gặp & mẹo
Lỗi 1 — Đóng khung quanh giải pháp yêu thích của sếp. Rất phổ biến ở môi trường công ty Việt Nam: sếp bảo "làm cái chatbot đi". Nếu bạn frame thành "làm thế nào để chúng ta xây chatbot tốt", bạn đã khóa cứng giải pháp. Mẹo: lùi một bước, hỏi "chatbot để giải quyết vấn đề gì của người dùng?" rồi frame quanh vấn đề đó.
Lỗi 2 — Frame quá rộng để khỏi sai. Nhiều bạn viết HMW kiểu "làm thế nào để cải thiện trải nghiệm" cho an toàn. An toàn nhưng vô dụng. Mẹo: nếu câu HMW có thể áp dụng cho bất kỳ sản phẩm nào, nó quá rộng.
Lỗi 3 — Đổ lỗi cho người dùng trong frame. "Người dùng không chịu đọc hướng dẫn." Frame này khiến bạn ngừng tìm hiểu. Mẹo: luôn giả định người dùng có lý do hợp lý — viết lại thành "người dùng không tìm thấy thông tin họ cần đúng lúc cần".
Lỗi 4 — Chỉ viết một câu HMW rồi lao vào vẽ. Câu HMW đầu tiên hiếm khi là câu tốt nhất. Mẹo: ép bản thân viết tối thiểu 5 câu trước khi chọn.
Mẹo nâng cao — Cặp đôi "amplify/remove". Với một insight, thử viết hai dạng HMW đối nghịch: một dạng khuếch đại điều tốt ("làm thế nào để chúng ta nhân rộng cảm giác hào hứng khi học xong bài đầu tiên?") và một dạng loại bỏ điều xấu ("làm thế nào để chúng ta xóa bỏ cảm giác choáng ngợp khi mới vào khóa học?"). Hai góc này thường cho ra ý tưởng rất khác nhau.
Bài tập thực hành
Hãy chọn một sản phẩm bạn dùng hằng ngày (ví dụ: ứng dụng ngân hàng, app đặt đồ ăn, hoặc chính nền tảng học này) và làm theo:
- Quan sát: Ghi lại một khoảnh khắc bạn thấy khó chịu hoặc bối rối khi dùng sản phẩm đó. Mô tả bối cảnh cụ thể: bạn đang làm gì, muốn gì, vướng ở đâu.
- Đào gốc: Áp dụng 5 Whys cho khó chịu đó. Viết ra đủ 5 câu hỏi "tại sao" và câu trả lời.
- Viết phát biểu vấn đề: Dùng công thức "[Đối tượng] cần [nhu cầu] vì [lý do], nhưng [rào cản]". Kiểm tra xem nó có chứa giải pháp giấu mặt không — nếu có, viết lại.
- Sinh 5 câu HMW: Từ phát biểu vấn đề, viết ít nhất năm câu "Làm thế nào để chúng ta có thể...", mỗi câu nhìn từ một góc khác nhau.
- Chấm điểm Goldilocks: Với mỗi câu, đánh dấu "quá rộng", "quá hẹp", hay "vừa phải". Khoanh tròn câu vừa phải nhất.
Tóm tắt
Problem Framing là kỹ năng phân biệt giữa designer nghiệp dư và chuyên nghiệp. Hãy nhớ những điểm cốt lõi:
- Đóng khung vấn đề quyết định mọi thứ phía sau. Giải pháp đúng cho sai vấn đề là lãng phí lớn nhất trong thiết kế.
- Luôn phân biệt triệu chứng và gốc rễ. Dùng 5 Whys để đào xuống tới nhu cầu con người thật sự.
- Tách bạch problem space và solution space. Khi frame vấn đề, tuyệt đối không giả định giải pháp.
- "How Might We" biến vấn đề thành lời mời sáng tạo — "How" giả định có lời giải, "Might" cho phép thử nghiệm, "We" là việc của cả nhóm.
- Nhắm vùng Goldilocks: không quá rộng đến mức vô nghĩa, không quá hẹp đến mức chứa sẵn giải pháp.
- Viết nhiều câu HMW rồi chọn, đừng dừng ở câu đầu tiên. Và đừng bao giờ đổ lỗi cho người dùng trong frame.