Bạn đã bao giờ tải một ứng dụng về, mở lên một lần rồi xóa luôn chưa? Đội ngũ Pumacode gặp chuyện này khá thường xuyên. Phần lớn những lần như vậy không phải vì app thiếu tính năng. Nguyên nhân thường nằm ở cảm giác khi dùng: chậm, rối, hoặc người dùng không hiểu chuyện gì đang xảy ra. Vì vậy, top 7 lưu ý về trải nghiệm người dùng dưới đây đáng để bạn xem qua trước khi bắt tay vào làm sản phẩm.
Chúng tôi chọn ra bảy điểm mà các team hay bỏ qua nhất. Đây là những điều thường xuất hiện khi bạn phát triển cho doanh nghiệp nhỏ và vừa, nơi nguồn lực có hạn và mỗi người dùng đều đáng giá.
Vì sao một sản phẩm tech tốt vẫn bị người dùng bỏ đi?
Trải nghiệm người dùng, nói nôm na, là cảm giác của người ta khi chạm vào sản phẩm của bạn. Cảm giác đó quyết định họ ở lại hay rời đi. Bạn có thể đã làm ra rất nhiều tính năng hay ho, nhưng nếu lần đầu mở ra họ thấy bối rối, họ sẽ không bao giờ đi tới phần đó.
Một tình huống chúng tôi gặp khá nhiều: người dùng tải app, mở ra, thấy màn hình đăng ký dài dằng dặc rồi thoát ngay. Đội phát triển thì tự hào vì đã làm được gần 30 tính năng. Nhưng người dùng chưa kịp nhìn thấy tính năng nào trong số đó.
Bảy lưu ý dưới đây được chọn theo ba tiêu chí: ảnh hưởng trực tiếp đến việc giữ chân người dùng, dễ áp dụng với team nhỏ, và có thể kiểm chứng lại bằng cách đo đạc sau khi thay đổi.
Tốc độ phản hồi và cảm giác mượt mà quan trọng thế nào?
Người dùng không đo mili-giây. Họ chỉ cảm nhận được khi thao tác chậm hơn điều họ mong đợi. Với một nút bấm, khoảng trễ vài trăm mili-giây đã đủ khiến người ta khựng lại và tự hỏi app có bị treo không.
Chúng tôi thường khuyên đừng chỉ tối ưu tốc độ máy chủ. Hãy nhìn vào cảm giác thật: nút có phản hồi ngay khi bấm không, khi chờ có spinner hay skeleton không, danh sách có cuộn mượt không. Một mẹo đơn giản là hiển thị trạng thái đang xử lý ngay lập tức, dù phần việc phía sau còn mất thêm thời gian. Người dùng sẵn sàng chờ khi họ biết hệ thống đã nhận yêu cầu.
Lưu ý này đặc biệt phù hợp với web và mobile có nhiều thao tác lặp lại, như app nhập liệu hay quản lý đơn hàng. Chúng tôi cũng chưa thấy con số chuẩn nào áp dụng cho mọi ngành. Bạn nên tự đo bằng công cụ phân tích trên chính sản phẩm của mình thay vì tin vào một ngưỡng chung.
Onboarding ngắn gọn để người dùng nhanh chạm tới giá trị
Onboarding là chuỗi màn hình hướng dẫn người mới làm quen sản phẩm. Có thể hiểu đơn giản, đây là buổi gặp gỡ đầu tiên giữa người dùng và app của bạn. Nếu buổi đầu dài dòng, rất dễ mất khách.
Theo kinh nghiệm của đội ngũ, một onboarding tốt thường làm ba việc. Thứ nhất, chỉ hỏi những thông tin thật sự cần để người dùng đạt giá trị đầu tiên. Thứ hai, đưa họ đến việc có ích ngay, thay vì bắt đọc hết hướng dẫn. Thứ ba, cho phép bỏ qua các bước không bắt buộc và quay lại sau.
Chúng tôi từng làm việc với một đội phát triển app quản lý cho cửa hàng nhỏ. Ban đầu họ yêu cầu người dùng điền 12 trường thông tin trước khi thấy bất kỳ màn hình nào. Sau khi rút xuống còn 3 trường cần thiết và chuyển phần còn lại vào mục cài đặt, người dùng đi qua bước đầu nhanh hơn rõ rệt. Con số cụ thể bạn cần tự đo trong dự án của mình.
Cách làm này hợp với SaaS, app quản lý và công cụ cho doanh nghiệp nhỏ. Tuy nhiên, onboarding quá ngắn cũng có thể bỏ sót thông tin quan trọng, nên bạn cần cân bằng giữa gọn và đủ.
Thiết kế cho điện thoại yếu và mạng không ổn định
Đội phát triển thường test trên máy mới và wifi ổn định. Nhưng người dùng thực tế có thể đang dùng điện thoại đã vài năm tuổi, với đường truyền chập chờn ở khu vực xa trung tâm. Khoảng cách giữa hai môi trường này là nguyên nhân của rất nhiều lỗi mà đội phát triển không thấy được.
Chúng tôi khuyên nên thử bằng cách giới hạn băng thông và dùng máy cấu hình thấp trong quá trình kiểm thử. Quan trọng hơn, hãy để app vẫn hiển thị được thông tin đã tải khi mạng rớt, thay vì bật ra một màn hình trắng khiến người dùng hoang mang.
Hạn chế là chi phí kiểm thử trên nhiều thiết bị khá cao với team nhỏ. Bạn có thể bắt đầu từ hai đến ba thiết bị phổ biến nhất trong tệp người dùng của mình, rồi mở rộng dần theo thời gian.
Thông báo lỗi nên nói gì để người dùng biết phải làm gì tiếp?
Thông báo kiểu “Lỗi 500” hay “Có lỗi xảy ra” khiến người dùng bối rối và dễ bỏ đi. Họ không biết lỗi do đâu, và cũng không biết nên làm gì tiếp theo. Với họ, đó là một ngõ cụt.
Một thông báo tốt thường nói rõ ba điều: chuyện gì đã xảy ra, vì sao (nếu biết), và việc tiếp theo nên làm. Chẳng hạn: “Số điện thoại này đã được đăng ký. Bạn thử đăng nhập bằng số này, hoặc dùng email khác.” Chỉ một câu ngắn như vậy đã giúp người dùng tiếp tục thay vì thoát ra.
Lưu ý này gần như áp dụng cho mọi sản phẩm có form, thanh toán hoặc đăng nhập. Viết được thông báo tốt cần dev và người viết nội dung cùng tham gia, đừng để dev tự xử lý toàn bộ.
Truy cập cho người khuyết tật: đừng bỏ quên
Một sản phẩm dùng được bằng bàn phím, đủ tương phản màu và chữ đủ lớn sẽ thân thiện với nhiều người hơn. Không chỉ người khuyết tật được hưởng lợi, mà cả người lớn tuổi đọc chữ nhỏ cũng thấy dễ chịu hơn.
Chúng tôi thường thấy các team tick đủ checklist nhưng vẫn gặp vấn đề khi người dùng sử dụng công cụ đọc màn hình. Vì vậy, nên kiểm thử thực tế với một công cụ đọc màn hình thay vì chỉ đánh dấu cho xong việc.
Lưu ý này phù hợp với sản phẩm công và những sản phẩm muốn mở rộng tệp người dùng. Việc kiểm thử tốn thời gian, và team mới thường cần vài vòng mới quen quy trình.
Thu thập phản hồi người dùng theo cách có hệ thống
Phản hồi người dùng không tự biến thành cải tiến. Nếu không có kênh rõ ràng và người chịu trách nhiệm đọc, phản hồi sẽ nằm im trong hộp thư và không ai nhớ đến nữa.
- Đặt nút góp ý ngay trong sản phẩm để người dùng gửi ý kiến khi đang thao tác.
- Gắn nhãn phân loại như lỗi, đề xuất hay lời khen để dễ lọc.
- Dành một buổi cố định mỗi tuần để đọc và chọn việc cần làm.
Chỉ cần giữ thói quen đều đặn như vậy cũng đã tạo khác biệt lớn. Cách làm này phù hợp với team đang chạy thử và cần lặp lại nhanh. Phản hồi nhiều có thể gây quá tải nếu không phân loại ngay từ đầu, nên đừng cố đọc hết một lúc mà hãy đọc theo nhóm.
Đo lường trải nghiệm bằng dữ liệu thật của người dùng
Cảm tính của đội phát triển thường lệch so với thực tế. Dữ liệu cho biết người dùng bỏ đi ở bước nào và tỷ lệ hoàn thành một thao tác là bao nhiêu, nhờ đó bạn không phải đoán mò.
Hãy theo dõi vài chỉ số cơ bản như tỷ lệ hoàn thành đăng ký, và tỷ lệ bỏ giữa chừng ở từng bước thanh toán hay điền form. Khi thấy một bước rớt mạnh, đó là chỗ nên xem lại đầu tiên. Bạn cũng có thể tìm hiểu thêm về nền tảng của việc tối ưu trải nghiệm qua bài trải nghiệm người dùng là gì và lợi ích của việc tối ưu UX cho mobile app.
Lưu ý này phù hợp khi sản phẩm đã có đủ người dùng để phân tích. Với sản phẩm mới, dữ liệu còn ít, nên kết hợp phỏng vấn trực tiếp vài người dùng để hiểu lý do đứng sau con số.
Ví dụ triển khai cho một team dev nhỏ
Hãy hình dung một team năm người đang làm app đặt lịch cho tiệm spa. Họ thấy nhiều khách vào đến bước thanh toán rồi bỏ đi. Đội ngũ chúng tôi thường gợi ý bắt đầu từ các lưu ý số 2, 4 và 7: rút gọn bước đặt lịch, viết lại thông báo khi thanh toán lỗi, và theo dõi tỷ lệ rớt từng bước trong hai tuần.
Sau hai tuần, team có thể thấy rõ bước nào thật sự gây rớt. Kết quả cụ thể cần đo lại trong dự án của chính bạn, vì đây không phải số liệu chuẩn cho mọi app đặt lịch.
Câu hỏi thường gặp
Nên bắt đầu từ lưu ý nào nếu team chỉ có một hai người phát triển?
Chúng tôi thường khuyên bắt đầu từ thông báo lỗi và onboarding. Cả hai đều ít tốn công nhưng tác động trực tiếp đến việc người dùng có ở lại hay không. Sau đó mới đến tốc độ phản hồi. Khi đã quen với nhịp làm việc này, bạn mới cần tính đến đo lường và thu thập phản hồi có hệ thống.
Làm sao biết trải nghiệm đang tệ khi không có ngân sách nghiên cứu người dùng?
Bạn không cần ngân sách lớn. Chỉ cần mời vài người quen thuộc với nhóm khách hàng của mình, cho họ dùng thử sản phẩm và nói to suy nghĩ trong lúc thao tác. Thường vài người là đủ để thấy các vấn đề lặp lại. Nếu có điều gì làm nhiều người cùng vướng, đó gần như chắc chắn là điểm cần sửa.
Có cần công cụ phân tích trả phí để theo dõi các chỉ số này không?
Không bắt buộc. Nhiều công cụ phân tích miễn phí đã đủ để đo tỷ lệ hoàn thành từng bước. Khi sản phẩm lớn hơn và nhu cầu phức tạp hơn, bạn mới nên cân nhắc gói trả phí.
Trải nghiệm người dùng có ảnh hưởng đến SEO không?
Có. Tốc độ tải trang, bố cục dễ đọc trên điện thoại và việc người dùng có ở lại lâu hay không đều liên quan đến cách công cụ tìm kiếm đánh giá website. Mức độ ảnh hưởng cụ thể phụ thuộc vào từng website, nên bạn cần tự kiểm tra bằng dữ liệu của mình. Nếu muốn tìm hiểu sâu hơn, bạn có thể tham khảo thêm bài tốc độ tải website ảnh hưởng thế nào đến SEO.
Tóm lại, trải nghiệm người dùng không phải phần trang trí thêm sau khi làm xong tính năng, mà là yếu tố quyết định sản phẩm có được dùng hay không. Bắt đầu từ vài việc nhỏ, đo lường đều đặn và lắng nghe người dùng thật, bạn sẽ thấy sản phẩm dần tốt lên theo thời gian.