Bài 11 — Designer mindset vs BA mindset: chuyển dịch cốt lõi

Mở đầu — vì sao bài này quan trọng

Bạn đã đi qua mười bài đầu tiên: nhận diện những kỹ năng Designer có thể mang theo, hiểu BA là gì, tập chuyển từ user research sang business requirements, và nhìn qua một case study thực tế tại agency Việt Nam. Nhưng có một sự thật mà nhiều người chuyển nghề nhận ra hơi muộn: bạn có thể học thuộc mọi template PRD, mọi ký hiệu BPMN, mọi câu lệnh SQL — mà vẫn "trượt" khi làm BA thật. Không phải vì thiếu công cụ, mà vì bạn vẫn đang suy nghĩ như một Designer trong khi tổ chức trông đợi bạn suy nghĩ như một BA.

Đây chính là bài học về sự chuyển dịch cốt lõi — cái mà mình gọi là "reset phần mềm bên trong đầu". Toàn bộ Module còn lại (từ mapping kỹ năng, elicitation, BPMN, use case cho tới UAT) chỉ là các công cụ. Nhưng công cụ nào cũng phục vụ một cách tư duy. Nếu tư duy chưa chuyển, bạn sẽ dùng công cụ BA nhưng ra kết quả của Designer — đẹp, thuyết phục về trải nghiệm, nhưng thiếu tính hệ thống, thiếu độ chặt về logic nghiệp vụ, và không được dev hay stakeholder tin tưởng.

Bài này không dạy bạn làm gì. Nó dạy bạn nghĩ khác đi. Đây là bài nền tảng nhất của cả giai đoạn chuyển đổi tư duy, và mình khuyên bạn đọc chậm, dừng lại tự soi chiếu bản thân ở từng đoạn.

Khái niệm cốt lõi

Bản chất khác biệt: hai nghề, hai câu hỏi gốc

Cách nhanh nhất để hiểu sự khác biệt là nhìn vào câu hỏi mặc định mà mỗi vai trò đặt ra khi đối diện một vấn đề.

Designer, theo bản năng, hỏi: "Làm sao để trải nghiệm này tốt hơn / dễ dùng hơn / đẹp hơn?"

BA, theo bản năng, hỏi: "Vấn đề nghiệp vụ thật sự ở đây là gì, ai chịu ảnh hưởng, và giải pháp nào tạo ra giá trị lớn nhất với chi phí hợp lý nhất?"

Bạn thấy sự khác biệt chưa? Designer bắt đầu từ giải pháp trải nghiệm. BA bắt đầu từ vấn đề và giá trị. Đây là gốc rễ của mọi khác biệt còn lại. Hãy hệ thống hóa nó qua bảng sau:

Ba dịch chuyển tư duy quan trọng nhất

Từ bảng trên, mình rút ra ba trục dịch chuyển mà bạn phải chủ động rèn.

Dịch chuyển 1: Từ "giải pháp" sang "vấn đề". Designer được huấn luyện để nhanh chóng hình dung giải pháp — nhìn một màn hình là đã tưởng tượng được layout tốt hơn. BA phải kìm phản xạ đó lại. Trước khi có bất kỳ giải pháp nào, BA sống trong không gian vấn đề (problem space) lâu hơn: tại sao business cần cái này, nó giải quyết nỗi đau gì, đo bằng chỉ số nào. Nếu bạn nhảy sang giải pháp quá sớm, bạn đang làm Designer, không phải BA.

Dịch chuyển 2: Từ "người dùng" sang "các bên liên quan". Designer trung thành với end user — đó là điểm mạnh. Nhưng BA phải cân bằng nhiều bên cùng lúc: người dùng muốn tiện, phòng kế toán muốn kiểm soát, đội dev muốn khả thi kỹ thuật, sponsor muốn tiết kiệm chi phí, phòng pháp chế muốn tuân thủ quy định. Nhiều khi những mong muốn này mâu thuẫn nhau, và việc của BA là làm rõ, ưu tiên, đàm phán — không phải luôn bênh vực trải nghiệm người dùng.

Dịch chuyển 3: Từ "cái đẹp/mượt" sang "cái đúng và đo được". Với Designer, chất lượng có phần chủ quan — dựa trên gu thẩm mỹ đã được rèn qua nghiên cứu. Với BA, chất lượng phải kiểm chứng được: một requirement tốt là requirement rõ ràng, không mâu thuẫn, có thể test được, có thể truy vết ngược về mục tiêu business. "Tôi cảm thấy thế này tốt hơn" là câu của Designer. "Cách này giảm 3 bước thao tác, tương ứng tiết kiệm 12 giây/giao dịch, quy mô 50.000 giao dịch/ngày" là câu của BA.

