Tổng quan về công việc UX Design

Mình có may mắn được làm việc chung với nhiều team UX lớn ở Úc (như CBA ở Sydney; ANZ, Telstra ở Melbourne;…), do đó đã từ lâu mình có dự định sẽ viết lại một cách hệ thống toàn bộ những kỹ năng và kinh nghiệm về UX mà mình đã tích lũy được.

Tuy nhiên trước khi viết sâu vào những chủ đề đó, thiết nghĩ cần phải có một bài tổng quan để mọi người có cái nhìn khái quát về công việc này. Đó là mục đích của bài viết này, bài viết khá là dài dù mình đã cố rút ngắn. Bài viết sẽ dùng tiếng Anh tiếng Việt lẫn lộn để dễ diễn đạt các từ chuyên môn.

UX Design, công việc thường bị hiểu sai ý nghĩa, có lẽ là vì có từ “Design” trong đó nên thường làm mọi người nghĩ rằng công việc này liên quan nhiều đến đồ họa, màu sắc,…

Thật ra phần nhiều công việc của vị trí này không đụng đến thiết kế đồ họa nhiều, có lẽ nên hiểu nghĩa của chữ design là “Xây dựng trải nghiệm người dùng” thì hợp lý hơn.

Công việc này thật ra gần với vị trí Product Manager (ở các ngân hàng thì thường gọi là Product Owner) hơn. Thực tế 80% thời gian của UXD là làm việc với Product Owner và các stakeholders, chỉ  khoảng 20% thời gian ở giai đoạn sau thì mới làm việc với Visual Designer (và thường thì UXD cũng chỉ phối hợp với Visual Designer chứ không phải là họ tự làm visual interface).

Công việc của UXD thường tương tác với 2 nhóm đối tượng: người dùng và stakeholders.

1. Người dùng (User):

Trước khi bắt tay build bất kỳ một wireframe hay prototype nào thì phải hiểu rõ về người dùng, do đó nghiên cứu và phân tích hành vi người dùng (phối hợp với team UX Research) là một mảng lớn và rất quan trọng của UX Design.

2. Stakeholders:

Trước hết cần phải định nghĩa stakeholder, một cách ngắn gọn thì: “đây là những người đại diện các mảng có liên quan đến việc phát triển và vận hành sản phẩm”.

Ví dụ trong một ngân hàng thì stakeholders sẽ bao gồm: đại diện marketing, đại diện team credit, đại diện về compliance, System Architect, BA, PO, PM,… Trung bình một buổi họp quan trọng thì số lượng stakeholder có khi lên đến 10-15 người. (Tuy nhiên nên hạn chế không để quá đông, dưới 10 người là lý tưởng nhất).

Và UXD là người phải lead những buổi họp này, do đó để tránh bàn luận lan man thì cần phải chuẩn bị kỹ và có những chiêu trò lèo lái, “bịt miệng” stakeholder khi cuộc họp có dấu hiệu đi ra ngoài scope. Nếu không sẽ dễ đẫn đến trường hợp họp thì nhiều mà chả rút ra được cái gì.

Trong nhóm này có một stakeholder rất quan trọng là Product Owner: đây chính là “khách hàng” và cũng là bạn đường quan trọng nhất của UXD. Thường xuyên sẽ thấy cảnh một PO và một UXD ngồi xì xầm to nhỏ khắp các góc của công ty.

Có nhiều kỹ thuật để làm việc với stakeholder (thường gọi là facilitate), tùy theo từng giai đoạn của công việc và loại thông tin muốn extract từ họ.

  • Đơn giản nhất là lôi nhau ra một góc ngồi tâm sự.
  • Brainstorm về chức năng sản phẩm thì có Feature Bidding.
  • Hiểu về flow của người dùng thì có Customer Journey Mapping.

(Trong tương lai mình sẽ viết kỹ hơn về những kỹ thuật này)

