title: "Tư duy về trải nghiệm người dùng (UX): Đặt người dùng cuối của khách hàng làm trung tâm"
series: "Thư viện Kỹ năng BA·PO·EA: 45 Bài học Thực chiến"
part: "Phần 3 — Tư duy Chiến lược & Tầm nhìn"
skill_number: 40
audience: "BA, PO, EA & vai trò làm việc trực tiếp với khách hàng"
reading_time: "10 phút đọc"
tags: ["UX", "user-centered design", "stakeholder management", "product ownership", "requirements", "BA skills"]

Tư duy về trải nghiệm người dùng (UX): Đặt người dùng cuối của khách hàng làm trung tâm

Người ký hợp đồng không phải lúc nào cũng là người ngồi gõ phần mềm 8 tiếng mỗi ngày. Khi hai nhóm này muốn hai thứ khác nhau — một bên cần cái nhìn "ấn tượng" để báo cáo lên trên, một bên cần cái nút bấm không làm họ chậm tay giữa ca — bạn, người BA/PO ngồi giữa, sẽ chọn ai? Đây là tình huống lặp đi lặp lại trong gần như mọi dự án B2B, và cách bạn xử lý nó quyết định phần mềm có thực sự được dùng hay chỉ nằm im sau lễ nghiệm thu.

🎯 Kỹ thuật cốt lõi: Phân biệt "Buyer" và "End User"

Trong mọi dự án doanh nghiệp, gần như luôn tồn tại một khoảng cách giữa hai vai trò:

• Buyer / Decision Maker (Người quyết định mua) — thường là giám đốc, trưởng phòng, người ký ngân sách. Họ quan tâm đến ROI, tiến độ, hình ảnh trước cấp trên/hội đồng quản trị, và những gì nhìn thấy được trong buổi demo hoặc báo cáo.
• End User (Người dùng cuối thực tế) — nhân viên vận hành, thu ngân, kế toán, công nhân kho, người trực tổng đài... Họ không có tiếng nói trong việc chọn nhà cung cấp, nhưng lại là người thao tác với hệ thống mỗi ngày, hàng trăm lượt, dưới áp lực thời gian thật.

Hai nhóm này đánh giá "tốt" theo hai tiêu chí hoàn toàn khác nhau:

Nguyên tắc hành động tổng quát (áp dụng được cho bất kỳ dự án nào, không riêng CNTT):

1. Lập bản đồ vai trò (Role Mapping) ngay từ đầu dự án: với mỗi yêu cầu/tính năng, hỏi rõ "Ai là người sẽ dùng cái này, và người đó có mặt trong phòng họp yêu cầu không?" Nếu câu trả lời là "không", đó là tín hiệu đỏ.
2. Không để buyer tự thiết kế UX thay end user. Buyer có quyền quyết định phạm vi, ngân sách, ưu tiên chiến lược — nhưng không có đủ dữ liệu về thao tác vận hành hàng ngày. Vai trò của BA/PO là mang dữ liệu đó vào bàn, không phải áp đặt.
3. Dịch "yêu cầu ấn tượng" thành "yêu cầu vận hành được" — tìm phần lõi nhu cầu thật của buyer (thường là muốn chứng minh giá trị, muốn kiểm soát, muốn báo cáo đẹp) và thiết kế giải pháp đáp ứng đúng phần lõi đó mà không đánh đổi trải nghiệm vận hành.
4. Dùng bằng chứng thay vì quan điểm — quan sát thực tế, đo thời gian thao tác, mô phỏng luồng việc thật, để cuộc tranh luận "tôi nghĩ" biến thành "chúng ta cùng thấy".

Bối cảnh (Situation)

Tình huống dưới đây là minh hoạ tổng hợp, xây dựng từ các mẫu hình lặp lại trong nhiều dự án CNTT tại Việt Nam, không phải case cụ thể của một công ty có thật.

Chị H., BA của một dự án triển khai hệ thống quản lý bán hàng (POS + kho) cho một chuỗi cửa hàng bán lẻ tại Hà Nội, đang ở tuần thứ sáu của giai đoạn thiết kế chi tiết. Phía khách hàng có hai đầu mối chính: anh T., Giám đốc Vận hành (COO) — người ký hợp đồng và là người quyết định cuối cùng về ngân sách/phạm vi — và chị L., trưởng ca tại một trong các cửa hàng, người sẽ trực tiếp đứng quầy thu ngân trong giờ cao điểm.

