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

Tôi 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 tôi 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à tôi đã 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ù tôi đã 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 tôi 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 tôi 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 tôi 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 tôi 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 tôi 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 với stakeholders như một buổi present. Như vậy sẽ đặt họ 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 tôi đã 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à tôi 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, tôi 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 để tôi có thêm động lực viết tiếp.

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

  • 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

    • 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.

Leave a reply:

Your email address will not be published.

Site Footer

Sliding Sidebar

About Me

About Me

Tôi may mắn được tham gia xây dựng một số công ty công nghệ ở cả Việt Nam và Úc trong suốt hơn 20 năm qua, trang web này là nơi tôi chia sẻ lại những kinh nghiệm đó. Đọc thêm →

Facebook

Social Profiles