Stakeholder cũng sẽ là đối tượng sẽ approve sơ bộ và cũng là người sẽ backup cho chúng ta khi present lên cấp cao hơn.

Do đó có một phần công việc không liên quan đến chuyên môn nhưng nó có tên trong mọi kỹ năng cần của của UXD gọi là “Stakeholder Relation Management”. Nói nôm na làm làm sao để giữ mối quan hệ với stakeholder được tốt.

Đó là 2 nhóm đối tượng mà chúng ta tương tác, còn đồng đội thì chúng ta thường có 2 team:

  • UX Research: đây là team đồng đội của UXD và sẽ hỗ trợ UXD rất nhiều trong các việc như recruite, user testing, logistic,…
  • Visual Design: đây là team sẽ hiện thực hóa những concept của UXD thành các interface cụ thể.

(Trong tương lai mình sẽ viết một bài chi tiết hơn về cách tổ chức một team UX Design).

Để hiểu thêm thì có lẽ nên nói sơ qua một số bước trong UX Process của một dự án lớn (ở các công ty nhỏ thì sẽ có nhiều sự kiêm nhiệm và bỏ qua một số bước uyển chuyển tùy theo từng dự án).

Lưu ý là ở đây mình liệt kê theo dạng waterfall (bước 1, bước 2,…) để mọi người dễ hình dung, trong thực tế khi làm việc trong môi trường Agile thì process sẽ khác.

Chúng ta sẽ có 3 bước lớn:

1. UX Research:

Một cách đơn giản thì đây là bước đặt nền móng:

  • Ta cần phải hiểu người dùng, những vấn đề của họ, những khó chịu khi sử dụng giải pháp hiện tại (gọi là pain points indication).
  • Bên cạnh đó quan trọng không kém, ta cần phải hiểu nhu cầu của business từ mọi góc độ (marketing, logistic, technology, thậm chí rộng hơn là những suppliers, partners,…)

Kỹ thuật:

Có nhiều kỹ thuật để áp dụng cho bước này, tùy tình huống và tùy nhu cầu, ví dụ:

  • Customer Interview (bà con thường gọi tắt là CI): là phỏng vấn hành vi người dùng, tùy theo loại thông tin muốn extract mà sẽ có nhiều loại phỏng vấn khác nhau, trước khi phỏng vấn thì UXD phải chuẩn bị recruitment script cho team UX Research và những marterial cần thiết khác.
  • Shadowing: đến trực tiếp môi trường của người dùng để quan sát và phân tích (shadowing nghĩa là đứng trong bóng tối).
  • Những dự án phức tạp hơn thì còn có Journaling, Feature Bidding,…

Dần dần mình sẽ viết chi tiết về những kỹ thuật này và những kinh nghiệm trong việc áp dụng từng kỹ thuật trong thực tế. Bài này chỉ mang tính khái quát nên sẽ không nói sâu.

Delivery:

Delivery của bước này đơn cử có thể kể như:

  • User Personas / User Story
  • User Scenarios
  • Customer Journey Map

Quan trọng nhất của bước này là những kỹ năng extract và phân tích thông tin.

2. Think

Ở một số công ty mình làm việc, phase này gọi là “Inception” (nghe như phim).

Khi đã có bức tranh về người dùng và business, ở bước thứ hai này UXD sẽ ngồi xuống với các stakeholders để cùng xây dựng giải pháp. Chủ yếu của bước này là phân tích các vấn đề đã được tìm ra ở phase đầu, từ đó đưa ra giải pháp. Bước này thì Product Owner và UXD gắn với nhau như hình với bóng.

Điểm quan trọng ở bước này: Think ở đây không có nghĩa là tự UXD think mà đó phải là công việc của tập thể.

Đây cũng là lỗi mà nhiều UXD thường mắc – khi họ thường tự mình xây dựng giải pháp và đến buổi họp thì share stakeholder như một buổi present. Như vậy sẽ đặt mình vô một vị trí rất khó khi mà các stakeholder không có cảm giác mình là một phần của giải pháp và một cách tự nhiên họ sẽ đặt mình vào vị trí người đánh giá (critique). Đây cũng là một trong những lỗi mà bạn đồng nghiệp của mình đã mắc phải trong câu chuyện lần trước.