Trong buổi họp thiết kế màn hình thanh toán, anh T. đưa ra yêu cầu: màn hình checkout phải hiển thị một dashboard nhỏ ở góc trên — biểu đồ doanh thu theo giờ, số lượng khách đã phục vụ, tiến độ so với chỉ tiêu ngày — để "khi nào sếp lớn ghé cửa hàng, nhìn màn hình là thấy ngay hiệu quả vận hành, rất chuyên nghiệp". Anh T. rất tâm đắc với ý tưởng này, đã nhắc đến nó trong ba cuộc họp liên tiếp và xem đây như một điểm nhấn để báo cáo lên Hội đồng quản trị.

Chị L., người duy nhất trong phòng họp thực sự đứng quầy mỗi ngày, chỉ nói nhỏ một câu trước khi cuộc họp chuyển sang chủ đề khác: "Bọn em thao tác rất nhanh, nhìn cái gì lằng nhằng trên màn hình lúc khách đang xếp hàng là dễ bấm nhầm lắm chị ạ." Không ai trong phòng họp phản ứng gì thêm.

Thách thức (Task)

Chị H. đứng trước một tình huống khó xử rõ ràng:

• Nếu làm đúng như anh T. muốn, dashboard sẽ chiếm không gian màn hình, thêm độ trễ tải dữ liệu, và có nguy cơ khiến quầy thu ngân — nơi tốc độ thao tác được tính bằng giây trong giờ cao điểm — chậm lại hoặc gây nhầm lẫn thao tác (mắt bị phân tán bởi biểu đồ động, tay bấm sai nút vì bố cục đổi).
• Nếu chị H. phản đối thẳng ("Anh T. ơi, ý này không hay đâu"), rất dễ chạm tự ái của người quyết định ngân sách — người đang tâm đắc với ý tưởng của chính mình và đã "quảng cáo" nó với cấp trên.
• Nếu chị H. im lặng làm theo, tính năng sẽ được nghiệm thu, hợp đồng vẫn ký, nhưng ba tháng sau khi go-live, nhân viên thu ngân ở tất cả chi nhánh sẽ vật lộn với nó mỗi ngày — và rốt cuộc anh T. cũng là người phải giải trình khi năng suất giảm hoặc khách hàng phàn nàn xếp hàng lâu.

Cái khó ở đây không phải là "ai đúng ai sai" về mặt kỹ thuật — mà là làm sao đưa tiếng nói của người không có quyền quyết định (end user) vào một quyết định đang được đóng khung theo ý muốn của người có quyền quyết định (buyer), mà không biến cuộc họp thành một cuộc đối đầu.

Hành động (Action)

Chị H. không phản bác ngay trong cuộc họp. Cô áp dụng kỹ thuật phân biệt buyer/end-user theo bốn bước:

Bước 1 — Xác định đúng "nhu cầu lõi" đằng sau yêu cầu của buyer.
Sau cuộc họp, chị H. hẹn riêng anh T. 15 phút, không phải để tranh luận về dashboard, mà để hỏi: "Anh muốn khi sếp lớn ghé cửa hàng, họ thấy được điều gì cụ thể?" Câu trả lời của anh T. hé lộ nhu cầu thật: anh không cần chính cái dashboard đó ở đúng vị trí đó — anh cần có cách chứng minh hiệu quả vận hành cho cấp trên, bất cứ lúc nào, không nhất thiết phải ngay trên màn hình thu ngân.

Bước 2 — Thu thập bằng chứng từ phía end user, không chỉ dựa vào cảm giác.
Chị H. dành nửa buổi sáng hôm sau đứng quan sát trực tiếp ba nhân viên thu ngân ở giờ cao điểm (10h-11h) tại một cửa hàng, bấm giờ từng giao dịch, đếm số thao tác chạm màn hình trung bình mỗi lượt khách (khoảng 4-6 chạm, 8-12 giây/giao dịch trong giờ đông). Cô cũng phỏng lại chị L. và hai nhân viên khác câu hỏi cụ thể: "Nếu thêm một khối thông tin động ở góc màn hình, các em nghĩ nó ảnh hưởng gì đến thao tác?" — ghi lại nguyên văn các mối lo: dễ bấm nhầm khi biểu đồ tự cập nhật đúng lúc đang thao tác, mỏi mắt vì màn hình "động" liên tục trong ca 8 tiếng.

Bước 3 — Thiết kế phương án dung hòa, tách bạch hai luồng trải nghiệm.
Thay vì tranh cãi "có hay không có dashboard", chị H. đề xuất tách hai luồng người dùng riêng:

