UX cost và dự án

Nói về UX cost cho các dự án ở Việt Nam

jhwebit_doodle
(Ảnh: cost doodle, nguồn doodlecreative)

Tháng trước có bạn hỏi tôi về chi phí dành cho UX trong các dự án tôi đang làm, câu hỏi làm tôi phải suy nghĩ, khá hay, và ở vị trí đang làm tôi phần nào hiểu được thực trạng đó ở Việt Nam. Vậy nên hôm tôi muốn ghi lại vài dòng, biết đâu mấy năm nữa tình hình thị trường UX ở Việt Nam khá hơn, lúc đó đọc lại bài này sẽ thấy vui vui.

Ở Việt Nam có 3 mảng dự án mà tôi nghĩ có thể “có phần” cho UX:

  1. Product & creative: Đa phần là các dự án phát triển sản phẩm ở “các công ty product”. Các công ty này có nguồn vốn đầu tư để build sản phẩm. Ví dụ như Tiki, Foody, Ringier Media, Lazada, Vietnamworks, Zalora.. hay các cty chủ quản của website Dân Trí, VNExpress, Danhgiaxe.com v.v… Nói chung là build product hoặc duy trì, phát triển 1 sản phẩm (đa phần là sản phẩm công nghệ). Cơ hội làm UX ở đây, theo tôi, là lớn nhất. Chi phí dành cho UX (nếu có) cũng khá nghiêm túc. Tuy nhiên, chi phí này nhiều khi là 1 phần của chi phí design hoặc BA (business analysis)
  2. Outsourcing:  Đây là mảng thị phần lớn nhất trong ngành IT ở Việt Nam. 70-80% các công ty IT là làm về outsourcing, các công ty này làm nhiều thị trường, nhiều mảng nghiệp vụ, nhưng với các công ty làm về Digital Marketing (như cty tôi đang làm) thì công việc liên quan tới UX là đáng kể nhất. Cụ thể hơn là bạn được làm trực tiếp với digital design team và qua đó được “tham gia phần nào” vào công việc UX thường xuyên hơn. Chi phí này được tính vào chi phí product design hoặc đúng nghĩa UX job.
  3. In house projects: Là những dự án dành cho những team UX chuyên biệt của các tập đoàn lớn. Loại hình này không nhiều nhưng theo tôi biết họ, các công ty này, được đầu tư và có team UX riêng. Ví dụ như FSoft, Vinagame, và mới đây theo tôi thấy là VIB. Có lẽ còn nhiều công ty khác mà tôi chưa biết. Nhưng nói chung là vẫn hiếm. Chi phí cho UX trong phân khúc này chủ yếu nằm trong chi phí R&D (research and development). Vậy nên hàng năm vẫn sẽ có trường hợp review budget. Thực ra cái này thì ở đâu cũng thế, team UX phải tự sale chính mình, và các dự án của mình với cấp lãnh đạo cao hơn.

Đó là mảng dự án, còn sale cho chí phí này thì sao? Với loại hình dự án số 1 và số 3 thì chi phí này đã được “cấp trên” tính đến, vì dù sao đó cũng là chi phí đầu tư, do vậy chỉ còn băn khoăn với loại hình số 2: outsource. Cá nhân tôi sau 1,5 năm làm ở mảng digital marketing với thị trường Úc, Singapore, UK và Hongkong thì rút ra một số trải nghiệm như sau:

  • Khi việc tới tay mình thì đa phần đã qua khâu UX và UI/graphic design rồi, tuy nhiên mình được làm việc cùng với team UX bên phía đối tác để review và điều chỉnh (gọi là verify and adjustment). Mặc dù value không nhiều nhưng vẫn có thể đưa ra những điều không hợp lý, cung cấp giải pháp (bắt buộc bạn phải có alternative solution thì hẵng nói chuyện review nhé) để hiệu quả của sản phẩm được tốt hơn. Theo tôi thấy, dân làm trong ngành này cởi mở và sẵn sàng lắng nghe hơn là khách hàng của mảng enterprise .
  • Chi phí UX được tính vào những dự án lớn (khoảng 100K USD trở lên) khi đối tác không thực sự có team UX mạnh hoặc đội ngũ UX của họ quá bận rộn, quá mỏng. 6 tháng trở lại đây, tôi thường được làm việc với UX lead của đối tác, hoặc Design director / creative director của khách hàng để triển khai các công việc UX design. Nghĩa là không có được làm UX strategy hoặc UX project từ A tới Z mà làm các khâu như phân tích (analyse), customer experience journey, và phần lớn là interactive wireframe. Chính vì vậy mà thời gian làm việc với Axure của tôi ngày một nhiều lên.
  • Với những dự án re-design (website hoặc mobile app) thì chi phí cho UX là rõ ràng, tách biệt, tuy nhiên cũng không nhiều. Một lần nữa, chi phí này không dành cho user research. Các công việc cần làm là hợp tác với nhóm creative design (có thể của 1 bên thứ ba), với nhóm marketing để có số liệu. Các công việc như personas, user interview chủ yếu được thực hiện dưới dạng remote research. Tất nhiên vì thế mà tính hiệu quả không thực sự mạnh, làm đi làm lại cũng nhiều và chi phí UX cho phía công ty tôi đang làm cũng không cao. (vì đâu có làm được full qui trình cho họ). Mặc dù vậy, xét một cách tích cực thì khi đã có chi phí UX, nó cũng chiếm 20-30% tổng chi phí của dự án, có khi ngang bằng chi phí development, deploy, support cộng lại.

