Xây dựng Customer Journey Map – Phần 4

15/06/2016

Bước 5: User Workshop – Hypotheses validation

Tái thẩm định hypotheses với khách hàng để rút ra sự hiểu biết sâu hơn về những vấn đề (issues) và nhu cầu của họ (user needs).

Việc validation này được thực hiện thông qua một User Workshop. Mục đích của workshop này là mời những người dùng thực tế đến, giải thích sơ bộ cho họ về Hypotheses CJM và nhờ họ tái thẩm định lại CJM này.

IMG_0027

Có nhiều điều cần lưu ý về việc tổ chức và triển khai workshop kiểu này. Ở đây mình chỉ nói một cách đơn giản và khái quát vài điểm quan trọng:

  • Số lượng user tham gia: 10 – 15 (không nên nhiều hơn con số này)
  • Nên có thêm một số đại diện của các bộ phận khác trong công ty, ví dụ: giao nhận, marketing, customer support,… Họ có thể cùng tham gia hoặc đóng vai trò quan sát cũng được, nhưng nên có.
  • Nên chia những người tham dự thành một số nhóm nhỏ tầm 4-6 người/nhóm.
  • Warm up bằng một số hoạt động như self-introduction, user story telling,…
  • Có một bước gọi là (In)validating assumption, cách tiến hành: in hypotheses CJM ra thành nhiều bản lớn (2-3m), dẫn dắt họ qua những assumptions của chúng ta. Từ đó nhờ họ điều chỉnh lại những bước (stages), những kỳ vọng (expectations) và trải nghiệm (emotions) của họ qua từng bước. Nhờ họ đánh dấu những điều đó lên HJM, cứ vậy hết nhóm này đến nhóm khác (do đó cần in CJM ra nhiều bản).
  • Những thông tin cần phải uncover trong workshop này bao gồm:
    • Loại hành động (Actions);
    • Touch point (phương tiện để thực hiện hành động đó, vd: điện thoại, laptop, call center, sales agent,…);
    • Nhận thức (perception);
    • Suy nghĩ (thoughts);
    • Cảm xúc (emotions) của họ trong khi tiến hành từng bước;
  • Hoạt động tiếp theo cần làm là facilitate để họ cùng nhau xây dựng lên một CJM hoàn hảo theo suy nghĩ của họ.
  • Trong một số trường hợp, có thể tiến hành cho họ vẽ thử một số prototype, tất nhiên prototype này không dùng để đưa cho development team mà thông qua đó chúng ta sẽ thấy được những ý tưởng của họ (đôi khi rất kỳ quặc) và từ đó hiểu rõ hơn họ muốn gì.
  • Cuối ngày sẽ là users chia sẻ về những gì họ đã làm, những pain points quan trọng đối với họ,… với toàn bộ mọi người và sau đó cùng nhau thảo luận.
  • Debrief: Sau buổi workshop này UX Designer và các stakeholder nên có một buổi debrief ngắn để xác định những điểm quan trọng đã được uncover trong buổi workshop.
• • •

Xây dựng Customer Journey Map – Phần 3

15/06/2016

Bước 3: User Experience Research

Bước này sẽ dùng những kỹ thuật chuyên cho UX research như:

  • Customer Interview (thường gọi là CI): phỏng vấn người dùng, chi tiết tiến hành CI như thế nào thì các bạn tự tìm hiểu trên mạng, có dịp mình sẽ nói chi tiết hơn trong một bài khác. Lưu ý là cái này khác với market research nhé.
  • Field observation (thường gọi là Shadowing): đến trực tiếp hiện trường để quan sát hành vi của khách hàng.
  • Empathy mapping (tự tìm hiểu qua cùng keyword).
• • •

Xây dựng Customer Journey Map – Phần 2

11/06/2016

Để bắt đầu, thường thì nếu điều kiện cho phép, mình sẽ yêu cầu setup một phòng riêng gọi là war room (keyword: “ux war room”). Trong đó in ra tất cả những thông tin có được đính lên tường, đây sẽ là nơi để trao đổi giữa mình với product owner và các stakeholders, có một nơi như thế này cũng sẽ tiện cho bất kỳ ai/bất kỳ lúc nào cũng có thể vô brainstorm mà không tốn thời gian setup lại.

Một cái war room sẽ trông như vầy:

warroom

