Vì sao chủ đề quan trọng
Tới đây bạn có 12 pain point, có nhu cầu, có điểm bằng chứng. Nhưng một pain point như "P1 xếp hàng 20 đến 25 phút" vẫn chỉ là một nhãn. Khi bạn đưa nó cho người thiết kế hay lập trình, mỗi người sẽ đọc ra một vấn đề khác: người nghĩ cần làm hàng nhanh hơn, người nghĩ cần bỏ hàng đi, người nghĩ cần app đặt trước. Cái thiếu là một câu nói rõ ai, cần gì, trong hoàn cảnh nào, bị chặn bởi điều gì, và hậu quả ra sao.
Câu đó gọi là phát biểu vấn đề (problem statement). Từ đó, bạn có thêm hai công cụ: câu việc cần làm (job statement, theo lối nghĩ Jobs-To-Be-Done) để thấy vấn đề từ động cơ của người dùng, và câu hỏi How Might We, tức "làm thế nào để...", để mở vấn đề thành không gian cho ý tưởng.
Điều khó nhất của bài này nghe rất đơn giản: không được để giải pháp lọt vào phát biểu vấn đề. Một khi câu vấn đề có chữ "app", "đặt trước" hay "thông báo", cuộc thảo luận về thiết kế đã kết thúc trước khi bắt đầu.
Bài này nhận vào: pain point, nhu cầu và điểm bằng chứng từ bài 3 và bài 4. Bài này giao ra: problem statement cho các pain point ưu tiên, một câu việc cần làm cho Minh Anh, và danh sách câu hỏi How Might We có độ rộng vừa phải. Đó là đầu vào cho khóa Persona & User Journey dựa trên bằng chứng.
Bức tranh lớn
Ba dạng câu, mỗi dạng một vai:
- Problem statement mô tả vấn đề, đứng trên bằng chứng. Nó dùng để thống nhất với sponsor và đội: chúng ta đang giải đúng chuyện này.
- Câu việc cần làm mô tả điều người dùng đang cố đạt được trong một hoàn cảnh. Nó giúp bạn thấy đối thủ thật của sản phẩm không chỉ là app khác, mà còn là việc nhịn bữa, là quầy bánh mì.
- How Might We biến vấn đề thành câu hỏi mở. Nó dùng để bắt đầu nghĩ giải pháp ở khóa sau.
Problem statement
Ai, cần gì, khi nào hoặc trong hoàn cảnh nào,
nhưng trở ngại gì, dẫn tới hậu quả gì.
Bằng chứng: nguồn và số liệu.
Câu việc cần làm
Khi tôi ở hoàn cảnh..., tôi muốn..., để tôi có thể...
How Might We
Làm thế nào để ai đó đạt kết quả trong ràng buộc,
không nêu cách làm.
flowchart TD
A[Pain point có bằng chứng] --> B[Problem statement]
B --> C{Có tên giải pháp trong câu?}
C -->|Có| B
C -->|Không| D[Câu việc cần làm]
D --> E[Câu hỏi How Might We]
E --> F{Độ rộng vừa phải?}
F -->|Quá rộng hoặc quá hẹp| E
F -->|Vừa| G[Giao cho khóa Persona và Journey]Ví dụ chi tiết
Problem statement cho P1, cách sai:
"Sinh viên cần một app đặt cơm trước để không phải xếp hàng."
Câu này có giải pháp ở giữa. Nó cũng nói "sinh viên" chung chung, trong khi bằng chứng chỉ về nhóm có lịch sát giờ, và không có hậu quả hay số liệu nào.
Cách đúng:
"Sinh viên tan lớp 11:30 và có lớp tiếp lúc 12:45 cần có bữa trưa trước giờ vào lớp, nhưng hàng ở quầy cơm mất 20 đến 25 phút trong khoảng 11:35 tới 12:15, nên nhiều em bỏ bữa. Bằng chứng: Minh Anh 'Thứ Hai em hay nhịn trưa, vì xếp hàng xong là trễ giờ vào lớp', khoảng 25 email phàn nàn mỗi tháng gửi Phòng Quản trị – Đời sống, nhóm đo trực tiếp thời gian hàng."
Đọc câu này, người thiết kế có thể nghĩ tới đặt trước, nhưng cũng có thể nghĩ tới một hàng riêng bán suất sẵn, hay một khung giờ nhận lệch cao điểm. Câu vấn đề không chọn hộ họ.
Problem statement cho P3:
"Sinh viên có dị ứng thực phẩm cần biết chắc món có chất gây dị ứng hay không trước khi mua, nhưng thực đơn chỉ ghi tên món trên bảng trắng và người bán cũng không nắm chắc thành phần, nên các em phải hỏi mỗi lần mà vẫn không chắc. Bằng chứng: Thảo Vy, dị ứng đậu phộng, có cờ an toàn ở bài 4; một nguồn, cần thêm."
Problem statement cho P6, góc nhìn của bếp:
"Bếp quầy cơm cần biết gần đúng số suất trước khi nấu mẻ đầu lúc 10:30, nhưng hiện không có tín hiệu nhu cầu nào trước giờ bán, nên quầy cơm vừa bỏ khoảng 40 suất mỗi ngày, vừa có hôm hết món lúc 12:30. Bằng chứng: Cô Hạnh, số liệu bỏ suất, quan sát."
Chú ý: P6 có chủ thể là bếp, không phải sinh viên. Problem statement không phải lúc nào cũng nói về người dùng cuối.
Câu việc cần làm cho Minh Anh:
"Khi tôi tan lớp lúc 11:30 mà 12:45 đã phải vào lớp tiếp, tôi muốn có một bữa trưa đủ no trong tay thật nhanh, để vào lớp đúng giờ mà không phải nhịn đói."
Hãy xem câu này làm được gì mà problem statement không làm. Nó cho thấy những thứ Minh Anh đang "thuê" để làm việc này hôm nay: đứng hàng, nhịn, hoặc một lựa chọn nhanh hơn ở quầy khác. Nó cũng có một tầng cảm xúc: không muốn trễ lớp. Và nó gợi ý ràng buộc thật, nhớ câu "Em không muốn trả tiền trước, lỡ ra tới nơi hết món thì sao": giải pháp nhanh mà làm cô mất tiền thì cô sẽ không thuê. Nếu bạn muốn đi sâu vào JTBD, khóa Customer Discovery & Jobs-To-Be-Done dạy kỹ hơn; ở đây bạn chỉ cần một câu viết đúng khung.
Câu hỏi How Might We, ba độ rộng:
| Pain point | Quá rộng | Vừa phải | Quá hẹp |
|---|---|---|---|
| P1 | Làm thế nào để sinh viên ăn trưa tốt hơn? | Làm thế nào để sinh viên có lớp 12:45 có bữa trưa mà không phải đứng hàng giờ cao điểm? | Làm thế nào để thêm nút đặt trước vào app? |
| P2 | Làm thế nào để căng tin không bao giờ hết món? | Làm thế nào để người tới sau 12:30 biết món nào còn trước khi đi tới căng tin? | Làm thế nào để gửi thông báo đẩy khi hết món mặn? |
| P3 | Làm thế nào để ăn uống an toàn hơn? | Làm thế nào để sinh viên dị ứng biết chắc thành phần mà không phải hỏi người bán? | Làm thế nào để có bộ lọc đậu phộng? |
| P6 | Làm thế nào để căng tin có lãi hơn? | Làm thế nào để bếp biết gần đúng số suất trước mẻ 10:30? | Làm thế nào để bếp xem đơn trên điện thoại? |
Lộ trình từng bước
- Chọn các pain point ưu tiên từ bảng điểm bài 4, cộng mọi pain point có cờ an toàn.
- Với mỗi pain point, viết problem statement theo khung: ai, cần gì, hoàn cảnh, trở ngại, hậu quả, bằng chứng.
- Đọc lại câu và gạch mọi danh từ chỉ thứ để xây. Viết lại cho tới khi không còn.
- Thu hẹp "ai" theo bằng chứng. Bằng chứng nói về sinh viên có lớp 12:45 thì đừng viết "sinh viên".
- Viết một câu việc cần làm cho người dùng chính của mỗi chủ đề, bắt đầu với Minh Anh.
- Với mỗi problem statement, viết ba câu How Might We: một rộng, một hẹp, một vừa. Giữ câu vừa, ghi lại câu hẹp vào bãi đỗ ý tưởng.
- Đưa problem statement cho một người ngoài nhóm đọc, hỏi "theo bạn nên làm gì?" Nếu họ chỉ nghĩ ra đúng một giải pháp, câu của bạn vẫn đang dẫn dắt.
flowchart TD
A[Câu How Might We nháp] --> B{Có tên tính năng?}
B -->|Có| C[Quá hẹp, bỏ tính năng]
C --> A
B -->|Không| D{Có chủ thể và ràng buộc cụ thể?}
D -->|Không| E[Quá rộng, thêm ai và ràng buộc]
E --> A
D -->|Có| F[Nghĩ được ba ý tưởng khác nhau?]
F --> G[Giữ câu này]Thói quen & kỷ luật
| Thói quen | Tần suất | Kết quả mong đợi |
|---|---|---|
| Gạch danh từ giải pháp trong mỗi câu vấn đề | Mỗi câu | Problem statement không chọn sẵn giải pháp |
| Gắn bằng chứng vào cuối mỗi câu | Mỗi câu | Người đọc biết câu đứng trên cơ sở nào |
| Viết ba độ rộng rồi mới chọn | Mỗi câu How Might We | Câu hỏi đủ mở và đủ cụ thể |
| Thử câu với người ngoài nhóm | Mỗi tuần | Phát hiện câu đang dẫn dắt |
Cần luyện tập
Drill một: Viết problem statement cho P12 của Thảo Vy, sao cho không có chữ "app", "mã QR" hay "phiếu điện tử". Sau đó viết một câu How Might We vừa phải từ nó.
Drill hai: Viết câu việc cần làm cho Quốc Bảo, người làm thêm buổi sáng và tới căng tin khoảng 12:40. Câu của bạn khác câu của Minh Anh ở chỗ nào?
Drill ba: Lấy một đề bài đồ án môn học của bạn. Viết lại nó thành problem statement không có giải pháp. Đếm xem đề bài gốc có bao nhiêu từ chỉ giải pháp.
Checklist hành động tuần này
- [ ] Viết problem statement cho mọi pain point ưu tiên và mọi cờ an toàn
- [ ] Gạch sạch danh từ giải pháp trong từng câu
- [ ] Viết câu việc cần làm cho Minh Anh
- [ ] Viết ba độ rộng How Might We cho mỗi problem statement
- [ ] Ghi kết quả vào sheet problem statement của mẫu tổng hợp
Chỉ số cho cách làm
Các con số dưới đây đo cách nhóm làm bước này, không đo app có thành công hay không. Câu hỏi app có hiệu quả không, và làm gì tiếp, là việc của khóa Đo lường thành công.
| Loại chỉ số | Ví dụ | Vai trò |
|---|---|---|
| North Star | Số How Might We vừa phải sinh ra từ ba ý tưởng khác nhau trở lên | Vấn đề đủ mở để thiết kế |
| Chỉ số dẫn dắt | Tỉ lệ pain point ưu tiên đã có problem statement | Cho biết tiến độ |
| Chỉ số chất lượng | Số problem statement còn chứa tên giải pháp | Phát hiện giải pháp lọt vào |
| Chỉ số truy vết | Tỉ lệ câu có ghi nguồn bằng chứng | Câu không tách khỏi dữ liệu |
Dấu hiệu bạn đã thành thạo
- Bạn viết problem statement cho P1 mà không có chữ "app" hay "đặt trước".
- Bạn thấy ngay một câu How Might We là quá hẹp khi nó có tên tính năng.
- Câu việc cần làm của bạn có hoàn cảnh, động cơ và kết quả, không có sản phẩm.
- Một người ngoài đọc câu vấn đề của bạn và nghĩ ra nhiều hơn một cách giải.
Cạm bẫy thường gặp
| Cạm bẫy | Biểu hiện | Cách tránh |
|---|---|---|
| Giải pháp trong câu vấn đề | "Sinh viên cần app đặt cơm" | Gạch mọi danh từ chỉ thứ để xây |
| Chủ thể quá chung | "Người dùng gặp khó khăn" | Thu hẹp theo đúng bằng chứng |
| Thiếu hậu quả | Câu dừng ở "phải xếp hàng lâu" | Viết tiếp chuyện gì xảy ra vì thế |
| How Might We là tính năng trá hình | "Làm thế nào để thêm bộ lọc" | Viết lại theo kết quả cần đạt |
| JTBD thành persona | Câu việc cần làm tả tuổi, ngành | Viết hoàn cảnh và động cơ, không tả người |
Chốt lại
Problem statement nói rõ ai cần gì, bị chặn bởi điều gì, hậu quả ra sao, và đứng trên bằng chứng nào, không có giải pháp. Câu việc cần làm của Minh Anh cho thấy điều cô đang cố đạt và cái giá cô không chấp nhận. Câu How Might We vừa phải mở ra không gian ý tưởng mà vẫn bám ràng buộc thật. Còn một việc nữa trước khi bàn giao: những chỗ người dùng và stakeholder muốn điều ngược nhau. Bài 6 xử lý chúng.