• Màn hình thu ngân (nơi end user thao tác) giữ nguyên tối giản, không có widget động — chỉ tập trung vào tốc độ và độ chính xác giao dịch.
• Một màn hình/dashboard riêng — có thể truy cập trên tablet ở quầy quản lý, hoặc trên điện thoại của giám đốc khu vực — hiển thị đúng các chỉ số anh T. muốn (doanh thu theo giờ, tiến độ chỉ tiêu), cập nhật real-time, và có thể chiếu lên màn hình TV treo ở khu vực khách chờ nếu muốn "khoe" hiệu quả vận hành trước khách và cấp trên.

Bước 4 — Trình bày phương án bằng dữ liệu, không bằng ý kiến cá nhân.
Trong buổi họp tiếp theo, chị H. không nói "em nghĩ dashboard trên màn hình thu ngân không ổn". Cô trình bày: số liệu thao tác đo được, trích dẫn nguyên văn lo ngại của nhân viên vận hành, và đề xuất phương án 2-màn-hình kèm mô phỏng (wireframe) cho cả hai. Cô nhấn mạnh: "Phương án này giúp anh có công cụ báo cáo tốt hơn cả yêu cầu ban đầu — vì giờ đây anh có thể chiếu số liệu cho khách hàng thấy ngay tại quầy chờ, chứ không chỉ nằm im trên màn hình thu ngân mà ít ai để ý lúc đang xếp hàng."

Kết quả (Result)

Anh T. đồng ý ngay với phương án 2 màn hình — vì thực chất nó đáp ứng đúng nhu cầu "chứng minh hiệu quả" của anh, thậm chí tốt hơn (có thể trình chiếu công khai, không giới hạn trong lúc đứng cạnh máy thu ngân). Dashboard vận hành trở thành một điểm cộng bán hàng của chính công ty triển khai khi giới thiệu cho các chi nhánh khác.

Về phía vận hành: sau khi go-live, thời gian giao dịch trung bình tại quầy không tăng so với hệ thống cũ (khác với lo ngại ban đầu nếu giữ nguyên yêu cầu gốc), tỷ lệ thao tác sai giảm nhẹ nhờ màn hình tối giản hơn phiên bản cũ.

Điều chưa hoàn hảo: việc phải xây thêm một màn hình dashboard riêng khiến phát sinh thêm khoảng 8 ngày công phát triển ngoài kế hoạch ban đầu, và nhóm phải đàm phán lại một phần phạm vi/chi phí bổ sung với anh T. — chị H. thừa nhận nếu vấn đề này được phát hiện sớm hơn, ngay từ vòng thu thập yêu cầu đầu tiên (mời cả end user tham gia từ đầu thay vì chỉ nghe qua buyer), phần phát sinh này có thể tránh được hoàn toàn.

📋 Áp dụng ngay

• Với mỗi yêu cầu tính năng mới, luôn tự hỏi và ghi rõ trong tài liệu: "Ai là end user thực tế của tính năng này, và họ có đang ở trong phòng/kênh trao đổi yêu cầu không?"
• Khi buyer đưa ra một yêu cầu "ấn tượng", đừng phản bác ngay — hỏi thêm một câu để lộ ra nhu cầu lõi đằng sau: "Anh/chị muốn điều này chứng minh/giải quyết cụ thể điều gì?"
• Trước khi chốt thiết kế bất kỳ màn hình/quy trình nào ảnh hưởng đến thao tác hàng ngày, dành thời gian quan sát trực tiếp hoặc phỏng vấn ngắn người dùng cuối thật — dù chỉ 30 phút — thay vì suy đoán thay họ.
• Khi có xung đột giữa buyer và end user, tìm phương án tách bạch luồng trải nghiệm (ví dụ: hai màn hình, hai chế độ hiển thị) thay vì cố nhồi một giải pháp làm hài lòng cả hai trên cùng một giao diện.
• Trình bày phương án dung hòa bằng dữ liệu quan sát được (thời gian thao tác, trích dẫn người dùng), không bằng cảm nhận cá nhân của BA/PO.

💡 Bài học đúc rút: Người ký hợp đồng quyết định bạn có dự án hay không; người dùng cuối quyết định dự án đó có sống được sau ngày nghiệm thu hay không. Việc của BA/PO là không để một tiếng nói lớn hơn nuốt mất một tiếng nói đúng hơn — mà tìm ra phương án đáp ứng cả nhu cầu thật của buyer lẫn trải nghiệm thật của end user, thay vì buộc phải chọn một trong hai.

🔗 Kỹ năng liên quan

• Cách xử lý các bên liên quan (Stakeholder Management)
• Tư duy "Đơn giản hóa"
• Kỹ năng Coaching khách hàng

Bài trước: Kỹ năng "Kể chuyện" (Storytelling) · Bài tiếp theo: Xây dựng văn hóa hợp tác