Các kỹ thuật:

  • Competitor Review,
  • Expert Inquiry,
  • Feature Bidding,

Deliver:

Deliver quan trọng nhất trong giai đoạn này là quyết định được scope của sản phẩm và prioritize các chức năng sản phẩm.

3. Build → Test → Improve.

3 bước này nó đi chung với nhau nên không tách ra được.

Cụ thể khi đã xong bước 2 thì đây là lúc UXD triển khai những giải pháp thành những chức năng cụ thể, UXD sẽ thử các hướng tiếp cận mà mình cho là tốt nhất và quan trọng là liên tục test để đảm bảo những ý tưởng đó khả thi.

Giống như vẽ tranh, sẽ đi qua từng giai đoạn từ tổng quát đến chi tiết: Sketch trước rồi dựng Wireframe + Prototype, rồi Visual Design (phối hợp với Visual Designer, hoặc nếu UXD có khả năng về Visual Design thì quá tốt), rồi bước cuối cùng là Visual Design Prototype (còn gọi là Hi Fidelity Prototype).

Mỗi giai đoạn như vậy sẽ là những vòng lặp (Build > Test > Improve) để đảm bảo mọi bước đều có validate:

Ví dụ:

  • Sketch → Test với user → Phân tích với Stakeholder → Revise Sketch → Test…
  • Low Fidelity Prototype → Test với user → Phân tích với Stakeholder → Revise Prototype → Test..
  • Hi Fidelity Prototype → Test với user →Phân tích với Stakeholder → Revise Prototype → Test…

Handshake

Và sau cùng, khi đã hoàn tất Hi-Fi Prototype thì UXD sẽ có một buổi để chính thức share với Dev mọi insight và yêu cầu của dự án (gọi là chính thức vì đã có đại diện của Dev là một stakeholder tham gia từ đầu qua mọi giai đoạn nên đến lúc này Dev đã nắm khá rõ về dự án).

Ở giai này UXD cũng sẽ phối hợp với Visual Designer để chuẩn bị các document cần thiết như: Design Guide Line, Style Guide,…

(Sau đó thì UXD vẫn theo tiếp quá trình develop ở góc độ support và follow up cho đến khi release sản phẩm để đảm bảo chất lượng đúng như yêu cầu đặt ra)

Như vậy chúng ta có thể thấy công việc của UX Designer không mấy liên quan đến công việc thiết kế. Công cụ mà UX Designer dùng gần nhất với thiết kế là công cụ dựng Wireframe/Prototype (thường các công ty lớn ở Úc sử dụng Axure).

Tuy nhiên cần nhấn mạnh rằng như vậy không có nghĩa là bạn không cần phải biết gì về thiết kế. Thật ra ngược lại thì đúng hơn: những hiểu biết về behaviour của người dùng + hiểu biết về thiết kế (như usability, accessibility,…) là cực kỳ quan trọng và yêu cầu bắt buộc. Do đó mà rất nhiều UXD thường xuất thân từ những designer truyền thống.

Ngoài ra những kỹ năng khác cần phải có thì phần nhiều sẽ là: thu thập, tổng hợp, phân tích, present và đặc biệt là facilitate các buổi họp/workshop…

Qua đó cũng thấy công việc này cũng đòi hỏi nói liên tục (và nói một cách có hệ thống). Nên tập cách nói một cách rõ ràng, có hệ thống và nói một cách đầy inspire,…

Qua bài này hy vọng mang đến một cái nhìn cụ thể hơn cho các bạn yêu thích công việc này, từ đó có hướng trau dồi những kỹ năng cần thiết phù hợp với yêu cầu công việc trong tương lai. Nếu bạn nào có câu hỏi cứ đăng vào phần comment, mình sẽ sắp xếp trả lời.

