UX as consultant & Expectation

Những năm gần đây, mình được làm trong cấu trúc tổ chức định hình team UX như một team consultant service, nó có hơi khác với công việc quá khứ của mình (UX trong product team - do mình cũng làm môi trường start-up nữa nên size khá nhỏ, vì thế được invovle luôn từ giai đoạn đầu), vì thế mình cũng tò mò “thật ra nó sẽ khác biệt ra sao giữa việc xem UX là consultant vs UX thuộc core product team?”.

Cùng mình tìm hiểu qua nhé.

Định nghĩa

Consult: tham vấn, xin ý kiến, bàn bạc trước khi ra quyết định.

Consultant: chuyên gia tư vấn, đưa kiến thức và góc nhìn chuyên môn giúp người khác giải quyết vấn đề.

Trong bản chất, consult không phải là làm thay, mà là giúp người khác ra quyết định tốt hơn bằng tri thức, kinh nghiệm và phân tích mà mình bổ sung thêm cho họ.

Trong ngữ cảnh UX team as a consulting service

Tính chất

Trong bối cảnh này, UX team không phải người đóng góp nhiều vào các quyết định mang tính đưa ra concept hay solution (thường PM, business owner mới là decision maker). UX team được xem như một người đồng hành chuyên môn, giúp các team khác (PM, Dev, Business, Marketing…), ta chịu trách đề xuất các giải pháp UX phù hợp. UX team giống như bác sĩ: chẩn đoán bệnh (phân tích problem mà PO đưa ra), kênh đơn thuốc- đưa giải pháp (UX solution), nhưng sau cùng bệnh nhân (business/stakeholder) mới là người chọn có theo hay không.

Workflow

Team UX thường được chia thành 1 department độc lập, team tiếp nhận request từ các bên, có thể hình dung như một agency in house.

Stage được involve vào = Sau khi problem hoặc thậm chí solution đã được định nghĩa, định hình → Mình đồng hành với PO/PM trong giai đoạn lên design concept là chính, sau đó chủ yếu follow up để support cho dev, và xem metrics report sau khi release.

Có tính khách quan hơn vì bạn chỉ đóng vai trò input góc nhìn của UX, không bị chịu nhiều áp lực KPI phía business hoặc feature outcome.

Ưu và nhược

✅ Tính độc lập: dễ giữ được quan điểm khách quan, unbiased.

✅ Tính linh hoạt cao vì có thể phục vụ nhiều team cùng lúc.

✅ Có cơ hội học hỏi chéo lẫn nhau (học từ các peer - designer).

❌ Khó tạo impact sâu, vì không có quyền ra quyết định. Dễ bị xem như “service team” (order taker).

Khác với ngữ cảnh UX as a Core Product teammate

Tính chất

UX cùng ngồi chung team cross-functional (PM, Dev, BA, QA), team này tự chủ 1 feature area cụ thể và cùng nhau ownership trực tiếp với outcome gì đó (KPIs, OKRs của product), nên lúc này UX có tiếng nói ngang hàng trong quyết định sản phẩm, có thể hình dung như một mini start up trong công ty.

Workflow

UX thuộc và chuyên trách cho 1 product area (hoặc 1 squad, ví dụ bạn chỉ thuộc squad growth & engagement, module payment & subscription, hoặc chuyên trách các tính năng cho gói Business account chẳng hạn).

Stage được involve vào = Tham gia từ rất sớm (discovery, định nghĩa vấn đề, ưu tiên backlog). Đồng hành xuyên suốt: từ research → design → test → launch → iterate. End-to-end process.

Đề xuất có tính ràng buộc hơn, không chỉ “tư vấn” mà còn đồng chịu trách nhiệm với product.

Ưu và nhược

✅ Impact lớn: UX có thể ảnh hưởng trực tiếp tới roadmap & outcome.

✅ Gắn kết chặt chẽ với business & tech, hiểu sâu domain.

❌ Dễ bị cuốn vào “business pressure”, mất đi tính khách quan vì có khi bạn làm theo hướng KPI-centered thay vì user-centered.