Như vậy có thể thấy rằng, chi phí cho UX ở đây (các công ty và dự án ở Việt Nam) hiện tại chưa nhiều và chưa định hình rõ ràng. Muốn làm về UX bạn cũng cần chọn những nơi có chi phí để làm, cũng như có chính sách hỗ trợ nó.

Một khía cạnh khác mà bạn cũng cần quan tâm là “không ai rót chi phí UX cho bạn để làm chơi”. Chi phí UX, theo kinh nghiệm của tôi, trước giờ luôn gắn với KPI dự án. Dù là dự án nội bộ. Ví dụ như một khách hàng của tôi, website của họ có doanh số online 500k – 1 triệu USD / tháng, họ đặt ra tiêu chí tăng trưởng 1% – 3% cũng khiến cả team của tôi “chạy theo” hết hơi rồi.

Vẫn biết UX project là ideal – build – test rồi lặp đi lặp lại, nhưng nếu quá trình này kéo dài quá lâu thì bạn sẽ không còn chi phí để thực hiện, lúc đó sẽ lẹm vào chi phí của các hạng mục khác trong dự án và thua lỗ là khó tránh. Vì vậy, UX lead và Project lead cần phối hợp chặt chẽ với nhau trong hoạch định dự án, và tới đây bạn cũng có thể thấy rằng làm UX cũng nhiều áp lực.

Persona or User Stories?

Nên sử dụng kỹ thuật persona hay là dùng user’s stories?

x1

(Ảnh: 90’s game – nguồn: www.hanselman.com)

Dạo gần đây thấy nhiều bạn (kể cả bạn sếp của mình) hay nói về user stories khi phân tích yêu cầu người sử dụng trong quá trình phát triển sản phẩm /dự án. Phần lớn tôi thấy các bạn có thể liệt kê ra hàng loạt user stories đối với một dự án web hoặc mobile. Ai cũng thuộc làu làu “khẩu quyết võ công” như sau:

“As a <type of user>, I want <some goal> so that <some reason>.”

Cá nhân tôi thấy pattern này áp dụng khá dễ dàng, dễ hiểu, có thể thể hiện cái người dùng muốn mà không phải giải thích nhiều ở góc độ kỹ thuật. User stories nếu liệt kê ra (đối với sản phẩm mang tính phức tạp cao như e-Commerce, Enterprise app) thì dài hàng chục trang giấy. Nó không phải là vô ích, nhưng với MVP hay Lean thì.. hơi mệt (cá nhân mình thấy vậy)

Tôi bắt đầu làm Scrum vào năm 2006 khi công tác tại Cebu – Philippines. Lúc đó tôi cũng áp dụng “máy móc” theo cách “As user.. I want…” để liệt kê đủ những stories mà mình thấy hệ thống cần có. Chẳng quan tâm tới những gì khác, cũng không biết người dùng thực sự họ nghĩ gì… Và tôi cảm thấy: xác định user stories không phải (không nên) là bước đi đầu tiên.  Với tôi, nó là persona.

