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

28/08/2015

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.


#Product Design

Comments

  1. Hiep - June 19, 2016 @ 3:00 am

    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 ?

    [Reply]

    Hieu -

    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.

    [Reply]

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

    [Reply]

  2. Hương - June 12, 2016 @ 6:16 pm

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

    [Reply]

  3. Hương - June 12, 2016 @ 6:14 pm

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

    [Reply]

  4. Minh - August 30, 2015 @ 10:26 pm

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

    [Reply]

  5. Tri - August 29, 2015 @ 2:03 am

    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.

    [Reply]

    Hieu -

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

    [Reply]

    Tri -

    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.

    [Reply]

  6. Đào Minh Đảm - August 28, 2015 @ 11:43 pm

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

    [Reply]

  7. Usernane - August 28, 2015 @ 8:55 pm

    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.

    [Reply]

  8. Viet - August 28, 2015 @ 7:46 pm

    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

    [Reply]

  9. Quinn - August 28, 2015 @ 6:56 pm

    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!

    [Reply]

  10. Nghia Le - August 28, 2015 @ 6:13 pm

    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 ;)

    [Reply]

  11. Lộc - August 28, 2015 @ 6:02 pm

    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.

    [Reply]

    Hieu -

    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://tapbut.ngochieu.com/ke-chuyen-man-ux-o-cba/

    [Reply]

  12. Tran Phu - August 28, 2015 @ 5:24 pm

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

    [Reply]

  13. nguyenhieptn - August 28, 2015 @ 5:18 pm

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

    [Reply]

  14. Hoài Mơ - August 28, 2015 @ 4:51 pm

    Cám ơn anh đã chia sẻ. :)

    [Reply]

Leave a Reply

Your email address will not be published / Required fields are marked *