UX Cracking: Vén màn bí ẩn đằng sau các Metrics

Tris’s Moving Box
One Mount Product Design
12 min readNov 2, 2023

Khái niệm data-driven decision-making có lẽ đã không còn xa lạ với các product designer nữa khi mà hiện nay, định hướng phát triển và đánh giá hiệu quả sản phẩm đều được xác định dựa trên dữ liệu thu thập được từ lịch sử.

Việc các công ty chú trọng vào việc theo dõi các metrics (chỉ số đo đường) từ cấp độ doanh nghiệp cho đến sản phẩm được coi như là một bước đột phá trong việc thấu hiểu khách hàng mục tiêu của mình dựa trên số liệu thực thay vì như trước đây chỉ là dựa trên “cảm giác”. Thế nhưng, nếu chỉ dựa trên các metrics, liệu chúng ta có thực sự hiểu được chuyện gì đang xảy ra?

Dưới góc độ chuyên môn, các metrics hay chỉ số đo lường thuộc loại dữ liệu định lượng (quantitative data). Nhưng trong nghiên cứu, bên cạnh dữ liệu định lượng chúng ta còn dữ liệu định tính (qualitative data). Việc phối hợp sử dụng các phương pháp nghiên cứu khác nhau (mixed-methods) để thu thập 2 loại dữ liệu được coi như là một phương án tối ưu giúp researchers có được bức tranh thông tin toàn cảnh khi:

  • Quantitative data: cho phép ta biết được cái gì đang xảy ra và mức độ ảnh hưởng như thế nào?!
  • Qualitative data: cho phép ta biết tại sao vẫn đề xảy ra, xảy ra như thế nào và cách người dùng thực tế sử dụng nó

Chà! Hiểu trên lý thuyết là như vậy, nhưng thực tế cần phải làm gì?

Trong khuôn khổ bài viết ngày hôm nay, mình muốn chia sẻ với anh em chiến hữu ngoài One Mount một case study thực tế của team OMRE Product Design trong việc sử dụng kết hợp các phương pháp nghiên cứu và phân tích dữ liệu nhằm đưa ra định hướng phát triển cho sản phẩm OneHousing.

Dành cho những bạn đọc chưa biết, OneHousing là một nền tảng được xây dựng với mục đích giải quyết toàn bộ nhu cầu của khách hàng về bất động sản, được phát triển bởi đội ngũ tại One Mount Real Estate — công ty thuộc tập đoàn One Mount Group.

Chapter 1: Bay trên tổ chim cúc cu…

Flexing văn hoá một chút, tại One Mount, mỗi tháng team Product Design sẽ cùng nhau chung tay review và đánh giá lại performance của sản phẩm. Giữ vững văn hoá mỗi tháng 1 chiếc UX Report, mỗi lần đến kỳ đánh giá, team lại 7 nổi 3 chìm, lăn lộn với việc phân tích data để hiểu được hành vi và nhu cầu của người dùng trên chính sản phẩm của mình.

Nhờ những buổi lăn lộn như thế, trong một buổi chiều đẹp trời, team đã tìm thấy những dấu hiệu lạ trên heatmap của một trang cực kỳ quan trọng. Team gọi trang đó là trang Chi tiết bất động sản.

Trang Chi tiết bất động sản là trang cung cấp đầy đủ các thông tin về các đặc điểm của một bất động sản cụ thể (diện tích, hướng, số phòng ngủ, số phòng vệ sinh,…) cho người dùng.

Ở trong hành trình mua bất động sản của khách hàng, việc tìm hiểu thông tin chi tiết về bất động sản là một bước bắt buộc cần thực hiện. Vậy nên, trang Chi tiết bất động sản có thể coi là một trong những trang quan trọng nhất của sản phẩm khi nó không chỉ phục vụ người dùng tại mọi bước trong hành trình mà con là nơi người dùng truy cập vào xem nhiều nhất.

Và câu chuyện cũng bắt đầu từ đây…

Khi nhìn sơ qua dashboard (bảng chỉ số) của trang từ T3/2023 — T6/2023, team nhận thấy các chỉ số của trang tưởng như rất ổn 🌚, mà hoá ra lại bất ổn không tưởng.

Demo lát cắt dashboard heatmap trang Chi tiết bất động sản được build trên PowerBI của team

