Mở đầu — vì sao bài này quan trọng
Có một sự thật khó chịu mà nhiều đội Scrum né tránh: chúng ta dành 80% thời gian tranh luận về cách làm (how) — chia story thế nào, estimate ra sao, ưu tiên cái gì — nhưng lại dành rất ít thời gian thực sự hiểu người dùng là ai và họ cần gì. Backlog đầy ắp những "As a user, I want..." nhưng nếu bạn dừng lại hỏi cả đội "user này là ai cụ thể, một ngày của họ trông như thế nào, họ đang bực bội điều gì", thường sẽ có một khoảng lặng lúng túng.
Empathy Map (Bản đồ thấu cảm) là một công cụ trực quan đơn giản giúp lấp đúng khoảng trống đó. Nó buộc cả đội ngồi lại và nhìn người dùng qua nhiều lăng kính khác nhau — không chỉ "họ nói gì" mà còn "họ nghĩ gì", "họ cảm thấy gì", "họ làm gì". Với vai trò Scrum Master, đây là một trong những công cụ facilitation mạnh nhất bạn có thể đưa vào buổi refinement, sprint planning, hoặc một workshop riêng để cả đội cùng "đứng vào đôi giày" của khách hàng.
Vì sao điều này quan trọng với một Scrum Master? Bởi vì khi đội mất kết nối với người dùng thật, họ bắt đầu xây tính năng dựa trên giả định của chính mình. Họ tối ưu cho cái mà họ nghĩ là hay, chứ không phải cái người dùng thật sự dùng. Empathy Map là cách rẻ tiền, nhanh chóng để phơi bày những giả định đó ra ánh sáng — và biến chúng thành câu hỏi cần kiểm chứng thay vì sự thật được mặc định. Đây không phải công cụ của riêng Product Owner hay UX designer; nó là công cụ giúp cả đội chia sẻ chung một hiểu biết về con người mà họ đang phục vụ.
Khái niệm cốt lõi
Empathy Map là gì
Empathy Map là một tấm canvas chia thành các vùng (quadrant), mỗi vùng đại diện cho một góc nhìn về trải nghiệm của một người dùng cụ thể. Cả đội cùng điền vào các vùng này bằng giấy nhớ (sticky notes) hoặc trên bảng số (Miro, Mural, FigJam). Công cụ này được phổ biến rộng rãi bởi Dave Gray (tác giả cuốn Gamestorming) và sau đó được XPLANE tinh chỉnh.
Điểm cốt lõi cần nhớ: một Empathy Map luôn về MỘT người (persona) cụ thể, trong MỘT bối cảnh cụ thể. Nếu bạn cố vẽ một bản đồ cho "tất cả người dùng", nó sẽ trở nên chung chung và vô dụng. "Chị Lan, 34 tuổi, chủ một shop quần áo nhỏ trên Shopee, đang cố xử lý 50 đơn hàng một ngày" là một đối tượng tốt. "Người bán hàng online" thì quá rộng.
Bốn vùng kinh điển
Phiên bản classic của Empathy Map có bốn vùng, đặt một bức ảnh hoặc tên persona ở giữa:
Says (Nói gì) — Những câu, lời trích dẫn người dùng thực sự thốt ra. Đây là những gì bạn quan sát hoặc nghe được trực tiếp: "Tôi muốn xem được doanh thu hôm nay ngay khi mở app", "Tại sao cái nút này khó tìm vậy?". Vùng này nên dùng đúng lời của người dùng, không diễn giải.
Thinks (Nghĩ gì) — Những gì chiếm tâm trí người dùng nhưng họ có thể không nói ra. Niềm tin, mối bận tâm thầm kín: "Liệu mình có bị mất đơn nào không?", "App này có an toàn để nhập số tài khoản không?". So sánh Says và Thinks rất giàu thông tin — khoảng chênh giữa điều người dùng nói và điều họ nghĩ nhưng giấu thường chính là nơi cơ hội hoặc rủi ro nằm ở đó.
Does (Làm gì) — Hành vi và hành động cụ thể. Người dùng thực sự làm gì? "Mở app 15 lần một ngày", "Chụp màn hình đơn hàng rồi gửi qua Zalo cho nhân viên", "Ghi tay vào sổ vì không tin số liệu trên app". Vùng Does hay phơi bày những workaround — những cách lách mà người dùng tự nghĩ ra, và đó là vàng cho việc thiết kế tính năng.
Feels (Cảm thấy gì) — Trạng thái cảm xúc. Lo lắng, phấn khích, bực bội, an tâm. "Căng thẳng vào giờ cao điểm đơn hàng", "Tự hào khi thấy doanh số tăng", "Sợ làm sai thao tác mất tiền". Cảm xúc là động lực mạnh mẽ thúc đẩy hành vi, nhưng đội kỹ thuật thường bỏ qua nó.
Hai vùng mở rộng: Pains và Gains
Phiên bản phổ biến hơn (đặc biệt trong giới UX và Lean) bổ sung hai vùng ở dưới đáy bản đồ:
Pains (Nỗi đau) — Những trở ngại, nỗi sợ, sự thất vọng, rủi ro mà người dùng đối mặt. Cái gì cản đường họ đạt được điều họ muốn?
Gains (Lợi ích mong muốn) — Những điều người dùng khao khát đạt được, thước đo thành công của họ, mong muốn và giấc mơ.
Hai vùng này tạo cầu nối tự nhiên sang Value Proposition — bạn thiết kế tính năng để giảm Pains và tạo Gains. Với một Scrum Master, đây là điểm để gắn Empathy Map vào Sprint Goal: sprint này chúng ta đang giải quyết Pain nào, tạo Gain nào cho persona nào?
Empathy Map khác gì với Persona hay User Story
Cần phân biệt rõ để không nhầm lẫn. Persona là một hồ sơ tĩnh, đầy đủ về một nhóm người dùng (nhân khẩu học, mục tiêu, hành vi chung). User Story là một mẩu yêu cầu nhỏ ("As a... I want... so that..."). Empathy Map nằm ở giữa: nó là một hoạt động cộng tác để cả đội cùng xây dựng sự thấu cảm, thường tạo ra đầu vào cho cả persona lẫn user story. Sức mạnh của nó không chỉ ở sản phẩm cuối (tấm bản đồ), mà ở cuộc trò chuyện diễn ra khi mọi người cùng điền vào nó.
Tình huống thực tế
Ví dụ 1 — Tiki và đội phát triển tính năng cho người bán
Giả định một đội phát triển tại một sàn thương mại điện tử kiểu Tiki đang xây dựng dashboard mới cho người bán (seller). Ban đầu, đội tin chắc rằng seller cần nhiều biểu đồ phân tích chi tiết — họ dồn ba sprint để xây các báo cáo doanh thu theo tuần, theo danh mục, theo khung giờ.
Khi tính năng ra mắt, tỉ lệ sử dụng dashboard chỉ đạt 12%. Scrum Master đề xuất làm một buổi Empathy Map cho persona "anh Tuấn, chủ một shop phụ kiện điện thoại, bán khoảng 30 đơn/ngày, quản lý mọi thứ trên điện thoại". Đội mời hai seller thật vào phỏng vấn 30 phút rồi cùng điền bản đồ.
Kết quả phơi bày điều bất ngờ. Trong vùng Does: "Anh Tuấn mở dashboard buổi sáng, liếc một con số duy nhất — số đơn cần xử lý — rồi tắt đi." Trong vùng Feels: "Choáng ngợp khi thấy quá nhiều biểu đồ, sợ bỏ sót đơn hàng." Trong vùng Pains: "Không có thời gian phân tích; mỗi giây chậm trễ là khách hủy đơn." Hóa ra điều seller cần không phải báo cáo đẹp, mà là một con số hành động được hiển thị ngay lập tức.
Bài học rút ra: Đội đã xây dựng cho trí tưởng tượng của chính mình về một "seller phân tích dữ liệu", trong khi seller thật là một người vận hành bận rộn cần ra quyết định trong vài giây. Empathy Map không cứu được ba sprint đã lỡ, nhưng nó định hướng lại toàn bộ roadmap quý sau — và lần này tỉ lệ sử dụng dashboard rút gọn đạt 68%.
Ví dụ 2 — Một fintech ví điện tử và nỗi sợ thầm kín
Một startup ví điện tử (kiểu MoMo giai đoạn đầu) muốn tăng tỉ lệ người dùng liên kết tài khoản ngân hàng. Họ liên tục tối ưu giao diện màn hình liên kết: nút to hơn, ít bước hơn, màu sắc bắt mắt hơn. Tỉ lệ chuyển đổi nhích lên rồi chững lại ở mức 40%.
Scrum Master tổ chức một Empathy Map workshop cho persona "cô Hoa, 45 tuổi, nhân viên văn phòng, dùng ví để nạp điện thoại nhưng chưa liên kết ngân hàng". Khi đối chiếu vùng Says và Thinks, đội nhìn thấy điểm mấu chốt. Vùng Says: "Để lúc khác làm cũng được." Nhưng vùng Thinks (rút ra từ phỏng vấn sâu): "Liên kết ngân hàng nghĩa là app này nhìn thấy hết tiền của mình à? Lỡ bị hack thì sao? Con mình bảo mấy app này hay lừa người già."
Bài học rút ra: Vấn đề không nằm ở giao diện (cái mà đội cứ mãi tối ưu), mà nằm ở niềm tin và nỗi sợ trong vùng Thinks/Feels. Khoảng chênh giữa lời nói lịch sự ("để lúc khác") và nỗi sợ thật ("sợ mất tiền, sợ bị lừa") chính là rào cản. Đội xoay hướng: thay vì làm nút đẹp hơn, họ thêm một màn hình giải thích bảo mật bằng ngôn ngữ đời thường, thêm huy hiệu xác nhận của ngân hàng, và một video ngắn hướng dẫn. Đây là loại insight mà bạn không bao giờ tìm thấy nếu chỉ nhìn số liệu chuyển đổi — nó chỉ lộ ra khi đội buộc phải tách "Says" khỏi "Thinks".
Ví dụ 3 — Đội nội bộ xây công cụ cho chính nhân viên
Một ngân hàng tại Việt Nam có đội Agile xây phần mềm nội bộ cho giao dịch viên tại quầy. Đội ngồi cùng tòa nhà với người dùng nhưng nghịch lý là họ chưa từng ngồi quan sát một giao dịch viên làm việc thực tế trong giờ cao điểm.
Scrum Master đề xuất một buổi Empathy Map kết hợp với một giờ quan sát tại chi nhánh đông khách. Persona: "chị Mai, giao dịch viên, xử lý ~80 giao dịch/ngày, bị khách xếp hàng gây áp lực." Vùng Does ghi nhận: "Chị Mai dán giấy nhớ ghi phím tắt lên màn hình", "Mở ba cửa sổ phần mềm cùng lúc và Alt+Tab liên tục", "Gọi điện hỏi đồng nghiệp khi gặp giao dịch lạ vì sợ bấm sai." Vùng Pains: "Mỗi lần hệ thống treo 5 giây là cả hàng khách thở dài, áp lực kinh khủng."
Bài học rút ra: Việc quan sát hành vi thật (Does) đáng giá hơn ngàn lời mô tả yêu cầu. Những tờ giấy nhớ ghi phím tắt là bằng chứng phần mềm chưa thân thiện; việc Alt+Tab ba cửa sổ cho thấy luồng làm việc bị phân mảnh. Đội đưa hai cải tiến vào sprint kế: gộp ba màn hình thành một, và thêm phím tắt ngay trong giao diện. Empathy Map ở đây hoạt động như một cầu nối giữa "gần về địa lý" và "gần về thấu hiểu" — hai thứ không hề giống nhau.
Hướng dẫn từng bước
Dưới đây là cách bạn — với vai trò người điều phối — chạy một buổi Empathy Map từ đầu đến cuối. Thời lượng gợi ý: 60–90 phút.
Bước 1 — Chọn đúng đối tượng (5 phút). Xác định MỘT persona cụ thể và MỘT bối cảnh/mục tiêu của họ. Viết rõ lên đầu bảng: "Empathy Map cho [tên persona] khi họ đang cố [mục tiêu] trong tình huống [bối cảnh]". Nếu cả đội chưa đồng thuận persona là ai, hãy giải quyết việc này trước.
Bước 2 — Chuẩn bị canvas (3 phút). Vẽ bản đồ với các vùng: Says, Thinks, Does, Feels (và thêm Pains, Gains nếu dùng bản mở rộng). Đặt tên/ảnh persona ở trung tâm. Với đội từ xa, dùng template có sẵn trên Miro/Mural/FigJam.
Bước 3 — Nạp dữ liệu đầu vào (nếu có). Đây là bước quan trọng nhất quyết định chất lượng. Empathy Map sẽ chỉ là "đoán mò tập thể" nếu không có dữ liệu thật. Trước buổi họp, gom: bản ghi phỏng vấn người dùng, ticket support, khảo sát, số liệu hành vi, hoặc tốt nhất là mời 1–2 người dùng thật vào quan sát/phỏng vấn. Nếu hoàn toàn không có dữ liệu, hãy nói rõ với đội rằng bản đồ này là giả định cần kiểm chứng, không phải sự thật.
Bước 4 — Điền cá nhân, im lặng (10 phút). Mỗi người tự viết sticky note cho từng vùng, mỗi ý một note. Làm im lặng để tránh hiệu ứng đám đông (groupthink) và để mọi giọng nói đều được ghi nhận — kể cả dev ít nói. Một note = một quan sát cụ thể.
Bước 5 — Dán và phân nhóm (15 phút). Lần lượt từng người dán note lên đúng vùng và đọc to. Gom các note giống nhau lại thành cụm. Khi điền, gợi ý đội bắt đầu từ Does và Says (dễ quan sát) rồi mới sang Thinks và Feels (cần suy luận).
Bước 6 — Tìm khoảng chênh và insight (15 phút). Đây là phần tạo giá trị thật. Đặt các câu hỏi điều phối: "Có chỗ nào người dùng nói một đằng nhưng làm một nẻo không?" (so Says vs Does). "Điều gì họ nghĩ nhưng không dám nói?" (Thinks). "Pain lớn nhất là gì?" Khoanh tròn những insight bất ngờ.
Bước 7 — Chuyển thành hành động (10 phút). Một bản đồ đẹp mà không dẫn tới hành động thì vô nghĩa. Hỏi: "Pain nào đáng giải quyết nhất trong sprint tới?", "Giả định nào rủi ro nhất cần đi kiểm chứng?". Đầu ra cụ thể: vài backlog item mới, vài câu hỏi nghiên cứu cần làm rõ, hoặc một điều chỉnh cho Sprint Goal.
Bước 8 — Lưu lại và làm sống. Chụp ảnh bản đồ, treo nơi đội nhìn thấy, và cập nhật khi có dữ liệu mới. Empathy Map là tài liệu sống, không phải tác phẩm trưng bày một lần.
Lỗi thường gặp & mẹo
Lỗi 1 — Đối tượng quá rộng. "Người dùng nói chung" cho ra bản đồ chung chung vô dụng. Mẹo: luôn đặt tên cụ thể, một bối cảnh, một mục tiêu. Nếu có nhiều persona khác nhau, làm nhiều bản đồ riêng.
Lỗi 2 — Toàn là giả định, không dữ liệu. Đội ngồi trong phòng "tưởng tượng" người dùng nghĩ gì. Bản đồ trở thành tấm gương phản chiếu thiên kiến của đội. Mẹo: đánh dấu rõ note nào là fact (có dữ liệu) và note nào là assumption (giả định) — dùng hai màu sticky khác nhau. Mọi giả định rủi ro phải trở thành câu hỏi nghiên cứu.
Lỗi 3 — Nhầm Says với Thinks. Đội điền vùng Thinks bằng chính suy nghĩ của họ chứ không phải của người dùng. Mẹo: nhắc đội rằng Says là điều nghe trực tiếp, Thinks là suy luận từ hành vi và bối cảnh — và phải có lý do để suy luận đó.
Lỗi 4 — Bỏ qua vùng Feels. Đội kỹ thuật thấy "cảm xúc" mơ hồ nên lướt qua. Mẹo: nhấn mạnh rằng cảm xúc điều khiển hành vi — nỗi sợ làm người dùng bỏ cuộc, sự an tâm khiến họ trung thành. Bỏ qua Feels là bỏ qua động cơ thật.
Lỗi 5 — Làm xong rồi để đó. Bản đồ đẹp dán tường rồi không ai động đến. Mẹo: mỗi buổi phải kết bằng hành động cụ thể và một người chịu trách nhiệm. Liên kết bản đồ với backlog item thật.
Lỗi 6 — Scrum Master độc diễn. Bạn vẽ sẵn rồi trình bày cho đội. Mẹo: giá trị nằm ở việc cả đội cùng làm. Vai trò của bạn là điều phối và đặt câu hỏi, không phải là tác giả duy nhất.
Mẹo bối cảnh Việt Nam: Người dùng Việt thường lịch sự, ngại chê thẳng ("cũng được", "ổn mà") — nên vùng Says hay bị "làm đẹp". Hãy đặc biệt chú trọng quan sát vùng Does (hành vi thật) và đào sâu vùng Thinks. Khoảng chênh giữa lời nói lịch sự và hành vi thật ở đây thường rất lớn và rất giàu insight.
Bài tập thực hành
Bài tập 1 — Cá nhân (30 phút). Chọn một tính năng gần đây nhất đội bạn vừa làm. Tự vẽ một Empathy Map cho persona dùng tính năng đó. Sau khi điền xong bằng giả định của bạn, đánh dấu mỗi note: bạn có dữ liệu thật để chứng minh nó không? Đếm xem bao nhiêu % note là sự thật và bao nhiêu là giả định. Con số này nói lên mức độ đội bạn thực sự hiểu người dùng.
Bài tập 2 — Cùng đội (90 phút). Tổ chức một buổi Empathy Map thật cho một persona quan trọng trong sprint hiện tại. Trước buổi họp, hãy gom ít nhất một nguồn dữ liệu thật (3 ticket support, hoặc một phỏng vấn 20 phút với người dùng). Chạy theo 8 bước ở trên. Kết thúc bằng việc tạo ra ít nhất 2 backlog item và 2 câu hỏi nghiên cứu.
Bài tập 3 — So sánh Says vs Does (kéo dài 1 tuần). Chọn một người dùng và thực sự quan sát họ dùng sản phẩm 15 phút (hoặc xem session recording). Ghi lại những gì họ làm vào vùng Does. Sau đó hỏi họ "anh/chị thấy phần này thế nào?" và ghi câu trả lời vào Says. Đối chiếu hai vùng. Viết ra một đoạn ngắn về khoảng chênh bạn phát hiện và ý nghĩa của nó.
Tóm tắt
Empathy Map là một công cụ trực quan, cộng tác giúp cả đội Scrum nhìn người dùng qua nhiều lăng kính: Says (nói gì), Thinks (nghĩ gì), Does (làm gì), Feels (cảm thấy gì) — và mở rộng với Pains và Gains. Sức mạnh thật của nó không nằm ở tấm bản đồ cuối cùng mà ở cuộc trò chuyện chung mà nó tạo ra, và ở những khoảng chênh nó phơi bày — đặc biệt giữa điều người dùng nói và điều họ thật sự làm hay nghĩ.
Với vai trò Scrum Master, hãy nhớ ba nguyên tắc: (1) luôn về MỘT persona cụ thể trong MỘT bối cảnh; (2) nạp dữ liệu thật, hoặc thành thật đánh dấu đâu là giả định cần kiểm chứng; (3) mỗi buổi phải kết bằng hành động cụ thể — backlog item hoặc câu hỏi nghiên cứu. Khi đội bạn bắt đầu tranh luận về người dùng thật thay vì giả định của chính mình, bạn đã hoàn thành công việc quan trọng nhất của công cụ này: kéo cả đội ra khỏi đầu họ và đặt vào đôi giày của người mà họ đang phục vụ.