Đây là bài số 5 trong chuỗi bài “Design thinking cho sáng tạo & phát triển sản phẩm mới: Thấu cảm tạo đột phá” nhằm giúp bạn đọc hiểu rõ bản chất, giá trị cốt lõi và ứng dụng của Tư duy Thiết kế (Design Thinking) trong hành trình đổi mới và phát triển sản phẩm.
Sau khi đã “lặn ngụp” trong thế giới của người dùng ở giai đoạn Discover (Bài DT#03 & DT#04), thu thập dữ liệu qua quan sát, phỏng vấn, nhập vai và hệ thống hóa chúng bằng các công cụ như Empathy Map, Personas, Customer Journey Map, đội ngũ của bạn giờ đây đã có một sự thấu cảm sâu sắc hơn và vô số insight giá trị. Chúng ta đã hoàn thành nửa đầu tiên của “viên kim cương” thứ nhất trong mô hình Double Diamond – giai đoạn tư duy phân kỳ để khám phá.
Bây giờ là lúc thực hiện nửa còn lại của viên kim cương đó: Define (Xác định) – giai đoạn của tư duy hội tụ. Đây là bước cực kỳ quan trọng, nơi chúng ta cần chắt lọc tất cả những gì đã học được để xác định một cách rõ ràng, sắc bén vấn đề cốt lõi mà chúng ta sẽ tập trung giải quyết. Không quá lời khi nói rằng, giai đoạn Define chính là “trái tim” của cả quy trình Design Thinking, bởi lẽ việc xác định đúng vấn đề sẽ định hướng toàn bộ nỗ lực sáng tạo giải pháp sau này.
Như một câu nói nổi tiếng trong giới khởi nghiệp và đổi mới sáng tạo: “Hãy yêu vấn đề của bạn, chứ không phải giải pháp của bạn” (Fall in love with the problem, not the solution). Giai đoạn Define giúp chúng ta làm chính xác điều đó.
Tại sao Define lại quan trọng đến vậy?
Nhiều đội ngũ thường có xu hướng bỏ qua hoặc làm sơ sài giai đoạn Define và nhảy ngay vào việc nghĩ ý tưởng, xây dựng giải pháp. Điều này tiềm ẩn rất nhiều rủi ro:
- Giải quyết sai vấn đề: Nếu không xác định rõ ràng vấn đề cốt lõi dựa trên insight thực tế, rất có thể bạn đang cố gắng giải quyết một vấn đề không tồn tại, hoặc một vấn đề không thực sự quan trọng đối với người dùng. Kết quả là tạo ra một giải pháp dù tốt về mặt kỹ thuật cũng không được đón nhận (nhớ lại ví dụ về Amazon Fire Phone ở DT#01).
- Lãng phí nguồn lực: Việc phát triển các giải pháp cho một vấn đề không đúng trọng tâm sẽ gây lãng phí lớn về thời gian, tiền bạc và công sức của cả đội ngũ.
- Thiếu định hướng và sự tập trung: Khi vấn đề không rõ ràng, đội ngũ sẽ dễ bị lan man, mất phương hướng trong quá trình lên ý tưởng và phát triển. Mỗi người có thể hiểu vấn đề theo một cách khác nhau, dẫn đến sự thiếu nhất quán.
- Khó đo lường thành công: Nếu không biết rõ vấn đề cần giải quyết là gì, làm sao bạn có thể đánh giá được liệu giải pháp của mình có thực sự hiệu quả hay không?
Ngược lại, một vấn đề được xác định tốt sẽ hoạt động như một “ngọn hải đăng”, giúp:
- Tập trung nỗ lực: Hướng sự sáng tạo của cả đội vào một mục tiêu chung, rõ ràng.
- Tạo sự đồng thuận: Đảm bảo mọi người cùng hiểu và nhất trí về thách thức cần vượt qua.
- Truyền cảm hứng: Một vấn đề được định nghĩa hấp dẫn, nhấn mạnh vào nhu cầu con người có thể tạo động lực mạnh mẽ cho đội ngũ.
- Làm cơ sở đánh giá: Giúp xác định các tiêu chí để đánh giá các ý tưởng, giải pháp tiềm năng sau này.
Từ Insight đến Vấn đề Cốt lõi: Quá trình tổng hợp và hội tụ
Giai đoạn Define là một quá trình tổng hợp (synthesis) và hội tụ (convergence). Nó đòi hỏi đội ngũ phải xem xét lại tất cả các dữ liệu và insight đã thu thập ở giai đoạn Discover, sau đó phân tích, kết nối và chắt lọc để tìm ra bản chất thực sự của vấn đề.
Các hoạt động chính trong quá trình này thường bao gồm:
- Phân loại và nhóm các insight (Affinity Clustering): Đưa tất cả các ghi chú, trích dẫn, quan sát… lên một không gian chung (bảng trắng, công cụ online) và bắt đầu nhóm những điểm tương đồng lại với nhau để tìm ra các chủ đề (themes) hoặc các mẫu hình (patterns) chính.
- Xác định các “Nỗi đau” (Pain Points) và “Nhu cầu” (Needs) chính: Từ các nhóm insight, xác định những khó khăn, trở ngại lớn nhất mà người dùng đang gặp phải và những nhu cầu cốt lõi (cả chức năng và cảm xúc) chưa được đáp ứng.
- Ưu tiên hóa: Không phải tất cả các vấn đề hay nhu cầu đều quan trọng như nhau. Cần đánh giá xem vấn đề nào có tác động lớn nhất đến người dùng, vấn đề nào phù hợp nhất với mục tiêu và khả năng của tổ chức để tập trung giải quyết.
Quá trình này thường không dễ dàng, đòi hỏi sự tranh luận, phân tích sâu và khả năng nhìn ra mối liên kết giữa các điểm dữ liệu tưởng chừng rời rạc. Mục tiêu cuối cùng là đi đến một hoặc một vài phát biểu vấn đề cốt lõi, được diễn đạt một cách rõ ràng và tập trung vào người dùng.
Công cụ Định nghĩa Vấn đề: Problem Statement & Point of View (POV)
Để diễn đạt vấn đề cốt lõi một cách hiệu quả, có hai công cụ chính thường được sử dụng trong giai đoạn Define:
1. Tuyên bố Vấn đề (Problem Statement)
Đây là một câu hoặc một đoạn văn ngắn gọn, mô tả rõ ràng vấn đề mà bạn sẽ giải quyết. Một Problem Statement tốt thường bao gồm thông tin về người dùng, bối cảnh, vấn đề họ gặp phải và tại sao vấn đề đó lại quan trọng.
Tuy nhiên, một cách tiếp cận cụ thể và tập trung vào người dùng hơn, thường được ưa chuộng trong Design Thinking, là sử dụng Point of View (POV) Statement.
2. Phát biểu Quan điểm (Point of View – POV Statement)
POV là một công cụ mạnh mẽ giúp đóng khung vấn đề từ góc nhìn của người dùng cụ thể, dựa trên những nhu cầu và insight đã được khám phá. Nó không chỉ mô tả vấn đề mà còn gợi ý hướng giải quyết tiềm năng.
Cấu trúc kinh điển của một POV:
[User (Người dùng cụ thể, có mô tả)] + needs + [Need (Nhu cầu – thường là một động từ)] + because + [Insight (Sự thật ngầm hiểu/Lý do sâu sắc – điều mới mẻ, không hiển nhiên)]
Hãy phân tích từng thành phần:
- User (Người dùng): Cần cụ thể hóa người dùng mà bạn đang nhắm tới. Sử dụng thông tin từ Persona đã xây dựng ở giai đoạn trước là tốt nhất. Ví dụ: thay vì nói “người mua hàng online”, hãy nói “Chị Mai, kế toán viên bận rộn thường mua hàng online vào buổi tối”.
- Need (Nhu cầu): Đây không phải là giải pháp, mà là nhu cầu cốt lõi, mong muốn sâu xa của người dùng. Nó thường được diễn đạt bằng một động từ. Ví dụ: “cần tìm kiếm thông tin nhanh chóng”, “cần cảm thấy an tâm”, “cần tiết kiệm thời gian”. Tránh nêu giải pháp ở đây (ví dụ: “cần một cái nút bấm to hơn” – đây là giải pháp, nhu cầu có thể là “cần thao tác dễ dàng hơn”).
- Insight (Sự thật ngầm hiểu): Đây là phần quan trọng nhất, là kết quả của sự thấu cảm sâu sắc. Nó giải thích tại sao nhu cầu kia lại tồn tại, hé lộ một sự thật không ngờ tới hoặc một mâu thuẫn trong hành vi/suy nghĩ của người dùng. Insight tốt thường gây ngạc nhiên và tạo cảm hứng.
Ví dụ về xây dựng POV (Dựa trên Persona “Chị Mai” từ bài DT#04):
- User: Chị Mai, kế toán viên 30 tuổi, bận rộn, thường mua sắm online sau giờ làm.
- Nghiên cứu cho thấy (Insight): Chị rất sợ mua phải hàng kém chất lượng vì không có thời gian và ngại quy trình đổi trả phức tạp, dù chị vẫn muốn mua được đồ tốt với giá hợp lý. Chị thường dành nhiều thời gian đọc review có hình ảnh thật để giảm thiểu rủi ro.
- Need: Nhu cầu cốt lõi không chỉ là “mua hàng”, mà là “đánh giá nhanh chóng và đáng tin cậy về chất lượng sản phẩm trước khi quyết định mua”.
- POV hoàn chỉnh: “Chị Mai (kế toán viên bận rộn hay mua hàng online) cần một cách để đánh giá nhanh chóng và đáng tin cậy về chất lượng/uy tín sản phẩm bởi vì chị có rất ít thời gian và cực kỳ e ngại rủi ro mua phải hàng kém chất lượng dẫn đến việc đổi trả phiền phức.”
Một POV tốt sẽ:
- Tập trung vào người dùng cụ thể.
- Xác định đúng nhu cầu cốt lõi (không phải giải pháp).
- Dựa trên insight sâu sắc, có tính bất ngờ.
- Đủ hẹp để có thể hành động, đủ rộng để không giới hạn sự sáng tạo.
Mở ra Cơ hội Sáng tạo: Câu hỏi “How Might We…?” (HMW)
Sau khi đã có một POV sắc bén, bước tiếp theo là biến nó thành những câu hỏi khơi gợi sự sáng tạo, tạo đà cho giai đoạn Lên ý tưởng (Ideate). Công cụ mạnh mẽ cho việc này là các câu hỏi “How Might We…?” (HMW) – “Làm thế nào chúng ta có thể…?”.
HMW giúp tái định hình POV (vốn mô tả một vấn đề) thành một câu hỏi mở về cơ hội. Nó tạo ra một tâm thế tích cực, hướng về giải pháp và khuyến khích nhiều ý tưởng khác nhau.
Cách tạo câu hỏi HMW từ POV:
- Bắt đầu bằng “How Might We…” hoặc “Làm thế nào chúng ta có thể…”: Cụm từ này tạo cảm giác lạc quan và khả thi.
- Tập trung vào User & Need trong POV: Ai là người chúng ta muốn giúp? Nhu cầu của họ là gì?
- Khai thác Insight: Làm thế nào để giải quyết cái “bởi vì” trong POV?
- Giữ câu hỏi đủ rộng: Đủ để không giới hạn ở một giải pháp duy nhất, nhưng không quá chung chung.
- Tránh nêu giải pháp trong câu hỏi: Ví dụ, thay vì hỏi “HMW tạo ra nút đánh giá uy tín?”, hãy hỏi “HMW giúp người dùng đánh giá uy tín nhanh chóng?”.
Ví dụ tạo HMW từ POV của Chị Mai:
POV: “Chị Mai (kế toán viên bận rộn hay mua hàng online) cần một cách để đánh giá nhanh chóng và đáng tin cậy về chất lượng/uy tín sản phẩm bởi vì chị có rất ít thời gian và cực kỳ e ngại rủi ro mua phải hàng kém chất lượng dẫn đến việc đổi trả phiền phức.”
Các câu hỏi HMW có thể tạo ra:
- Làm thế nào chúng ta có thể giúp Chị Mai đánh giá chất lượng sản phẩm mà không cần đọc quá nhiều review?
- Làm thế nào chúng ta có thể tăng cường sự tin cậy vào thông tin sản phẩm/shop cho Chị Mai?
- Làm thế nào chúng ta có thể giúp Chị Mai cảm thấy an tâm hơn khi mua hàng online?
- Làm thế nào chúng ta có thể giảm thiểu rủi ro mua phải hàng kém chất lượng cho người bận rộn?
- Làm thế nào chúng ta có thể làm cho quy trình đổi trả trở nên đơn giản và ít tốn thời gian nhất cho Chị Mai?
- Làm thế nào chúng ta có thể tận dụng các review có hình ảnh để giúp Chị Mai ra quyết định nhanh hơn?
Bạn có thể thấy, từ một POV, chúng ta có thể tạo ra nhiều câu hỏi HMW khác nhau, mỗi câu hỏi mở ra một hướng tiềm năng để khám phá giải pháp trong giai đoạn Develop.
Ví dụ thực tế về sức mạnh của Define
- Airbnb: Ban đầu, những người sáng lập có thể đã định nghĩa vấn đề là “Làm thế nào chúng ta có thể kiếm tiền từ việc cho thuê phòng/đệm hơi?”. Nhưng khi thấu cảm người dùng (cả chủ nhà và khách thuê), họ nhận ra vấn đề cốt lõi là thiếu sự tin tưởng. POV có thể là: “Người đi du lịch muốn tiết kiệm chi phí (User) cần một cách để cảm thấy an toàn và tin tưởng khi ở nhà người lạ (Need) bởi vì họ lo ngại về sự an toàn cá nhân và không chắc chắn về chất lượng chỗ ở (Insight)”. Từ đó, các câu hỏi HMW dẫn đến các giải pháp như hệ thống đánh giá hai chiều, hồ sơ người dùng chi tiết, ảnh chụp chuyên nghiệp, bảo hiểm cho chủ nhà…
- Ngân hàng Việt Nam & Tiểu thương (Ví dụ giả định): Như đã nêu ở bài DT#01, POV có thể là: “Tiểu thương chợ truyền thống (User) cần một cách [tiếp cận vốn nhanh chóng, linh hoạt, thủ tục đơn giản] (Need) vì [họ thường gặp khó khăn với quy trình vay phức tạp của ngân hàng và không có tài sản thế chấp theo yêu cầu truyền thống] (Insight).” Các câu hỏi HMW như “HMW giúp tiểu thương chứng minh uy tín tín dụng phi truyền thống?” hay “HMW thiết kế gói vay siêu nhỏ với quy trình thẩm định tối giản?” sẽ mở đường cho những giải pháp tài chính sáng tạo, phù hợp hơn với đối tượng này thay vì áp dụng cứng nhắc các sản phẩm vay tiêu chuẩn.
Key Takeaway: Xác định đúng vấn đề là một nửa của giải pháp
Giai đoạn Define trong Double Diamond là bước hội tụ quan trọng, nơi sự thấu cảm sâu sắc từ giai đoạn Discover được chắt lọc thành một định nghĩa vấn đề rõ ràng, tập trung vào người dùng và khơi gợi sự sáng tạo.
Việc xây dựng một Problem Statement hoặc, tốt hơn nữa, một POV Statement mạnh mẽ và sau đó chuyển hóa nó thành các câu hỏi HMW kích thích tư duy, chính là cách bạn đặt nền móng vững chắc cho việc tìm kiếm giải pháp hiệu quả. Nó đảm bảo rằng cả đội ngũ đang cùng nhau nhắm vào đúng mục tiêu, giải quyết đúng vấn đề cho đúng người dùng.
Hãy đầu tư thời gian và trí tuệ xứng đáng cho giai đoạn Define này, bởi lẽ, như người ta thường nói, một vấn đề được xác định tốt đã chứa đựng một nửa giải pháp bên trong nó.