Từ dashboard, team nhận thấy:

  • Tổng lượt views (traffic) và tổng số users view trang luôn đứng top đầu
  • % số users tương tác vào các khu vực trên trang đạt cấp bậc đúng như kỳ vọng

Tuy nhiên, có 1 chỉ số hiện lên cực kỳ thấp và khiến team phải vắt tay lên chán kêu trời, đó là vertical scroll depth tại mốc 100%.

Vertical scroll depth là một chỉ số đo lường hành vi cuộn trang của người dùng trên website theo chiều dọc tại các mốc 30%, 50%, 70%, 100% — được team mình đặt tracking trên các page của website OneHousing.

Câu hỏi được đặt ra là:

  1. Nếu người dùng scroll hết 100% trang thì có giúp cải thiện success criteria của trang không? (trong bức tranh tổng thể của sản phẩm, team nhận định mục đích của trang này là nơi cung cấp đầy đủ thông tin về bất động sản cho khách hàng, từ đó giúp khách hàng có cơ sở để quyết định nhận tư vấn mua bất động sản cùng OneHousing)
  2. Vì sao đa phần người dùng chỉ scroll đến 30% trang là rời bỏ trang?
  3. Người dùng thực sự đang tìm kiếm điều gì trên trang này?

Ba câu hỏi chính và hàng ngàn câu hỏi phụ được các thành viên đặt ra. Nhưng đoán xem, team không tìm được lời giải 🙂

Số liệu bất ổn thì đã rõ ràng trước mắt, nhưng team hoàn toàn thiếu thông tin để làm cơ sở quyết định cải tiến thiết kế.

Rõ ràng là team chưa thực sự thấu hiểu với người dùng rồi ☠️

Oh no, phải làm thế nào bây giờ?

Chapter 2: Ánh sáng vô hình…

Nhận ra được lỗ hổng trong việc thấu hiểu người dùng của mình, team quyết định cùng nhau ngồi lại và bàn bạc về phương án giải quyết phù hợp. Phương án thực tế mà team quyết định triển khai là thành lập một nghiên cứu tích hợp giữa Usability Testing, In-depth Interview và Card Sorting.

Lý do team lựa chọn sử dụng các phương pháp nghiên cứu này và tích hợp vào cùng một phiên nghiên cứu vì:

  • Chất lượng: Nhờ tận dụng được cả 2 hoạt động hỏiquan sát người dùng — những hoạt động nền tảng của nghiên cứu sơ cấp nên kết quả nghiên cứu thu được sẽ toàn diện hơn.
  • Tiết kiệm: Với cùng kết quả nghiên cứu, việc tích hợp các phương pháp nghiên cứu vào cùng 1 phiên nghiên cứu có thể khiến cho thời gian của một phiên kéo dài hơn, nhưng tổng thể việc triển khai dự án lại ngắn hơn do không phải tổ chức nghiên cứu rời rạc với từng phương pháp.

Dựa trên những lợi ích đó, cùng với sự đồng thuận của cả team về phương án triển khai, team bắt đầu với nhiệm vụ đầu tiên…

2.1. Xác định mục tiêu nghiên cứu

Mục tiêu nghiên cứu được coi như là trái tim của dự án nghiên cứu vì sự ảnh hưởng của nó đến kết quả cuối cùng là vô cùng lớn. Để so sánh thì nó giống như là đích đến của chặng đường vậy. Nếu chọn đúng đích đến, dù đi đường thẳng hay đường vòng bạn vẫn biết nơi cuối con đường của bạn là nơi nào. Còn nếu bạn chọn sai, à thì…có thể bạn vẫn đến đích, chỉ là đích đến không như bạn tưởng thôi 🤡

Và để hỗ trợ phòng ngừa các sự sai lệch đó, team mình đã thiết lập một cấu trúc mục tiêu nghiên cứu — đóng vai trò như Google Maps giúp các thành viên xác định định đích đến cho chuẩn.

Cấu trúc đó là:

Để hiểu rõ hơn, mình xin được lấy ví dụ về một mục tiêu được viết theo cấu trúc bên trên như sau:

Ví dụ: Mục tiêu nghiên cứu team là “Đánh giá khả năng sử dụng của người dùng khi xem chi tiết bất động sản trên trang Chi tiết bất động sản của website OneHousing”

Phân tích theo cấu trúc, ta có:

  • Mục đích: Đánh giá
  • Chủ đề: Khả năng sử dụng
  • Chủ thể: Người dùng của OneHousing
  • Trạng thái: khi xem chi tiết bất động sản trên trang Chi tiết bất động sản của website OneHousing

