Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn là BA của một ngân hàng số tại Việt Nam. Đội kinh doanh đưa cho bạn một bản brief ngắn gọn: "Khách hàng trẻ không dùng tính năng tiết kiệm tự động của app, hãy thu thập yêu cầu để cải tiến". Theo phản xạ, bạn lập tức đi phỏng vấn, hỏi: "Anh/chị muốn tính năng tiết kiệm có thêm gì?" Và bạn nhận được một mớ câu trả lời mâu thuẫn: người muốn lãi suất cao hơn, người muốn rút linh hoạt, người bảo "tôi không quan tâm". Bạn về viết một danh sách yêu cầu dài, đội dev làm xong, và sáu tháng sau tỉ lệ sử dụng vẫn không nhúc nhích.
Vấn đề ở đây không phải kỹ thuật phỏng vấn của bạn kém. Vấn đề là bạn đã giải quyết một bài toán mà chưa ai thực sự định nghĩa đúng. Người dùng không "không thích tính năng tiết kiệm" — họ không tin rằng mình có khả năng tiết kiệm, nên không buồn mở tính năng đó ra xem.
Đây chính là lúc Design Thinking phát huy giá trị cho một BA. Design Thinking (tư duy thiết kế) là một phương pháp tiếp cận lấy con người làm trung tâm để khám phá đúng vấn đề trước khi lao vào giải pháp. Trong vai trò elicitation (thu thập yêu cầu), Design Thinking workshop là một định dạng workshop đặc biệt — không phải để chốt requirements như JAD, không phải để brainstorm tính năng đơn thuần, mà để cùng stakeholder thấu hiểu người dùng, định hình lại vấn đề, và sản sinh ý tưởng giải pháp dưới góc nhìn của người dùng. Đây là kỹ năng giúp bạn bước từ "người ghi chép yêu cầu" lên thành "người định hình bài toán" — một bước nhảy lớn trong sự nghiệp BA.
Khái niệm cốt lõi
Design Thinking là gì và khác gì với elicitation thông thường
Design Thinking, theo mô hình của Stanford d.school, là quy trình 5 giai đoạn lặp lại nhằm giải quyết các vấn đề phức tạp, mơ hồ, nơi mà chính nhu cầu người dùng cũng chưa rõ ràng. Điểm khác biệt cốt lõi so với elicitation truyền thống nằm ở chỗ: phỏng vấn hay workshop thông thường thường giả định rằng "bài toán đã đúng, ta chỉ cần lấy chi tiết yêu cầu". Design Thinking lại đặt câu hỏi ngược: "Liệu ta có đang giải đúng bài toán không?"
Với một BA, Design Thinking đặc biệt hữu ích khi bạn đối mặt với cái gọi là "wicked problem" — vấn đề kiểu khó định hình: chuyển đổi số một quy trình cũ, ra mắt sản phẩm cho thị trường mới, hay khi stakeholder mỗi người nói một kiểu mà chẳng ai sai.
Năm giai đoạn của Design Thinking (Stanford d.school)
1. Empathize (Đồng cảm). Quan sát và lắng nghe người dùng thật trong bối cảnh thật của họ. Mục tiêu không phải hỏi "bạn muốn gì" mà là hiểu họ đang làm gì, cảm thấy gì, và vướng mắc ở đâu. Đây là phần giao thoa mạnh nhất với kỹ năng elicitation: bạn dùng quan sát (observation), phỏng vấn sâu (in-depth interview), và lắng nghe chủ động.
2. Define (Định nghĩa vấn đề). Từ những gì thu được ở giai đoạn Empathize, bạn cô đọng thành một phát biểu vấn đề rõ ràng — gọi là POV statement (Point of View). Công thức kinh điển: [Người dùng cụ thể] cần [nhu cầu] bởi vì [insight bất ngờ]. Ví dụ: "Một nhân viên văn phòng 25 tuổi cần cảm thấy mình có thể tiết kiệm, bởi vì họ tin rằng tiết kiệm là việc của người giàu." POV statement chính là "requirement gốc" định hướng mọi thứ sau này.
3. Ideate (Lên ý tưởng). Sản sinh càng nhiều ý tưởng giải pháp càng tốt cho POV đã định nghĩa. Đây là lúc dùng các kỹ thuật sáng tạo có cấu trúc. Nguyên tắc vàng: tách bạch việc tạo ý tưởng và việc đánh giá ý tưởng — đừng phán xét khi đang phun ý tưởng.
4. Prototype (Tạo mẫu thử). Biến ý tưởng triển vọng nhất thành một thứ hữu hình để người dùng có thể phản hồi — bản vẽ tay, sơ đồ luồng, hay màn hình giả lập đơn giản. Ở đây ta chỉ làm mẫu vừa đủ để học hỏi, không phải để giao cho dev.
5. Test (Kiểm thử). Đưa prototype cho người dùng thật để thu phản hồi, từ đó quay lại tinh chỉnh POV hoặc ý tưởng. Design Thinking là vòng lặp, không phải đường thẳng — bạn có thể quay về Empathize bất cứ lúc nào.
Vai trò của BA trong Design Thinking workshop
Trong workshop kiểu này, BA thường đóng ba vai cùng lúc: người facilitate (dẫn dắt nhịp độ workshop), người synthesizer (tổng hợp dữ liệu thô thành insight và POV), và người người gác cổng phạm vi (đảm bảo các ý tưởng cuối cùng quy đổi được thành requirements khả thi). Khác với designer thuần — vốn tập trung vào trải nghiệm — BA luôn giữ một chân ở thực tế nghiệp vụ: ràng buộc hệ thống, quy định pháp lý, ngân sách.
Tình huống thực tế
Ví dụ 1 — Ngân hàng số: từ "thêm tính năng" đến "thay đổi niềm tin"
Quay lại câu chuyện ở đầu bài. Một ngân hàng số giả định tên TPNeo có app với 800.000 người dùng, nhưng chỉ 4% dùng tính năng "Tiết kiệm tự động". BA tổ chức một Design Thinking workshop nửa ngày với 8 người: 2 từ sản phẩm, 2 từ marketing, 1 từ vận hành, 1 từ tuân thủ, và bản thân BA cùng một designer.
Ở giai đoạn Empathize, trước workshop BA đã đi quan sát và phỏng vấn 6 người dùng trẻ. Một câu nói ám ảnh: "Mỗi tháng cuối tháng em mới biết còn dư bao nhiêu, làm sao đặt mục tiêu trước được." Trong workshop, BA chiếu lại các đoạn ghi âm này (empathy map). Ở giai đoạn Define, cả nhóm chốt POV: "Người dùng trẻ thu nhập biến động cần một cách tiết kiệm theo những gì còn dư chứ không phải số tiền cố định, vì họ sợ cam kết một con số rồi không kham nổi và thấy mình thất bại."
Bước Ideate cho ra 30 ý tưởng trong 20 phút, trong đó nổi lên ý "làm tròn giao dịch" (round-up) — mỗi lần chi tiêu sẽ làm tròn và bỏ phần lẻ vào tiết kiệm. Prototype chỉ là 4 màn hình vẽ trên Figma trong 1 giờ. Test với 3 người dùng ngay chiều hôm đó cho phản hồi tích cực.
Bài học rút ra: Yêu cầu thật ("tiết kiệm theo số dư còn lại / round-up") chỉ lộ ra khi nhóm định nghĩa lại vấn đề từ góc nhìn niềm tin của người dùng, thay vì hỏi thẳng "muốn thêm gì". Nếu chỉ phỏng vấn truyền thống, BA hẳn đã viết requirement "cho phép tùy chỉnh số tiền tiết kiệm" — đúng nhưng vô dụng.
Ví dụ 2 — Tiki và bài toán hoàn trả (giả định minh họa)
Một sàn TMĐT lớn (lấy bối cảnh giống Tiki) nhận thấy tỉ lệ khách bỏ giỏ hàng cao bất thường ở nhóm hàng thời trang. Đội sản phẩm nghĩ ngay đến giải pháp "giảm phí ship". BA đề xuất một Design Thinking workshop 3 giờ trước khi cam kết bất kỳ thay đổi nào.
Giai đoạn Empathize hé lộ điều bất ngờ: khách không ngại phí ship, họ sợ "mua về không vừa rồi đổi trả phiền phức". POV được định hình: "Người mua quần áo online cần chắc chắn về việc đổi trả dễ dàng ngay trước khi bấm mua, vì rủi ro size sai khiến họ chần chừ." Ideate sinh ra ý tưởng hiển thị chính sách đổi trả 7 ngày ngay tại nút thanh toán, kèm minh họa "đổi size miễn phí". Prototype là một biến thể màn hình checkout. Kết quả test định tính cho thấy mức độ tự tin của khách tăng rõ rệt.
Bài học rút ra: Design Thinking giúp BA chặn một quyết định tốn kém sai hướng (giảm phí ship — ăn vào biên lợi nhuận) và chuyển ngân sách sang một thay đổi rẻ hơn, đúng vào nỗi lo thật. Đây chính là giá trị "định hình bài toán" mà một BA giỏi mang lại.
Ví dụ 3 — Bệnh viện và quy trình tiếp đón nội bộ
Một bệnh viện tư tại TP.HCM muốn số hóa quy trình tiếp đón bệnh nhân. Người dùng ở đây không phải khách hàng mà là điều dưỡng và lễ tân nội bộ. BA tổ chức workshop với chính các nhân viên này. Giai đoạn Empathize bằng kỹ thuật "shadowing" (đi theo quan sát) cho thấy lễ tân phải nhập một thông tin tới ba lần ở ba màn hình khác nhau. POV: "Lễ tân giờ cao điểm cần nhập thông tin một lần duy nhất, vì việc nhập lại gây xếp hàng dài và sai sót." Nhóm ideate ra ý "một form gom toàn bộ", prototype bằng giấy, test ngay với lễ tân.
Bài học rút ra: Design Thinking không chỉ dành cho sản phẩm hướng khách hàng. Với các dự án internal/quy trình, "người dùng" chính là nhân viên — và đồng cảm với họ thường lộ ra những lãng phí mà không buổi họp lấy yêu cầu kiểu hỏi-đáp nào tìm ra được.
Hướng dẫn từng bước
Dưới đây là cách một BA chuẩn bị và chạy một Design Thinking workshop, áp vào ngữ cảnh thu thập yêu cầu.
Bước 1 — Trước workshop: làm sẵn phần Empathize. Đừng đợi đến hôm workshop mới đi đồng cảm. Trước đó 1–2 tuần, hãy phỏng vấn 5–8 người dùng thật, quan sát họ thao tác, và mang dữ liệu thô (trích dẫn, ảnh, video ngắn) vào phòng. Đây là "nguyên liệu" để cả nhóm cùng đồng cảm, tránh việc cả buổi ngồi đoán mò.
Bước 2 — Chọn đúng người và đặt mục tiêu. Mời 6–10 người đa chức năng: sản phẩm, kỹ thuật, vận hành, và nếu được, một người dùng thật. Viết rõ một câu "How Might We" (Làm thế nào để chúng ta có thể...) làm tiêu điểm, ví dụ: "Làm thế nào để chúng ta giúp người dùng trẻ thấy việc tiết kiệm là khả thi?"
Bước 3 — Empathize trong phòng bằng Empathy Map. Chia bảng thành bốn ô: Says (nói gì), Thinks (nghĩ gì), Does (làm gì), Feels (cảm thấy gì). Cả nhóm dán sticky note dựa trên dữ liệu thật bạn mang đến. Mục tiêu là cùng nhìn người dùng bằng một đôi mắt.
Bước 4 — Define: viết POV statement. Từ empathy map, rút ra 2–3 insight bất ngờ, rồi viết POV theo công thức [ai] cần [gì] vì [insight]. Cả nhóm bỏ phiếu chọn một POV để theo đuổi. Đây là output quan trọng nhất với BA — nó sẽ trở thành business need gốc trong tài liệu sau này.
Bước 5 — Ideate có cấu trúc. Đặt giờ 15–20 phút, mỗi người viết ý tưởng lên sticky note (im lặng trước, nói sau — kỹ thuật brainwriting để tránh người nói to lấn át). Nhắc nguyên tắc: không phán xét, khuyến khích số lượng, xây dựng trên ý người khác. Sau đó nhóm gom cụm và bỏ phiếu chọn 1–3 ý triển vọng.
Bước 6 — Prototype nhanh. Chia nhóm nhỏ, mỗi nhóm dựng một mẫu thử thô trong 30–60 phút: vẽ tay màn hình, sơ đồ luồng, hay storyboard. Đừng cầu toàn — mục tiêu là đủ để người khác phản hồi.
Bước 7 — Test và ghi nhận. Nếu có người dùng, cho họ tương tác với prototype và quan sát. Nếu không, dùng kỹ thuật "đóng vai người dùng". Ghi lại phản hồi, điều gì gây bối rối, điều gì khiến họ hào hứng.
Bước 8 — Sau workshop: chuyển hóa thành requirements. Đây là phần BA không được bỏ. Lấy POV + ý tưởng đã validate + phản hồi test, biến chúng thành các yêu cầu sơ bộ (epic, nhu cầu nghiệp vụ, giả định cần kiểm chứng). Lưu ý: output của workshop là đầu vào định hướng, chưa phải requirement chốt — bạn vẫn cần các bước elicitation và xác nhận tiếp theo.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhảy thẳng vào giải pháp, bỏ qua Empathize và Define. Đây là lỗi phổ biến nhất. Cả nhóm hào hứng "vẽ tính năng" ngay từ phút thứ năm. Hậu quả: bạn có một đống ý tưởng đẹp cho một bài toán sai. Mẹo: kiên quyết không cho ai nói "giải pháp" trước khi POV được chốt; treo POV statement lên tường suốt buổi.
Lỗi 2 — Empathize bằng giả định thay vì dữ liệu thật. Cả nhóm ngồi tưởng tượng "chắc người dùng nghĩ là...". Empathy map khi đó chỉ là định kiến tập thể. Mẹo: luôn mang ít nhất vài trích dẫn nguyên văn từ người dùng thật vào phòng.
Lỗi 3 — Lẫn lộn Design Thinking workshop với JAD hay workshop chốt requirements. Một số BA mời cả phòng vào rồi cố "vừa đồng cảm vừa chốt scope". Hai mục tiêu này xung đột về tư duy (mở rộng vs hội tụ). Mẹo: tách riêng — Design Thinking để khám phá đúng vấn đề, các buổi sau mới để chốt yêu cầu chi tiết.
Lỗi 4 — Để prototype quá đẹp, quá tốn công. BA hoặc designer dành 3 ngày dựng prototype hi-fi, khiến cả nhóm "phải lòng" nó và ngại sửa. Mẹo: prototype trong workshop nên thô và nhanh — giấy bút là đủ; càng thô càng dễ mời người dùng chê thẳng.
Lỗi 5 — Không có bước chuyển hóa sang requirements. Workshop kết thúc trong hứng khởi rồi... để đó. Mẹo: ngay trong vòng 48 giờ, BA viết lại POV, danh sách insight, và các epic/giả định ra một tài liệu, gửi cho stakeholder xác nhận.
Mẹo bổ sung — quản lý động lực nhóm: Người cấp cao thường vô tình áp đặt ý kiến. Dùng kỹ thuật viết im lặng trước khi thảo luận, và bỏ phiếu kín (dot voting) để tiếng nói nhỏ vẫn có trọng lượng.
Bài tập thực hành
Tình huống: Bạn là BA cho một ứng dụng giao đồ ăn tại Việt Nam (giả định tên FoodGo). Dữ liệu cho thấy nhiều người dùng mở app vào giờ trưa nhưng thoát ra mà không đặt món. Đội sản phẩm muốn "thêm nhiều khuyến mãi hơn".
Hãy thực hiện các phần sau trên giấy hoặc một file:
- Viết câu "How Might We" làm tiêu điểm cho workshop, thay vì chấp nhận ngay giả định "thiếu khuyến mãi".
- Phác một Empathy Map giả định (4 ô: Says/Thinks/Does/Feels) cho một người dùng "nhân viên văn phòng đói giờ trưa, ít thời gian". Ghi ít nhất 2 mục mỗi ô.
- Viết một POV statement theo công thức [ai] cần [gì] vì [insight] — cố gắng tìm một insight bất ngờ khác với "thiếu khuyến mãi" (gợi ý: nghĩ về sự quá tải lựa chọn hay thời gian quyết định).
- Liệt kê 5 ý tưởng giải pháp cho POV đó, không phán xét.
- Mô tả 1 prototype thô bạn sẽ dựng để test ý tưởng triển vọng nhất.
- Chuyển hóa: viết 2 yêu cầu nghiệp vụ sơ bộ (business need) mà bạn rút ra để đưa vào tài liệu requirements sau này.
Tóm tắt
Design Thinking workshop là một định dạng elicitation đặc biệt giúp BA khám phá đúng vấn đề trước khi cam kết giải pháp, thông qua năm giai đoạn của Stanford d.school: Empathize (đồng cảm với người dùng thật), Define (viết POV statement cô đọng nhu cầu và insight), Ideate (sản sinh ý tưởng có cấu trúc, tách tạo khỏi đánh giá), Prototype (dựng mẫu thô để học hỏi), và Test (thu phản hồi rồi lặp lại). Khác với workshop chốt requirements hay JAD, mục tiêu ở đây là mở rộng hiểu biết và định hình lại bài toán theo góc nhìn người dùng.
Vai trò của BA trải khắp ba mặt: facilitate nhịp độ, tổng hợp dữ liệu thô thành POV, và quan trọng nhất — chuyển hóa kết quả workshop thành các yêu cầu nghiệp vụ sơ bộ cho các bước elicitation tiếp theo. Ba ví dụ về ngân hàng số, sàn TMĐT và bệnh viện cho thấy cùng một bài học: yêu cầu giá trị nhất thường ẩn sau một bài toán bị định nghĩa sai, và Design Thinking là công cụ giúp bạn lật nó lên. Hãy nhớ năm cạm bẫy — nhảy vào giải pháp quá sớm, đồng cảm bằng giả định, lẫn với JAD, prototype quá cầu kỳ, và quên bước chuyển hóa — và bạn sẽ biến workshop từ một buổi vui vẻ thành một bước elicitation thực sự tạo ra giá trị.