Điều bạn KHÔNG cần vứt bỏ

Đây là chỗ nhiều người hiểu sai và tự làm khổ mình. Chuyển sang BA không có nghĩa là chôn vùi con người Designer. Empathy với người dùng, khả năng trực quan hóa (visualize) một quy trình rối rắm thành sơ đồ dễ hiểu, kỹ năng dẫn dắt workshop, con mắt phát hiện điểm ma sát trong trải nghiệm — đây đều là siêu năng lực khiến bạn nổi bật hơn một BA thuần túy học từ trường kinh tế ra. Vấn đề không phải là bỏ Designer mindset, mà là đặt nó dưới sự chỉ huy của BA mindset: dùng empathy để elicit requirement tốt hơn, dùng visualization để mô hình hóa nghiệp vụ rõ hơn, chứ không để chúng kéo bạn về thói quen "thiết kế màn hình" quá sớm.

Tình huống thực tế

Ví dụ 1: Tính năng "hoàn tiền" tại một sàn TMĐT (Tiki-style)

Bối cảnh. Linh, cựu Product Designer, mới chuyển sang vai trò BA tại một sàn thương mại điện tử ở TP.HCM. Yêu cầu đầu tiên cô nhận: "Cải thiện luồng yêu cầu hoàn tiền (refund) — khách hàng đang phàn nàn rất nhiều." Phản xạ Designer bật lên ngay: trong hai ngày, Linh dựng xong bộ wireframe luồng refund mới, gọn hơn, từ 6 bước xuống 4 bước, giao diện sáng sủa, có cả trạng thái theo dõi tiến độ.

Diễn giải. Khi Linh trình bày, trưởng nhóm vận hành hỏi một câu làm cô đứng hình: "Trong số các khiếu nại refund, bao nhiêu phần trăm là do luồng khó dùng, và bao nhiêu là do tiền về chậm vì quy trình đối soát với ngân hàng mất 5-7 ngày?" Linh không có dữ liệu. Hóa ra 70% phàn nàn không phải về giao diện, mà về thời gian xử lý — một vấn đề nghiệp vụ liên quan tới quy trình đối soát nội bộ và điều khoản với đối tác thanh toán, không phải vấn đề UI. Bộ wireframe đẹp của Linh giải quyết đúng 30% vấn đề.

Bài học. Linh đã nhảy vào solution space trước khi hiểu problem space. Một BA đúng nghĩa sẽ bắt đầu bằng việc phân rã khiếu nại theo nguyên nhân gốc, xác định vấn đề nghiệp vụ thật, rồi mới quyết định giải pháp nằm ở đâu — có thể là quy trình, có thể là chính sách, có thể là hệ thống, và chỉ một phần là UI. Redesign màn hình chỉ là một mảnh nhỏ của bức tranh.

Ví dụ 2: Xung đột giữa các bên tại một ví điện tử (MoMo-style)

Bối cảnh. Tại một ví điện tử lớn, Đức — cũng xuất thân Designer — được giao phân tích yêu cầu cho tính năng "chuyển tiền theo lịch định kỳ". Đức phỏng vấn người dùng và kết luận: người dùng muốn thao tác càng ít bước xác thực càng tốt, lý tưởng là chỉ cần vân tay một lần rồi hệ thống tự chuyển hằng tháng.

Diễn giải. Đức viết requirement theo hướng tối giản xác thực để "tối ưu trải nghiệm". Nhưng khi đưa sang review, phòng Risk và phòng Compliance phản ứng mạnh: theo quy định phòng chống rửa tiền và bảo vệ người dùng của Ngân hàng Nhà nước, giao dịch định kỳ trên một ngưỡng số tiền bắt buộc phải có bước xác thực bổ sung mỗi kỳ. Đội dev thì lo ngại về xử lý trường hợp giao dịch thất bại khi số dư không đủ. Requirement "trải nghiệm tối ưu" của Đức bất khả thi về mặt tuân thủ và kỹ thuật.

Bài học. Đức đã trung thành với một bên — end user — mà quên rằng BA phục vụ nhiều bên với các ràng buộc khác nhau. Requirement cuối cùng là một sự cân bằng: đơn giản hóa ở mức pháp lý cho phép, thêm bước xác thực khi vượt ngưỡng, và định nghĩa rõ luồng xử lý lỗi. Bài học cốt lõi: BA mindset là tư duy đa bên và ràng buộc, không phải tư duy một chiều bênh vực người dùng. Empathy của Đức vẫn quý giá — nhưng nó phải hoạt động trong khung của các ràng buộc nghiệp vụ, pháp lý và kỹ thuật.