Hybrid

Ngoài còn có một dạng giữa giữa, bạn có thể vừa trực thuộc chính cho một squad để đảm đương các task trong squad đó, nhưng song song vẫn thuộc chapter UX (phòng ban UX), nơi mà có Head of design sẽ quyết định career development & đảm bảo chất lượng design.

Bối cảnh của mình…

Ở công ty hiện tại của mình tồn tại cả 2 mô hình trên, nhưng mình thuộc team xu hướng dạng service, nên bài này muốn nghiên cứu xem “nếu mình trong tổ chức dạng đó thì nên xử trí thế nào?”.

Vậy làm thế nào để consult tốt?

Nguyên tắc cốt lõi

Listen first, then advise

: lắng nghe bối cảnh, constraint, mục tiêu trước khi đưa lời khuyên.

Evidence-based

: tư vấn dựa trên data, research, best practice UX — tránh chỉ nói theo cảm tính.

Frame choices, not orders

: thay vì “phải làm thế này”, hãy đưa 2–3 option kèm trade-off để họ chọn.

Bridge mindset

: hiểu ngôn ngữ business, tech, và user để “thông dịch” & giao tiếp.

Kỹ năng cần

Khai thác vấn đề

: biết đặt câu hỏi để hiểu real problem / root cause, không chỉ giải quyết symptom.

Storytelling

: trình bày insight và đề xuất theo cách dễ hiểu, dễ hành động.

Negotiation

: tuỳ tình huống biết khi nào cần nhượng bộ, khi nào cần biết push back.

Expectation management

: luôn rõ ràng rằng UX không “cứu cả thế giới”, mà hỗ trợ trong phạm vi nhất định.

Kinh nghiệm xương máu

Hãy document mọi thứ, từ problem statement, solution proposal cho đến meeting note & decision log. Chúng là những source of truth rằng bạn đã consult ra sao, vì again decision maker không thuộc về mình, mình chỉ chuẩn đoán & tư vấn.

What UX consult will do:

Hiểu người dùng, bối cảnh sử dụng.

Cung cấp insight và best practice.

Đưa khuyến nghị với trade-off rõ ràng.

Hỗ trợ thiết kế để test idea nhanh.

What UX consult won’t do:

Không tự quyết business strategy.

Không cam kết outcome nếu stakeholder không theo UX solution.

Không làm “order taker” - chỉ để vẽ màn hình mà không tham gia vào problem framing.

Tóm gọn

Tâm thế cần set trong đầu: “UX team sẽ giúp đưa ra góc nhìn người dùng, stand for “user voice”, tư vấn giải pháp dựa trên evidence, và dùng thiết kế để kiểm chứng. Nhưng quyết định cuối cùng nằm ở PM/business.”

📌

Làm consult tốt = (Lắng nghe + Phân tích bằng evidence + Truyền đạt rõ ràng trade-off) x Quản lý kỳ vọng.

Vài chia sẻ cá nhân

— Bài này mình có tham khảo nhiều từ chatGPT, tuy nhiên đọc và ngẫm, đối chiếu với công việc và kinh nghiệm quá khứ thì thấy rất đúng. Đồng thời có thêm vài nhận định cá nhân, nên nếu mọi người có góc nhìn khác, mình rất mong được biết thêm. Nếu bạn muốn nghiên cứu thêm, có thể xem thêm các nguồn bên dưới.

Ban đầu mình cũng muốn được nhìn nhận UX như một core product team, nhưng việc nhìn nhận sai này khiến mình set expectation sai → dẫn đến mâu thuẫn nội tâm, nên nếu nhìn nhận đúng hơn thì expectation sẽ được đặt về đúng chỗ (nó như kiểu bơi xuôi dòng thay vì ngược dòng) → Dễ thở hơn và tập trung cho phần việc mình tốt hơn.

Không có cách nhìn nhận team UX như thế nào là tốt hoàn toàn, nó tuỳ thuộc vào cấu trúc tổ chức, resource team, product phase cũng như độ UX maturity.