Ship được một flow, một feature chỉ mới hoàn thành 1 nửa chặng đường, có thể nói là ta mới dừng lại ở việc deliver ra output, artifact gì đó và cho nó ra thế giới.
Thử hình dung artifact đó là một hợp chất A, ta release để nó tiếp xúc với world - hợp chất B, và ta cần xem chúng nó phản ứng ra sao, liệu sự phản ứng đó có phải thứ mà ta đang kì vọng. Sự phản ứng này chính là outcome của project/product, nếu mình không đo đạc chúng thì sẽ thiếu dữ kiện, thiếu định hướng, chơi bài may rủi, và tệ hơn là không learn được gì cả.
Đây là mindset nhìn nhận mình như là một nhà hoá học, mang tâm thế của một người thử nghiệm, các bạn có thể xem thêm bài này về
experimental mindset
.
Vậy câu hỏi: “ta nên đo lường ra sao?”
Phạm vi đo lường
Ta nói ta cần đo lường, không đo thì giống như chạy xe trong bóng đêm mà không có đèn. Tuy nhiên có bao nhiêu thứ cần đo? trước khi vô detail các loại metrics thì có thể bắt đầu từ phạm vi trước, vì mỗi phạm vi cho chúng ta biết những thứ khác nhau.
Note: mình hơi confuse nghĩ xem liệu có thêm feature hay module level không, vì anyway trong các daily task của designer vẫn dính nhiều đến feature hoặc một module nào đó, mà mình thấy nó có khi là combine của task & journey level, có khi lại nằm ở task level thôi,… nên thôi anyway thấy các level trên cũng đã đủ cover.
Các loại metrics
Nhìn một cách tổng quan nhất thì mình thấy có vài cái đo để giúp mình biết:
Quantitative:
cho mình biết “what & how many, when, where…”
Qualitative:
cho mình biết “why”
Tích cực:
đo xem thông qua design đó nó cải thiện được những gì?
Tiêu cực:
các metrics để ta hình dung được liệu user có gặp khó khăn, phiền hà ở đâu không?
Behavior:
nhận diện hành vi, thói quen dùng của user.
Attitude:
nhận diện thái độ của user, xem họ hiểu nó ra sao, có perception như thế nào? xem liệu họ có cần / có thích không?, có cảm giác gì khi dùng feature / product?
Nhiều lắm, nên mình nghĩ rảnh thì có thể tìm hiểu dần dần nhe. Mình tổng hợp sơ qua như sau:
Link này giúp tìm hiểu về các tactic trong research / testing.
Vài mindset nên có khi measure
Balance giữa định tính & định lượng, vì định tính cho ta thông tin, raw data nhưng định lượng giúp ta hiểu thêm “tại sao nó lại như thế”. Đằng sau những con số đó, có những câu chuyện, và mình cần “get out of the building” để tìm hiểu chúng.
Outcome > Output. Hãy đo xem người dùng đạt được mục tiêu chưa, có thành công & hài lòng không thay vì những con số sáo rỗng. (ví dụ: mình làm blog khi ban đầu khá vui nếu đạt được 200 lượt view nhưng buồn khi thấy chẳng mấy ai đọc hết bài viết - thời gian scan 1 bài chỉ tầm 30s).
Giá trị của số liệu đến từ sự so sánh, nên nếu ta có 1 cái benchmark thì sẽ tốt hơn. Và metrics có giá trị nhất thì nó giúp ta take được action gì đó, chứ không phải chỉ để báo cáo. Think Diagnostic, not Vanity.
Đo UX thì nên chú ý đo cả 1 hành trình, 1 trải nghiệm tổng thể, measure learnability, ease of use, funnel, measure error, measure happniess / delight…
Vài điểm lưu ý
Nên tinh gọn các metrics cần log, vì có đợt làm việc chung với PO để define các metrics cần log thì mình có gặp phải comment “log nhiều làm tăng tải, chi phí storage, query chậm → ảnh hưởng performance”.
Xem có thể define main metrics nào mà thông qua nó trả lời được nhiều câu hỏi hay không, liệu thứ mình cần log quan trọng đến đâu, có giúp mình take được action gì sau khi biết hay không → Vậy bằng cách nào để ta lựa metrics cho phù hợp?
Why we log this metrics? What we want to know? Actionability test (nếu số này tăng/giảm, mình có hành động gì?)?
Goal-driven (GSM – Goal → Signal → Metrics)
Maybe ta có thể ưu tiên metrics tùy theo vòng đời sản phẩm. Ví dụ: Phase khám phá → log để hiểu hành vi user; Phase tối ưu → log sâu chỗ bottleneck. Phase mature → giảm log noise, giữ lại metrics chiến lược.
Reference
Relevant Items