Ví dụ 3: "Cảm thấy tốt hơn" vs "chứng minh được tốt hơn" tại một ngân hàng số

Bối cảnh. Trang chuyển từ UX Designer sang BA tại một ngân hàng số ở Hà Nội. Trong buổi họp đề xuất thay đổi luồng mở tài khoản online, Trang nói: "Em thấy luồng hiện tại quá dài, làm lại gọn hơn sẽ tốt hơn nhiều." Giám đốc sản phẩm gật gù nhưng hỏi: "Tốt hơn bao nhiêu? Chúng ta đang mất khách ở bước nào? Nếu đầu tư 2 sprint để làm lại, mình kỳ vọng cải thiện chỉ số nào, bao nhiêu phần trăm?"

Diễn giải. Trang chưa chuẩn bị con số. Cô về nhà, kéo dữ liệu funnel và phát hiện: tỷ lệ rớt (drop-off) tập trung 43% ở bước chụp và xác thực giấy tờ (eKYC), không phải ở độ dài luồng nói chung. Cô định lượng lại: nếu giảm drop-off ở bước eKYC từ 43% xuống 30%, với 8.000 lượt mở tài khoản/tháng, sẽ thêm khoảng 1.040 tài khoản mới/tháng. Lần trình bày sau, đề xuất của Trang được duyệt ngay — vì nó không còn là "em cảm thấy", mà là một business case có con số.

Bài học. Chuyển từ ngôn ngữ cảm tính ("tốt hơn", "gọn hơn") sang ngôn ngữ đo lường và giá trị là dấu hiệu rõ nhất cho thấy tư duy BA đã hình thành. Không phải bỏ trực giác Designer — trực giác của Trang về "luồng quá dài" là điểm khởi đầu tốt — mà là kiểm chứng và định lượng trực giác đó trước khi biến nó thành requirement.

Hướng dẫn từng bước

Đây là quy trình 6 bước để bạn tập "chuyển kênh tư duy" mỗi khi nhận một yêu cầu mới. Hãy dán nó lên bàn làm việc trong vài tuần đầu.

Bước 1 — Dừng phản xạ giải pháp. Ngay khi đầu bạn bắt đầu tưởng tượng màn hình, tự nhắc: "Chưa phải lúc." Ghi ý tưởng giải pháp ra một tờ giấy nháp riêng để nó không chiếm chỗ trong đầu, rồi quay lại vấn đề.

Bước 2 — Hỏi "vấn đề nghiệp vụ thật là gì". Đặt liên tiếp câu hỏi "tại sao" (kỹ thuật 5 Whys). "Khách phàn nàn refund" — tại sao? "Vì tiền về chậm" — tại sao chậm? "Vì đối soát ngân hàng 7 ngày"... Đào tới khi chạm nguyên nhân gốc, không dừng ở triệu chứng bề mặt.

Bước 3 — Vẽ bản đồ các bên liên quan. Liệt kê ai bị ảnh hưởng và ai có tiếng nói: user, business owner, dev, QA, compliance, finance, vận hành. Với mỗi bên, ghi họ muốn gì và sợ gì. Đây là bước Designer hay bỏ qua nhất.

Bước 4 — Xác định tiêu chí thành công đo được. Trước khi nghĩ giải pháp, trả lời: "Nếu làm xong, chúng ta đo thành công bằng chỉ số nào?" Nếu không nêu được chỉ số, nghĩa là bạn chưa hiểu đủ vấn đề.

Bước 5 — Mới bắt đầu khám phá giải pháp. Đến đây bạn được phép bật lại Designer mindset — nhưng bây giờ nó phục vụ một vấn đề đã được định nghĩa rõ. Đưa ra nhiều phương án, không chỉ phương án UI: thay đổi quy trình, thay đổi chính sách, tự động hóa, hay điều chỉnh giao diện.

Bước 6 — Diễn đạt bằng ngôn ngữ kiểm chứng được. Chuyển mọi phát biểu từ "tôi thấy" sang "dữ liệu cho thấy / mục tiêu là / thành công khi". Đây là cách bạn xây dựng lòng tin với dev và stakeholder.

Lỗi thường gặp & mẹo

Lỗi 1: Nhảy vào wireframe/giải pháp quá sớm. Đây là lỗi số một của Designer chuyển BA — như trường hợp Linh. Mẹo: Áp dụng "quy tắc 24 giờ" — trong ngày đầu nhận yêu cầu, cấm bản thân mở Figma. Chỉ được viết câu hỏi và ghi chú vấn đề.

