Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn được giao thiết kế một ứng dụng đặt đồ ăn mới. Phản xạ đầu tiên của hầu hết người mới vào nghề là gì? Mở Figma lên, chọn màu, kéo nút, vẽ màn hình cho thật đẹp. Và rồi sau ba tuần làm việc cật lực, sản phẩm ra mắt — nhưng không ai dùng. Vì sao? Vì bạn đã giải một bài toán mà chưa thật sự hiểu người dùng đang gặp vấn đề gì.
Đây chính là lý do Design Thinking (tư duy thiết kế) tồn tại. Nó không phải là một bộ công cụ vẽ vời, mà là một tư duy giải quyết vấn đề lấy con người làm trung tâm (human-centered problem solving). Design Thinking dạy bạn một điều cốt lõi: trước khi nghĩ đến giải pháp, hãy hiểu thật sâu vấn đề.
Trong khóa học này, Design Thinking là nền móng. Mọi kỹ năng bạn học về sau — wireframing, prototyping, design system, hay đo lường metrics — đều chỉ là công cụ phục vụ cho một quy trình tư duy đúng đắn. Một Product Designer giỏi không phải người vẽ đẹp nhất, mà là người đặt đúng câu hỏi và giải đúng vấn đề. Bài học này sẽ trao cho bạn bộ khung tư duy đó: năm giai đoạn của Design Thinking và cách vận dụng chúng vào công việc thực tế.
Hãy nhớ: đây là bài tổng quan về toàn bộ quy trình. Các bài sau trong khóa sẽ đào sâu từng phần (ví dụ Bài 6 về "How Might We", Bài 7 về Crazy 8s, Bài 9 về wireframing). Ở bài này, mục tiêu của bạn là nắm được bức tranh lớn và hiểu vì sao mỗi giai đoạn lại quan trọng.
Khái niệm cốt lõi
Design Thinking được phổ biến bởi công ty thiết kế IDEO và trường d.school của Đại học Stanford. Mô hình phổ biến nhất chia quy trình thành năm giai đoạn: Empathize (Đồng cảm), Define (Xác định), Ideate (Lên ý tưởng), Prototype (Tạo nguyên mẫu), và Test (Kiểm thử).
Điều quan trọng cần hiểu ngay từ đầu: năm giai đoạn này không phải là một đường thẳng. Nó là một vòng lặp. Bạn có thể đang ở giai đoạn Test rồi nhận ra mình hiểu sai người dùng, và quay ngược về Empathize. Đó không phải thất bại — đó chính là bản chất của thiết kế tốt.
Giai đoạn 1 — Empathize (Đồng cảm)
Đây là giai đoạn bạn hiểu người dùng thật sâu. Không phải hiểu họ qua giả định trong đầu bạn, mà qua quan sát và lắng nghe thực tế. Ba phương pháp chính:
- Phỏng vấn (interviews): trò chuyện trực tiếp, hỏi về trải nghiệm và cảm xúc của họ, không hỏi về giải pháp họ muốn.
- Quan sát (observation): nhìn người dùng làm việc trong môi trường thật của họ. Họ thường làm khác với những gì họ nói.
- Thâm nhập (immersion): tự mình trải nghiệm như người dùng để cảm nhận nỗi đau của họ.
Nguyên tắc vàng của Empathize: gác lại cái tôi và mọi giả định. Bạn không phải người dùng. Sở thích của bạn không đại diện cho họ.
Giai đoạn 2 — Define (Xác định vấn đề)
Sau khi thu thập đầy đủ thông tin, bạn cần tổng hợp (synthesize) chúng lại thành một định nghĩa vấn đề rõ ràng. Đây là bước nhiều người bỏ qua, và đó là sai lầm chết người.
Kết quả của giai đoạn này thường là một problem statement (phát biểu vấn đề) hoặc Point of View (POV). Một POV tốt có cấu trúc: [Người dùng] cần [nhu cầu] vì [insight bất ngờ]. Ví dụ: "Chị Lan, một bà mẹ bận rộn ở TP.HCM, cần đặt bữa tối nhanh trong giờ tan tầm vì chị không có thời gian so sánh giá khi đang kẹt xe đón con."
Hãy chú ý: một problem statement tốt không chứa giải pháp. Nó chỉ mô tả vấn đề. Việc chọn giải pháp là chuyện của giai đoạn sau.
Giai đoạn 3 — Ideate (Lên ý tưởng)
Bây giờ mới đến lúc nghĩ giải pháp — và nghĩ thật nhiều. Mục tiêu của Ideate là số lượng trước, chất lượng sau. Bạn muốn càng nhiều ý tưởng càng tốt, kể cả những ý tưởng điên rồ, để không bị kẹt vào lựa chọn hiển nhiên đầu tiên.
Các kỹ thuật phổ biến gồm brainstorming nhóm, Crazy 8s (vẽ 8 ý tưởng trong 8 phút), và "How Might We" (Làm thế nào để chúng ta có thể...). Nguyên tắc quan trọng: trong lúc tạo ý tưởng, không phán xét. Phán xét sẽ giết chết sự sáng tạo. Việc lọc và chọn ý tưởng tốt nhất sẽ làm sau.
Giai đoạn 4 — Prototype (Tạo nguyên mẫu)
Prototype là biến ý tưởng thành một thứ có thể chạm vào, có thể tương tác — dù còn rất thô. Mục đích không phải là làm ra sản phẩm hoàn hảo, mà là làm rẻ và nhanh để học hỏi.
Prototype có thể là bản vẽ tay trên giấy, một wireframe đơn giản, hay một bản nhấp được trong Figma. Triết lý ở đây: "fail fast, fail cheap" — thất bại sớm và rẻ còn hơn thất bại muộn và đắt. Một prototype giấy mất 30 phút giúp bạn phát hiện sai lầm trước khi đội kỹ thuật mất ba tuần code.
Giai đoạn 5 — Test (Kiểm thử)
Bạn đưa prototype cho người dùng thật và quan sát họ dùng nó. Đây là lúc bạn kiểm chứng xem giả định của mình đúng hay sai.
Nguyên tắc khi test: bạn đang test thiết kế, không phải test người dùng. Nếu họ không hiểu cách dùng, đó là lỗi của bạn, không phải lỗi của họ. Hãy đặt câu hỏi mở ("Bạn đang nghĩ gì lúc này?"), quan sát chỗ họ vấp, và đừng vội giải thích hay bào chữa.
Kết quả của Test sẽ đẩy bạn quay lại một giai đoạn trước đó — có thể là tinh chỉnh prototype, có thể là định nghĩa lại vấn đề. Và đó chính là vòng lặp Design Thinking.
Tình huống thực tế
Ví dụ 1 — Grab và bài toán tài xế không biết chữ tốt
Khi Grab mở rộng tại Đông Nam Á, đội thiết kế phát hiện nhiều tài xế xe ôm ở Việt Nam và Indonesia không quen với giao diện app phức tạp, một số còn đọc chữ chậm. Thay vì giả định "ai cũng dùng smartphone thành thạo", đội ngũ đã xuống đường (Empathize), ngồi sau xe quan sát tài xế thao tác khi đang chạy.
Họ phát hiện vấn đề thật (Define): tài xế cần nhận và xác nhận cuốc xe chỉ bằng một thao tác, trong điều kiện vừa lái xe vừa nhìn màn hình dưới nắng gắt. Từ đó họ Ideate ra nhiều phương án và Prototype giao diện với nút bấm cực lớn, âm thanh thông báo rõ ràng, ít chữ và nhiều biểu tượng. Sau khi Test với tài xế thật ngoài đường, họ tinh chỉnh kích thước nút và độ tương phản màu.
Bài học: Nếu Grab chỉ ngồi trong văn phòng thiết kế theo cảm tính của dân văn phòng thành thị, họ đã tạo ra một app đẹp nhưng vô dụng với chính người dùng cốt lõi của mình. Đồng cảm thực địa thay đổi hoàn toàn thiết kế.
Ví dụ 2 — Ngân hàng số và mẫu đăng ký 22 trường
Một ngân hàng số tại Việt Nam (tạm gọi là dự án "FinApp") gặp tình trạng tỷ lệ bỏ dở khi đăng ký mở tài khoản lên tới 68%. Đội sản phẩm ban đầu cho rằng vấn đề là "màu nút chưa đủ nổi bật" và định đổi màu nút thành cam.
May mắn là designer đã yêu cầu làm đúng quy trình. Họ Empathize bằng cách mời 8 người dùng thật vào phòng và nhờ họ đăng ký, vừa làm vừa nói suy nghĩ. Kết quả: không ai phàn nàn về màu nút. Vấn đề thật (Define) là biểu mẫu đăng ký có 22 trường thông tin trên một màn hình, khiến người dùng choáng ngợp và bỏ cuộc ở giữa chừng.
Đội Ideate ra giải pháp chia nhỏ thành quy trình nhiều bước với thanh tiến trình, Prototype ngay trong Figma và Test lại với 5 người. Tỷ lệ hoàn thành trong bản thử tăng rõ rệt. Sau khi triển khai thật, tỷ lệ bỏ dở giảm từ 68% xuống còn khoảng 41%.
Bài học: Giải pháp "đổi màu nút" xuất phát từ giả định trong đầu, không từ dữ liệu. Một giờ quan sát người dùng đã tiết kiệm hàng tuần làm sai hướng. Define đúng vấn đề quan trọng hơn vẽ đẹp.
Ví dụ 3 — Ứng dụng học tiếng Anh cho học sinh tỉnh
Một startup edtech muốn làm app luyện nói tiếng Anh cho học sinh cấp 2 ở các tỉnh. Giả định ban đầu: học sinh cần nhiều bài học chất lượng cao. Nhưng khi Empathize — về tận một trường ở Đồng Tháp — đội ngũ phát hiện điều bất ngờ: nhiều em dùng điện thoại cũ của bố mẹ, mạng yếu, và ngại nói vì sợ bạn bè cười.
Vấn đề thật (Define) không phải "thiếu bài học" mà là "rào cản tâm lý và kỹ thuật khi luyện nói". Đội Ideate ra ý tưởng cho phép luyện nói riêng tư với AI thay vì trước lớp, và tối ưu app chạy được offline. Họ làm một Prototype giấy đơn giản mô phỏng luồng "luyện nói một mình với robot", rồi Test với chính các em.
Bài học: Nếu cứ làm theo giả định ban đầu, sản phẩm sẽ giải sai bài toán. Đồng cảm với bối cảnh thật (thiết bị, mạng, tâm lý) mới lộ ra vấn đề cốt lõi.
Hướng dẫn từng bước
Đây là cách bạn áp dụng quy trình Design Thinking vào một dự án thật, từ đầu đến cuối:
Bước 1 — Bắt đầu bằng Empathize, đừng bằng Figma. Trước khi mở công cụ thiết kế, hãy nói chuyện với ít nhất 5 người dùng mục tiêu. Hỏi về trải nghiệm và nỗi đau của họ, không hỏi "bạn muốn tính năng gì". Ghi chép lại bằng lời của chính họ.
Bước 2 — Tổng hợp thành empathy map. Sau phỏng vấn, gom các quan sát vào bốn ô: Nói / Nghĩ / Làm / Cảm thấy. Tìm những mâu thuẫn (ví dụ: họ nói thích nhưng hành vi cho thấy không dùng) — đó thường là nơi ẩn chứa insight.
Bước 3 — Viết problem statement. Dùng cấu trúc POV: [Người dùng] cần [nhu cầu] vì [insight]. Kiểm tra: nếu câu của bạn đã chứa giải pháp, hãy viết lại. Problem statement chỉ mô tả vấn đề.
Bước 4 — Ideate không phán xét. Đặt hẹn giờ 8 phút, vẽ càng nhiều phương án càng tốt. Đừng dừng lại đánh giá ý tưởng nào hay. Sau khi hết giờ, mới chấm điểm và chọn 1–2 hướng để phát triển.
Bước 5 — Prototype ở mức thấp nhất đủ để học hỏi. Đừng đánh bóng. Một bản vẽ tay hay wireframe xám trắng là đủ. Mục tiêu là kiểm chứng ý tưởng, không phải khoe kỹ năng.
Bước 6 — Test với người dùng thật. Đưa prototype cho 5 người (con số 5 là đủ để lộ ra phần lớn vấn đề lớn). Quan sát họ làm, ghi lại chỗ vấp. Đừng giải thích trước.
Bước 7 — Lặp lại. Dựa trên kết quả test, quay về giai đoạn phù hợp. Lặp cho đến khi thiết kế giải quyết được vấn đề một cách trơn tru.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhảy thẳng vào giải pháp. Đây là lỗi phổ biến nhất. Bạn nghe một vấn đề và lập tức nghĩ "à làm cái nút này là xong". Hãy ép bản thân ở lại với vấn đề lâu hơn. Mẹo: trước khi vẽ bất cứ thứ gì, viết ra problem statement và đọc to lên — nếu nó chứa giải pháp, bạn đang đi quá nhanh.
Lỗi 2 — Phỏng vấn kiểu dẫn dắt. Hỏi "Bạn có thích tính năng X không?" sẽ luôn nhận được câu trả lời lịch sự "có". Mẹo: hỏi về quá khứ và hành vi cụ thể: "Lần gần nhất bạn đặt đồ ăn online là khi nào? Lúc đó có gì khó chịu không?"
Lỗi 3 — Coi Design Thinking là đường thẳng. Nhiều người làm tuần tự một lần rồi nghĩ là xong. Mẹo: hãy xem nó là vòng lặp. Mỗi lần test xong đều là cơ hội quay lại học thêm. Đừng ngại quay về Empathize.
Lỗi 4 — Đánh bóng prototype quá sớm. Bỏ ba ngày làm prototype đẹp lung linh rồi không nỡ vứt đi khi nó sai. Mẹo: prototype càng xấu thì bạn càng dễ thay đổi, và người test càng thoải mái chê thẳng.
Lỗi 5 — Bỏ qua bước Test vì "không có thời gian". Test với 5 người chỉ mất một buổi nhưng tiết kiệm hàng tuần. Mẹo: test với 5 người đã đủ phát hiện khoảng 80% vấn đề khả dụng nghiêm trọng.
Bài tập thực hành
Hãy chọn một sản phẩm số bạn dùng hằng ngày (ví dụ app ngân hàng, app gọi xe, hoặc một website thương mại điện tử Việt Nam) và thực hiện một vòng Design Thinking thu nhỏ:
- Empathize: Tìm 3 người quen có dùng sản phẩm đó. Phỏng vấn mỗi người 10 phút về một tác vụ cụ thể (ví dụ "lần gần nhất bạn chuyển tiền"). Ghi lại bằng đúng lời họ nói.
- Define: Tổng hợp thành một empathy map và viết một problem statement theo cấu trúc POV. Tự kiểm tra: câu của bạn có chứa giải pháp không? Nếu có, viết lại.
- Ideate: Đặt hẹn giờ 8 phút, vẽ ra ít nhất 6 ý tưởng giải quyết vấn đề đó trên giấy. Không phán xét trong lúc vẽ.
- Prototype: Chọn 1 ý tưởng và vẽ tay 3–4 màn hình thể hiện luồng giải quyết vấn đề.
- Test: Đưa bản vẽ cho 1 người trong số đã phỏng vấn, nhờ họ "dùng thử" và nói suy nghĩ. Ghi lại 3 chỗ họ vấp.
Tóm tắt
- Design Thinking là tư duy giải quyết vấn đề lấy con người làm trung tâm, không phải bộ công cụ vẽ vời.
- Quy trình gồm 5 giai đoạn: Empathize (đồng cảm sâu với người dùng), Define (xác định đúng vấn đề), Ideate (tạo thật nhiều ý tưởng), Prototype (làm nguyên mẫu rẻ và nhanh), Test (kiểm thử với người dùng thật).
- Đây là một vòng lặp, không phải đường thẳng. Quay lại giai đoạn trước là điều bình thường và cần thiết.
- Sai lầm lớn nhất là nhảy thẳng vào giải pháp trước khi hiểu vấn đề. Define đúng quan trọng hơn vẽ đẹp.
- Các ví dụ Grab, ngân hàng số và app edtech cho thấy: đồng cảm thực địa thường lật ngược hoàn toàn giả định ban đầu, giúp bạn giải đúng bài toán.
- Đây là nền móng cho toàn bộ khóa học. Mọi kỹ năng phía sau đều phục vụ cho quy trình tư duy này.