Dựa theo cấu trúc đó, team xác định các mục tiêu chính và lập được thành bảng như dưới đây 👇

Wèo wéo weo, đến đoạn này có thể nhiều bạn sẽ thắc mắc, vì sao team lại viết mục tiêu nghiên cứu (research objectives) thay vì câu hỏi nghiên cứu (research questions) đúng không? 🤫

Thực ra, mục tiêu nghiên cứu và câu hỏi nghiên cứu bản chất đều như nhau. Về cơ bản, nhà nghiên cứu vẫn cần hình dung kết quả sau nghiên cứu sẽ thu được gì, trả lời cho câu hỏi gì. Tuy nhiên, cách lựa chọn thể hiện như thế nào được quyết định bởi đối tượng tiếp nhận thông tin đó. Và team mình lựa chọn cách viết theo mục tiêu nghiên cứu nhằm giúp stakeholders dễ dàng hình dung kết quả cuối cùng là gì hơn.

Xác định rõ ràng được các mục tiêu rồi, bước tiếp theo team thực hiện là…

2.2. Xác định đối tượng nghiên cứu và số lượng mẫu

Dựa trên Persona đã có của các target segments, team phân loại và xác định các tiêu chí cần thiết đối với từng user type.

Để dễ dàng cho việc lựa chọn và không bị bỏ sót các tiêu chí, team đã tạo một bảng phân loại để đánh dấu những điều kiện bắt buộc

Ví dụ về bảng phân loại

Như các bạn thấy, team lựa chọn các tiêu chí theo target segment gồm:

  • Thị trường: Sơ cấp
  • Nhu cầu về bất động sản: Mua
  • Mục đích mua: Mua để ở/Mua để đầu tư
  • Loại bất động sản: Cao tầng/Thấp tầng/Thổ cư

Nếu dựa trên bảng, ta sẽ thấy có đến 15 tập đối tượng cần phải khai thác. Nghe cái đã muốn khó thở luôn rồi đúng không? Đây là lý do mà ta luôn cần phải làm rõ thứ tự ưu tiên với các stakeholders. Như trong dự án này, team thống nhất chỉ tập trung vào 2 nhóm đối tượng mà thôi. Và dựa trên những tiêu chí nền tảng đó, team có thể thêm vào một vài ràng buộc để thu hẹp nhóm đối tượng lại.

Ví dụ:

  • Kinh nghiệm: Đã từng/Chưa từng mua BĐS
  • Nhân khẩu học: Độ tuổi, giới tính,… theo dữ liệu khách hàng của dịch vụ đó (yêu cầu PO cung cấp hoặc phân tích dữ liệu từ BI).
  • Yêu cầu bổ sung: Khu vực BĐS đang quan tâm, có kinh nghiệm sử dụng các website cung cấp thông tin về bất động sản,…

Sau khi lựa chọn và phân loại được các tập đối tượng rồi, team sẽ tiến hành tính toán để đưa ra số lượng mẫu cần thiết để mời tham gia nghiên cứu.

Cách thức tính toán số lượng mẫu cần thiết, mọi người có thể tham khảo bài viết này:

2.3. Triển khai nghiên cứu

Sau khi thống nhất với stakeholders về mục tiêu nghiên cứu và kế hoạch triển khai cụ thể. Đến giai đoạn này, công việc của team là tập trung vào thực hiện nghiên cứu mà thôi.

Tổng thời gian thực hiện nghiên cứu được team đặt ra là hoàn thành trong 5 ngày làm việc (không kể T7 và Chủ nhật). Trong đó:

  • 1 ngày sync-up với stakeholders và chuẩn bị kế hoạch chi tiết
  • 1 ngày tìm kiếm và mời các ứng viên phù hợp với tiêu chí đặt ra ban đầu tham gia nghiên cứu
  • 2 ngày thực hiện kiểm thử và phỏng vấn
  • 2 ngày phân tích + tổng hợp kết quả nghiên cứu và báo cáo kết quả với stakeholders

Sau quá trình vắt giò lên để thực hiện nghiên cứu cực nhanh cực trầm cảm. Kết quả team thu được thực sự là xoáy sâu vào những niềm đau…

2.4. Tổng hợp, phân tích và báo cáo kết quả

Sau khi phân tích, gom nhóm và thống kê lại các vấn đề, team ghi nhận:

  • 12 vấn đề về usability
  • 12 insights & suggesstions mới