PS: Bạn nào muốn trích dẫn lại bài viết xin cứ tự nhiên, chỉ cần dẫn nguồn và dẫn link về bài gốc để mình có thêm động lực viết tiếp.

31 comments On Tổng quan về công việc UX Design

  • Chào anh Hiếu, cám ơn anh đã chia sẻ những kiến thức chuyên môn về một ngành quả thực thú vị. Bên cạnh việc trình bày rất dễ hiểu cho người ngoài ngành, đọc bài của anh em còn cảm nhận được sự nhiệt tình của một người trẻ hào sảng chia sẻ những kiến thức quý giá mà anh đã tích lũy được. Mindset Think – Build – Test – Improve mà em đọc từ anh quả thật vận vào nhiểu tình huống trong cuộc sống lắm. Chúc anh thật nhiều sức khỏe và niềm vui!

    8
  • Em đang tìm hiểu về ngành này UX ở tuổi khá là xế chiều, nhưng em nghĩ không có gì là quá muộn. Cảm ơn anh về bài viết chia sẽ giúp em hiểu hơn phần nào về công việc sắp tới. Em hy vọng là sau này khi trải qua nhìu thăng trầm của cuộc sống, và công việc, em cũng có thể viết sách, dựng podcast và chia sẻ lại kinh nghiệm sống như anh . Một lần nữa, em cảm ơn anh Hiếu nhiều nhé.

    5
  • Cảm ơn bạn đã chia sẽ

    3
  • Đọc xong bài viết này của Anh mới thấy mình làm marketing mà trước giờ cũng làm nhiều về UXD. Tuy nhiên thì không có 1 team nào để brainstorm mà chủ yếu là tự khảo sát, phân tích rồi lên design (Vì thế nên cũng bỏ qua nhiều bước vì tự mình đánh giá).

    3
  • Cảm ơn anh đã chia sẻ.

  • Cảm ơn bài viết của anh, rất chi tiết và cung cấp góc nhìn tổng quát khá tốt. Tuy nhiên em có một phần bổ sung. Ở giai đoạn Think, sẽ không chỉ có PO và UX team work với nhau để think about giải pháp đâu. Ở đây sẽ có sự tham gia của nhiều stakeholder khác như PM, Engineers lead. Các giải pháp chủ yếu do các bạn engineers đưa ra và cùng thảo luận xem đáp ứng được bao nhiêu % use case. PM dựa vào các nghiên cứu trước đó của UX Research và development cost để quyết định làm phần nào trước phần nào sau, chia milestone sao cho phù hợp với release của từng phase.

    17
  • Cám ơn bài viết vô cùng hữu ích của anh. Hiện tại em đang là 1 frontend Dev và đang tìm hiểu về UxD. Anh cho em hỏi những khó khăn và lợi ích khi chuyển từ Frondend Dev sang Ux được không ạ. Em cám ơn hy vọng sẽ nhận được nhiều bài chia sẻ hơn từ a.

    7
  • Cảm ơn bài viết của anh ạ, hy vọng a sẽ sớm có những bài viết sâu về Brainstorm về chức năng sản phẩm (Feature Bidding), flow của người dùng (Customer Journey Mapping)… Có mấy bài viết chuyên sâu process cũng như cách thực hiện thì sẽ giúp ích rất nhiều ạ.

    4
  • mai tường luân

    Chào anh, em là sinh viên năm 3 ngành Kỹ thuật phần mềm, không biết trong UX có phải đã bao gồm Business Analys không ạ, vì qua những gì anh nói ở trên với những gì em đã được biết (học) thì em cảm thấy có vẻ giống nhau. Cảm ơn anh <3

    1
    • ngochieu

      Chào em, đúng như em cảm nhận, UX rất gần với BA, ở một số công ty thậm chí đã không còn vị trí BA (trách nhiệm của 2 team UX và Product đã bao trọn vị trí này) – tuy nhiên ở những công ty lớn (ví dụ ở ngân hàng Commonwealth Bank anh đã làm việc) thì vẫn có cả BA và UX làm việc song song cùng nhau.

      Anh cũng được biết một số bạn bè làm UX xuất thân từ BA, do đó em không cần phải quá lo lắng và cứ tiếp tục việc học về BA. Nền tảng BA sẽ giúp ích cho em rất nhiều trong trường hợp sau này em muốn chuyển sang làm về UX.

      3
  • Hi anh Hiếu,
    Cám ơn anh đã viết bài viết hay như vậy, Anh Hiếu cho em hỏi bây giờ mình muốn học và làm như một UX design thì nền tảng kiến thức và kỹ năng của mình cần là gì?
    Em cám ơn anh.

    2
  • UXD khác với Business Analyst ở điểm nào anh? Những gì anh mô tả trong bài này giống như những gì em đã làm ở vị trí Business Analyst, từ client requirement -> work with task holder s -> product features -> user cases -> data modeling -> wireframe > prototype -> document guide ?

    2
    • Một câu hỏi rất hay!

      Cả 2 công việc đều có nhiệm vụ là chuyển user needs thành actionable requirements.

      Điểm khác biệt cơ bản giữa 2 vị trí này là UXD quan tâm nhiều đến trải nghiệm người dùng và tập trung design cho thật tốt xung quanh yếu tố này, họ không quan tâm lắm đến các vấn đề kỹ thuật. Trong các công ty đặt UX làm trọng tâm thì UXD chỉ tập trung thiết kế sao cho trải nghiệm người dùng thật tốt, họ “set the bar” và bên technical phải chạy theo.

      Còn BA thiết kế thì vấn đề quan trọng là phải cân bằng được user needs và kỹ thuật. Chính vì lý do đó nên BA thường yêu cầu hiểu biết nhiều về kỹ thuật mà không đòi hỏi nhiều về yếu tố design. Ví dụ đơn giản là một animation của một button hay một popup đối với BA có thể không quan trọng, nhưng đối với UX thì lại rất quan trọng.

      Hiện tại ở Úc, anh đang thấy có nhiều người cho rằng trong tương lai gần công việc BA sẽ từ từ tiến hóa thành công việc UX Design.

      2
    • ThuongVT

      Cùng câu hỏi với bạn này, rất hay.
      Trên thực tế tại một dự án của Vingroup, mình làm BA và ko có UXD. Ví dụ một page thì BA sẽ dựng prototype chung rồi Designer chủ động thiết kế chi tiết. Việc bố trí các dialog box theo kiểu Mac hay Windows (thứ tự các nút OK-Cancel) cũng do designer chủ động. Vậy nên mới có lần cãi nhau vì designer toàn dùng Mac nên thiết kế kiểu Cancel-OK, nhưng mình xài Windows thấy ngược rất khó chịu. Về sau mới ngồi vs nhau nhiều hơn về cái này (có lẽ là tiến hóa dần).

    • Em hiện đang làm công việc BA và thấy hai công việc này có nhiều điểm chung
      Cảm ơn anh vì đã giải thích rất rõ dàng dễ hiểu cho sự khác biệt giữa hai công việc này.
      Trong tương lai em cũng có dự định chuyển dần sang công việc UX. Rất mong anh chia sẻ thêm kiến thức về công việc này

  • Bể kiến thức MKT thật rộng lớn. Mong anh tiếp tục chia sẻ! Thanks,

  • Bài viết hay quá, cảm ơn anh!

    2
  • Bài Overview hay quá, em xin phép reblog lại anh Hiếu nhé!

  • Cảm ơn anh Hiếu về bài viết. Em cũng đang tìm hiểu về UX nhưng chưa biết nên bắt đầu đọc những tài liệu gì, anh có thể chia sẻ những tài liệu tham khảo hay những cuốn sách nên đọc để hiểu sâu thêm về UX được không ah. Cám ơn anh nhiều.

    • Anh sẽ sớm một bài về những quyển sách mà anh đã đọc (và thấy hay), em đón xem nhé.

      1
    • Hi anh Hiếu,

      Em thấy hiện nay trên mạng có khá nhiều khoá học online về UX. E thấy trang https://www.interaction-design.org/courses/ có nhiều khoá học về UX khá hữu ích, a có biết gì về những khoá học của trang này và thấy thế nào ah. E cám ơn anh nhiều.

      1
  • Đào Minh Đảm

    Cám ơn anh, bài viết rất hay.

  • Rất thích mấy thuật ngữ chuyên ngành mà anh Hiếu viết. Anh cứ viết đi anh, độc giả nhiều lắm.

    1
  • Em đồng ý với những ý kiến của anh. Đặc biệt với ý kiến là: vì UX có gắn thêm chữ Design nên nhiều người hay nhầm giữa UI design với UX design.

    Quan điểm của em về “chức danh” UX designer là 1 nhóm/nhiều nhóm) người làm UX Design trong đó mỗi người (nhóm) phải có chuyên môn trong mỗi công việc của họ. Phân tích dữ liệu, nghiên cứu đặc điểm dân cư, chiến lược sản phẩm… và tất nhiên không thể thiếu người làm UI nhưng hiểu về việc áp dụng tâm lý học trong thiết kế :v

    1
  • Cám ơn anh đã chia sẻ bài viết rất hay! Em cũng đang tìm hiểu UX vì rất muốn học UX và làm UX. Hóng các bài viết khác của anh!

  • Cảm ơn bài chia sẻ rất hay của anh. Hy vọng anh có thể tiếp tục viết sâu hơn để có thể tham khảo được 😉

  • Cảm ơn anh Hiếu về bài viết chia sẻ. Những thông tin này thật sự rất hữu ích. Có một điểm khiến em vẫn chưa hình dung được về công việc UXDesigner ở những công ty anh đã từng làm qua là đến mức nào, ví dụ như:

    – Thời gian dành cho giai đoạn UX Design, UX Research, … chiếm bao nhiêu phần trăm của dự án?

    – Chi phí dành cho UX Design thường chiếm bao nhiêu % tổng chi phí cho dự án?

    – Những dự án nào sẽ được đầu tư khâu UX Design, những website của ngân hàng đa quốc gia Standard Charter chẳng hạn, liệu họ có invest nhiều cho mảng UX Design ko, hay họ sẽ tập trung cho những hệ thống nội bộ hơn?

    Mong anh có thể giải đáp giúp. Cảm ơn anh.

    • Chào em,

      Anh trả lời các câu hỏi của em lần lượt như sau:

      – Tuỳ theo dự án, công ty anh áp dụng Agile, trung bình các dự án ở nơi anh làm việc thì phần UX Research mất khoảng 2 sprint (mỗi sprint 2 tuần, coi như là khoảng 1 tháng).

      – Phần chi phí anh không đủ thẩm quyền để biết nên không có câu trả lời cụ thể, tuy nhiên anh đoán sẽ ngang với chi phí development.

      – Anh chưa làm việc với Standard Charter nên không dám nói, ở 2 ngân hàng anh đã làm việc ở Úc (CBA và ANZ) thì họ đầu tư cực lớn và nghiêm túc cho mảng này, và đã gặt hái được rất nhiều thành công nhờ UX. Em đọc thêm bài anh viết về CBA ở đây: http://ngochieu.com/ke-chuyen-man-ux-o-cba/

      1
  • Cám ơn chia sẻ của bạn, bài viết rất hay 🙂

  • nguyenhieptn

    Cám ơn anh đã chia sẻ, bài viết rất hay.

  • Cám ơn anh đã chia sẻ. 🙂

Trả lời cho HOMY Bỏ trả lời

Địa chỉ email của bạn sẽ được giữ bí mật.

Site Footer