/Xây dựng Customer Journey Map (CJM) – Phần 4

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

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.

” Lời của Phạm Khôi: Tôi đang chuẩn bị ra 1 chuyên đề về vấn đề Customer Journey Map thì search ra được website của bạn này: http://tapbut.ngochieu.com. Đây là một blogger thú vị và giàu kinh nghiệm về UX. Tôi thấy rằng không nên viết lại một vấn đề về điều này nữa, thay vì vậy tôi sẽ đọc và comment của bạn này, để giải thích hoặc đưa ra các quan điểm của mình. Dù sao thì tôi vẫn chưa xin phép tác giả, tôi sẽ liên lạc để xin phép tác giả ngay sau đây. Các bạn có thể xem bài viết gốc tại đây: http://tapbut.ngochieu.com/xay-dung-customer-journey-map/

Phải nói rằng là dù tôi thấy đây là 1 chủ đề thú vị và quan trọng nhưng khá là nâng cao về UX Design, đặc biệt là ở Việt Nam mà áp dụng phương pháp này có lẽ là hơi khó và tiêu tốn nhiều công sức. Do đó, tôi sẽ tìm đến 1 phương pháp rút gọn hơn và sẽ đề cập trong 1 bài viết khác.

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:

Khóa học online miễn phí “Tự học để trở thành UX Designer” của tác giả Phạm Khôi với 4 giờ – 40 phút video + tài liệu Designlab.edu.vn, dành cho UI Designer, Product Owner, Developer và sinh viên..

BẮT ĐẦU HỌC

Không cần đăng ký hoặc trả bất cứ chi phí nào! Tất cả đã sẵn sà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.

Điểm quan trọng trong buổi workshop này là UX Designer phải có kỹ năng facilitate sao để extract được nhiều thông tin từ user nhất. Motivate và dẫn dắt họ chia sẻ nhưng không để bị bias bởi những ý kiến của mình,…

Bước 6: Matching những insight từ workshop với các thông tin thô đã có từ trước.

Nhiều lần mình nhận được câu hỏi là trong buổi workshop như vậy chỉ có từ 10-15 người, vậy làm sao đủ để đại diện cho toàn bộ khách hàng của công ty. Câu trả lời là ý nghĩa của workshop này là để thu hẹp lại và đào sâu insight hơn. Và sau đó matching với những thông tin rộng (mà cạn) mà chúng ta đã thu thập được ở các bước trước.

Đó là chúng ta có bước 6 này, bước kết hợp thông tin rộngthông tin sâu lại với nhau.

  • Thông tin rộng chúng ta có từ những dữ liệu analytics, survey ở bước 1.
  • Sau đó chúng ta bắt đầu chuyển sang thông tin sâu khi bắt đầu làm UX Research.
  • Và cuối cùng journey workshop là thông tin sâu nhất.

Sau khi kết hợp tất cả thông tin với nhau + validate mọi thứ → chúng ta sẽ có những hiểu biết khá vững chắc về những gì đã extract được từ user.

Và sẵn sàng để chuyển sang bước 7.

Bước 7: Phân tích để tìm nguyên nhân vấn đề (root cause).

Những pain points mà khách hàng gặp phải chỉ là phần nổi của tảng băng, đôi khi gốc rễ của vấn đề nằm tuốt mấy tầng sâu bên dưới. Do đó bước này rất quan trọng để uncover đâu là gốc rễ thật sự của vấn đề cần khắc phục, nhằm tránh trường hợp chặt cây từ ngọn.

Việc phân tích root cause được tổ chức qua một buổi Stakeholder Workshop. Buổi này thường có mặt của các stakeholder quan trọng, ví dụ với ngân hàng thì có: Product Owner, Business Analyst đại diện cho Technical, đại diện của Marketing, Compliance (về luật pháp),…

Kỹ thuật được dùng trong bước này là 5-WHYS (từ khóa: “5 whys tool”). Đây là cách uncover vấn đề theo từng layer, qua 5 layers thì đa số uncover được đủ sâu nguyên nhân của vấn đề (gọi là “root cause”)

Bài sưu tầm Kỹ thuật thiết kế  Xây dựng Customer Journey Map (CJM) – Phần 4

Một ví dụ thường được dùng để giải thích cho 5-whys như sau:

  • Problem: Bị cảnh sát phạt
  • Why 1: Tại sao lại bị phạt?
    • Cause: Vì chạy quá tốc độ.
  • Why 2: Tại sao lại chạy quá tốc độ?
    • Cause: Đi làm trễ.
  • Why 3: Tại sao lại đi làm trễ?
    • Cause: Thức dậy trễ.
  • Why 4: Tại sao lại thức dậy trễ?
    • Cause: Đồng hồ báo thức không hoạt động.
  • Why 5: Tại sao lại lại không hoạt động?
    • Cause: Hết pin.
  • → Tới đây thì ra được gốc rễ của vấn đề và giải pháp khắc phục đơn giản hơn rất nhiều (thay pin). Nếu không dùng 5-whys thì chúng ta có thể đưa ra giải pháp ở đâu đó Why#2, là “chạy xe chậm lại” → nghĩa là không giải quyết triệt để vấn đề, về lâu về dài vấn đề sẽ vẫn còn đó.

Có một số từ khóa mà các bạn cần tìm hiểu sâu hơn ở bước này.

  • “Line of visibility” – Như đã nói pain points chỉ là phần nổi của vấn đề, và ở một điểm nào đó, các lý do sẽ không còn thấy nữa, điểm đó gọi là line of visibility. Đây là một từ khóa mà bạn cũng nên đào sâu tìm hiểu thêm, sẽ có rất nhiều ví dụ hay.
  • “Fishbone Diagram” – còn gọi là “cause and effect” hoặc là Ishikawa. Đọc thêm để hiểu về kỹ thuật này.

Những buổi workshop này thường là rất “rối loạn”, mỗi người một ý, ai cũng có insight và chủ kiến riêng của mình. Ai cũng cho là mình đúng. Là người faciliator, UX Designer phải biết dung hòa giữa kiến thức của mình và việc motivate để extract thông tin của các stakeholder, quan trọng những là để họ cảm thấy họ luôn là một phần của toàn bộ mọi việc. Đọc thêm một câu chuyện nhỏ về bạn đồng nghiệp của mình về việc này.

Cho đến lúc này thì ta đã khá rõ về journey của user, những vấn đề mà họ gặp phải.

Tuy nhiên chúng ta còn 2 mảng việc quan trọng nữa là balance nhu cầu của user với nhu cầu kinh doanh của công ty (business). Và từ đó xác định những cơ hội (opportunities), sau đó đề ra các giải pháp (solutions) và cuối cùng là tổng hợp lại trên các “nguyên liệu” (materials) có thể chia sẻ được.

Tất cả những điều này sẽ được nói đến trong phần cuối cùng, phần 5.

(Còn tiếp)

Software Product Designer Mobile: +84 981-911-011 Email: khoipn@uxvietnam.com Skype: khoipn - Always Online