Chương 1
Thấu cảm (Empathize)
"Hiểu người dùng, bối cảnh vận hành và ràng buộc kỹ thuật – nền tảng để thiết kế trạm sạc AC xe máy điện hiệu quả"
Mục tiêu học tập
- Phát triển tư duy lấy người dùng làm trung tâm (user-centered mindset) trong nghiên cứu và thiết kế.
- Thành thạo các phương pháp thu thập dữ liệu định tính: quan sát, phỏng vấn, trải nghiệm.
- Phân biệt giữa dữ liệu thực tế và ý kiến chủ quan; tuân thủ nguyên tắc đạo đức nghiên cứu.
- Tạo Persona, Empathy Map và Journey Map dựa trên dữ liệu thu thập được.
Kết quả chương trình
- Khả năng xác định nhu cầu cốt lõi, pain points và động lực của người dùng trong bối cảnh thực tế.
- Đầu vào chất lượng cho các giai đoạn tiếp theo (Define, Ideate) thông qua actionable insights.
- Kỹ năng thu thập và phân tích dữ liệu người dùng một cách có hệ thống.
- Persona: Hồ sơ chân dung người dùng điển hình, mô tả hoàn cảnh, mục tiêu, động lực và pain points.
- Empathy Map: Bản đồ cảm xúc, suy nghĩ, hành động, lời nói của người dùng trong bối cảnh thực tế.
- Journey Map: Sơ đồ hóa hành trình trải nghiệm của người dùng từ điểm bắt đầu đến kết thúc.
- Danh sách Insights: Tổng hợp các phát hiện quan trọng với nguồn dữ liệu rõ ràng và đề xuất hành động cụ thể.
Bài giảng: Thấu cảm (Empathize)
Khái niệm (What)
Thấu cảm là bước đầu tiên trong Design Thinking. Bạn sẽ tìm hiểu người dùng là ai, họ gặp vấn đề gì, cảm xúc ra sao. Đây là nền tảng để thiết kế sản phẩm/dịch vụ phù hợp thực tế.
Mục tiêu: Thu thập thông tin thực tế từ người dùng qua quan sát, trò chuyện, và trải nghiệm thử. Không chỉ nghe mà còn phải "cảm" được vấn đề của họ.
Nguyên tắc: Luôn phân biệt giữa sự thật và ý kiến cá nhân; tôn trọng quyền riêng tư và sự đồng ý của người tham gia.
Mindsets cốt lõi
Tư duy người mới (Beginner's mindset): Luôn đặt câu hỏi "Tại sao?" và không vội phán đoán.
Ví dụ: Khi thấy khách hàng gọi món lâu, hãy hỏi "Vì sao bạn phân vân khi chọn món?".
Ưu tiên giá trị con người (Focus on human values): Đặt nhu cầu, cảm xúc của người dùng lên hàng đầu.
Ví dụ: Nếu khách hàng lo lắng về chất lượng món uống, hãy lắng nghe và ghi nhận.
Hành động nhanh (Bias toward action): Đừng chỉ ngồi phân tích, hãy ra ngoài quan sát, thử nghiệm thực tế.
Ví dụ: Tự mình gọi món, ghi lại trải nghiệm chờ đợi và thanh toán.
Tổng quan 4 hoạt động:
- Lập kế hoạch nghiên cứu: xác định mục tiêu, người tham gia, sắp xếp lịch và xin phép.
- Quan sát hiện trường: xem người dùng thực sự làm gì; ghi lại sự thật kèm thời điểm.
- Phỏng vấn bán cấu trúc: trò chuyện mở để hiểu lý do và cảm xúc; tránh gợi ý câu trả lời.
- Nhập vai trải nghiệm: tự mình đi qua hành trình như người dùng để thấy điểm ma sát.
Chi tiết thực hành xem phần "Các hoạt động chính" ngay bên dưới.
Output chính:
- Persona: 1-2 chân dung người dùng chính với tên, hoàn cảnh, mục tiêu, nỗi đau cụ thể.
- Empathy Map: Bản đồ 4 vùng (Says, Thinks, Does, Feels) cho mỗi persona.
- Journey Map: Hành trình từ đầu đến cuối với các touchpoint, cảm xúc, pain points.
- Danh sách Insights: 5-10 phát hiện quan trọng, ưu tiên theo tác động và khả thi.
- Bảng ghi chú: Tất cả quan sát, phỏng vấn, trích dẫn có thể truy vết.
Tiêu chuẩn chất lượng:
- Rõ ràng: Persona có tên, hoàn cảnh cụ thể; Empathy Map đủ 4 vùng; Journey Map có timeline rõ ràng.
- Bám dữ liệu: Mọi insight có thể truy vết về ghi chú/quan sát thực tế.
- Sẵn sàng Define: Đủ insight để viết POV và HMW trong bước tiếp theo.
5 bước thực hiện:
- Lập kế hoạch nghiên cứu:
- Xác định mục tiêu (vd: hiểu pain points khi gọi món)
- Chọn đối tượng (5-7 người đại diện)
- Chuẩn bị công cụ (checklist, câu hỏi phỏng vấn)
- Sắp xếp lịch và xin phép
- Quan sát hiện trường:
- Xem người dùng thực sự làm gì (không chỉ hỏi)
- Ghi lại sự thật kèm thời điểm
- Chụp ảnh, ghi âm (có xin phép)
- Tập trung vào hành vi, không phán xét
- Phỏng vấn bán cấu trúc:
- Trò chuyện mở để hiểu lý do và cảm xúc
- Tránh gợi ý câu trả lời
- Hỏi về trải nghiệm gần nhất
- Ghi lại quote chính xác
- Nhập vai trải nghiệm:
- Tự mình đi qua hành trình như người dùng
- Ghi lại điểm ma sát và bất ngờ
- Chú ý cảm xúc và suy nghĩ
- So sánh với quan sát/phỏng vấn
- Tổng hợp và phân tích:
- Tách sự thật và ý kiến
- Gom nhóm theo chủ đề
- Rút ra insight quan trọng
- Tạo Persona, Empathy Map, Journey Map
Lưu ý: Luôn tôn trọng người tham gia, xin phép trước khi ghi hình/phỏng vấn, và bảo mật thông tin cá nhân.
Các lĩnh vực phù hợp:
Dịch vụ khách hàng
- Quán ăn, cà phê, nhà hàng
- Quầy dịch vụ (ngân hàng, bưu điện)
- Khách sạn, resort
- Bệnh viện, phòng khám
Quy trình nội bộ
- Quy trình phê duyệt, xử lý đơn hàng
- Quy trình đào tạo nhân viên
- Quy trình bảo trì, sửa chữa
- Quy trình quản lý kho, logistics
Sản phẩm số
- Ứng dụng di động, website
- Hệ thống quản lý nội bộ
- Dashboard, báo cáo
- Chatbot, AI assistant
Nguyên tắc chung: Empathize phù hợp cho mọi dự án cần hiểu người dùng sâu sắc trước khi thiết kế giải pháp. Đặc biệt hiệu quả khi có nhiều stakeholder với nhu cầu khác nhau.
Ví dụ: Cải tiến quy trình gọi món tại quán cà phê
Từ quan sát thực tế:
- Hành vi: Khách bước vào, chọn món, gọi món, chờ phục vụ, thanh toán, rời đi
- Cảm xúc: Lo lắng khi chờ đợi, bực bội khi thanh toán khó khăn
- Pain points: Không biết món đã chuẩn bị chưa, chờ lâu không ai thông báo
Insight chính rút ra:
- Nhu cầu cốt lõi không chỉ là gọi món, mà là độ chắc chắn về trạng thái món
- Cần bảng trạng thái đơn hàng rõ ràng và thông báo thời gian phục vụ
- Quy trình thanh toán cần minh bạch và thuận tiện
Phân tích:
- Insight sâu: Khách hàng cần kiểm soát thời gian để lên kế hoạch
- Giải pháp tiềm năng: Hệ thống thông báo trạng thái món theo thời gian thực
- Đo lường: Giảm thời gian chờ, tăng sự hài lòng khách hàng
Checklist thực hành:
✓ Cần có:
- Mục tiêu nghiên cứu rõ ràng (vd: giảm thời gian chờ)
- 5-7 người tham gia đại diện
- Ghi chú chi tiết với timestamp
- Xin phép trước khi ghi hình/phỏng vấn
- Persona, Empathy Map, Journey Map
- 5-10 insights có thể truy vết
✗ Tránh:
- Chỉ hỏi ý kiến, không quan sát
- Gợi ý câu trả lời
- Không xin phép người tham gia
- Ghi chú mơ hồ, không có bằng chứng
- Phán xét thay vì lắng nghe
- Bỏ qua cảm xúc và context
Rubric đánh giá:
Rõ ràng (3 điểm)
- Persona có tên, hoàn cảnh cụ thể
- Empathy Map đủ 4 vùng
- Journey Map có timeline rõ ràng
Bám dữ liệu (4 điểm)
- Mọi insight có thể truy vết
- Ghi chú chi tiết với bằng chứng
- Không suy diễn quá xa
Sẵn sàng Define (3 điểm)
- Đủ insight để viết POV
- Pain points rõ ràng
- Có thể chuyển sang Define
Tổng điểm: 10 điểm. Đạt từ 7 điểm trở lên là sẵn sàng sang Define.
Practice: Thực hiện 1 phiên Empathize hoàn chỉnh cho dự án thực tế. Kiểm tra theo checklist và rubric trên.
Các hoạt động chính
Gợi ý: Đọc nhanh mục 1–2 trong "Bài giảng" phía trên để nắm khái niệm.
Xác định mục tiêu nghiên cứu (ví dụ: giảm thời gian chờ gọi món), phạm vi quan sát (quán cà phê, giờ cao điểm), mẫu khách hàng (sinh viên, nhân viên văn phòng), và các ràng buộc thực tế.
- Mục tiêu: Ví dụ: Giảm thời gian chờ gọi món; tăng sự hài lòng khi thanh toán.
- Đối tượng: Khách hàng quán cà phê (tuyển 5–7 người/nhóm).
- Công cụ: Guide phỏng vấn, checklist quan sát, mẫu nhật ký, biểu mẫu ghi sự kiện (thời gian chờ, lỗi phục vụ, phản hồi khách).
Practice:
- Viết 1 Research Plan 1 trang cho quán cà phê
- Nêu KPI cần đo: thời gian chờ gọi món, tỉ lệ khách hài lòng
- Xác định 5-7 người tham gia với tiêu chí cụ thể
- Chuẩn bị checklist quan sát và câu hỏi phỏng vấn
Ghi nhận hành vi tại quán: cách khách chọn món, gọi món, chờ phục vụ, thanh toán. Lưu các trường hợp thất bại (gọi món nhầm, chờ lâu, thanh toán khó khăn).
Practice:
- Quan sát 60 phút tại quán cà phê
- Ghi ít nhất 10 quan sát có timestamp và bối cảnh
- Tập trung vào hành vi, cảm xúc, pain points
- Chụp ảnh minh hoạ (có xin phép)
Đào sâu quyết định và cảm xúc: vì sao chọn món này, vì sao nghi ngờ chất lượng, khi nào cần nhân viên hỗ trợ, kỳ vọng về quy trình gọi món và thanh toán.
Practice:
- Thực hiện 5 phỏng vấn bán cấu trúc với khách hàng
- 3 phỏng vấn với nhân viên phục vụ/quản lý
- Ghi lại quote chính xác và cảm xúc
- Hỏi về trải nghiệm gần nhất, không gợi ý
Đóng vai khách hàng: bước vào quán, chọn món, gọi món, chờ phục vụ, thanh toán và rời đi. Ghi lại ma sát và điểm mù (vd: không biết món đã chuẩn bị chưa, khó khăn khi thanh toán).
Practice:
- Viết nhật ký trải nghiệm 1 phiên gọi món end-to-end
- Ghi lại cảm xúc, suy nghĩ, điểm ma sát
- So sánh với quan sát/phỏng vấn trước đó
- Rút ra insight mới từ góc nhìn người dùng
Ví dụ thực tiễn: Giai đoạn Thấu cảm
Bảng tổng hợp lỗi thường gặp & misconduct (có đánh số, mức độ nghiêm trọng)
| # | Lỗi / Misconduct | Mức độ | Hậu quả | Cách khắc phục |
|---|---|---|---|---|
| 1 | Không xin phép/quyền riêng tư | H | Vi phạm đạo đức, mất lòng tin người dùng | Luôn xin phép trước khi ghi hình/phỏng vấn |
| 2 | Ghi âm/phỏng vấn mà không thông báo | H | Vi phạm pháp luật, có thể bị kiện | Luôn thông báo và xin phép trước khi ghi âm |
| 3 | Chỉnh sửa dữ liệu/phỏng vấn để "đẹp" hơn | H | Dữ liệu sai lệch, mất uy tín, ảnh hưởng quyết định | Giữ nguyên bản ghi, chỉ phân tích trên dữ liệu thực tế |
| 4 | Không bảo mật thông tin người dùng | H | Rò rỉ thông tin, mất lòng tin, vi phạm pháp luật | Ẩn danh dữ liệu, bảo mật file ghi chú |
| 5 | Không tuân thủ quy trình an toàn khi nhập vai | H | Nguy cơ tai nạn, ảnh hưởng sức khoẻ | Luôn phối hợp kỹ thuật/ops, tuân thủ quy trình an toàn |
| 6 | Chỉ hỏi ý kiến, không quan sát thực tế | H | Insight thiếu thực tiễn, giải pháp không phù hợp | Luôn kết hợp phỏng vấn với quan sát, nhập vai |
| 7 | Gợi ý câu trả lời cho người dùng | M | Dữ liệu bị lệch, không phản ánh đúng nhu cầu | Hỏi trung tính, hỏi về trải nghiệm gần nhất |
| 8 | Không phân biệt fact và opinion | M | Insight không rõ nguồn, khó truy vết | Ghi chú tách biệt dữ liệu thực tế và ý kiến |
| 9 | Chỉ chọn người quen/phỏng vấn "dễ" | M | Mẫu không đại diện, insight bị lệch | Chọn mẫu đa dạng, có tiêu chí rõ ràng |
| 10 | Phán xét, áp đặt quan điểm cá nhân lên người dùng | M | Insight bị bóp méo, mất khách quan | Lắng nghe, hỏi mở, không phán xét |
| 11 | Không ghi chú đầy đủ (bỏ qua cảm xúc, hành động nhỏ) | L | Bỏ sót insight quan trọng, khó phân tích | Ghi chú chi tiết, dùng checklist, chụp ảnh minh hoạ |
| 12 | Không kiểm tra lại dữ liệu trước khi phân tích | L | Dễ sai sót, insight không chính xác | Kiểm tra lại bản ghi, xác thực với đồng đội |
Tiếp nối hành trình Design Thinking
Sau khi hoàn thành Thấu cảm, hãy chuyển sang Xác định (Define) để chưng cất insight thành vấn đề cốt lõi, và Lên ý tưởng (Ideate) để phát triển giải pháp sáng tạo.
Bảng truy vết logic chi tiết:
| Quan sát/Phỏng vấn | Ghi chú | Insight | Persona/Map | Ưu tiên |
|---|---|---|---|---|
| Quan sát Lan gọi món (14:30, quán đông) |
"Lan nhìn đồng hồ 3 lần trong 5 phút" "Lan hỏi nhân viên: 'Bao lâu thì có món?'" |
Lo lắng về thời gian Lan cần kiểm soát thời gian để lên kế hoạch |
Persona: Lan - sinh viên Empathy Map: Feels - lo lắng |
Cao |
| Phỏng vấn Lan (15:00, sau khi nhận món) |
"Em không biết món đã chuẩn bị chưa nên cứ lo" "Ước gì có bảng trạng thái để biết" |
Thiếu thông tin trạng thái Lan cần biết rõ trạng thái món để yên tâm |
Empathy Map: Thinks - "Ước gì có bảng trạng thái" Journey Map: Touchpoint chờ đợi |
Cao |
| Quan sát thanh toán (15:15, quầy thanh toán) |
"Lan mất 3 phút tìm ví, đếm tiền" "Lan hỏi: 'Có chuyển khoản không?'" |
Khó khăn thanh toán Lan muốn thanh toán nhanh và thuận tiện |
Empathy Map: Does - tìm ví, đếm tiền Journey Map: Touchpoint thanh toán |
Trung bình |
| Nhập vai trải nghiệm (16:00, tự thực hiện) |
"Cảm thấy bất lực khi không biết món ở đâu" "Muốn có thông báo khi món sẵn sàng" |
Nhu cầu thông báo Khách hàng cần được thông báo khi món sẵn sàng |
Empathy Map: Feels - bất lực Journey Map: Pain point - thiếu thông báo |
Cao |
Lợi ích của bảng truy vết:
- Minh bạch: Mọi insight có thể truy vết về quan sát/phỏng vấn cụ thể
- Kiểm tra chất lượng: Đảm bảo insight bám dữ liệu thực tế
- Ưu tiên: Dựa trên tần suất và tác động để chọn insight quan trọng
- Chia sẻ: Dễ dàng trình bày cho stakeholder và team
Lan – Sinh viên, khách quen quán cà phê
"Em muốn gọi món nhanh, biết rõ khi nào món được phục vụ, và thanh toán dễ dàng để kịp giờ học."
- Hoàn cảnh: Lịch học dày, thường tranh thủ thời gian nghỉ để ghé quán.
- Mục tiêu: Gọi món nhanh, nhận thông báo khi món sẵn sàng, thanh toán tiện lợi.
- Nỗi đau: Chờ lâu không biết món đã chuẩn bị chưa, khó khăn khi thanh toán, lo bị trễ giờ học.
NÓI (Says)
"Cho em hỏi món này còn không?"
"Bao lâu thì có món?"
"Em muốn thanh toán nhanh để kịp giờ học."
SUY NGHĨ (Thinks)
"Nếu chờ lâu thì có kịp giờ học không?"
"Ước gì có bảng trạng thái món để biết khi nào xong."
HÀNH ĐỘNG (Does)
- Chọn món, hỏi nhân viên về thời gian phục vụ.
- Quan sát quầy để biết món đã chuẩn bị chưa.
- Chuẩn bị tiền/chuyển khoản trước để thanh toán nhanh.
CẢM THẤY (Feels)
Tiêu cực: Lo lắng, sốt ruột, bực bội khi chờ lâu hoặc thanh toán khó.
Tích cực: Yên tâm khi biết rõ trạng thái món và thanh toán thuận tiện.
Nhu cầu cốt lõi không chỉ là gọi món, mà là độ chắc chắn về trạng thái món (đang chuẩn bị/xong/chờ), thời gian phục vụ rõ ràng và thanh toán thuận tiện, giúp giảm lo lắng và tăng sự hài lòng.
Bước vào quán → Chọn món → Gọi món → Chờ phục vụ (quan sát trạng thái món) → Nhận món → Thanh toán → Rời quán. Điểm ma sát: không biết món đã chuẩn bị chưa, chờ lâu không ai thông báo, thanh toán phức tạp.
Chương 2
Xác định (Define)
"Chưng cất dữ liệu thành vấn đề cốt lõi có thể hành động, cân bằng nhu cầu người dùng và ràng buộc kỹ thuật/bus"
Mục tiêu học tập
- Hiểu cách phân tích và tổng hợp dữ liệu từ Empathize thành vấn đề cốt lõi có thể hành động.
- Thực hành Affinity Diagramming để gom nhóm ghi chú và tìm chủ đề lặp lại.
- Viết POV (Point of View) rõ ràng theo công thức USER–NEED–INSIGHT.
- Chuyển POV thành HMW (How Might We) đủ mở để sáng tạo, đủ hẹp để hành động.
- Ưu tiên vấn đề theo tác động và tính khả thi.
Kết quả chương trình
- 3–5 chủ đề từ Affinity với tên rõ ràng và bằng chứng cụ thể.
- 1–3 POV tốt, bám dữ liệu thực tế, không "nhúng" giải pháp.
- 3–5 HMW từ 1 POV ưu tiên, sẵn sàng cho Ideate.
- Bảng truy vết logic: Ghi chú → Chủ đề → POV → HMW.
- Affinity Diagram: Bảng chủ đề từ ghi chú Empathize, có tên rõ ràng và bằng chứng cụ thể.
- POV: Phát biểu quan điểm theo công thức USER–NEED–INSIGHT, bám dữ liệu thực tế.
- HMW: Câu hỏi mở để ideate, đủ cụ thể để hành động, không gài sẵn giải pháp.
- Bảng truy vết logic: Logic từ ghi chú → chủ đề → POV → HMW để kiểm tra và minh bạch.
Bài giảng: Xác định (Define)
Khái niệm (What)
Xác định (Define) là chưng cất dữ liệu từ Thấu cảm thành vấn đề cốt lõi có thể hành động.
Mindsets
- Rõ ràng: Diễn đạt ngắn gọn, tránh mơ hồ.
- Bám dữ liệu: Mỗi kết luận phải truy vết về ghi chú/quan sát.
- Chưa nhảy sang giải pháp: Tách bạch "vấn đề" và "giải pháp".
Output chính:
- Danh sách chủ đề (từ Affinity): 3–5 chủ đề có tên rõ ràng, mỗi chủ đề gom 5–8 ghi chú tương đồng.
- 01–03 POV tốt: Bám dữ liệu thực tế, không "nhúng" giải pháp, có thể truy vết về ghi chú/quan sát.
- 03–05 HMW từ 1 POV: Đủ mở để sáng tạo, đủ hẹp để hành động, không gài sẵn giải pháp.
- Bảng truy vết: Ghi chú → Chủ đề → POV → HMW (để kiểm tra logic và minh bạch).
Tiêu chuẩn chất lượng:
- Rõ ràng: POV/HMW dễ hiểu, không mơ hồ, có thể dùng ngay cho Ideate.
- Bám dữ liệu: Mỗi kết luận có thể truy vết về ghi chú/quan sát từ Empathize.
- Sẵn sàng Ideate: HMW đủ cụ thể để brainstorm, đủ mở để sáng tạo.
5 bước thực hiện:
- Thu gom dữ liệu: Tập hợp tất cả ghi chú, quote, hình ảnh từ Empathize. Đảm bảo có đủ bằng chứng cho mỗi insight.
- Affinity Diagramming:
- Gom nhóm các ghi chú tương đồng (theo chủ đề, cảm xúc, hành vi)
- Đặt tên cho từng nhóm (vd: "Lo lắng về thời gian", "Khó khăn thanh toán")
- Chọn 3–5 chủ đề quan trọng nhất theo tần suất/tác động
- Viết POV:
- Công thức: [USER] cần [NEED] vì [INSIGHT]
- Viết 1–3 POV, mỗi POV bám vào 1 chủ đề chính
- Kiểm tra: có thể truy vết về ghi chú thực tế không?
- Tạo HMW:
- Chọn 1 POV tốt nhất, tạo 3–5 HMW từ POV đó
- Đảm bảo HMW không gài sẵn giải pháp
- Kiểm tra: đủ mở để sáng tạo, đủ hẹp để hành động
- Ưu tiên và chuẩn bị:
- Đánh giá HMW theo tác động và tính khả thi
- Chọn 2–3 HMW ưu tiên để đưa sang Ideate
- Chuẩn bị bảng truy vết để minh bạch logic
Lưu ý: Luôn kiểm tra lại mỗi bước để đảm bảo không nhảy vội sang giải pháp. Mục tiêu là định nghĩa rõ vấn đề trước khi ideate.
Các lĩnh vực phù hợp:
Dịch vụ khách hàng
- Quán ăn, cà phê, nhà hàng
- Quầy dịch vụ (ngân hàng, bưu điện)
- Khách sạn, resort
- Bệnh viện, phòng khám
Quy trình nội bộ
- Quy trình phê duyệt, xử lý đơn hàng
- Quy trình đào tạo nhân viên
- Quy trình bảo trì, sửa chữa
- Quy trình quản lý kho, logistics
Sản phẩm số
- Ứng dụng di động, website
- Hệ thống quản lý nội bộ
- Dashboard, báo cáo
- Chatbot, AI assistant
Nguyên tắc chung: Define phù hợp cho mọi dự án cần làm rõ vấn đề cốt lõi trước khi tìm giải pháp. Đặc biệt hiệu quả khi có nhiều dữ liệu từ Empathize cần tổng hợp.
Ví dụ: Cải tiến quy trình gọi món tại quán cà phê
Từ Empathize → Define:
- Ghi chú: "Lan lo lắng khi không biết món đã chuẩn bị chưa"
- Chủ đề: "Lo lắng về thời gian và trạng thái món"
- POV: "Lan (sinh viên) cần biết khi nào món sẵn sàng để chủ động thời gian học."
HMW từ POV trên:
- Làm thế nào để hiển thị thời gian phục vụ dự kiến cho từng món?
- Làm thế nào để thông báo khi món sẵn sàng phục vụ?
- Làm thế nào để hiển thị bảng trạng thái theo số hoá đơn?
- Làm thế nào để ưu tiên món nhanh cho khách vội?
- Làm thế nào để nhắc nhân viên cập nhật trạng thái món?
Phân tích:
- POV tốt: Bám dữ liệu thực tế, không gài sẵn giải pháp, có thể truy vết về ghi chú
- HMW đa dạng: Từ hiển thị thông tin đến quy trình, từ khách hàng đến nhân viên
- Sẵn sàng Ideate: Mỗi HMW đủ cụ thể để brainstorm, đủ mở để sáng tạo
Checklist thực hành:
✓ Cần có:
- Bảng chủ đề từ Affinity (3–5 chủ đề có tên rõ ràng)
- POV bám dữ liệu thực tế (có thể truy vết)
- HMW không gài sẵn giải pháp
- Lý do ưu tiên HMW (tác động/khả thi)
- Bảng truy vết logic
✗ Tránh:
- POV mơ hồ, không bám dữ liệu
- HMW gài sẵn giải pháp cụ thể
- Không có lý do ưu tiên
- Không thể truy vết về ghi chú
- Nhảy vội sang Ideate
Rubric đánh giá:
Rõ ràng (3 điểm)
- POV/HMW dễ hiểu
- Không mơ hồ
- Có thể dùng ngay cho Ideate
Bám dữ liệu (3 điểm)
- Có thể truy vết về ghi chú
- Không suy diễn quá xa
- Bằng chứng rõ ràng
Sẵn sàng Ideate (4 điểm)
- HMW đủ cụ thể
- Đủ mở để sáng tạo
- Có ưu tiên rõ ràng
Tổng điểm: 10 điểm. Đạt từ 7 điểm trở lên là sẵn sàng sang Ideate.
Practice: Thử viết 1 POV và 3 HMW cho dự án thực tế của bạn. Kiểm tra theo checklist và rubric trên.
Các hoạt động chính
Gợi ý: Đọc nhanh mục 1–2 trong "Bài giảng" phía trên để nắm khái niệm.
Mục tiêu: Tổng hợp và phân tích dữ liệu từ Empathize để tìm ra các chủ đề lặp lại và insight quan trọng.
Các bước thực hiện:
- Thu thập tất cả ghi chú, quote, hình ảnh từ Empathize
- Dán sticky notes lên bảng lớn (hoặc dùng Miro/Figma)
- Gom nhóm theo chủ đề tương đồng (cảm xúc, hành vi, vấn đề)
- Đặt tên cho từng nhóm (vd: "Lo lắng về thời gian", "Khó khăn thanh toán")
- Xếp hạng theo tần suất xuất hiện và tác động
Ví dụ chủ đề từ trạm sạc:
- "Không biết ổ trống/lỗi" (tần suất cao)
- "Bắt đầu sạc chậm, nhiều bước" (tác động lớn)
- "Thanh toán không rõ, lo lắng về chi phí" (cảm xúc mạnh)
- "Thiếu hỗ trợ khi lỗi" (pain point rõ ràng)
Practice: Tạo Affinity Map cho 30 ghi chú từ giai đoạn Empathize; trích 3 chủ đề lớn nhất.
Mục tiêu: Viết phát biểu quan điểm rõ ràng để định nghĩa vấn đề cốt lõi từ góc nhìn người dùng.
Công thức POV:
[USER] cần [NEED] bởi vì [INSIGHT]
- USER: Ai là người dùng chính? (rider, operator, technician)
- NEED: Họ cần gì? (nhu cầu cụ thể, có thể đo lường)
- INSIGHT: Tại sao họ cần điều đó? (lý do sâu xa từ dữ liệu)
Ví dụ POV từ trạm sạc:
- An (rider) cần biết chắc ổ nào đang trống và hoạt động bởi vì thời gian chờ làm gián đoạn học/làm
- Kỹ thuật vận hành cần giám sát ổ lỗi và reset relay từ xa bởi vì sự cố làm mất doanh thu/ảnh hưởng trải nghiệm
Lưu ý:
- POV phải bám dữ liệu thực tế từ Empathize
- Không "nhúng" giải pháp vào POV
- Có thể truy vết về ghi chú/quan sát
- Ràng buộc kỹ thuật: gateway + RS485/CANBus, chỉ gateway IoT
Practice: Viết 3 POV từ 3 chủ đề khác nhau, chọn 1 theo tiêu chí tác động/KPI.
Mục tiêu: Chuyển POV thành câu hỏi mở để khơi gợi ý tưởng sáng tạo trong giai đoạn Ideate.
Nguyên tắc viết HMW:
- Đủ mở: Không gài sẵn giải pháp cụ thể
- Đủ hẹp: Có thể hành động được, không quá trừu tượng
- Bắt đầu bằng "Làm thế nào để...": Tạo cảm giác có thể giải quyết
- Phù hợp ràng buộc: Khả thi với kiến trúc hệ thống hiện có
Ví dụ HMW từ POV trạm sạc:
POV: "An (rider) cần biết chắc ổ nào đang trống và hoạt động bởi vì thời gian chờ làm gián đoạn học/làm"
- Làm thế nào để hiển thị trạng thái thời gian thực của từng ổ?
- Làm thế nào để cho phép bắt đầu sạc nhanh (one-tap) khi đã cắm phích?
- Làm thế nào để cung cấp ước tính thời gian/chi phí ngay trên bản đồ bãi?
- Làm thế nào để báo ổ lỗi sớm để tránh người dùng đi tới ổ hỏng?
- Làm thế nào để hỗ trợ hàng đợi công bằng mà không cần phần cứng mới?
Ràng buộc kỹ thuật:
- Gateway điều khiển ổ qua RS485/CANBus
- Chỉ gateway kết nối IoT, không IoT per-socket
- App/web cho CPO và người dùng
- Đo lường thời gian và năng lượng tại ổ
Practice: Viết 5 HMW từ 1 POV ưu tiên; gắn feasibility note theo ràng buộc kỹ thuật.
Ví dụ thực tiễn: Giai đoạn Xác định
Bước 1: Affinity Diagramming
Ghi chú từ Empathize:
- "An lo lắng khi không biết ổ nào trống"
- "Mất 10 phút tìm ổ trống"
- "Không biết ổ có lỗi không"
- "Bắt đầu sạc phải làm nhiều bước"
Chủ đề: "Lo lắng về trạng thái ổ và thời gian chờ"
Bước 2: Viết POV
An (rider) cần biết chắc ổ nào đang trống và hoạt động bởi vì thời gian chờ làm gián đoạn học/làm
✓ Bám dữ liệu thực tế ✓ Không gài giải pháp ✓ Có thể truy vết
Bước 3: Tạo HMW
- Làm thế nào để hiển thị trạng thái thời gian thực của từng ổ?
- Làm thế nào để cho phép bắt đầu sạc nhanh (one-tap)?
- Làm thế nào để báo ổ lỗi sớm?
✓ Đủ mở để sáng tạo ✓ Đủ hẹp để hành động ✓ Phù hợp ràng buộc
Bảng truy vết logic chi tiết:
| Ghi chú từ Empathize | Chủ đề (Affinity) | POV Statement | HMW Questions | Ưu tiên |
|---|---|---|---|---|
| "An lo lắng khi không biết ổ nào trống" "Mất 10 phút tìm ổ trống" "Không biết ổ có lỗi không" |
Lo lắng về trạng thái ổ Tần suất: Cao Tác động: Lớn |
An (rider) cần biết chắc ổ nào đang trống và hoạt động bởi vì thời gian chờ làm gián đoạn học/làm | • Làm thế nào để hiển thị trạng thái thời gian thực? • Làm thế nào để báo ổ lỗi sớm? • Làm thế nào để cập nhật trạng thái tự động? |
Cao |
| "Bắt đầu sạc phải làm nhiều bước" "Quét QR rồi nhập mã, rồi xác nhận" "Đôi khi app lag, phải làm lại" |
Thời gian chờ & thao tác Tần suất: Trung bình Tác động: Trung bình |
An (rider) cần bắt đầu sạc nhanh và đơn giản bởi vì quy trình phức tạp làm mất thời gian và gây bực bội | • Làm thế nào để bắt đầu sạc nhanh (one-tap)? • Làm thế nào để giảm số bước thao tác? • Làm thế nào để xử lý lỗi app tốt hơn? |
Trung bình |
| "Không biết phải trả bao nhiêu tiền" "Lo lắng về chi phí" "Thanh toán không rõ ràng" |
Lo lắng về chi phí Tần suất: Cao Tác động: Lớn |
An (rider) cần biết rõ chi phí trước khi sạc bởi vì lo lắng về ngân sách và muốn kiểm soát chi tiêu | • Làm thế nào để hiển thị chi phí dự kiến? • Làm thế nào để tính phí theo thời gian thực? • Làm thế nào để thanh toán minh bạch? |
Cao |
Lợi ích của bảng truy vết:
- Minh bạch: Mọi người có thể thấy logic từ dữ liệu đến giải pháp
- Kiểm tra chất lượng: Đảm bảo POV bám dữ liệu, HMW phù hợp POV
- Ưu tiên: Dựa trên tần suất và tác động để chọn vấn đề quan trọng
- Chia sẻ: Dễ dàng trình bày cho stakeholder và team
POV Kỹ thuật vận hành chi tiết:
Từ Empathize:
- "Khi ổ lỗi, phải đi tận nơi để reset"
- "Không biết ổ nào lỗi cho đến khi khách phàn nàn"
- "Mất thời gian xử lý sự cố, ảnh hưởng doanh thu"
- "Không có hệ thống cảnh báo sớm"
Chủ đề (Affinity):
"Giám sát và xử lý sự cố từ xa"
- Tần suất: Cao (sự cố thường xuyên)
- Tác động: Lớn (mất doanh thu, ảnh hưởng trải nghiệm)
- Độ khẩn cấp: Cao (cần xử lý ngay)
POV Statement:
Kỹ thuật vận hành cần giám sát ổ lỗi và reset relay từ xa bởi vì sự cố làm mất doanh thu và ảnh hưởng trải nghiệm người dùng
USER: Kỹ thuật vận hành (operator, technician)
NEED: Giám sát ổ lỗi và reset relay từ xa
INSIGHT: Sự cố làm mất doanh thu và ảnh hưởng trải nghiệm
HMW từ POV này:
- Làm thế nào để cảnh báo ổ lỗi tự động cho kỹ thuật?
- Làm thế nào để giám sát hiệu suất ổ theo thời gian thực?
- Làm thế nào để dự đoán lỗi trước khi xảy ra?
- Làm thế nào để reset relay từ xa qua gateway?
- Làm thế nào để điều khiển ổ từ xa an toàn?
- Làm thế nào để log lại tất cả thao tác từ xa?
Ràng buộc kỹ thuật:
- Giao thức: RS485/CANBus giữa gateway và ổ
- Điều khiển: Chỉ gateway có thể điều khiển relay
- Bảo mật: Thao tác từ xa phải an toàn
- Logging: Ghi lại tất cả thao tác để audit
Bảng tổng hợp lỗi thường gặp & misconduct
Bảng tổng hợp lỗi thường gặp & misconduct (có đánh số, mức độ nghiêm trọng)
| # | Lỗi / Misconduct | Mức độ | Hậu quả | Cách khắc phục |
|---|---|---|---|---|
| 1 | Nhảy vội sang Ideate mà chưa Define rõ ràng | H | Giải pháp không giải quyết đúng vấn đề, lãng phí thời gian | Luôn hoàn thành Define trước khi Ideate, kiểm tra POV/HMW |
| 2 | POV nhúng sẵn giải pháp cụ thể | H | Giới hạn không gian giải pháp, mất tính sáng tạo | Tập trung vào nhu cầu/vấn đề, không đề cập giải pháp |
| 3 | POV không bám dữ liệu thực tế từ Empathize | H | Giải pháp không phù hợp nhu cầu thực tế | Luôn truy vết POV về ghi chú/quan sát cụ thể |
| 4 | HMW gài sẵn giải pháp cụ thể | H | Giới hạn ý tưởng, mất cơ hội sáng tạo | Viết HMW mở, không đề cập công nghệ/giải pháp cụ thể |
| 5 | Bỏ qua bước Affinity Diagramming | H | POV thiếu cơ sở, không có chủ đề rõ ràng | Luôn gom nhóm ghi chú trước khi viết POV |
| 6 | POV mơ hồ, không cụ thể | M | HMW khó viết, Ideate không hiệu quả | Sử dụng công thức USER-NEED-INSIGHT rõ ràng |
| 7 | HMW quá trừu tượng, không thể hành động | M | Ý tưởng không thực tế, khó prototype | Đảm bảo HMW đủ cụ thể để có thể thực hiện |
| 8 | Không ưu tiên HMW theo tác động/khả thi | M | Chọn ý tưởng không tối ưu, lãng phí nguồn lực | Đánh giá theo Impact/Effort Matrix |
| 9 | Không có bảng truy vết logic | M | Khó kiểm tra chất lượng, không minh bạch | Tạo bảng Ghi chú → Chủ đề → POV → HMW |
| 10 | Bỏ qua góc nhìn kỹ thuật vận hành | M | Giải pháp không khả thi về mặt vận hành | Bao gồm POV cho operator/technician |
| 11 | Không kiểm tra tính khả thi với ràng buộc kỹ thuật | L | Ý tưởng không thực hiện được | Ghi chú feasibility cho mỗi HMW |
| 12 | POV/HMW không đủ cụ thể để Ideate | L | Brainstorming không hiệu quả | Đảm bảo đủ cụ thể để có thể hành động |
| 13 | Không có rationale cho việc ưu tiên | L | Quyết định thiếu cơ sở | Ghi rõ lý do ưu tiên theo KPI/tác động |
Chương 3
Lên ý tưởng (Ideate)
"Mở rộng không gian giải pháp nhưng tôn trọng ràng buộc kỹ thuật và nguồn lực có sẵn"
Mục tiêu học tập
- Áp dụng các kỹ thuật phát sinh ý tưởng (Brainstorming, Crazy 8s, SCAMPER) một cách có hệ thống.
- Phát triển tư duy "số lượng trước, chất lượng sau" trong quá trình tạo ý tưởng.
- Sử dụng Impact/Effort Matrix để sàng lọc và ưu tiên ý tưởng một cách khách quan.
- Chọn lọc ý tưởng dựa trên tính khả thi và tác động tiềm năng.
Kết quả chương trình
- Danh mục ý tưởng đa dạng đã được phân loại và nhóm theo chủ đề.
- Danh sách ý tưởng ưu tiên có rationale rõ ràng và sẵn sàng cho Prototype.
- Kỹ năng tạo ý tưởng sáng tạo và có hệ thống cho các dự án Design Thinking.
- Kho ý tưởng: Danh sách 20-50 ý tưởng đa dạng với đánh giá tính khả thi.
- Nhóm chủ đề: 3-5 nhóm ý tưởng được phân loại theo chủ đề chính.
- Impact/Effort Matrix: Bảng đánh giá ý tưởng theo tác động và nỗ lực thực hiện.
- Danh sách ưu tiên: 3-5 ý tưởng được chọn với rationale rõ ràng.
Bài giảng: Lên ý tưởng (Ideate)
Khái niệm (What)
Lên ý tưởng (Ideate) là nghĩ ra nhiều cách khác nhau để giải quyết vấn đề từ câu hỏi "Làm thế nào để..." (HMW) mà chúng ta đã xác định ở bước Define.
Ví dụ đơn giản: Nếu HMW là "Làm thế nào để giúp học sinh học tốt hơn?", thì Ideate sẽ nghĩ ra: dùng app, học nhóm, video, game, v.v.
Tư duy cần có (Mindsets)
- Không phán xét: Tất cả ý tưởng đều tốt, đừng nói "ý tưởng này dở" ngay. Có thể ý tưởng "dở" lại dẫn đến ý tưởng hay.
- Nhiều hơn tốt hơn: Càng nghĩ ra nhiều ý tưởng càng tốt. Sau đó mới chọn lọc những ý tưởng tốt nhất.
- Thực tế: Ý tưởng phải có thể làm được với công nghệ và nguồn lực hiện có.
Lưu ý: Đây là bước "nghĩ thoải mái" nhưng vẫn phải nhớ rằng cuối cùng phải chọn ý tưởng có thể thực hiện được.
4 hoạt động chính:
- Brainstorming: Ngồi lại với team, mỗi người nói ra ý tưởng của mình, không ai được phán xét ý tưởng của người khác.
- Crazy 8s: Mỗi người vẽ 8 ý tưởng trong 8 phút (1 phút/ý tưởng). Vẽ nhanh, không cần đẹp, chỉ cần hiểu được ý tưởng.
- SCAMPER: Dùng 7 cách để cải tiến ý tưởng tốt nhất: Thay thế, Kết hợp, Điều chỉnh, Sửa đổi, Dùng cho mục đích khác, Loại bỏ, Đảo ngược.
- Chọn lọc: Dùng bảng "Tác động vs Nỗ lực" để chọn ý tưởng nào dễ làm mà lại có tác dụng lớn.
Ví dụ: Nếu muốn cải thiện quán cà phê, có thể: thêm wifi (dễ làm, tác dụng lớn), thay đổi menu (khó hơn, tác dụng trung bình), mở rộng quán (rất khó, tác dụng lớn).
Chi tiết cách làm từng hoạt động xem phần "Các hoạt động chính" bên dưới.
Kết quả cần có:
- Danh sách ý tưởng: Ít nhất 20-50 ý tưởng khác nhau, ghi rõ ý tưởng nào có thể làm được với công nghệ hiện có.
- Nhóm ý tưởng: Gộp các ý tưởng tương tự vào 3-5 nhóm (ví dụ: nhóm "hiển thị thông tin", nhóm "thanh toán", nhóm "thông báo").
- Ý tưởng ưu tiên: Chọn ra 3-5 ý tưởng tốt nhất, giải thích rõ tại sao chọn những ý tưởng này.
- Bảng đánh giá: Bảng so sánh các ý tưởng theo "dễ làm" và "tác dụng lớn".
Tiêu chuẩn đánh giá:
- Đa dạng: Ý tưởng từ nhiều góc nhìn khác nhau, không chỉ nghĩ về công nghệ mà còn nghĩ về trải nghiệm người dùng.
- Có thể làm được: Ý tưởng phải phù hợp với công nghệ và nguồn lực có sẵn (ví dụ: gateway + RS485/CANBus, app/web).
- Rõ ràng: Ý tưởng đủ cụ thể để có thể làm mẫu thử và kiểm tra.
- Danh sách: 25 ý tưởng từ Crazy 8s
- Nhóm: 4 nhóm (hiển thị trạng thái, bắt đầu sạc, thanh toán, thông báo)
- Ưu tiên: 3 ý tưởng - "Bảng hiển thị trạng thái thời gian thực", "Bắt đầu sạc bằng 1 chạm", "Tự động thông báo khi có ổ trống"
5 bước thực hiện:
- Chuẩn bị (5-10 phút):
- Chọn 2-3 câu hỏi "Làm thế nào để..." quan trọng nhất từ bước Define
- Chuẩn bị giấy, bút, sticky notes, bảng vẽ, đồng hồ đếm ngược
- Nhắc mọi người: "Không ai được nói ý tưởng này dở, tất cả đều tốt!"
- Brainstorming (20-30 phút):
- Mỗi người nói ra ý tưởng của mình, người khác ghi lại
- Khuyến khích ý tưởng "điên rồ" - có thể dẫn đến ý tưởng hay
- Ghi lại TẤT CẢ ý tưởng, không bỏ ý tưởng nào
- Crazy 8s (8 phút):
- Chọn 1 câu hỏi "Làm thế nào để..." quan trọng nhất
- Mỗi người vẽ 8 ý tưởng trong 8 phút (1 phút/ý tưởng)
- Vẽ nhanh, không cần đẹp, chỉ cần hiểu được ý tưởng
- SCAMPER (15-20 phút):
- Chọn 1-2 ý tưởng tốt nhất từ Crazy 8s
- Dùng 7 cách để cải tiến: Thay thế, Kết hợp, Điều chỉnh, Sửa đổi, Dùng cho mục đích khác, Loại bỏ, Đảo ngược
- Tạo ra các biến thể mới từ ý tưởng gốc
- Chọn lọc (15-20 phút):
- Gộp các ý tưởng tương tự vào nhóm
- Dùng bảng "Tác động vs Nỗ lực" để đánh giá
- Chọn 3-5 ý tưởng tốt nhất để làm mẫu thử
Lưu ý quan trọng: Luôn nhớ kiểm tra xem ý tưởng có thể làm được với công nghệ hiện có không. Ý tưởng phải thực tế để có thể làm mẫu thử.
Ví dụ thời gian: Tổng cộng khoảng 1-1.5 giờ cho toàn bộ quá trình Ideate. Có thể chia thành 2 buổi: buổi 1 làm brainstorming + Crazy 8s, buổi 2 làm SCAMPER + chọn lọc.
Ideate phù hợp cho các trường hợp:
Sản phẩm số
- Làm app di động, website mới
- Thêm tính năng mới cho app
- Thiết kế giao diện người dùng
- Cải thiện trải nghiệm người dùng
Cải tiến dịch vụ
- Làm cho khách hàng hài lòng hơn
- Làm việc nhanh hơn, hiệu quả hơn
- Giải quyết vấn đề trong công ty
- Tạo quy trình mới
Hệ thống phần cứng
- Thiết kế thiết bị mới
- Cải tiến máy móc hiện có
- Hệ thống tự động hóa
- Giám sát và điều khiển từ xa
Ví dụ cụ thể:
- Quán cà phê: Làm thế nào để phục vụ khách nhanh hơn?
- Trường học: Làm thế nào để học sinh học tốt hơn?
- Công ty: Làm thế nào để nhân viên làm việc hiệu quả hơn?
- Sản phẩm: Làm thế nào để người dùng dễ sử dụng hơn?
Nguyên tắc: Ideate phù hợp cho MỌI dự án cần nghĩ ra nhiều cách giải quyết vấn đề. Đặc biệt hiệu quả khi bạn biết rõ vấn đề cần giải quyết và có giới hạn về công nghệ/nguồn lực.
Ví dụ: Nghĩ ý tưởng cho câu hỏi "Làm thế nào để người dùng biết ổ nào đang trống?"
Từ Brainstorming (ngồi nói chuyện):
- Ý tưởng 1: Gắn đèn LED tại mỗi ổ - xanh = trống, đỏ = đang sạc
- Ý tưởng 2: App gửi thông báo khi có ổ trống
- Ý tưởng 3: Bảng điện tử hiển thị tất cả ổ
- Ý tưởng 4: Loa phát thanh thông báo "Có ổ trống ở vị trí..."
Từ Crazy 8s (vẽ nhanh):
- Ý tưởng 5: QR code dán trên ổ, quét để xem trạng thái
- Ý tưởng 6: Đèn màu sắc (xanh/đỏ/vàng) tại ổ
- Ý tưởng 7: Màn hình đếm ngược thời gian còn lại
- Ý tưởng 8: Hình ảnh 3D hiển thị trạng thái (như trong phim)
Phân tích và chọn lọc:
- Dễ làm: Ý tưởng 2, 6 (app notification, đèn màu) - có thể làm ngay
- Tác dụng lớn: Ý tưởng 1, 2 (đèn LED, app notification) - người dùng thấy ngay
- Chọn làm: Kết hợp app notification + đèn màu tại ổ
Kết quả cuối cùng:
Chọn 2 ý tưởng: (1) App thông báo khi có ổ trống, (2) Đèn màu tại mỗi ổ. Cả hai đều dễ làm và có tác dụng lớn cho người dùng.
Danh sách kiểm tra:
✓ Những gì cần có:
- Ít nhất 20-50 ý tưởng khác nhau từ brainstorming
- 8 ý tưởng từ Crazy 8s cho 1 câu hỏi quan trọng
- Gộp ý tưởng thành 3-5 nhóm theo chủ đề
- Bảng "Tác động vs Nỗ lực" đã hoàn thành
- Chọn 3-5 ý tưởng tốt nhất và giải thích tại sao
✗ Những gì cần tránh:
- Nói "ý tưởng này dở" trong lúc brainstorming
- Chỉ nghĩ về 1 loại giải pháp (ví dụ: chỉ nghĩ về app)
- Quên kiểm tra xem ý tưởng có làm được không
- Không giải thích tại sao chọn ý tưởng này
- Ý tưởng quá mơ hồ, không thể làm mẫu thử
Cách đánh giá (10 điểm):
Đa dạng (3 điểm)
- Ý tưởng từ nhiều góc nhìn khác nhau
- Không chỉ nghĩ về công nghệ
- Có ý tưởng "điên rồ" nhưng sáng tạo
Có thể làm được (4 điểm)
- Phù hợp với công nghệ hiện có
- Có thể thực hiện được
- Đủ cụ thể để làm mẫu thử
Sẵn sàng làm mẫu (3 điểm)
- Có ý tưởng ưu tiên rõ ràng
- Giải thích hợp lý tại sao chọn
- Có thể chuyển sang bước làm mẫu thử
Tổng điểm: 10 điểm. Đạt từ 7 điểm trở lên là sẵn sàng sang bước làm mẫu thử.
Bài tập thực hành: Thực hiện 1 buổi Ideate hoàn chỉnh cho 1 câu hỏi "Làm thế nào để..." từ bước Define. Kiểm tra theo danh sách và cách đánh giá trên.
Ví dụ bài tập:
Câu hỏi: "Làm thế nào để học sinh học tốt hơn?"
- Brainstorming: 30 ý tưởng trong 20 phút
- Crazy 8s: 8 ý tưởng vẽ nhanh trong 8 phút
- Nhóm: 4 nhóm (công nghệ, phương pháp, môi trường, động lực)
- Chọn: 3 ý tưởng tốt nhất để làm mẫu thử
Các hoạt động chính
Gợi ý: Đọc nhanh mục 1–2 trong "Bài giảng" phía trên để hiểu khái niệm cơ bản.
Brainstorming: Ngồi lại với team, mỗi người nói ra ý tưởng của mình. Không ai được nói "ý tưởng này dở". Khuyến khích ý tưởng "điên rồ" vì có thể dẫn đến ý tưởng hay.
Crazy 8s: Mỗi người vẽ 8 ý tưởng trong 8 phút (1 phút/ý tưởng). Vẽ nhanh, không cần đẹp, chỉ cần hiểu được ý tưởng.
Bài tập thực hành:
- Thực hiện Crazy 8s cho câu hỏi "Làm thế nào để người dùng biết ổ nào đang trống?"
- Tạo 8 ý tưởng trong 8 phút, vẽ sketch nhanh
- Nhớ: Không phán xét, tập trung vào số lượng
- Sau đó chọn 2-3 ý tưởng tốt nhất để phát triển
SCAMPER là 7 cách để cải tiến ý tưởng hiện có. Chọn 1-2 ý tưởng tốt nhất từ Crazy 8s, rồi dùng 7 cách này để tạo ra biến thể mới:
- Substitute (Thay thế): Thay thế một phần bằng cái khác (ví dụ: thay đèn LED bằng màn hình OLED)
- Combine (Kết hợp): Ghép ý tưởng này với ý tưởng khác (ví dụ: kết hợp app + đèn LED + thông báo)
- Adapt (Điều chỉnh): Thay đổi để phù hợp với tình huống mới (ví dụ: điều chỉnh theo điều kiện thời tiết)
- Modify (Sửa đổi): Thay đổi kích thước, hình dạng, màu sắc (ví dụ: làm đèn to hơn, sáng hơn)
- Put to another use (Dùng cho mục đích khác): Dùng ý tưởng này cho việc khác (ví dụ: dùng dữ liệu lịch sử để dự đoán)
- Eliminate (Loại bỏ): Bỏ bớt những gì không cần thiết (ví dụ: bỏ bước xác nhận, làm nhanh hơn)
- Reverse (Đảo ngược): Làm ngược lại (ví dụ: thay vì tìm ổ, để hệ thống gợi ý ổ)
Bài tập thực hành:
- Chọn 1 ý tưởng tốt nhất từ Crazy 8s (ví dụ: "đèn LED tại ổ")
- Áp dụng 7 cách SCAMPER để tạo 7 biến thể mới
- Kiểm tra xem biến thể nào có thể làm được
- Chọn 1-2 biến thể tốt nhất để phát triển
Dot Voting: Mỗi người có 3-5 điểm, dán vào ý tưởng mình thích nhất. Ý tưởng nào có nhiều điểm nhất sẽ được chọn.
Bảng "Tác động vs Nỗ lực": Vẽ bảng 2x2: Dễ làm/Khó làm và Tác dụng nhỏ/Tác dụng lớn. Chọn ý tưởng ở ô "Dễ làm + Tác dụng lớn".
Bài tập thực hành:
- Dùng Dot Voting để chọn 5 ý tưởng tốt nhất
- Dùng Bảng "Tác động vs Nỗ lực" để đánh giá
- Ưu tiên theo mục tiêu: giảm thời gian chờ, tăng trải nghiệm người dùng
- Chọn 3-5 ý tưởng cuối cùng và giải thích tại sao chọn
Ví dụ: Ý tưởng "đèn LED tại ổ" - Dễ làm (3 điểm), Tác dụng lớn (4 điểm) = 7 điểm. Ý tưởng "hologram 3D" - Khó làm (1 điểm), Tác dụng lớn (4 điểm) = 5 điểm. Chọn đèn LED.
Ví dụ thực tiễn: Giai đoạn Lên ý tưởng
Bảng truy vết logic chi tiết:
| HMW từ Define | Ý tưởng từ Brainstorming | Biến thể từ SCAMPER | Chủ đề | Ưu tiên |
|---|---|---|---|---|
| "Làm thế nào để hiển thị trạng thái ổ theo thời gian thực?" | • Bảng LED tại mỗi ổ • App push notification • Bản đồ nhiệt trong app • Voice assistant |
• Substitute: LED → OLED display • Combine: App + LED + Voice • Modify: Thêm thời gian còn lại |
Hiển thị trạng thái Mục tiêu: Giảm thời gian tìm ổ |
Cao |
| "Làm thế nào để bắt đầu sạc nhanh (one-tap)?" | • QR code quét • NFC tag • Auto-detect khi cắm • Voice command |
• Adapt: QR → NFC + QR • Eliminate: Bỏ bước xác nhận • Reverse: App tự động start |
Khởi tạo phiên Mục tiêu: Giảm thời gian start |
Cao |
| "Làm thế nào để cảnh báo ổ lỗi tự động?" | • Sensor monitoring • Predictive maintenance • Alert system • Status dashboard |
• Put to another use: Dữ liệu lịch sử để dự đoán • Combine: Sensor + ML + Alert • Modify: Thêm mức độ ưu tiên |
Giám sát vận hành Mục tiêu: Giảm downtime |
Trung bình |
| "Làm thế nào để thanh toán minh bạch?" | • Real-time billing • Multiple payment methods • Receipt generation • Usage analytics |
• Substitute: Cash → Digital only • Adapt: Tích hợp e-wallet • Modify: Thêm breakdown chi tiết |
Thanh toán Mục tiêu: Tăng minh bạch |
Trung bình |
Lợi ích của bảng truy vết:
- Minh bạch: Mọi ý tưởng có thể truy vết về HMW gốc
- Kiểm tra chất lượng: Đảm bảo ý tưởng phù hợp với vấn đề
- Ưu tiên: Dựa trên tác động và khả thi để chọn ý tưởng
- Chia sẻ: Dễ dàng trình bày cho stakeholder và team
- Bản đồ bãi trong app: trạng thái từng ổ (Trống/Đang sạc/Lỗi) do gateway tổng hợp.
- Tooltip hiển thị công suất, lịch sử lỗi gần nhất của ổ.
- One-tap Start: khi cắm phích, app tự nhận ổ và đề xuất bắt đầu.
- Thông báo push khi có ổ trống ở bãi gần (dựa trên lịch sử luân chuyển).
- Đèn chỉ thị tại ổ (vòng LED) đồng bộ trạng thái do gateway điều khiển qua RS485/CANBus.
Chọn 2 hướng:
- Realtime Map qua gateway: Gateway đọc đo lường và trạng thái relay từng ổ (Modbus RTU/RS485 hoặc CAN), đồng bộ cloud; app hiển thị và dự báo thời điểm trống.
- Đèn chỉ thị tại ổ: LED đổi màu (Trống/Đang sạc/Lỗi) do gateway điều khiển theo trạng thái bus, tăng khả năng nhận biết tại chỗ.
Bảng tổng hợp lỗi thường gặp & misconduct
Bảng tổng hợp lỗi thường gặp & misconduct (có đánh số, mức độ nghiêm trọng)
| # | Lỗi / Misconduct | Mức độ | Hậu quả | Cách khắc phục |
|---|---|---|---|---|
| 1 | Phán xét ý tưởng trong quá trình brainstorming | H | Giảm số lượng ý tưởng, mất tính sáng tạo | Nhắc lại nguyên tắc "không phán xét", tạo môi trường an toàn |
| 2 | Bỏ qua ràng buộc kỹ thuật khi tạo ý tưởng | H | Ý tưởng không khả thi, lãng phí thời gian prototype | Luôn kiểm tra tính khả thi với kiến trúc hệ thống |
| 3 | Chỉ tập trung vào 1 loại giải pháp (công nghệ) | H | Thiếu đa dạng, bỏ lỡ cơ hội sáng tạo | Khuyến khích ý tưởng từ nhiều góc nhìn khác nhau |
| 4 | Không có rationale cho việc ưu tiên ý tưởng | H | Chọn ý tưởng không tối ưu, lãng phí nguồn lực | Sử dụng Impact/Effort Matrix và KPI rõ ràng |
| 5 | Ý tưởng quá trừu tượng, không thể prototype | H | Không thể test, không có giá trị học hỏi | Đảm bảo ý tưởng đủ cụ thể để có thể prototype |
| 6 | Không đủ số lượng ý tưởng (dưới 20) | M | Không gian giải pháp hạn chế, thiếu lựa chọn | Đặt mục tiêu 20-50 ý tưởng, sử dụng Crazy 8s |
| 7 | Không gom nhóm ý tưởng theo chủ đề | M | Khó ưu tiên, không thấy pattern | Gom nhóm 3-5 chủ đề trước khi ưu tiên |
| 8 | Bỏ qua SCAMPER hoặc các kỹ thuật cải tiến | M | Ý tưởng thiếu sáng tạo, không có biến thể | Áp dụng SCAMPER cho ý tưởng tốt nhất |
| 9 | Không có Impact/Effort Matrix | M | Quyết định ưu tiên thiếu cơ sở | Luôn tạo Impact/Effort Matrix trước khi chọn |
| 10 | Không liên kết ý tưởng với HMW gốc | M | Ý tưởng không giải quyết đúng vấn đề | Tạo bảng truy vết logic từ HMW đến ý tưởng |
| 11 | Không ghi lại ý tưởng đầy đủ | L | Mất ý tưởng, khó chia sẻ với team | Ghi lại tất cả ý tưởng với mô tả rõ ràng |
| 12 | Không có thời gian giới hạn cho brainstorming | L | Mất thời gian, không hiệu quả | Đặt timer, sử dụng Crazy 8s để tạo áp lực |
| 13 | Không có stakeholder tham gia | L | Thiếu góc nhìn đa dạng | Mời stakeholder tham gia brainstorming |
Tiếp nối hành trình Design Thinking
Sau khi hoàn thành Lên ý tưởng, hãy chuyển sang Tạo mẫu (Prototype) để hiện thực hoá ý tưởng, và Kiểm thử (Test) để đánh giá với người dùng.
Chương 4
Tạo mẫu (Prototype)
"Hiện thực hoá nhanh nhất có thể để kiểm chứng giả định với người dùng và các bên liên quan"
Mục tiêu học tập
- Hiểu nguyên lý và phân biệt low-fidelity vs high-fidelity prototyping.
- Thực hành tạo prototype nhanh để kiểm tra giả định với người dùng.
- Xác định và ưu tiên các giả định quan trọng cần kiểm chứng sớm.
- Áp dụng nguyên tắc "fail fast, learn fast" trong quá trình prototype.
Kết quả chương trình
- Prototype đủ để test với người dùng thật và thu thập phản hồi có ý nghĩa.
- Danh sách giả định đã kiểm chứng và insight học được cho vòng lặp tiếp theo.
- Kỹ năng tạo prototype nhanh và hiệu quả cho các dự án Design Thinking.
- Low-fidelity Prototype: Sketch, wireframe, mô hình giấy hoặc bìa cứng.
- High-fidelity Prototype: Interactive prototype (Figma, code demo) hoặc mô hình hoạt động.
- Danh sách giả định: Các giả định quan trọng cần kiểm tra với người dùng.
- Kế hoạch test: Hướng dẫn sử dụng và câu hỏi để hỏi người dùng.
Bài giảng: Tạo mẫu (Prototype)
Khái niệm (What)
Tạo mẫu (Prototype) là làm ra phiên bản đơn giản của ý tưởng để kiểm tra xem nó có hoạt động không và người dùng có thích không.
Ví dụ đơn giản: Thay vì xây nhà ngay, bạn làm mô hình bằng giấy để xem bố cục có ổn không. Thay vì làm app hoàn chỉnh, bạn vẽ màn hình trên giấy để test.
Tư duy cần có (Mindsets)
- Nhanh và đơn giản: Làm mẫu càng nhanh càng tốt, không cần hoàn hảo. Mục đích là học hỏi, không phải làm sản phẩm cuối.
- Thử nghiệm: Mẫu thử để kiểm tra giả định. Nếu không hoạt động, đó cũng là bài học quý giá.
- Lặp lại: Làm mẫu → test → học hỏi → làm mẫu mới. Không ngại thay đổi.
Lưu ý: Mẫu thử không phải để khoe với sếp, mà để học hỏi từ người dùng thật. Đừng sợ mẫu thử "xấu"!
2 loại mẫu thử chính:
- Low-Fidelity (Độ trung thực thấp): Vẽ tay, giấy, bìa cứng. Nhanh, rẻ, dễ thay đổi. Dùng để test ý tưởng cơ bản.
- High-Fidelity (Độ trung thực cao): Figma, code đơn giản, mô hình 3D. Giống sản phẩm thật hơn. Dùng để test chi tiết.
Ví dụ:
- Low-fi: Vẽ màn hình app trên giấy, dùng ngón tay "click" để test
- High-fi: Làm prototype Figma có thể click được, hoặc mô hình Arduino với LED thật
Chi tiết cách làm từng loại xem phần "Các hoạt động chính".
Kết quả cần có:
- Mẫu thử có thể test: Ít nhất 1 mẫu thử (low-fi hoặc high-fi) có thể cho người dùng thử
- Danh sách giả định cần kiểm tra: Ghi rõ những gì muốn kiểm tra với mẫu thử
- Hướng dẫn test: Cách sử dụng mẫu thử và câu hỏi cần hỏi người dùng
- Kế hoạch cải tiến: Dựa trên kết quả test, sẽ thay đổi gì trong mẫu thử tiếp theo
Tiêu chuẩn đánh giá:
- Có thể test được: Mẫu thử đủ rõ ràng để người dùng hiểu và thử nghiệm
- Kiểm tra được giả định: Mẫu thử giúp trả lời câu hỏi quan trọng về ý tưởng
- Dễ thay đổi: Có thể sửa đổi nhanh chóng dựa trên phản hồi
- Mẫu thử: App Figma có thể click từ bản đồ → ổ → bắt đầu sạc
- Giả định kiểm tra: Người dùng có hiểu cách sử dụng không?
- Hướng dẫn: "Bạn hãy thử tìm ổ trống và bắt đầu sạc"
- Cải tiến: Thêm nút "Hướng dẫn" nếu người dùng bối rối
5 bước thực hiện:
- Chọn ý tưởng (5 phút):
- Chọn 1-2 ý tưởng quan trọng nhất từ Ideate
- Xác định phần nào của ý tưởng cần test trước
- Viết ra giả định cần kiểm tra
- Làm mẫu thử đơn giản (30-60 phút):
- Bắt đầu với low-fi: vẽ tay, giấy, bìa cứng
- Tập trung vào chức năng chính, không lo về đẹp
- Làm đủ để người dùng hiểu ý tưởng
- Test nhanh với team (15-20 phút):
- Cho đồng nghiệp thử mẫu thử
- Quan sát cách họ sử dụng
- Ghi lại phản hồi và vấn đề
- Cải tiến mẫu thử (30-45 phút):
- Sửa những vấn đề phát hiện được
- Làm high-fi nếu cần test chi tiết hơn
- Chuẩn bị cho test với người dùng thật
- Chuẩn bị test (15-20 phút):
- Viết hướng dẫn sử dụng mẫu thử
- Chuẩn bị câu hỏi để hỏi người dùng
- Lên kế hoạch test với người dùng thật
Lưu ý quan trọng: Không cố gắng làm mẫu thử hoàn hảo. Mục đích là học hỏi nhanh, không phải làm sản phẩm cuối cùng.
Ví dụ thời gian: Tổng cộng khoảng 2-3 giờ cho toàn bộ quá trình Prototype. Có thể chia thành 2 buổi: buổi 1 làm mẫu thử + test nội bộ, buổi 2 cải tiến + test người dùng.
Prototype phù hợp cho các trường hợp:
Sản phẩm số
- Thiết kế app, website mới
- Thêm tính năng mới
- Kiểm tra giao diện người dùng
- Test luồng sử dụng
Sản phẩm vật lý
- Thiết kế thiết bị mới
- Cải tiến sản phẩm hiện có
- Test kích thước, hình dạng
- Kiểm tra chức năng cơ bản
Dịch vụ và quy trình
- Thiết kế quy trình mới
- Cải tiến dịch vụ khách hàng
- Test trải nghiệm người dùng
- Kiểm tra tính khả thi
Ví dụ cụ thể:
- Quán cà phê: Làm mô hình bàn ghế để test bố cục
- Trường học: Vẽ giao diện app học online để test
- Công ty: Làm mô hình quy trình làm việc mới
- Sản phẩm: Làm mô hình 3D để test kích thước
Nguyên tắc: Prototype phù hợp cho MỌI dự án cần kiểm tra ý tưởng trước khi đầu tư nhiều thời gian và tiền bạc. Đặc biệt quan trọng khi ý tưởng mới hoặc phức tạp.
Ví dụ: Làm mẫu thử cho ý tưởng "App hiển thị trạng thái ổ sạc"
Bước 1: Chọn ý tưởng và giả định
- Ý tưởng: App hiển thị trạng thái ổ sạc theo thời gian thực
- Giả định cần kiểm tra: Người dùng có hiểu cách sử dụng app không?
- Phần cần test: Luồng từ mở app → xem bản đồ → chọn ổ → bắt đầu sạc
Bước 2: Làm mẫu thử low-fi
- Vẽ tay 3 màn hình: Màn hình chính (bản đồ), Màn hình chi tiết ổ, Màn hình xác nhận sạc
- Dùng giấy: Cắt giấy làm nút bấm, dán lên màn hình vẽ
- Test nội bộ: Cho đồng nghiệp thử, quan sát cách họ sử dụng
Bước 3: Cải tiến và làm high-fi
- Phát hiện vấn đề: Người dùng không biết ổ nào đang trống
- Cải tiến: Thêm màu sắc: xanh = trống, đỏ = đang sạc
- Làm Figma: Tạo prototype có thể click được
Kết quả cuối cùng:
Có mẫu thử Figma với 3 màn hình, có thể test với người dùng thật. Học được rằng cần hiển thị trạng thái rõ ràng bằng màu sắc.
Danh sách kiểm tra:
✓ Những gì cần có:
- Ít nhất 1 mẫu thử có thể test được (low-fi hoặc high-fi)
- Danh sách giả định cần kiểm tra rõ ràng
- Hướng dẫn sử dụng mẫu thử
- Kế hoạch test với người dùng
- Danh sách câu hỏi để hỏi người dùng
✗ Những gì cần tránh:
- Làm mẫu thử quá phức tạp, mất nhiều thời gian
- Không có mục đích rõ ràng cho mẫu thử
- Không test với người dùng thật
- Không ghi lại phản hồi và bài học
- Làm mẫu thử "đẹp" thay vì "có ích"
Cách đánh giá (10 điểm):
Có thể test được (4 điểm)
- Mẫu thử đủ rõ ràng để hiểu
- Có thể thực hiện được chức năng chính
- Người dùng có thể tương tác được
Kiểm tra được giả định (3 điểm)
- Giả định rõ ràng và cụ thể
- Mẫu thử giúp trả lời câu hỏi
- Có cách đo lường kết quả
Sẵn sàng test (3 điểm)
- Có hướng dẫn sử dụng
- Có kế hoạch test
- Có thể cải tiến nhanh
Tổng điểm: 10 điểm. Đạt từ 7 điểm trở lên là sẵn sàng sang bước Test.
Bài tập thực hành: Làm 1 mẫu thử hoàn chỉnh cho 1 ý tưởng từ Ideate. Kiểm tra theo danh sách và cách đánh giá trên.
Ví dụ bài tập:
Ý tưởng: "App thông báo khi có ổ trống"
- Low-fi: Vẽ 3 màn hình app trên giấy
- Test nội bộ: Cho 3 đồng nghiệp thử
- High-fi: Làm prototype Figma có thể click
- Test người dùng: Cho 5 người dùng thật thử
Các hoạt động chính
Gợi ý: Đọc nhanh mục 1–2 trong "Bài giảng" phía trên để hiểu khái niệm cơ bản.
Low-Fidelity là làm mẫu thử đơn giản, nhanh và rẻ. Dùng giấy, bút, bìa cứng để vẽ hoặc làm mô hình.
Cho app/website: Vẽ tay các màn hình chính: màn hình chính, màn hình chi tiết, màn hình xác nhận.
Cho phần cứng: Dùng bìa cứng, giấy để làm mô hình kích thước thật.
Bài tập thực hành:
- Vẽ tay 6 màn hình app chính: bản đồ bãi, chi tiết ổ, bắt đầu sạc, thanh toán
- Dùng giấy cắt làm nút bấm, dán lên màn hình vẽ
- Cho đồng nghiệp thử và quan sát cách họ sử dụng
- Ghi lại phản hồi và vấn đề phát hiện được
High-Fidelity là làm mẫu thử giống sản phẩm thật hơn. Dùng công cụ chuyên nghiệp như Figma, code đơn giản, hoặc mô hình 3D.
Cho app/website: Dùng Figma để tạo prototype có thể click được, giống app thật.
Cho phần cứng: Dùng Arduino, LED, relay để làm mô hình hoạt động thật.
Bài tập thực hành:
- Làm prototype Figma: tạo luồng click từ bản đồ → chọn ổ → bắt đầu sạc → thanh toán
- Làm mô hình Arduino: điều khiển LED sáng/tắt theo trạng thái ổ (xanh = trống, đỏ = đang sạc)
- Test với người dùng thật và ghi lại phản hồi
- Cải tiến dựa trên phản hồi nhận được
Ví dụ: Dùng Arduino + LED để mô phỏng việc điều khiển relay đóng/mở ổ sạc. LED xanh = ổ trống, LED đỏ = ổ đang sạc, LED vàng = ổ lỗi.
Ví dụ thực tiễn: Giai đoạn Tạo mẫu
Low-Fidelity:
Vẽ màn bản đồ, chi tiết ổ, xác nhận bắt đầu sạc; mô phỏng chuyển màn bằng giấy.
High-Fidelity:
Figma hiển thị trạng thái ổ, thời gian/chi phí ước tính; nút bắt đầu/khóa phiên; thông báo khi ổ chuyển trạng thái.
Gateway demo điều khiển vòng LED qua RS485/CANBus theo trạng thái ổ: Xanh (Trống), Đỏ (Đang sạc), Vàng (Lỗi). Thử các mức sáng và góc nhìn trong bãi tối.
Chương 5
Thử nghiệm (Test)
"Kiểm chứng với người dùng và đội vận hành; lặp nhanh để nâng chất lượng trải nghiệm và vận hành"
Mục tiêu học tập
- Lập và chạy Usability Test cho app/web (rider, operator).
- Kiểm tra prototype gateway/bus: đóng/mở relay, báo lỗi, độ trễ và ổn định.
- Tổng hợp phản hồi → quyết định cải tiến; chuẩn bị vòng lặp tiếp theo.
Kết quả chương trình
- Danh sách issue đã ưu tiên, đề xuất cải tiến khả thi, kế hoạch test tiếp theo (ai, khi nào, mục tiêu/KPI).
- Biên bản test: Quan sát/quote/điểm tắc.
- Danh sách vấn đề: Ưu tiên theo mức độ/tần suất/tác động.
- Kế hoạch cải tiến: Thay đổi UI, logic gateway, quy trình vận hành.
Các hoạt động chính
Định nghĩa tasks: tìm ổ trống, bắt đầu sạc, xem thời gian/chi phí, thanh toán, xử lý khi ổ lỗi.
Practice: Soạn test script 6–8 tasks; nêu thước đo thành công và thời gian kỳ vọng.
Tuyển rider (5–7), operator (3–5). Quan sát tương tác tự nhiên; tránh dẫn dắt.
Practice: Chạy 1 vòng pilot nội bộ trước khi test chính thức.
Gom nhóm vấn đề; đánh dấu quick wins vs. cần thay đổi lớn (UI/logic/ops); tạo backlog cải tiến.
Practice: Viết 3 cải tiến cụ thể sẵn sàng đưa vào sprint tới.
Ví dụ thực tiễn: Giai đoạn Thử nghiệm
Kịch bản:
"Bạn cần sạc xe để đi làm; hãy tìm ổ trống, bắt đầu sạc và xem thời gian/chi phí ước tính."
Phản hồi & Học hỏi:
Người dùng hiểu map và trạng thái ổ; cần chú giải rõ biểu tượng "Lỗi"; mong xem giá/kWh ngay trên thẻ ổ; thích one-tap start khi đã cắm phích.
Phản hồi & Học hỏi:
LED dễ nhận biết; cần giảm độ chói màu đỏ trong bãi tối; kiểm tra độ trễ đóng/mở relay qua bus; bổ sung chế độ an toàn khi quá dòng.
UI: thêm chú thích trạng thái và giá/kWh; cải tiến one-tap start. Hardware: điều chỉnh mức sáng LED, logic an toàn relay. Ops: quy trình xử lý ổ lỗi và thông báo sớm. Lặp test với mẫu lớn hơn.
Bảng truy vết logic
Bảng này giúp theo dõi từ ý tưởng đến mẫu thử, đảm bảo mẫu thử giải quyết đúng vấn đề từ Define và Ideate.
| Ý tưởng từ Ideate | Loại mẫu thử | Giả định kiểm tra | Cách test | Kết quả mong đợi |
|---|---|---|---|---|
| App hiển thị trạng thái ổ | Low-fi: Vẽ tay High-fi: Figma |
Người dùng hiểu cách sử dụng | Cho người dùng thử và quan sát | Hoàn thành task trong <2 phút |
| Đèn LED tại ổ | Low-fi: Bìa cứng High-fi: Arduino + LED |
Người dùng thấy được trạng thái | Test trong điều kiện ánh sáng khác nhau | Nhận diện đúng 100% trạng thái |
| One-tap start | Low-fi: Giấy High-fi: Figma |
Giảm thời gian bắt đầu sạc | Đo thời gian thực hiện task | Bắt đầu sạc trong <30 giây |
| Thông báo tự động | Low-fi: Giấy High-fi: App demo |
Người dùng nhận thông báo kịp thời | Mô phỏng tình huống thực tế | 90% người dùng hài lòng |
Lợi ích của bảng truy vết:
- Đảm bảo mẫu thử giải quyết đúng vấn đề từ Define
- Giúp lập kế hoạch test có hệ thống
- Đo lường được hiệu quả của mẫu thử
- Chuẩn bị tốt cho bước Test tiếp theo
Bảng tổng hợp lỗi thường gặp & misconduct
Danh sách các lỗi thường gặp trong giai đoạn Prototype, giúp tránh và khắc phục nhanh chóng.
| # | Lỗi / Misconduct | Mức độ | Hậu quả | Cách khắc phục |
|---|---|---|---|---|
| 1 | Làm mẫu thử quá phức tạp, mất nhiều thời gian | H | Chậm trễ, không kịp test, lãng phí nguồn lực | Bắt đầu với low-fi đơn giản, tập trung vào chức năng chính |
| 2 | Không có mục đích rõ ràng cho mẫu thử | H | Test không hiệu quả, không học được gì | Viết rõ giả định cần kiểm tra trước khi làm mẫu thử |
| 3 | Không test với người dùng thật | H | Mẫu thử không phản ánh nhu cầu thực tế | Luôn test với ít nhất 3-5 người dùng thật |
| 4 | Không ghi lại phản hồi và bài học | H | Mất thông tin quan trọng, không cải tiến được | Ghi lại tất cả phản hồi, quan sát, và insight |
| 5 | Làm mẫu thử "đẹp" thay vì "có ích" | H | Tập trung sai mục tiêu, không test được chức năng | Ưu tiên chức năng hơn thẩm mỹ trong prototype |
| 6 | Không có hướng dẫn sử dụng mẫu thử | M | Người dùng bối rối, test không hiệu quả | Viết hướng dẫn rõ ràng cho người test |
| 7 | Không có kế hoạch cải tiến sau test | M | Không biết làm gì tiếp theo | Lập danh sách cải tiến ưu tiên sau mỗi test |
| 8 | Chỉ làm low-fi hoặc chỉ làm high-fi | M | Thiếu góc nhìn đa dạng, test không toàn diện | Làm cả low-fi và high-fi tùy theo mục đích |
| 9 | Không test với đủ loại người dùng | M | Thiếu góc nhìn đa dạng | Test với nhiều nhóm người dùng khác nhau |
| 10 | Không có cách đo lường kết quả | M | Không biết mẫu thử có hiệu quả không | Định nghĩa KPI và cách đo lường trước khi test |
| 11 | Không chuẩn bị môi trường test | L | Test bị gián đoạn, không chính xác | Chuẩn bị môi trường test phù hợp |
| 12 | Không có backup plan | L | Test bị hủy khi có vấn đề | Luôn có phương án dự phòng |
| 13 | Không chia sẻ kết quả với team | L | Team không học được từ kết quả test | Chia sẻ kết quả và insight với toàn team |
Tiếp nối hành trình Design Thinking
Sau khi hoàn thành Tạo mẫu, hãy chuyển sang Thử nghiệm (Test) để kiểm chứng mẫu thử với người dùng thật.
Chương 5
Thử nghiệm (Test)
"Kiểm chứng mẫu thử với người dùng thật để thu thập phản hồi và cải tiến sản phẩm"
Mục tiêu học tập
- Hiểu nguyên lý và phương pháp usability testing trong Design Thinking.
- Thực hành thiết kế và thực hiện test với người dùng thật.
- Phân tích và tổng hợp phản hồi từ người dùng một cách có hệ thống.
- Áp dụng insight từ test để cải tiến sản phẩm.
Kết quả chương trình
- Báo cáo usability test với phát hiện và đề xuất cải tiến cụ thể.
- Danh sách vấn đề ưu tiên cần khắc phục dựa trên phản hồi người dùng.
- Kỹ năng thực hiện test và thu thập phản hồi hiệu quả.
- Kế hoạch test: Script test, danh sách task, tiêu chí thành công.
- Báo cáo usability test: Phát hiện, vấn đề, đề xuất cải tiến.
- Danh sách vấn đề ưu tiên: Phân loại theo mức độ nghiêm trọng.
- Kế hoạch cải tiến: Hướng dẫn cho vòng lặp tiếp theo.
Bài giảng: Thử nghiệm (Test)
Khái niệm (What)
Thử nghiệm (Test) là kiểm chứng mẫu thử với người dùng thật để thu thập phản hồi, phát hiện vấn đề và cải tiến sản phẩm.
Ví dụ đơn giản: Thay vì đoán người dùng có thích app không, bạn cho họ dùng thử và quan sát cách họ sử dụng. Thay vì giả định giao diện dễ hiểu, bạn test xem họ có hiểu không.
Tư duy cần có (Mindsets)
- Học hỏi từ người dùng: Người dùng luôn đúng. Nếu họ không hiểu, đó là lỗi của thiết kế, không phải lỗi của họ.
- Quan sát, không can thiệp: Để người dùng tự nhiên sử dụng, chỉ quan sát và ghi lại.
- Phản hồi là vàng: Mọi phản hồi đều có giá trị, kể cả phản hồi tiêu cực.
Lưu ý: Test không phải để chứng minh ý tưởng hay, mà để học hỏi và cải tiến. Đừng sợ phát hiện vấn đề!
Các hoạt động chính
Gợi ý: Đọc nhanh mục 1–2 trong "Bài giảng" phía trên để hiểu khái niệm cơ bản.
Xác định mục tiêu test, đối tượng người dùng, task cần thực hiện, và tiêu chí thành công. Chuẩn bị script test và công cụ ghi lại.
- Mục tiêu: Ví dụ: Kiểm tra tính dễ sử dụng của app, phát hiện vấn đề trong luồng thanh toán.
- Đối tượng: Người dùng thật (5-8 người), đại diện cho nhóm mục tiêu.
- Task: 3-5 task cụ thể, có thể đo lường được (thời gian, tỉ lệ thành công).
- Công cụ: Script test, checklist quan sát, công cụ ghi hình/âm.
Practice:
- Viết 1 kế hoạch test cho app mobile
- Xác định 3 task chính cần test
- Chuẩn bị script phỏng vấn
- Thiết lập tiêu chí thành công
Thực hiện test với người dùng theo script đã chuẩn bị. Quan sát hành vi, ghi lại vấn đề, và thu thập phản hồi.
Practice:
- Thực hiện test với 3-5 người dùng
- Quan sát và ghi lại vấn đề
- Thu thập phản hồi định tính
- Đo lường thời gian và tỉ lệ thành công
Tổng hợp dữ liệu từ tất cả người dùng, phân loại vấn đề theo mức độ nghiêm trọng, và đưa ra đề xuất cải tiến.
Practice:
- Tổng hợp vấn đề từ tất cả người dùng
- Phân loại theo mức độ nghiêm trọng
- Viết báo cáo với đề xuất cải tiến
- Lập kế hoạch cho vòng lặp tiếp theo
Ví dụ thực tiễn: Giai đoạn Test
Kế hoạch test cho app trạm sạc
Task chính:
- Tìm ổ sạc trống gần nhất
- Bắt đầu phiên sạc
- Kiểm tra trạng thái sạc
- Kết thúc và thanh toán
Tiêu chí thành công:
- Hoàn thành task trong ≤3 phút
- Không cần trợ giúp từ moderator
- Không có lỗi nghiêm trọng
- Đánh giá dễ sử dụng ≥4/5
Kết quả test với 5 người dùng
Vấn đề phát hiện:
- Nghiêm trọng: 3/5 người không tìm thấy nút "Bắt đầu sạc"
- Trung bình: 4/5 người không hiểu biểu tượng trạng thái ổ
- Nhẹ: 2/5 người muốn có thêm thông tin về thời gian sạc
Đề xuất cải tiến:
- Làm nổi bật nút "Bắt đầu sạc" bằng màu sắc và kích thước
- Thêm chú thích cho biểu tượng trạng thái
- Hiển thị thời gian sạc ước tính
Bảng tổng hợp lỗi thường gặp & misconduct
| # | Lỗi / Misconduct | Mức độ | Hậu quả | Cách khắc phục |
|---|---|---|---|---|
| 1 | Không test với người dùng thật | H | Phát hiện vấn đề muộn, tốn kém sửa chữa | Luôn test với ít nhất 5 người dùng thật |
| 2 | Can thiệp quá nhiều trong quá trình test | H | Kết quả không thực tế, bỏ lỡ vấn đề thật | Chỉ quan sát, không hướng dẫn trừ khi cần thiết |
| 3 | Task không rõ ràng hoặc quá phức tạp | H | Người dùng bối rối, kết quả không đáng tin | Viết task đơn giản, cụ thể, có thể đo lường |
| 4 | Không ghi lại phản hồi chi tiết | H | Mất insight quan trọng, khó phân tích | Ghi âm, ghi chép chi tiết mọi phản hồi |
| 5 | Chọn người dùng không đại diện | H | Kết quả không phản ánh đúng đối tượng mục tiêu | Chọn người dùng phù hợp với persona |
| 6 | Không có tiêu chí thành công rõ ràng | M | Khó đánh giá kết quả, không có cơ sở cải tiến | Định nghĩa tiêu chí cụ thể trước khi test |
| 7 | Test quá nhiều task một lúc | M | Người dùng mệt mỏi, chất lượng giảm | Giới hạn 3-5 task chính, tối đa 60 phút |
| 8 | Không phân loại vấn đề theo mức độ | M | Khó ưu tiên cải tiến, lãng phí nguồn lực | Phân loại vấn đề theo tác động và tần suất |
| 9 | Bỏ qua phản hồi tiêu cực | M | Bỏ lỡ cơ hội cải tiến quan trọng | Ghi nhận mọi phản hồi, kể cả tiêu cực |
| 10 | Không có kế hoạch cải tiến sau test | M | Test không có tác dụng, không cải tiến | Lập kế hoạch cải tiến cụ thể sau mỗi test |
| 11 | Không chuẩn bị môi trường test | L | Test bị gián đoạn, kết quả không chính xác | Chuẩn bị môi trường test trước 30 phút |
| 12 | Không có script test chuẩn | L | Test không nhất quán, khó so sánh | Viết script test chi tiết và sử dụng nhất quán |
| 13 | Không chia sẻ kết quả với team | L | Team không học hỏi, không cải tiến | Chia sẻ báo cáo test với toàn team |
Hoàn thành hành trình Design Thinking
Chúc mừng! Bạn đã hoàn thành toàn bộ quy trình Design Thinking. Hãy áp dụng insight từ Test để cải tiến sản phẩm và bắt đầu vòng lặp mới.