Nếu để ý bạn sẽ thấy làm UX đa số dùng những cách làm “thô sơ”. Tụi mình đã thử đủ thứ ứng dụng, phần mềm,… cuối cùng thì những cách làm “thô sơ” này vẫn luôn hiệu quả nhất (đọc thêm ở đây). Ưu điểm lớn nhất của cách làm này là tính trực quan, bên cạnh đó các stakeholders và users ai cũng có thể tham gia được dễ dàng, không lệ thuộc vào công nghệ.

Như đã nói ở bài trước, cách mình viết sẽ là gợi mở vấn đề, đưa ra những keyword để các bạn tự tìm hiểu và nghiên cứu thêm. Từ đó chọn ra cách làm phù hợp với bản thân và công ty của mình. Mình sẽ không đưa ra template hay kết quả mẫu. Đó cũng là cách để các bạn xây dựng riêng style làm UX cho mình.

• • •

Xây dựng Customer Journey Map

10/06/2016

Lại kể chuyện tiếp về thời gian đi làm consultant.

Đa số trường hợp, khi khách hàng đã bắt đầu cần đến consultant nghĩa là họ đang đối mặt với những vấn đề mà nguồn lực bên trong công ty không tìm ra được giải pháp. Do đó họ mới cần đến một nguồn lực bên ngoài vào giúp họ. Vậy làm thế nào mà tụi mình – những người ất ơ từ đâu đến – lại có thể giúp họ tìm ra giải pháp? (trong khi họ là những người làm việc sát cánh ở công ty trong thời gian dài – là người có nhiều insight nhất – còn chưa tìm ra được giải pháp).

Bài này mình sẽ chia sẻ một trong những kỹ thuật mà tụi mình dùng rất nhiều (và cũng thường tư vấn khách hàng tiến hành nhất). Đó là Customer Journey Map.

Loạt bài này sẽ hơi dài (dù mình đã cố viết ngắn nhất có thể) và thuộc dạng hơi nâng cao một chút, nên những ai chưa biết về khái niệm UX Design có thể đọc thêm bài tổng quan ở link này. Ai muốn hiểu hơn chút xíu về công việc UX consultant có thể đọc thêm ở đây.

Như thường lệ bài viết sẽ dùng nhiều từ tiếng Anh, không phải vì “chảnh” (dù bình thường mình cũng chảnh), mà do có 2 lý do chính:

  • Các từ đó sẽ là keyword cho các bạn dùng để nghiên cứu sâu hơn.
  • Cho tiện viết bài, vì một số từ dịch ra tiếng Việt nghe rất kỳ.

• • •

Less is more

09/06/2016

Có câu chuyện nho nhỏ về việc viết email.

Thời gian làm consultant, mình có làm việc onsite ở một công ty khách hàng. Ở đó mình làm việc cùng với một bạn Head of CX (Customer Experience). Tuy chỉ trong thời gian ngắn nhưng mình học được khá nhiều cách làm việc và tư duy của bạn.

Có một chi tiết mình vẫn nhớ.

Trong mọi giao tiếp, đặc biệt là bằng email, bạn thường viết rất ngắn gọn, đi thẳng vào ý chính, hầu hết là dùng bullet points. Có vài lần (chính xác là 2 lần) bạn gửi cho mình email khá dài. Và mình để ý cả 2 lần, ở cuối email bạn đều kèm theo dưới email một dòng: “Xin lỗi tao viết email này hơi dài, nếu có thời gian tao hẵn đã viết nó ngắn hơn”.

Hôm sau gặp bạn, mình hỏi: “Sao mày lại xin lỗi?”

Bạn trả lời như sau: “Một email dài sẽ làm người đọc bực mình khi nhận, mệt mỏi khi đọc, mất thời gian khi xử lý để nắm được ý mình muốn gì. → Viết một email ngắn mà vẫn truyền tải đủ ý sẽ làm cho người đọc có một trải nghiệm tốt hơn. → Nhưng viết ngắn cần phải có thời gian để optimize. → Và mấy lần viết dài cho mày là những lần tao đang gấp không có thời gian optimize. Nên tao có thói quen mỗi khi viết dài thì tao xin lỗi”.

“Less is more” – rule cơ bản nhất của UX – được bạn áp dụng vào cả việc viết email. Không quá khó hiểu khi bạn nắm toàn bộ mảng CX của một trong những công ty lớn nhất ở Úc.

• • •

Các thiết bị chuyên dụng cho UX, cần hay không?

12/05/2016

