Cùng TELOS Academy tìm hiểu về Problem Statement trong tư duy thiết kế và mục tiêu cuối cùng của việc xác định vấn đề trong quá trình tư duy thiết kế là gì trong bài viết sau đây!
Problem Statement trong tư duy thiết kế là gì?
Problem Statement (Tuyên bố vấn đề) là một mô tả ngắn gọn, rõ ràng và cụ thể về một vấn đề mà người dùng đang gặp phải, cần được giải quyết.
Nó đóng vai trò là kim chỉ nam, giúp đội ngũ tập trung vào người dùng (User), nhu cầu (Need), và mục tiêu (Goal) cần đạt được, trước khi bắt tay vào giải pháp (Solution).
🎯 Vai trò trong Product Design
Trong lĩnh vực Product Design (Thiết kế Sản phẩm), Problem Statement là bước đầu tiên và quan trọng nhất trong quy trình Design Thinking (Tư duy Thiết kế) hoặc User-Centered Design (Thiết kế lấy người dùng làm trung tâm). Nó giúp trả lời câu hỏi: “Chúng ta đang cố gắng giải quyết vấn đề gì, cho ai, và tại sao?”
Một Problem Statement hiệu quả trong Product Design thường tập trung vào:
- Ai đang gặp vấn đề? (A specific user/persona).
- Vấn đề thực sự là gì? (The pain point/frustration).
- Họ muốn đạt được điều gì? (The desired outcome/goal).
Cấu trúc Problem Statement phổ biến (Dưới dạng “How Might We”)
Trong Product Design, Problem Statement thường được chuyển hóa thành các câu hỏi “Làm thế nào chúng ta có thể…” (How Might We – HMW) để khuyến khích tư duy sáng tạo về giải pháp.
Tuy nhiên, dạng cơ bản nhất, tập trung vào vấn đề, thường có cấu trúc như sau:
[Tên người dùng/Đối tượng] cần [Nhu cầu của họ] bởi vì [Lý do hoặc sự thất vọng hiện tại].
Ví dụ: Sinh viên năm nhất cần một cách để dễ dàng tìm kiếm sách giáo trình cũ bởi vì việc mua sách mới quá đắt và tốn thời gian.
Problem Statement còn tồn tại ở lĩnh vực khác không?
CÓ, Problem Statement là một khái niệm nền tảng và tồn tại mạnh mẽ ở rất nhiều lĩnh vực khác nhau, đặc biệt là những nơi cần giải quyết vấn đề, đưa ra quyết định hoặc thực hiện nghiên cứu. Đôi khi người ta sẽ không gọi tên, hoặc có một thuật ngữ rõ ràng cho nó như cách các quy trình trong Product Design thể hiện, nhưng nó vẫn tồn tại như một tư duy.
| Lĩnh vực | Mục đích của Problem Statement | Ví dụ (ý tưởng) |
| Quản lý Dự án (Project Mgmt) | Xác định phạm vi và mục tiêu của dự án, đảm bảo mọi thành viên tập trung vào kết quả mong muốn. | Mức độ hoàn thành dự án A đã giảm 15% trong Q4 do quy trình phê duyệt tài liệu chậm trễ. |
| Nghiên cứu Khoa học | Thiết lập trọng tâm của nghiên cứu, nêu rõ khoảng trống kiến thức mà nghiên cứu sẽ lấp đầy. | Mối quan hệ giữa sự thay đổi khí hậu và tần suất các hiện tượng thời tiết cực đoan ở khu vực B chưa được xác định rõ ràng. |
| Kinh doanh/Chiến lược | Xác định thách thức kinh doanh hiện tại và dẫn dắt việc phát triển chiến lược hoặc sản phẩm mới. | Doanh thu từ khách hàng mới đã giảm 10% so với năm trước vì quy trình đăng ký sản phẩm quá phức tạp. |
| Kỹ thuật/CNTT | Xác định rõ lỗi hệ thống, sự cố kỹ thuật hoặc nhu cầu nâng cấp cần được giải quyết. | Hệ thống máy chủ hiện tại không thể đáp ứng được 500 yêu cầu/giây, dẫn đến tình trạng treo máy trong giờ cao điểm. |
Tóm lại: Dù ở lĩnh vực nào, Problem Statement vẫn giữ nguyên chức năng cốt lõi là định hình rõ vấn đề, giúp quá trình tìm kiếm giải pháp trở nên có mục tiêu và hiệu quả hơn.
Vai trò then chốt của Problem Statement
Problem Statement không chỉ là một câu mô tả, mà nó là bản tuyên ngôn định hình toàn bộ quá trình giải quyết vấn đề. Vai trò của nó bao gồm:
1. Thiết lập sự Đồng thuận và Tập trung (Alignment)
- Chỉ dẫn: Nó là kim chỉ nam, đảm bảo rằng mọi thành viên trong đội ngũ (Designers, Engineers, Product Managers, Marketing) đều hiểu và đồng ý về vấn đề cốt lõi đang được giải quyết.
- Ngăn chặn lan man lạc đề (Scope Creep): Nó giúp đội ngũ tránh bị phân tán bởi các giải pháp hấp dẫn nhưng không giải quyết được vấn đề ban đầu. Bất kỳ tính năng hoặc ý tưởng nào được đề xuất phải phục vụ cho Problem Statement này.
2. Làm Cơ sở Đánh giá (Evaluation Foundation)
- Đo lường Thành công: Problem Statement định nghĩa trạng thái mong muốn (Desired State). Mọi giải pháp được tạo ra sẽ được đánh giá dựa trên mức độ nó giúp người dùng chuyển từ trạng thái hiện tại (Current State) sang trạng thái mong muốn đó.
- Ưu tiên: Nó giúp đội ngũ ưu tiên các vấn đề nào cần được giải quyết trước. Vấn đề nào có Problem Statement rõ ràng và ảnh hưởng lớn nhất đến người dùng sẽ được ưu tiên.
3. Khởi tạo Sáng tạo (Inspiration for Ideation)
- Nó không đưa ra giải pháp, mà mở ra không gian cho giải pháp. Bằng cách tập trung vào nhu cầu của người dùng (chứ không phải cách làm), Problem Statement (thường được chuyển thành câu hỏi “How Might We”) thúc đẩy tư duy sáng tạo.
Problem Statement xuất hiện trong giai đoạn nào?
Trong quy trình Product Development (Phát triển Sản phẩm) hoặc Design Thinking, Problem Statement xuất hiện rất sớm, ngay sau giai đoạn nghiên cứu và khám phá:
Giai đoạn 1: Thấu hiểu (Empathize & Define)
- Thời điểm: Đây là nơi Problem Statement được khởi tạo.
- Hoạt động: Sau khi thực hiện nghiên cứu người dùng (phỏng vấn, khảo sát, quan sát), đội ngũ sẽ tổng hợp và phân tích dữ liệu để tìm ra các điểm đau (pain points) và nhu cầu chưa được đáp ứng.
- Vai trò: Problem Statement được hình thành ở giai đoạn Define (Xác định) để chưng cất tất cả những hiểu biết sâu sắc (insights) này thành một tuyên bố duy nhất, có thể hành động được.
Giai đoạn 2: Phát triển Ý tưởng (Ideate)
- Thời điểm: Problem Statement được sử dụng để bắt đầu.
- Hoạt động: Problem Statement thường được chuyển thành các câu hỏi “Làm thế nào chúng ta có thể…” (How Might We).
- Vai trò: Những câu hỏi này giúp kích thích các buổi brainstorming (động não) để tạo ra nhiều giải pháp khả thi nhất.
Giai đoạn 3: Nguyên mẫu và Thử nghiệm (Prototype & Test)
- Thời điểm: Problem Statement được dùng để đánh giá.
- Hoạt động: Khi thử nghiệm nguyên mẫu (prototype) với người dùng, đội ngũ sẽ kiểm tra xem liệu giải pháp đó có thực sự giải quyết được vấn đề đã nêu trong Problem Statement hay không.
- Vai trò: Nó là thước đo cuối cùng cho sự thành công của giải pháp.
Tìm hiểu thêm về Design Thinking và Design Thinking Framework!
Các Tài liệu liên quan chứa Problem Statement
Problem Statement không đứng độc lập mà là một phần thiết yếu của nhiều tài liệu quan trọng trong Product Design và Quản lý Sản phẩm:
| Tài liệu | Mô tả | Vị trí của Problem Statement |
| Product Brief/Project Charter | Tài liệu cấp cao xác định mục tiêu, phạm vi và lý do của dự án. | Ngay đầu tài liệu, để xác nhận mục tiêu kinh doanh và mục tiêu người dùng. |
| User Story/Job to be Done (JTBD) | Mô tả một tính năng từ góc độ người dùng. JTBD là một phiên bản mở rộng của Problem Statement. | Thường là cơ sở để viết User Story: As a [User], I want [Goal], so that [Reason]. |
| Design Specification | Đặc tả chi tiết về cách sản phẩm hoặc tính năng sẽ hoạt động. | Được tham chiếu xuyên suốt để đảm bảo các chi tiết thiết kế phục vụ việc giải quyết vấn đề. |
| Bản đồ Hành trình Người dùng (User Journey Map) | Phân tích các bước người dùng thực hiện. | Problem Statement thường được đặt ở giai đoạn “Pain Point” hoặc “Opportunity” trên bản đồ. |
| Tài liệu Nghiên cứu Người dùng (Research Document) | Báo cáo tổng hợp các phát hiện từ nghiên cứu. | Là phần kết luận cô đọng nhất của các Insights tìm được. |
Để hiểu thêm về hành trình và nghiên cứu người dùng, hãy xem thêm bài viết sau: User Flow: Dẫn Lối Người Dùng Trong Từng Tương Tác
Ví dụ về ứng dụng 5-Why’s để xác định Problem Statement
Giả sử chúng ta đang làm việc trong lĩnh vực E-commerce (Thương mại điện tử) và nhận thấy một vấn đề về hành vi người dùng.
Triệu chứng ban đầu (The Symptom)
Chúng ta bắt đầu với một quan sát cụ thể (thường là một chỉ số kinh doanh hoặc hành vi người dùng xấu): Quan sát: 60% người dùng thêm sản phẩm vào giỏ hàng trên ứng dụng di động nhưng lại không hoàn tất thanh toán.
Bắt đầu với câu hỏi “TẠI SAO?” 5 lần (5-Why’s?)
- Tại sao 60% người dùng thêm sản phẩm vào giỏ hàng nhưng không hoàn tất thanh toán?
Trả lời: Vì họ thường bị chuyển hướng ra khỏi ứng dụng để nhập thông tin thanh toán (ví dụ: OTP ngân hàng) và không quay lại.
- Tại sao người dùng bị chuyển hướng ra khỏi ứng dụng để nhập thông tin thanh toán?
Trả lời: Vì ứng dụng không lưu trữ hoặc không hỗ trợ thanh toán bằng một lần chạm (One-click Payment) hoặc các phương thức thanh toán phổ biến tại địa phương.
- Tại sao ứng dụng không hỗ trợ thanh toán bằng một lần chạm hoặc lưu trữ thông tin thẻ?
Trả lời: Vì người dùng ngại chia sẻ thông tin thẻ do thiếu niềm tin vào tính bảo mật của ứng dụng di động này so với các nền tảng lớn khác.
- Tại sao người dùng thiếu niềm tin vào tính bảo mật của ứng dụng này?
Trả lời: Vì giao diện thanh toán trông lỗi thời (Outdated UI), không có biểu tượng bảo mật rõ ràng (ví dụ: PCI DSS, SSL), và không có thông báo xác nhận về việc dữ liệu được bảo vệ.
- Tại sao giao diện trông lỗi thời và thiếu các yếu tố bảo mật trực quan?
Trả lời: Vì đội ngũ phát triển ban đầu đã ưu tiên tốc độ ra mắt (Time to Market) hơn là việc thiết kế trải nghiệm người dùng minh bạch và đáng tin cậy trong quá trình thanh toán.
Xác định
Sau khi đào sâu bằng 5 Whys, chúng ta đi đến vấn đề gốc rễ, đó là vấn đề về Niềm tin (Trust) và Trải nghiệm Bảo mật (Security Experience):
[Người dùng tiềm năng của chúng ta] cần [một quy trình thanh toán minh bạch, đáng tin cậy và không bị gián đoạn] bởi vì [họ cảm thấy lo lắng khi nhập thông tin cá nhân và tài chính vào một giao diện lỗi thời, điều này khiến họ bỏ giỏ hàng giữa chừng].
Chuyển đổi thành “How Might We” (HMW)
Để khởi động quá trình thiết kế giải pháp (Ideation), chúng ta chuyển Problem Statement trên thành câu hỏi HMW:
HMW: Làm thế nào chúng ta có thể thiết kế quy trình thanh toán để truyền tải ngay lập tức sự bảo mật và tính chuyên nghiệp, từ đó khuyến khích người dùng lưu thông tin thẻ và hoàn tất giao dịch một cách nhanh chóng?
Bây giờ, đội ngũ thiết kế và kỹ thuật sẽ tập trung vào việc giải quyết vấn đề niềm tin này, thay vì chỉ cố gắng thêm một nút “thanh toán nhanh” mà không giải quyết gốc rễ.
KẾT LUẬN
Problem Statement là tuyên bố cốt lõi, rõ ràng, trung lập về giải pháp, xác định ai đang gặp vấn đề gì và tại sao. Problem Statement là kim chỉ nam, đảm bảo sự đồng thuận và tập trung vào nhu cầu người dùng, làm cơ sở để đo lường thành công của giải pháp. Problem Statement sẽ xuất hiện sau giai đoạn nghiên cứu/phân tích (CJM) và là bước khởi đầu chính thức cho giai đoạn phát triển ý tưởng (Ideation)
Nếu bạn là một một UI/UX Designer, bạn sẽ nhận PS từ PM/UX Researcher và chuyển hóa nó thành câu hỏi “How Might We” (HMW) để bắt đầu quá trình thiết kế và động não. Designer sẽ dùng PS để đánh giá các wireframes/prototype, đảm bảo mọi lựa chọn thiết kế đều giải quyết trực tiếp vấn đề được nêu ra. Học thêm về các nội dung UI/UX qua các khóa học UI/UX của TELOS Academy!
