Có một ứng dụng đúng tính năng, đúng kỹ thuật, nhưng người dùng đến bước thứ ba là thoát luôn. Chúng tôi gặp tình huống này khá thường xuyên khi tư vấn cho các team startup. Điều đáng nói là nguyên nhân hiếm khi nằm ở đoạn code. Phần lớn nằm ở một cảm giác khó chịu mà người dùng không gọi tên được.
Bài viết này tổng hợp 7 câu hỏi mà dev, PM và founder hỏi chúng tôi nhiều nhất về trải nghiệm người dùng. Mỗi câu đi kèm cách đội ngũ thường trả lời, dựa trên những dự án đã triển khai. Bạn có thể đọc theo thứ tự, hoặc nhảy thẳng đến phần đang vướng trong sản phẩm của mình.
Trải nghiệm người dùng (UX) là gì và vì sao dev không nên bỏ qua?
UX là cảm nhận và mức độ dễ dùng khi người dùng tương tác với sản phẩm. Nói đơn giản, đó là cảm giác khi mở app, tìm được thứ mình cần và rời đi mà không bực bội. Giao diện đẹp chỉ là một phần của nó.
Chúng tôi từng làm việc với một ứng dụng đặt lịch có đầy đủ tính năng. Thế nhưng khoảng 60% người dùng mới bỏ dở ở form đăng ký vì phải điền 12 trường. Tính năng không sai. Người dùng chỉ chưa kịp thấy giá trị thì đã mỏi tay. Với dev và PM, đây là lý do UX cần được nghĩ đến ngay từ đầu, không nên làm qua loa cho xong.
Tiêu chí chọn 7 câu hỏi và cách đọc bài này
Chúng tôi chọn 7 câu hỏi theo ba tiêu chí. Thứ nhất, đó là câu được tìm kiếm nhiều. Thứ hai, câu lặp đi lặp lại trong đội dev. Thứ ba, câu có thể trả lời bằng một quy trình cụ thể. Phạm vi tập trung vào sản phẩm web và mobile phục vụ người dùng Việt Nam.
Cần nói rõ một hạn chế. Hiện chưa có số liệu khảo sát chính thức công khai cho từng câu hỏi. Các ngưỡng trong bài là gợi ý thực hành, nên bạn hãy kiểm chứng lại với sản phẩm của mình trước khi áp dụng.
UX khác gì UI, và có cần tách vai trò riêng không?
UI là lớp hình ảnh bạn nhìn thấy, gồm màu sắc, nút bấm và font chữ. UX là toàn bộ hành trình, từ lúc người dùng nghe về sản phẩm đến lúc họ quyết định quay lại. Một nút bấm rất đẹp nhưng đặt sai chỗ vẫn là UX tệ.
Với team hai đến ba người, bạn chưa cần tuyển UX researcher riêng. Dev hoặc PM kiêm nhiệm phần nghiên cứu cơ bản là đủ để bắt đầu. Khi team lớn lên, việc này nên tách ra. Đội build rất dễ thiên lệch, vì đã quen sản phẩm nên không còn nhìn thấy chỗ khó nữa.
Làm sao biết người dùng đang gặp khó khăn?
Có vài dấu hiệu khá rõ ràng. Tỷ lệ bỏ dở ở form đăng ký tăng bất thường là dấu hiệu đầu tiên. Nhiều ticket hỏi về cùng một thao tác là dấu hiệu thứ hai. Thời gian hoàn thành một tác vụ đơn giản kéo dài bất thường là dấu hiệu thứ ba.
Để tìm ra những chỗ đó, team thường dùng phân tích sự kiện để xem người dùng đi đâu và dừng ở đâu. Ngoài ra, có thể ghi hình phiên dùng và phỏng vấn khoảng năm đến tám người dùng thật. Số liệu cho biết điều gì đang xảy ra, nhưng không giải thích vì sao. Muốn biết lý do, bạn phải nói chuyện trực tiếp với người dùng.
Nên ưu tiên sửa lỗi UX nào trước?
Nguyên tắc đội ngũ hay áp dụng là sửa các lỗi chặn luồng chính trước, ví dụ đăng nhập hay thanh toán. Lỗi nằm ở trang phụ có thể đợi. Một người không đăng nhập được thì dù trang giới thiệu có đẹp đến đâu cũng vô ích.
Khi xếp thứ tự, chúng tôi thường nhìn vào hai yếu tố. Yếu tố đầu là mức ảnh hưởng: lỗi làm mất người dùng ở luồng chính là nặng nhất. Yếu tố thứ hai là tần suất: lỗi xảy ra hàng trăm lần mỗi ngày cần xử lý trước lỗi xảy ra vài lần mỗi tháng. Kết hợp hai yếu tố này sẽ cho bạn một điểm ưu tiên tương đối.
Cách chấm điểm này vẫn mang tính chủ quan. Điều quan trọng là cả team thống nhất một cách chấm, rồi áp dụng nhất quán.
Thiết kế cho điện thoại khác máy tính ở đâu?
Trên điện thoại, vùng chạm phải lớn hơn vì ngón tay không chính xác như chuột. Kết nối mạng cũng kém ổn định hơn, nhất là khi người dùng đi tàu hoặc ở vùng sóng yếu. Rất nhiều người còn thao tác chỉ bằng một tay.
Ở Việt Nam, phần lớn người dùng truy cập qua điện thoại, đặc biệt ở các tỉnh. Đừng chỉ test trên chiếc máy đời mới của dev. Hãy thử trên một máy cấu hình trung bình, mạng chập chờn, để thấy trải nghiệm thật sự ra sao.
Ví dụ thực tế: đơn giản hóa luồng đăng ký
Một khách hàng của chúng tôi có form đăng ký 12 trường, và tỷ lệ bỏ dở rất cao. Nhóm quyết định rút còn bốn trường bắt buộc, phần còn lại chuyển sang bước sau khi người dùng đã dùng thử sản phẩm.
Trước khi thay đổi, họ đo tỷ lệ hoàn thành. Sau đó tiếp tục đo trong ít nhất hai tuần để tránh bị nhiễu bởi biến động ngắn hạn. Kết quả phụ thuộc vào từng sản phẩm, nên bạn không nên lấy con số đó làm chuẩn chung cho mọi app.
Test nội bộ có đủ, hay cần người dùng thật?
Test nội bộ rất dễ bỏ sót vấn đề. Người trong team đã quen với sản phẩm và vô thức né những chỗ khó. Đó là lý do gần như đội nào cũng nên thử với người dùng bên ngoài.
Theo kinh nghiệm chung, khoảng năm người dùng đúng đối tượng là đủ để phát hiện phần lớn vấn đề lớn. Người tham gia phải đúng đối tượng mục tiêu. Đừng mời bạn bè cùng ngành, vì họ sẽ nhìn sản phẩm khác với người dùng thật.
Cân bằng giữa tốc độ ra mắt và chất lượng trải nghiệm
Startup luôn bị kéo giữa hai thứ này. Chúng tôi thường khuyên giữ các luồng cốt lõi thật ổn định, còn tính năng phụ thì chấp nhận nợ kỹ thuật tạm thời. Lỗi hay gặp nhất là đánh đổi quá tay ở khâu onboarding. Người dùng vào rồi không hiểu app làm gì nên bỏ đi, và tỷ lệ giữ chân thấp là hệ quả trực tiếp.
Đo lường thành công UX bằng chỉ số nào?
Có ba chỉ số được dùng nhiều nhất. Chỉ số đầu là tỷ lệ hoàn thành tác vụ. Chỉ số thứ hai là thời gian tới giá trị đầu tiên, tức người dùng mất bao lâu để thấy thứ có ích. Chỉ số thứ ba là tỷ lệ quay lại. Điểm hài lòng tự báo cáo cũng hữu ích, nhưng dễ lệch nếu khảo sát không đúng thời điểm, chẳng hạn ngay sau khi người dùng vừa gặp lỗi.
Quan trọng nhất là định nghĩa chỉ số trước khi triển khai. Đừng chọn chỉ số sau khi đã có kết quả, vì khi đó rất dễ chọn cái đẹp nhất.
Quy trình cải thiện UX cho team dev nhỏ
Đội ngũ chúng tôi thường đi theo một vòng lặp đơn giản. Đầu tiên, chọn một đến hai luồng cốt lõi cần cải thiện, đừng dàn trải. Tiếp theo, thu thập dữ liệu hành vi và phỏng vấn ngắn để hiểu vì sao người dùng gặp khó. Cuối cùng, thử một thay đổi nhỏ, đo lại kết quả, rồi lặp lại.
Nhiều đội nhờ đơn vị tư vấn thiết kế và gia công phần mềm hỗ trợ phần khảo sát và làm prototype, vì không đủ người để làm song song. Bạn có thể tham khảo quy trình tư vấn thiết kế và gia công phần mềm tại đây để hiểu cách phối hợp này. Nếu chưa nắm rõ nền tảng, hãy đọc thêm trải nghiệm người dùng là gì trước khi bắt tay vào. Với các đội đang lên kế hoạch phát triển sản phẩm, bạn cũng nên xem top 7 lưu ý về trải nghiệm người dùng khi phát triển sản phẩm tech.
Câu hỏi thường gặp
UX có quan trọng với sản phẩm B2B không?
Có, và đôi khi còn quan trọng hơn. Người dùng B2B phải dùng sản phẩm mỗi ngày trong công việc. Một thao tác thừa vài bước sẽ nhân lên thành hàng giờ lãng phí mỗi tuần. Họ có thể không chọn sản phẩm vì nó đẹp, nhưng chắc chắn sẽ bỏ nếu thấy mệt.
Startup ngân sách hạn chế nên bắt đầu UX từ đâu?
Hãy bắt đầu từ luồng quan trọng nhất, tức đăng ký và hành động đầu tiên có giá trị. Quan sát năm người dùng làm đúng việc đó đã cho bạn một nguồn thông tin rất giá trị, gần như không tốn chi phí ngoài thời gian của team.
Bao lâu nên làm một vòng nghiên cứu người dùng?
Không có lịch cố định. Chúng tôi thường khuyên làm trước khi thiết kế tính năng lớn, và làm lại mỗi khi có thay đổi lớn ở luồng cốt lõi. Với team nhỏ, một vòng ngắn mỗi quý là nhịp khá hợp lý để bắt đầu.
Có nên tự làm UX hay thuê chuyên gia bên ngoài?
Ở giai đoạn đầu, tự làm là đủ, miễn là bạn giữ kỷ luật quan sát người dùng thật. Khi sản phẩm phức tạp hoặc team chưa có người có kinh nghiệm, thuê chuyên gia làm một vòng nghiên cứu sẽ tiết kiệm nhiều chi phí làm lại về sau.
Sai lầm UX nào dev hay mắc phải nhất?
Lỗi phổ biến nhất là tự cho rằng người dùng sẽ hiểu sản phẩm như mình. Dev biết rõ hệ thống nên thường bỏ qua những chỗ người mới bị vướng. Cách tốt nhất để tránh là đưa sản phẩm cho người ngoài dùng sớm. Khi họ loay hoay, hãy quan sát thay vì giải thích, vì chính khoảnh khắc đó mới là chỗ học được điều thật.