Product Designer tự học Data thế nào khi công ty chưa có cơ hội thực hành?
“Em chưa biết gì về Data”
“Công ty em chưa có cơ hội thực hành nhiều về Data ạ”
“À em cũng xem số rồi nhưng em chưa biết làm gì tiếp 🤦♀️”
Rất nhiều JD của các công ty hiện nay đều yêu cầu ứng viên có những hiểu biết, kinh nhiệm về Data như xác định metric, biết cách thu thập dữ liệu, phân tích dữ liệu, và từ đó đưa ra các quyết định thiết kế. Tuy nhiên đáng tiếc là chưa có nhiều nơi dạy về Product Design hiện nay đề cập đến kiến thức này.
Trăn trở về điều này đã lâu, nay mình mới có dịp ngồi lại để thực sự tổng hợp lại những kiến thức mình đã trải nghiệm trong 3 năm rưỡi làm việc tại OneMount, xoay quanh 2 chủ đề chính:
- 1 là Xác định metric cần đo
- 2 là Các công cụ có thể thu thập dữ liệu
Hy vọng đây là những hướng dẫn cơ bản nhất mà bạn các bạn Fresher, Junior có thể đọc xong và tự tư duy cho sản phẩm đang làm. Còn với các bạn đang là Senior hay Leader, có thể nhặt nhạnh được vài tips hay ho để xây dựng văn hoá Data cho team Product Design của mình.
1. Xác định metric cần đo
Cái gì không đo lường được thì không quản trị được. Vậy thì mình đo cái gì nhỉ? Khoan hẵng đi vào các chỉ số cụ thể như GMV, Traffic hay Bounce Rate… như rất nhiều bài viết mà bạn đã từng đọc.
Xác định metric cần đo cũng giống như việc bạn quyết định thu thập dữ liệu gì khi lên một kế hoạch research. Hãy xuất phát từ những câu hỏi bạn muốn trả lời trước, rồi từ đó tư duy mình cần đo metric gì.
Mỗi giai đoạn phát triển sản phẩm chúng ta lại có những thắc mắc khác nhau. Để cho “dễ tiêu hoá” kiến thức, mình sẽ dẫn bạn đi từng giai đoạn:
- (1) Khi bắt đầu dự án
- (2) Phân tích, đánh giá & cải tiến sau khi go-live tính năng
1. 1 Giai đoạn khi bắt đầu dự án
Với những team chưa có mức độ UX Mature cao, Product Designer gần như không hiện diện trong những buổi brainstorm tính năng, vẽ roadmap cùng các anh/chị PM, BA. Khi nhận đề bài thì đã có sẵn yêu cầu phải làm tính năng gì, dẫn đến không hiểu được:
- Mục tiêu cuối cùng của dự án này là gì?
- Tại sao mình cần làm tính năng này?
- Những tính năng mình phải làm đóng góp thế nào vào mục tiêu của công ty?
Nắm được North Star Metric (chỉ số quan trọng nhất của dự án) và Metric Tree (phương pháp vẽ các chỉ số phụ và nối vào các tính năng cần làm) sẽ giúp Product Designer tự tin giải đáp được những tâm tư trên.
1.1.1 North Star Metric
North Star Metric là chỉ số quan trọng nhất mà công ty tập trung đo lường và theo dõi. Mục tiêu của North Star Metric là định hướng chiến lược dài hạn cho sản phẩm, đồng thời đem lại giá trị lớn nhất cho người dùng.
Lấy ví dụ về website OneHousing mình đang làm, giả sử North Star Metric của dự án là Số lượng Deal (giao dịch mua bất động sản thành công).
Vì Deal = Lead x Tỷ lệ Deal/ Lead → Để tăng số lượng Deal:
- Squad Customer (làm website OneHousing phục vụ end-user) cần tập trung vào metric quan trọng nhất là tăng số lượng Lead — thông tin liên hệ của khách hàng đang quan tâm đến BĐS.
- Squad Agent (làm app ProAgent phục vụ sales) sẽ tập trung vào metric quan trọng nhất là tăng % Deal/ Lead — Tỷ lệ chuyển đổi từ Deal sang Lead.
Vậy làm thế nào để tụi mình biết được công ty đang hướng đến North Star Metric nào?
Để xác định đúng North Star Metric, mình cần phân biệt các loại metric cũng như PIC để không nhầm lẫn.
Nếu bạn chưa biết North Star Metric mình cần hướng đến là gì, ngay lập tức hỏi các anh chị Business Owner, Product Manager chia sẻ cho bạn về mục tiêu và chiến lược dài hạn của công ty nhé.
Nhưng nhỡ dự án của bạn chưa xác định được North Star Metric thì sao?
Team bạn có thể đọc bài viết dưới đây để tham khảo North Star Metric của các công ty khác cùng ngành và cùng model nhé ⤵️.
1.1.2 Metric Tree
Nắm trong tay chỉ số quan trọng nhất rồi, mình cùng tiếp tục bẻ nhỏ xuống để xác định các sub-metric (chỉ số phụ) cần hướng tới nhé. Các chỉ số phụ này sẽ được phân về các team nhỏ hơn, và là cơ sở để mình nghĩ ra các tính năng cần làm, phục vụ North Star Metric cuối cùng.
Vậy làm thế nào để vẽ được Metric Tree này?
Mình học được 2 phương pháp khá hay từ bài viết dưới, đó là Mathematical Relationships (mối quan hệ toán học) and Hypotheses (giả định). Dưới đây là toàn bộ bài viết gốc cho bạn nào muốn tìm hiểu sâu hơn, còn trong bài viết này mình chỉ xin tóm tắt phương pháp quan trọng nhất mà tác giả đề cập, kèm ví dụ mình đã áp dụng.
Phương pháp #1: Mathematical Relationship
Hiểu đơn giản thì bạn sẽ vẽ tiếp các tầng metric tiếp theo bằng phép toán cộng, trừ, nhân, chia. Tiếp tục ví dụ trên, các sub-metric mà website onehousing.vn cần hướng tới có thể là:
Số Lead = Số User x Tỷ lệ chuyển đổi từ Lead sang User
Liên quan đến các metric về Users, bạn có thể bẻ nhỏ tiếp dựa trên User Segment và Marketing Source. Đây là 2 tips có thể áp dụng cho bất kỳ sản phẩm nào bạn đang làm.
- Tip #1: Dựa trên User Segment
Ví dụ: User = New User + Reactivated User + Returning User
New User là tập user mới. Returning User là tập users ngay lập tức quay lại website/app trong tháng sau. Reactivated User là những users đã từng truy cập website/app vào tháng T, và quay lại vào những tháng sau nữa (T+2, T+3…).
Để chăm sóc mỗi tập users trên, sản phẩm cần đánh những chiến lược khác nhau, nên việc bẻ nhỏ các metric càng chi tiết càng tốt sẽ giúp team bạn vẽ được bức tranh đầy đủ hơn trong dài hạn, tránh chỉ tập trung kéo traffic vào web/app mà quên việc tối ưu UI/UX để retain users.
- Tip #2: Dựa trên Marketing Source
Ví dụ: New User = Organic User + Direct User + Paid User + …
Không thể thiếu được hàng xóm Marketing trong câu chuyện giúp sản phẩm tăng trưởng người dùng trên các kênh khác nhau, vì vậy đừng quên kéo người anh em Marketing cùng brainstorm các chỉ số, giải pháp hai bên cần phối hợp để hướng đến mục tiêu chung nhé.
Phương pháp #2: Hypothesis
Bất kì khi nào bạn có Qualitative Data (dữ liệu định tính) hoặc Quantitative Data (dữ liệu định lượng) về users, bạn đều có thể sử dụng phương pháp này với 3 tips dưới đây:
- Tip #1: Sử dụng dữ liệu hành vi của người dùng
Ví dụ: từ dữ liệu, bạn tìm ra đa số tập người dùng quay lại website đều có hành vi xem ít nhất 3 căn nhà trong sessions đầu tiên. Suy ra, để tăng Returning User → sản phẩm nên tăng tập người dùng có hành vi trên.
Để tìm hiểu thêm về cách tiếp cận này, bạn có thể tham khảo một bài viết rất nổi tiếng của Facebook về cách họ tìm ra “Aha Moment” — nếu một người dùng mới kết bạn với ít nhất 7 bạn bè trong 10 ngày đầu tiên, họ có khả năng quay lại sử dụng Facebook hơn ⤵️
- Tip #2 — Phỏng vấn người dùng
Ví dụ: để tăng Reactivated User → bạn có thể hỏi người dùng động lực gì sẽ khiến họ tiếp tục quay trở lại một website? Giả sử động lực đó là xem có căn nào mới không? Suy ra, để tăngsố lượng Reactivated User → sản phẩm nên tăng Tỷ lệ users quay lại website để xem các căn mới tương tự căn họ đã tìm kiếm.
- Tip #3: Dựa trên Customer Journey Map
Ví dụ: để một User chuyển đổi thành Lead, nghĩa là để một người mua nhà xem tìm kiếm bất động sản trên website OneHousing và có động lực để lại thông tin liên hệ, họ sẽ đi qua Customer Journey như bên dưới:
Suy ra, để tăng % Lead/ User → sản phẩm nên tăng các sub-metric bên dưới:
1.1.3 Có North Star Metric và Metric Tree rồi thì mình làm gì tiếp?
Phù 😮💨 Đã vất vả vẽ xong các Metric Tree từ North Star Metric rồi, sắp nhìn thấy ánh sáng cuối con đường rồi 💪 Giờ là lúc Product Designer tụi mình cần hợp lực cùng các anh chị PM, PO, BA, thậm chí là các anh/chị team Tech để brainstorm các tính năng cần làm, nối vào Metric Tree và North Star Metric vừa vẽ.
Ví dụ để tăng Tỷ lệ users xem ít nhất 3 căn nhà trong sessions đầu tiên → sản phẩm có thể làm tính năng Gợi ý các căn tương tự cùng vị trí, dự án, mức giá, số phòng ngủ…
Cho xin 500 hình Full HD không che bạn Linh ơi xem nó trông như thế nào? — OK sốp 👌. Hình ví dụ thôi nhe. Chứ ngồi lai rai làm thêm vài cốc bia với tí lạc rang nữa thì cái hình này nó phình to dữ lắm.
Có được bức tranh tổng quan này rồi thì dự án của bạn yên tâm có nguyên liệu để “nấu nướng” roadmap dài hạn, giúp team có định hướng rõ ràng hơn, hạn chế làm đến đâu “quay xe” đến đó.
1.2 Giai đoạn đo lường, phân tích và đánh giá sau khi go-live
Khi mình mới bắt đầu với team OneHousing, một trong những thử thách mà mình gặp phải chính là đây. Có 3 vấn đề chính mình nhận ra được:
- 1 là Quy trình phát triển sản phẩm chưa có khâu tracking data → collect data → visualize data để phục vụ việc đánh giá và cải tiến sau khi go-live.
- 2 là Không phải tất cả Stakeholders đều có mindset về Data Analysis.
- 3 là Team chưa biết đo xong những con số ở trên thì làm gì tiếp? Làm thế nào để đánh giá số đó đã tốt hay chưa tốt? Nếu thấy số thấp thì phân tích thế nào để hiểu nguyên nhân? Phải làm gì tiếp để cải tiến?.
Trong giới hạn bài này, mình sẽ chỉ tập trung giải quyết vấn đề 3. Vấn đề 1 & 2 liên quan đến xây dựng quy trình phối hợp với nhiều stakeholders, chuẩn hoá dữ liệu event tracking… Nếu bạn quan tâm có thể “hẹn hò” cafe với mình để cùng chia sẻ nhé 🍺 🥜 À lộn, icon này mới đúng ☕️.
1.2.1 Vậy làm thế nào để đánh giá chỉ số cao hay thấp? tốt hay xấu?
Tiếp tục với một trong những tính năng chúng ta đã brainstorm ở trên. Giả sử một ngày đẹp trời team sản phẩm OneHousing vừa triển khai xong tính năng Search — Tìm kiếm căn nhà
- Sau 1 tuần triển khai, team đo lường thấy có 80 users bấm vào các căn nhà trên trang kết quả tìm kiếm. Mới có 80 người thôi á??? Nghe có vẻ buồn. Nhưng mà khoan, nếu tính trên tổng 100 users đã tìm kiếm, và có đến 80% (~ 80 users) bấm vào kết quả thì cũng không phải dạng vừa phải không? 😃
- Sau vài tháng chạy tính năng, team sản phẩm thấy một con số khả quan hơn là 80,000 users bấm vào kết quả tìm kiếm. Nghe cũng nhiều nhiều ha? Nhưng nếu so sánh với tháng trước đó, tháng 8/2022 có tận 100,000 users bấm vào kết quả tìm kiếm, tụt 20%, thì thôi… cụ đi chân lạnh toát! 🥲
Hai ví dụ ở trên đã giúp chúng ta rút ra được 2 tiêu chí cơ bản nhất để chọn đúng chỉ số cần đo lường:
Tiêu chí #1: Comparative (có tính so sánh)
- So sánh với tháng trước
- So sánh với các tính năng tương tự trong cùng website
- So sánh với benchmark của thị trường: các bạn có thể tìm kiếm theo tính năng (VD: “Search Engine Benchmarks”) hoặc theo ngành hàng (VD: “Real Estate benchmarks)
Tiêu chí #2: Rate or Ratio (có tính tỷ lệ)
- Tính trên tổng số user vào trang
- Tính theo Funnel từng bước user thao tác
Báo cáo số tổng vẫn cần thiết với mục tiêu Branding, nhưng với team sản phẩm, biết có 1 triệu users hay 10 triệu users không giúp mình đánh giá điều gì để biết cách tối ưu về sau.
1.2.2 Đánh giá được chỉ số cao hay thấp rồi, làm thế nào để chúng ta hiểu được lí do tại sao?
Để đào sâu phân tích thêm lí do thì team cần cùng nhau brainstorm các giả định và kiểm chứng qua dữ liệu định lượng (User Metric) hoặc dữ liệu định tính (User Insight).
Giả sử sau khi triển khai tính năng, team sản phẩm thấy chỉ số Tỷ lệ users bấm vào kết quả chỉ ~ 10 %, được đánh giá là thấp. Có những giả định nào khiến tỷ lệ trên thấp đến vậy?
- Giả định #1: Users không tìm thấy kết quả sau khi tìm kiếm
- Giả định #2: Users có tìm thấy kết quả tìm kiếm nhưng thông tin tại trang kết quả không đủ hấp dẫn để users bấm xem chi tiết
Để kiểm chứng giả định #1 — Users không tìm thấy kết quả sau khi tìm kiếm, chúng ta sẽ đo thử Tỷ lệ từ khoá tìm kiếm không ra kết quả. Nếu con số đó khá cao ~ 70%, chúng ta sẽ làm gì tiếp để cải tiến tính năng Tìm kiếm? Lúc này mình sẽ cần thu thập User Metrics — Top từ khoá user tìm kiếm mà không ra kết quả.
Nhìn vào bảng trên mình có thể thấy ngay hành vi tìm kiếm của user rất đa dạng mà sản phẩm chưa thể đáp ứng được. Ví dụ:
- Tìm kiếm theo toà và phân khu (VD: toà S2.03, phân khu Chà Là…)
- Kết hợp nhiều tiêu chí tìm kiếm (VD: căn 2PN + toà S2.07 + The Sapphire — Vinhomes Ocean Park)
- Cùng một tiêu chí nhưng gõ khác nhau (VD: căn 1 phòng ngủ, căn 1PN)
Với Giả định #2 — Users có tìm thấy kết quả tìm kiếm nhưng thông tin tại trang kết quả không đủ hấp dẫn để users bấm xem chi tiết, bạn có thể thực hiện Usability Testing và thu thập User Insight để kiếm chứng giả định này.
1.2.3 Làm thế nào để không bỏ sót các Product Metric cần đo?
Vũ khí để đánh giá và phân tích cơ bản là đủ, nhưng với Junior thậm chí là Senior Product Designer, những Data Analyst “tay ngang” chưa có nhiều kinh nghiệm, chúng ta rất dễ nhìn thiếu góc độ để đánh giá sản phẩm. Để không bị “bí” khi xác định metric, các bạn có thể tham khảo thêm HEART Framework — phương pháp đánh giá và đo lường hiệu quả sản phẩm được phát triển bởi Google.
Áp dụng HEART Framework như thế nào?
5 loại chỉ số trên giúp chúng ta không bị bỏ sót tất cả cả điểm chạm trên hành trình của người dùng từ lúc biết đến tính năng — Adoption, tương tác với tính năng — Engagement, thực hiện các nhiệm vụ — Task Success và quay lại sử dụng — Retention. Cuối cùng thì, người dùng đánh giá mức độ hài lòng về sản phẩm thế nào? — Happiness.
Tư duy giúp chúng ta xác định đúng metric ở mỗi điểm chạm là đi từ:
- Goal: Mục tiêu sản phẩm là gì?
- Signal: Điều đó thể hiện qua hành vi gì của người dùng?
- Metric: Chỉ số nào giúp chúng ta đo lường hành vi đó?
Mình sẽ lấy ví dụ về tính năng Property Detail (Thông tin căn nhà) trên website onehousing.vn để mình cùng hiểu hơn nhé.
2. Các công cụ có thể thu thập dữ liệu
Xác định được metric rồi, thì mình “đào số” ở đâu ra?
2.1 Tích hợp công cụ có sẵn
Tool toy thì vô biên lắm, nhưng có những công cụ sau đây rất phổ biến mà nếu team bạn chưa bao giờ sử dụng thì hãy nhanh trí đề xuất ngay với các anh/chị Product Manager, Tech và Data tích hợp vô nhé.
Team mình đã từng thử tích hợp Clarity lên website OneHousing, dù miễn phí nhưng lợi hại không kém gì các công cụ trả phí, bạn có thể đọc bài viết review của mình dưới đây nhé 👇
2.2 Công cụ “của nhà trồng được”
Các công cụ trên sẽ chỉ cho chúng ta các chỉ số tổng quan nhất, đôi khi để đào sâu nghiên cứu, Product Designer sẽ cần đề xuất team Dev hỗ trợ code thêm một vài event tracking.
Event Tracking là dữ liệu ghi lại hành vi của người dùng trên website (không ghi lại các thông tin cá nhân). Mỗi 1 hành động của user (view, click, scroll…) sẽ được ghi lại thành 1 event.
Để tiết kiệm thời gian, bạn nên đề xuất team triển khai code tracking theo components trong Design System của team Product Design. Để khi Product Designer sử dụng lại các components đó, trên sản phẩm đã có ngay tracking mà không cần team Dev code lại từ đầu.
Mỏ vàng dữ liệu để tha hồ đào đây rồi, công việc đơn giản còn lại là qua “đấm bóp” các bạn Data để giúp team tính toán các metric ở trên. Nếu hàng xóm Data bận quá, thì mình cực kỳ khuyên các bạn Product Designer nên luyện 2 võ công sau đây, đảm bảo có thêm nhiều điểm cộng trong CV 👌.
- SQL — ngôn ngữ giúp chúng ta query, tự “đào” dữ liệu khi cần. Học qua các Online Course và đừng quên nhờ ChatGPT hỗ trợ nhé.
- Exel, Looker Studio, Tableau, PowerBI — các công cụ phổ biến nhất giúp visualize data. Học cái nào sẽ phụ thuộc vào công ty bạn chọn công cụ nào để sử dụng, không nên học hết sẽ bị thừa kiến thức.
Lời kết thân thương.
Hy vọng một vài tips trên sẽ giúp cho bạn có đủ vũ khí cơ bản để biết đọc số hiểu số, biết cách phân tích và đánh giá. Đừng quên kéo các anh chị anh chị Product Manager, Product Owner, Tech Lead, QC Lead… vô cùng bàn luận để lan toàn văn hoá Data Analysis nhé 😉
