Sắp xếp nội dung theo cách khách nghĩ

Khi khách hàng vào website mà phải đoán, phải quét qua từng mục rồi bỏ đi, nguyên nhân hầu như không phải do giao diện xấu hay nội dung thiếu. Nguyên nhân thường là cấu trúc trang đang phản ánh cách doanh nghiệp nghĩ về mình, không phải cách khách hàng nghĩ về nhu cầu của họ. Đây là bài toán kiến trúc thông tin (information architecture: cách tổ chức, phân nhóm và đặt tên nội dung), và nó cần được giải trước khi thiết kế giao diện.

Vấn đề thực sự: ai đang đặt tên cho nội dung?

Trong hầu hết dự án website Sinh Vũ từng tiếp nhận, menu và cấu trúc trang được dựng theo cách đội ngũ nội bộ quen gọi. Phòng Kinh doanh có một mục. Phòng Dịch vụ có một mục. Tên nhóm dùng thuật ngữ mà chỉ người trong ngành mới hiểu ngay. Kết quả là khách hàng phải "học" cách doanh nghiệp tổ chức bộ máy trước khi tìm được thứ họ cần.

Mô hình tư duy (mental model) là tập hợp kỳ vọng mà khách mang vào khi họ tới website: họ kỳ vọng tìm "bảng giá" ở đâu, họ gọi dịch vụ đó là gì, họ nghĩ bước tiếp theo sau khi đọc xong là gì. Kiến trúc thông tin đúng là kiến trúc khớp với mô hình tư duy đó, không phải khớp với sơ đồ tổ chức nội bộ.

Hai phương pháp để nghe khách phân nhóm

Có hai kỹ thuật nghiên cứu người dùng được đánh giá cao trong thực hành thiết kế trải nghiệm, và chúng bổ trợ nhau theo thứ tự:

• Sắp xếp thẻ (card sorting): Viết từng mục nội dung lên thẻ rời, nhờ một nhóm khách hàng thật tự gom thành các nhóm hợp lý với họ, rồi tự đặt tên nhóm. Kết quả cho thấy khách phân loại ra sao và dùng từ ngữ nào. Dùng kỹ thuật này khi chưa chắc cách phân nhóm, hoặc khi nội dung nhiều và dễ chồng lấn nhau.
• Kiểm thử cây (tree testing): Sau khi đã có cấu trúc dự kiến, nhờ khách thực hiện các nhiệm vụ tìm kiếm cụ thể chỉ dựa vào cấu trúc văn bản, tách hoàn toàn khỏi giao diện. Kết quả đo được khách tìm đúng hay sai đường, và bị mắc kẹt ở chỗ nào. Dùng kỹ thuật này để xác minh trước khi đưa vào thiết kế thật.

Để chính người dùng tự nhóm và tự đặt tên nội dung là cách nhanh nhất để khám phá mô hình tư duy của họ, thay vì đội ngũ tự phỏng đoán rồi áp đặt.

Nielsen Norman Group, Card Sorting: Uncover Users' Mental Models

Nhóm theo nhiệm vụ hay theo chủ đề?

Câu trả lời phụ thuộc vào lý do chính khiến khách vào trang:

Một website thường có cả hai loại nội dung. Nguyên tắc là xác định nhiệm vụ chính của đa số khách, rồi ưu tiên cấu trúc đó cho phần điều hướng chính, trong khi nội dung tham khảo có thể xếp riêng theo chủ đề.

Độ rộng và độ sâu: bao nhiêu tầng là đủ?

Không có con số cố định, nhưng có nguyên tắc thực hành: giữ cấu trúc phẳng khi số mục ít, chia tầng khi lượng nội dung lớn tới mức một cấp không chứa nổi. Vấn đề thường gặp không phải quá nhiều tầng, mà là quá nhiều mục nằm ngang hàng ở một tầng khiến khách phải quét quá lâu. Khi một cấp có quá nhiều lựa chọn, đó là tín hiệu để chia nhóm nhỏ hơn, không phải để nhồi thêm.

Với nhãn (label) của từng mục, nguyên tắc đơn giản là: đặt từ khóa quan trọng nhất lên đầu và dùng từ khách hiểu ngay, không để khách phải đoán nghĩa. "Bảng giá" rõ hơn "Giải pháp đầu tư". "Liên hệ" rõ hơn "Kết nối với chúng tôi".

Lỗi thường gặp khi tự cấu trúc

• Bê sơ đồ phòng ban lên thành menu, khiến khách phải hiểu bộ máy nội bộ trước khi tìm được thứ họ cần.
• Đặt tên nhóm bằng slogan hoặc thuật ngữ marketing sáng tạo mà khách không tra ra nghĩa, ví dụ "Hành trình chuyển hóa" thay vì "Quy trình làm việc".
• Dựa hoàn toàn vào ý kiến nội bộ và bỏ qua bước để khách thật kiểm chứng cấu trúc, dù chỉ là hỏi vài người quen chưa biết về doanh nghiệp.
• Nhồi mọi thứ vào một cấp cho "đủ thấy", khiến khách phải quét qua mười lăm mục trước khi tìm được hai mục thực sự liên quan.

Góc nhìn của Sinh Vũ

Sinh Vũ dựng website từ chiến lược nội dung và luồng trải nghiệm trước khi chạm vào giao diện. Giai đoạn khám phá đầu dự án là lúc Sinh Vũ làm rõ hai thứ: khách hàng của Anh/Chị cần gì, và doanh nghiệp muốn họ làm gì tiếp theo sau mỗi bước. Cấu trúc trang được dựng từ hai câu hỏi đó, không từ danh sách nội dung Anh/Chị muốn đưa lên.

Đây là việc thuộc thiết kế trải nghiệm và kiến trúc thông tin, không phải lập trình. Làm đúng ở giai đoạn này tiết kiệm nhiều lần chỉnh sửa sau khi đã dựng giao diện xong, vì sửa cấu trúc sau khi thiết kế xong tốn công hơn sửa cấu trúc trên giấy rất nhiều.