Lỗi 2: Chỉ nghe một bên (thường là user). Mẹo: Với mỗi requirement, tự hỏi "Ai sẽ phản đối cái này, và vì sao?" Nếu không nghĩ ra ai phản đối, khả năng cao bạn chưa nói chuyện đủ với các bên.

Lỗi 3: Dùng ngôn ngữ cảm tính trong tài liệu. "Đẹp hơn", "trực quan hơn", "thân thiện" — những từ này không test được. Mẹo: Mỗi lần định viết một tính từ chủ quan, thay bằng một tiêu chí đo được hoặc một hành vi cụ thể quan sát được.

Lỗi 4: Coi thường tính hệ thống và edge case. Designer quen với "happy path" đẹp; BA phải nghĩ tới mọi ngã rẽ: giao dịch lỗi, số dư không đủ, mất mạng, dữ liệu thiếu. Mẹo: Với mỗi luồng, hỏi "Còn trường hợp nào khác? Cái gì có thể sai?" ít nhất năm lần.

Lỗi 5: Tưởng phải vứt bỏ hết kỹ năng Design. Mẹo: Đừng. Hãy xem empathy và visualization là lợi thế cạnh tranh của bạn — chỉ cần đặt chúng phục vụ tư duy vấn đề, đa bên và đo lường.

Mẹo tổng: Mỗi cuối tuần, nhìn lại một quyết định bạn đưa ra và tự chấm: mình đã nghĩ như Designer hay như BA? Sự tự soi chiếu đều đặn này giúp "cơ bắp tư duy" BA hình thành nhanh hơn bất kỳ khóa học nào.

Bài tập thực hành

Bài tập 1 — Tự soi chiếu (15 phút). Nhớ lại một dự án Design gần nhất của bạn. Viết ra: (a) câu hỏi gốc bạn đã đặt khi bắt đầu, (b) bạn đã phục vụ những bên nào và bỏ quên bên nào, (c) bạn đo thành công bằng gì. So sánh với ba dịch chuyển tư duy trong bài.

Bài tập 2 — Chuyển kênh tư duy (30 phút). Lấy một yêu cầu giả định: "Làm lại trang thanh toán của một app đặt đồ ăn vì khách bỏ giỏ hàng nhiều." Áp dụng đúng 6 bước trong phần Hướng dẫn. Đặc biệt: liệt kê ít nhất 4 bên liên quan và điều họ muốn/sợ, và đề xuất ít nhất 3 loại giải pháp khác nhau (không chỉ UI).

Bài tập 3 — Dịch ngôn ngữ (15 phút). Viết lại 5 câu sau từ ngôn ngữ Designer sang ngôn ngữ BA đo được. Ví dụ: "Luồng này trực quan hơn" → "Luồng mới giảm số bước từ 6 xuống 4, mục tiêu giảm drop-off ở bước xác thực từ X% xuống Y%." Tự nghĩ thêm 4 câu và dịch.

Bài tập 4 — Truy vấn 5 Whys (20 phút). Chọn một "phàn nàn của người dùng" bất kỳ bạn từng gặp và đào 5 lớp "tại sao" để tìm nguyên nhân gốc là vấn đề nghiệp vụ. Ghi lại xem giải pháp cuối cùng có còn nằm ở UI không.

Tóm tắt

Sự chuyển đổi từ Designer sang BA, ở tầng sâu nhất, không phải chuyện công cụ mà là chuyện tư duy. Ba dịch chuyển cốt lõi bạn cần khắc ghi: từ giải pháp sang vấn đề, từ người dùng sang các bên liên quan, và từ cái đẹp/cảm tính sang cái đúng/đo được. Ba câu chuyện của Linh, Đức và Trang cho thấy cùng một bài học lặp lại: người chuyển nghề thất bại không phải vì thiếu kỹ năng, mà vì mang phản xạ Designer vào một vai trò đòi hỏi phản xạ BA.

Nhưng đừng hiểu lầm rằng bạn phải xóa bỏ con người Designer. Empathy, visualization, khả năng dẫn dắt và con mắt trải nghiệm chính là lợi thế khiến bạn có thể trở thành một BA xuất sắc hơn người khác — miễn là bạn đặt chúng dưới sự chỉ huy của tư duy vấn đề, đa bên và đo lường. Quy trình 6 bước và các bài tập trong bài là công cụ để bạn tập "chuyển kênh" cho tới khi nó trở thành phản xạ mới. Ở những bài tiếp theo, chúng ta sẽ lấy chính tư duy này làm nền để mapping cụ thể từng kỹ năng Designer sang competency BA, rồi đi sâu vào các kỹ thuật thực hành. Hãy để bài này là chiếc la bàn: mỗi khi bối rối, quay lại hỏi — "Lúc này mình đang nghĩ như Designer, hay như BA?"