Tất cả đều hoạt động, nhưng người dùng vẫn bối rối: Đội nhóm SaaS đang thiếu điều gì?

Người dùng không thực sự quan tâm đến tài liệu, lộ trình phát triển hay nhật ký thay đổi của bạn.

Họ quan tâm đến một điều duy nhất:

Tôi có thể tự mình tìm ra cách sử dụng này mà không gặp rắc rối gì không?

Mọi thứ khác, bao gồm việc tài liệu được viết hay đến đâu hay lộ trình trông chuyên nghiệp thế nào, đều chỉ là thứ yếu nếu trải nghiệm tổng thể cảm thấy rời rạc.

Chúng tôi đã sai ở đâu?

Ban đầu, chúng tôi thực sự tin rằng mình đang làm tốt công việc vì đã bao gồm đầy đủ các thành phần cần thiết.

Chúng tôi có tài liệu chi tiết, tài liệu tham khảo API rõ ràng, lộ trình công khai, kênh để người dùng gửi phản hồi và thậm chí còn duy trì các ghi chú phát triển (release notes) đều đặn.

Từ góc độ nội bộ, nó cảm thấy hoàn chỉnh và có cấu trúc tốt.

Nhưng từ góc nhìn bên ngoài, nó lại rất gây rối.

Sự ngắt kết nối mà chúng tôi không nhìn thấy

Sai lầm ở đây rất tinh vi. Chúng tôi đã tổ chức mọi thứ dựa trên cách chúng tôi suy nghĩ với tư cách là người xây dựng, chứ không phải cách người dùng suy nghĩ khi đang cố gắng giải quyết một vấn đề.

Dưới đây là cách chúng tôi cấu trúc các yếu tố:

Bề mặt	Mục đích (từ góc nhìn của chúng tôi)
Tài liệu (Docs)	Tìm hiểu cách mọi thứ hoạt động
Lộ trình (Roadmap)	Xem những gì đang được lên kế hoạch
Nhật ký thay đổi (Changelog)	Theo dõi những gì đã thay đổi
Phản hồi (Feedback)	Yêu cầu tính năng mới

Nó trông có vẻ logic. Nhưng người dùng không suy nghĩ theo các danh mục như vậy.

Họ suy nghĩ theo từng khoảnh khắc, thường là khi đang cố gắng hoàn thành một công việc cụ thể.

Người dùng thực sự suy nghĩ như thế nào?

Một người dùng không thức dậy với suy nghĩ: "Hãy xem lộ trình hôm nay thế nào." Thay vào đó, hành trình của họ trông giống như thế này:

• "Làm sao tôi thực hiện việc này?"
• "Việc này có khả thi không?"
• "Nếu không, liệu nó có đang được lên kế hoạch không?"
• "Họ đã tung ra tính năng này chưa?"

Những câu hỏi này có liên quan mật thiết với nhau và chúng xảy ra liên tiếp, không phải tách rời.

Trải nghiệm bị đứt gãy ở đâu?

Hãy tưởng tượng một nhà phát triển truy cập vào tài liệu của bạn khi đang cố giải quyết một vấn đề cụ thể. Họ bắt đầu đọc và sau đó vướng phải một giới hạn.

Lúc này, một câu hỏi mới xuất hiện: "Đây là giới hạn vĩnh viễn, hay là thứ đang được xử lý?" Tại thời điểm đó, luồng công việc bị đứt quãng.

Họ phải rời khỏi tài liệu, mở lộ trình, cố tìm kiếm thông tin liên quan, có thể kiểm tra nhật ký thay đổi, và nếu vẫn không tìm thấy câu trả lời, họ mới gửi phản hồi.

Dưới đây là hành trình thực tế của họ:

Bước	Hành động	Rủi ro
1	Đọc tài liệu	Ngữ cảnh rõ ràng
2	Chuyển sang lộ trình	Ngữ cảnh bắt đầu đứt gãy
3	Kiểm tra nhật ký thay đổi	Cần nhiều nỗ lực hơn
4	Gửi phản hồi	Xác suất rời bỏ cao

Tại mọi bước, đều có sự ma sát. Không phải vì sản phẩm của bạn tệ, mà vì trải nghiệm bị phân mảnh trên nhiều nơi khác nhau.

Tại sao việc cải thiện tài liệu không giải quyết được vấn đề

Đây là điều khiến chúng tôi ngạc nhiên. Chúng tôi liên tục cải thiện tài liệu, làm cho nó rõ ràng hơn, cấu trúc tốt hơn và thêm nhiều ví dụ.

Nhưng trải nghiệm tổng thể không cải thiện nhiều. Bởi vì khoảng trống thực sự không nằm trong tài liệu.