Có nhiều công ty quan niệm rằng đầu tư cho UX rất tốn kém, trong đó một phần không nhỏ là đầu tư vào các thiết bị, phòng óc, máy móc chuyên dụng. Vậy những thiết bị này có thực sự cần thiết không? Liệu rằng phải có thiết bị thì mới triển khai được?

Câu trả lời ngắn gọn là: Không!

Câu trả lời dài dòng là:

• • •

Quy trình tuyển dụng một UX Designer

28/04/2016

Hồi đầu năm nay mình lead một dự án nhằm xây dựng lại quy trình tuyển dụng cho team Product Design ở công ty. Để có được quy trình này, mình và công ty đã tốn rất nhiều thời gian tham khảo các quy trình tuyển dụng từ các công ty lớn khác ở Úc và Mỹ + kết hợp với tình hình thực tế của công ty + tư vấn từ các chuyên gia trong ngành và chuyên gia tuyển dụng (có thuê hẳn một consultancy để tư vấn).

Quy trình này thoạt trông thì có vẻ hơi dài tuy nhiên nếu so với các công ty lớn khác ở Úc thì cũng thuộc dạng trung bình. Khi thăm dò phản hồi của các ứng viên thì đa số cũng phản hồi là không quá dài.

Bài bên dưới là dành cho công việc UX Design, các vị trí khác như UX Researcher hay Visual Designer cũng tương tự, chỉ khác bài test cà cách tiến hành Onsite Interview.

Chia sẻ lại cho những ai quan tâm.

• • •

Check out process

14/01/2016

Khá nhiều website thương mại điện tử vẫn đang thiết kế những process check out kiểu như vầy:

• • •

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

• • •

Lý thuyết và thực hành

26/08/2015

Công ty gần đây mình làm việc là một UX Consultancy khá nổi tiếng (Top10 UX Consultancy lớn nhất Úc), khách hàng của công ty trải rộng trong nhiều lĩnh vực (tài chính, technology, telecommucation,…)

Nói thêm một chút về mô hình công ty này vì nó khá thú vị và (hình như) chưa có ở Việt Nam – ít ra là trong ngành UX.

Công việc chủ yếu của bọn mình là đến trực tiếp trụ sở của khách hàng và làm việc (gọi là onsite), thường là mỗi người sẽ được giao một dự án và trực tiếp lead team của khách hàng (gọi là inject).

Tùy theo industry và quy mô của công ty khách hàng mà: khi thì bọn mình sẽ lead một team Dev, khi thì sẽ lead một team UX Design (đóng vai trò như một UX Lead), thậm chí có trường hợp là one man show luôn (tự xử hết). Đến khi deliver sản phẩm là coi như xong dự án, lại tiếp tục đi dự án khác. Industry mình phụ trách là FinTech (Financial Technology) nên thường môi trường là các ngân hàng và thường làm việc chung với team UX Design.

Công việc này khá thú vị vì:

1. Được làm việc với rất nhiều môi trường khác nhau, nhiều ngành nghề khác nhau.
2. Khác với mô hình Agency, Consultancy khi đến làm việc với khách hàng là với tư cách là một chuyên gia nên rất được cưng chiều và trao rất nhiều quyền. Chính điều này tạo điều kiện rất thuận lợi cho bọn mình làm việc (và dĩ nhiên expectation của khách hàng cũng rất cao).
3. Đi rất nhiều nơi (nhờ thời gian làm việc ở đây mà mình được đi nhiều nơi ở nước Úc) và thường đi lại ăn ở rất sướng.

Đổi lại thì kỳ vọng của khách hàng đặt lên vai cũng rất lớn, nếu làm không tốt sẽ là thảm họa.

Do tính chất công việc là phải tự thân lead dự án của khách hàng nên trước giờ công ty tuyển rất kỹ, trung bình các bạn đồng nghiệp của mình có tối thiểu 10-15 năm kinh nghiệm trực tiếp trong ngành. Tuy nhiên thời gian gần đây công ty phát triển quá nhanh, mà nhân lực lại không đủ dẫn đến yêu cầu tuyển dụng giảm đi (trước đây trung bình khoảng 5 vòng thì bây giờ còn 3 vòng), trước đây sau khi tuyển dụng phải có gần 1 tháng induction mới ra field thì gần đây chỉ sau một tuần cá biệt có trường hợp vài ngày là ra field luôn.

Vì tình hình như vậy nên phát sinh một câu chuyện làm mình rút tỉa được một kết luận muốn chia sẻ với mọi người (sẽ kết luận cuối bài).

• • •