Nói một cách đơn giản, ví dụ như trong cuộc sống, trước khi nghĩ rằng mình nên làm thế này, thế kia để lấy lòng 1 bạn gái, bạn cần phải hiểu người ta trước đã. Persona cũng vậy. Trước khi viết ra những user stories chính xác và phù hợp với user’s needs, bạn cần phải hiểu target users của mình cũng như hiểu khách hàng của mình cần gì. Trong nhóm target user của bạn, có bao nhiêu personas? Hay đơn giản hơn, bạn phân loại người dùng của mình theo nhóm, rồi tìm hiểu những nhu cầu, khó khăn và mục tiêu cần đạt được của họ khi sử dụng sản phẩm, rồi qua đó mới đưa ra những thứ họ cần về mặt chức năng của hệ thống.

Ví dụ dưới đây là sự phân cấp theo cách hiểu của tôi (cách tôi được học) về user research, kết hợp UX và Agile:

  • Persona
    • Epic
      • User stories
        • Task break-down (WBS)

..qua đó, trước khi đưa ra các user stories chúng ta tiến thành phân nhóm người dùng bằng cách xây dựng các persona tiêu biểu, rồi qua đó đưa ra nhưng chức năng chính của hệ thống, sau cùng mới xây dựng những chức năng cụ thể cho từng nhóm người dùng.

Nếu ngay từ đầu, bạn dựa vào thảo luận nhóm, dựa vào kinh nghiệm, dựa vào survey 1 nhóm người bạn quen, và đưa ra danh sách các user stories thì theo tôi, sẽ có nhiều điểm không phù hợp với UX approach, cụ thể như sau:

  1. Wrong target user: Không đúng đối tượng người dùng. Bạn thiết kế 1 website bán hàng rau củ quả, nhưng bạn, dựa vào kinh nghiệm thiết kế UX, liệt kê ra một loạt tính năng của e-commerce trong khi bạn không hiểu họ là những ai? Cụ thể hơn, user của bạn là phụ nữ, độ tuổi 25-40 tuổi, thường online vào giờ nào (để mua sắm)? , cần trình bày thông tin của những sản phẩm thiết yếu gì? khó khăn của họ là gì? Họ quan tâm tới rau tươi, tiết kiệm thời gian mua thực phẩm thiết yếu, giao hàng nhanh chóng đúng hẹn v.v.. Những thứ khác kiểu như so sánh sản phẩm, nhóm sản phẩm, bộ lọc, các loại hình thanh toán, zoom in/out sản phẩm… chỉ là thứ yếu.
  2. No role: với persona, bạn chỉ quan tâm tới người dùng thực sự, phân loại họ dựa trên các yếu tố con người , không phải tuân theo các vai trò của người dùng hệ thống (Kiểu như admin, mod, super user, newbie). Điều này tránh sa đà vào việc phân tích hệ thống thay vì phải phân tích người dùng.
  3. Wrong time (and waste): Loanh quanh với user stories ở giai đoạn đầu của quá trình phát triển sản phẩm sẽ khiến bạn và team của bạn tốn rất rất nhiều thời gian. Thời gian phân tích, rồi xếp loại, rồi thiết lập thứ tự ưu tiên.. một lần nữa, nó khiến bạn tốn nhiều công sức trong khi bạn cần tập trung toàn lực vào suy nghĩ làm sao hiểu được nhóm user nào bạn cần phục vụ, khó khăn của họ là gì và mong muốn của họ ra sao (ở một mức độ rất high level).

Nói tóm lại, mấy thứ như epic, user stories, use case, scrum.. là cần thiết nhưng không nên lạm dụng. Scrum là 1 framework chứ không phải là process. Nghĩa là cái gì phù hợp đúng hoàn cảnh, thời điểm, đặc tính của sản phẩm thì ta áp dụng. UX vẫn cần chú trọng tới tìm hiểu và phân loại người dùng, xây dựng và điều chỉnh persona trong suốt vòng đời của sản phẩm, và những thứ như Lean, Scrum concepts là bạn đồng hành đi theo và hỗ trợ lẫn nhau.

P.s: Bài viết này phần lớn là quan điểm cá nhân. Tôi không muốn thấy quá nhiều bạn cứ băm bổ vào Agile/Scrum và cứ mang nó “đè” lên cái cơ bản của UX 🙂