Sương sương cũng 24 nhát đâm vào trái tim vốn vẫn chưa bao giờ ngừng rỉ máu của đội ngũ OMRE product designers 🥲

Với các findings thu được sau nghiên cứu, team tiếp tục tiến hành thực hiện xếp hạng mức độ nghiêm trọng của các vấn đề. Định nghĩa các mức độ nghiêm trọng như bảng dưới đây:

Bảng định nghĩa xếp hạng mức độ nghiêm trọng

Sau khi xếp hạng được mức độ nghiêm trọng rồi, team sẽ tiếp tục phân loại thêm một vòng nữa các vấn đề theo các big theme. Mục đích là giúp cho Product Designer để dễ dàng chỉnh sửa các vấn đề theo nhóm, từ đó giúp tối ưu hiệu suất khi chỉnh sửa và cập nhật.

Bảng phân loại lỗi theo các big themes

Gốc rễ vấn đề giải đáp cho các con số thì đã có rồi, vậy thì câu chuyện này cần đi tới…

Chapter 3: Ngàn mặt trời rực rỡ…🌞💃🕺

Đúng là không qua cơn bĩ cực thì sao biết được hồi thái lai 😌. Đau đớn thì cũng không thể cứ ngồi đấy chịu đau mãi được.

Từ kết quả nghiên cứu, team nhanh chóng hội họp bắt tay vào giải quyết toàn bộ vấn đề trong vòng 2 sprints phát triển (mỗi sprint của team có 11 ngày ~ 2 tuần).

  • Các vấn đề nghiêm trọng và khả năng công nghệ có thể đáp ứng được → ưu tiên sửa gấp luôn trong sprint đầu (dành 80% nguồn lực)
  • Các vấn đề ít nghiêm trọng, khả năng công nghệ đáp ứng được và không quá tốn effort để sửa → phân bổ đều vào 2 sprint (dành 10% nguồn lực)
  • Các đề xuất phát triển mới được đưa ra từ ý kiến của người dùng hoặc những vấn đề nền tảng công nghệ chưa thể đáp ứng ngay → đưa vào backlogs để phát triển về sau.

Và cuối cùng, sau hơn 2 tháng theo dõi kể từ thời điểm go-live cuối T7/2023, kết quả nhận được thật sự khiến con tim của toàn bộ đội ngũ phát triển như được chữa lành.

Từ dữ liệu thu thập được từ 01/08/2023–30/09/2023, team ghi nhận tỷ lệ người dùng vào trang và scroll xem hết 100% nội dung trên trang đã tăng 6% so với giao diện cũ.

Tuyệt vời làm sao, các số liệu đã cải thiện rồi 🎉

Việc thật số thật. Được nhìn thấy những sự thay đổi tích cực và giá trị mình tạo ra đối với người dùng của sản phẩm, còn gì vui hơn nữa đúng không anh em đì zai nơ? 🤩

Lời kết.

Chặng đường phát triển sản phẩm của team mình tất nhiên còn rất dài và chưa kết thúc ở đây. Con đường xây dựng và cải tiến sản phẩm cũng chưa bao giờ có điểm đến gọi là hoàn hảo 🥲

Tuy nhiên, thông qua bài viết này, mình hy vọng mọi người đã có thêm những thông tin bổ ích mới và có những góc nhìn mới về việc công việc ứng dụng data-driven decision-making vào việc làm sản phẩm.

Data trong UX không chỉ là những con số, nó còn là những tiếng nói, những suy nghĩ, những mong muốn của người dùng sản phẩm. Mỗi dữ liệu đều là những mảnh ghép, và việc của chúng ta là hãy ghép nó lại để nhìn được bức tranh tổng thể.

Chung quy làm product designer cũng nhàn ý mà…

Lời cuối, xin được cảm ơn bạn đọc vì đã đi cùng mình đến hết bài viết này. Mọi lời phản hồi và đóng góp từ bạn sẽ là tư liệu để mình thêm hoàn thiện bản thân bản thân nói chung và các bài viết nói riêng, nên đừng ngần ngại để lại bình luận tại đây hoặc gõ đầu mình tại qua messages trên linkedin nhé 🫢

P/s: Đừng quên để lại 1 claps để ủng hộ mình và bấm follow để nghe mình tám trong những bài viết tiếp theo nhe 😉

--

--