Nó nằm giữa tài liệu, lộ trình, phản hồi và các bản cập nhật.

Sự thay đổi đã thay đổi tư duy của chúng tôi

Thay vì hỏi: "Làm sao để cải thiện tài liệu của chúng tôi?"

Chúng tôi bắt đầu hỏi: "Người dùng di chuyển như thế nào trong kiến thức về sản phẩm của chúng tôi khi họ đang cố gắng giải quyết một vấn đề?"

Sự thay đổi duy nhất đó đã thay đổi cách tiếp cận của chúng tôi đối với mọi thứ.

Điều chúng tôi đã thử thay vào đó

Chúng tôi bắt đầu đưa mọi thứ lại gần nhau hơn, không phải là các công cụ riêng biệt, mà là một luồng kết nối.

• Tài liệu được kết nối với các quyết định sản phẩm thực tế.
• Lộ trình hiển thị trong ngữ cảnh cụ thể, không bị cô lập.
• Phản hồi được liên kết với các trường hợp sử dụng thực tế.
• Các bản cập nhật được gắn trở lại với những gì người dùng đã yêu cầu.

Mục tiêu không phải là tạo ra nhiều nội dung hơn, mà là giảm khoảng cách giữa các nội dung đó.

Cách tiếp cận này là thứ cuối cùng đã dẫn chúng tôi đến việc xây dựng CandyDocs.

Điều thực sự được cải thiện

Sự cải thiện lớn nhất không phải là hiệu suất nội bộ hay tốc độ.

Nó rất đơn giản: người dùng cảm thấy bớt bối rối hơn.

Trước đây	Sau đây
Người dùng phải tự tìm ra nơi cần đến	Người dùng có thể khám phá trong một luồng duy nhất
Thường xuyên gặp ngõ cụt	Điều hướng trơn tru hơn
Không rõ cái gì đã có và cái gì sắp tới	Khả năng hiển thị và rõ ràng tốt hơn
Các bản cập nhật thường bị bỏ sót	Các bản cập nhật được phát hiện một cách tự nhiên

Không có gì mang tính kịch tính, nhưng lại tốt hơn một cách nhất quán.

Một sự nhận thức nhỏ nhưng quan trọng

Trước đây, chúng tôi nghĩ công việc của mình là xuất bản thông tin.

Bây giờ, chúng tôi nhìn nhận nó khác đi.

Công việc của chúng tôi là giúp người dùng đưa ra quyết định và tiến lên phía trước mà không gặp ma sát.

Đó là một vấn đề hoàn toàn khác để giải quyết.

Điều mà hầu hết các đội nhóm đánh giá thấp

Rất dễ để nghĩ rằng đây là các lớp riêng biệt:

• Tài liệu để học hỏi.
• Lộ trình để minh bạch.
• Nhật ký thay đổi để cập nhật.

Nhưng đối với người dùng, tất cả những điều này chỉ là một thứ duy nhất:

Hiểu về sản phẩm của bạn.

Nếu việc hiểu điều đó yêu cầu phải nhảy qua nhiều công cụ và ngữ cảnh khác nhau, bạn đang thêm vào những rào cản vô hình sẽ tích tụ theo thời gian.

Một điều tôi vẫn đang tìm hiểu

Tôi không nghĩ rằng việc có mọi thứ trong một nơi luôn là câu trả lời hoàn hảo.

Các công cụ riêng biệt rất mạnh mẽ và linh hoạt.

Nhưng chúng đi kèm với một giả định rằng bạn sẽ tự kết nối trải nghiệm. Hầu hết các đội nhóm không làm điều đó hoàn toàn. Chúng tôi cũng vậy.

Tò mò xem người khác đang xử lý việc này như thế nào

Đối với những người đang xây dựng sản phẩm SaaS:

• Tài liệu, lộ trình và phản hồi của bạn có cảm thấy được kết nối hiện tại không?
• Hay chúng tồn tại như các lớp riêng biệt?
• Bạn có nhận thấy người dùng bị lạc giữa chúng không?

Và quan trọng hơn,

Việc quản lý mọi thứ trong một nơi, thậm chí là các trang tùy chỉnh, có cảm thấy hữu ích với bạn hay không cần thiết hạn chế?

Nếu có một điều mà điều này đã thay đổi đối với chúng tôi, đó là:

Chúng tôi ngừng hỏi: "Làm sao để viết tài liệu tốt hơn?"

Và bắt đầu hỏi,

"Làm thế nào để người dùng hiểu sản phẩm của chúng tôi mà không gặp rào cản?"

Đó chính là câu hỏi đã dẫn chúng tôi đến việc xây dựng CandyDocs ngay từ đầu.