Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn thiết kế một app thương mại điện tử tuyệt đẹp: màu sắc hài hòa, animation mượt mà, nút bấm rõ ràng. Nhưng khi người dùng muốn tìm "chính sách đổi trả", họ mở menu "Tài khoản", không thấy, chuyển sang "Hỗ trợ", vẫn không thấy, cuối cùng bỏ cuộc và gọi tổng đài. Vấn đề ở đây không phải giao diện xấu — mà là cấu trúc thông tin (Information Architecture — IA) sai. Bạn đã đặt món hàng đúng nhưng vào sai ngăn tủ.
Trong chuỗi bài về UX Metrics, đây là bài đầu tiên chạm trực tiếp vào cách con người tổ chức và tìm kiếm thông tin trong đầu họ. Rất nhiều lỗi UX tốn kém — tỷ lệ tìm kiếm thất bại cao, người dùng đi vòng vo, giỏ hàng bị bỏ dở — không đến từ nút bấm hay màu sắc, mà đến từ việc menu, danh mục, luồng điều hướng không khớp với "bản đồ tư duy" của người dùng.
Hai phương pháp trong bài này — Card Sorting (phân loại thẻ) và Tree Testing (kiểm thử cây điều hướng) — là cặp công cụ kinh điển để thiết kế và kiểm chứng cấu trúc thông tin dựa trên dữ liệu thực từ người dùng, thay vì phỏng đoán của designer. Điều đặc biệt là cả hai đều rẻ, nhanh, có thể làm từ xa (remote), và cho ra kết quả định lượng lẫn định tính. Một nghiên cứu Card Sorting với 20 người có thể thực hiện trong 2-3 ngày với chi phí gần như bằng 0, nhưng lại quyết định cách hàng nghìn người dùng điều hướng sản phẩm của bạn trong nhiều năm.
Nắm vững hai phương pháp này, bạn chuyển từ vai trò "người vẽ giao diện" sang "kiến trúc sư trải nghiệm" — người thiết kế cả bộ khung nhận thức bên dưới lớp da giao diện.
Khái niệm cốt lõi
Trước khi đi vào chi tiết, cần phân biệt vai trò của hai phương pháp. Nếu bạn ví cấu trúc thông tin như xây một tòa nhà:
- Card Sorting = phương pháp generative (khám phá, sinh ý tưởng): giúp bạn tạo ra bản thiết kế các phòng, tầng, cách gom nhóm — dựa trên cách người dùng nghĩ.
- Tree Testing = phương pháp evaluative (đánh giá, kiểm chứng): giúp bạn kiểm tra xem người dùng có tìm được đúng phòng trong tòa nhà đã dựng khung hay không.
Card Sorting — Phân loại thẻ
Ý tưởng đơn giản đến bất ngờ: bạn đưa cho người tham gia một tập thẻ (card), mỗi thẻ ghi tên một mẩu nội dung hoặc tính năng (ví dụ: "Đổi trả hàng", "Theo dõi đơn hàng", "Mã giảm giá", "Đánh giá sản phẩm"). Người tham gia sẽ gom các thẻ thành các nhóm mà theo họ là hợp lý, rồi đặt tên cho từng nhóm. Từ đó bạn thấy được người dùng tự nhiên phân loại thông tin như thế nào.
Có ba biến thể chính:
1. Open Card Sort (phân loại mở) — Người tham gia tự do tạo nhóm và tự đặt tên nhóm. Đây là dạng generative thuần túy, dùng khi bạn chưa có cấu trúc và muốn khám phá cách người dùng gom nhóm cũng như ngôn ngữ họ dùng. Điểm mạnh: phát hiện cách gọi tên (labeling) mà chính bạn chưa nghĩ ra. Điểm yếu: kết quả đa dạng, khó tổng hợp.
2. Closed Card Sort (phân loại đóng) — Bạn đưa sẵn các nhóm cố định (danh mục đã đặt tên), người tham gia chỉ việc bỏ từng thẻ vào nhóm phù hợp. Đây thiên về evaluative — dùng khi bạn đã có cấu trúc và muốn kiểm tra xem nội dung có "về đúng nhà" hay không. Kết quả dễ tổng hợp thành số liệu.
3. Hybrid Card Sort (lai) — Bạn cho sẵn một số nhóm gợi ý nhưng vẫn cho phép người tham gia tạo thêm nhóm mới. Cân bằng giữa khám phá và kiểm chứng.
Chỉ số quan trọng nhất khi phân tích Card Sorting là ma trận tương đồng (similarity matrix) — cho biết tỷ lệ % người tham gia xếp hai thẻ bất kỳ vào cùng một nhóm. Cặp thẻ có độ tương đồng cao (ví dụ 85% người xếp "Đổi trả" và "Hoàn tiền" cùng nhóm) chính là gợi ý mạnh rằng chúng nên nằm chung một danh mục. Công cụ như OptimalSort còn vẽ dendrogram (biểu đồ cây phân nhánh) để bạn thấy các cụm tự nhiên hình thành.
Tree Testing — Kiểm thử cây điều hướng
Nếu Card Sorting hỏi "bạn sắp xếp thông tin thế nào?", thì Tree Testing hỏi "bạn có tìm thấy thông tin trong cấu trúc này không?".
Bạn cung cấp cho người tham gia một cây điều hướng dạng text thuần (chỉ là các danh mục và danh mục con, không có giao diện, không màu sắc, không hình ảnh, không thanh tìm kiếm). Sau đó bạn đưa nhiệm vụ dạng: "Bạn muốn xem hạn cuối để đổi một chiếc áo đã mua. Bạn sẽ bấm vào đâu?". Người tham gia click lần lượt qua cây để tìm đến nơi họ cho là chứa câu trả lời.
Tại sao lại bỏ hết giao diện? Vì để cô lập biến số cấu trúc. Khi có UI đẹp, người dùng có thể tìm ra nhờ màu sắc, icon gợi ý, hay thanh search — che giấu việc cấu trúc thực chất rất tệ. Tree Testing lột trần cấu trúc để đo đúng chất lượng của nó.
Ba chỉ số cốt lõi của Tree Testing:
- Success rate (tỷ lệ thành công): % người tìm đúng đích. Đây là chỉ số quan trọng nhất.
- Directness (tính trực tiếp): % người đi thẳng đến đích mà không quay lui (backtrack). Directness thấp cho thấy cấu trúc gây bối rối dù cuối cùng vẫn tìm ra.
- Time to complete (thời gian hoàn thành): đo tốc độ, bổ sung ngữ cảnh cho hai chỉ số trên.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT Việt Nam gom nhầm "Chính sách"
Một sàn thương mại điện tử tại TP.HCM (giả định tên ChợViệt) nhận thấy tổng đài chăm sóc khách hàng nhận trung bình 400 cuộc gọi/ngày, trong đó gần 30% chỉ hỏi những thông tin đã có sẵn trên website: chính sách đổi trả, thời gian giao hàng, phí ship. Rõ ràng người dùng không tìm thấy dù thông tin tồn tại.
Đội UX chạy một Open Card Sort với 25 người dùng thật, dùng 30 thẻ nội dung. Kết quả ma trận tương đồng cho thấy điều bất ngờ: 78% người tham gia gom "Đổi trả", "Hoàn tiền", "Bảo hành" vào chung một nhóm mà họ tự đặt tên là "Quyền lợi khi mua" — trong khi website hiện tại đang rải ba mục này ở ba nơi khác nhau (Tài khoản, Hỗ trợ, và footer). Ngoài ra, không một ai đặt tên nhóm là "Chính sách" — từ mà công ty đang dùng làm menu chính. Người dùng nghĩ theo hướng quyền lợi của tôi, không phải chính sách của công ty.
Bài học: Card Sorting không chỉ cho biết gom nhóm thế nào, mà còn phơi bày khoảng cách ngôn ngữ giữa doanh nghiệp và người dùng. ChợViệt đổi tên menu thành "Quyền lợi & Hỗ trợ" và gom ba mục lại một chỗ. Ba tuần sau, cuộc gọi hỏi thông tin cơ bản giảm khoảng 22%.
Ví dụ 2 — Ứng dụng ngân hàng số kiểm chứng menu trước khi code
Một ngân hàng số (giả định NeoBank) chuẩn bị tung tính năng mới và có 4 phương án sắp xếp menu chính do 4 nhóm nội bộ tranh luận không dứt: nên để "Chuyển tiền" ngang cấp với "Thanh toán hóa đơn", hay gộp cả hai vào "Giao dịch"? Thay vì để sếp quyết theo cảm tính, PM cho chạy Tree Testing trên hai phương án cấu trúc, mỗi phương án 50 người tham gia remote qua Treejack (công cụ của Optimal Workshop), với 8 nhiệm vụ điển hình.
Kết quả rất rõ: Ở nhiệm vụ "Tìm nơi thanh toán tiền điện", phương án gộp vào "Giao dịch" chỉ đạt 54% success rate và directness 41% — nhiều người click nhầm vào "Chuyển tiền" trước. Phương án tách riêng "Thanh toán hóa đơn" thành mục độc lập đạt 89% success rate và directness 82%. Dữ liệu first-click cho thấy từ "Giao dịch" quá mơ hồ, không "kéo" đúng người vào.
Bài học: Tree Testing biến một cuộc tranh cãi nội bộ vô tận thành quyết định dựa trên số liệu, và điều quan trọng nhất — nó diễn ra trước khi một dòng code nào được viết. Chi phí sửa một cấu trúc trên bản text vài đô-la; sửa sau khi đã code và launch có thể tốn hàng chục nghìn đô.
Ví dụ 3 — Kết hợp cả hai cho một hệ thống nội bộ
Một công ty logistics ở Đông Nam Á xây dựng lại intranet (cổng thông tin nội bộ) cho 2.000 nhân viên vì ai cũng than "không tìm được gì cả". Đội thiết kế làm quy trình hai bước: đầu tiên chạy Hybrid Card Sort với 30 nhân viên để dựng cấu trúc mới từ dữ liệu — ví dụ phát hiện nhân viên gom "Đơn xin nghỉ phép", "Bảng lương", "Bảo hiểm" vào nhóm họ gọi là "Của tôi / My Stuff". Sau khi có cấu trúc nháp, họ chạy Tree Testing với 60 nhân viên khác để nghiệm thu.
Vòng Tree Testing đầu tiên chỉ đạt 61% success rate cho nhiệm vụ tìm "quy định công tác phí". Nhìn kỹ, đội thấy người dùng phân vân giữa "Tài chính" và "Chính sách HR". Họ điều chỉnh, đưa ra bản v2, test lại và đạt 88%.
Bài học: Card Sorting và Tree Testing mạnh nhất khi dùng nối tiếp thành một vòng lặp: sinh cấu trúc → kiểm chứng → tinh chỉnh → kiểm chứng lại. Đây chính là "test rồi mới xây" áp dụng cho cấu trúc thông tin.
Hướng dẫn từng bước
Với Card Sorting:
- Xác định mục tiêu và chọn biến thể. Chưa có cấu trúc và muốn khám phá → Open. Đã có danh mục và muốn kiểm chứng → Closed. Ở giữa → Hybrid.
- Chọn nội dung làm thẻ. Chọn 30–60 thẻ. Dưới 30 thì thiếu độ tin cậy; trên 60 người tham gia sẽ mệt và bỏ giữa chừng. Mỗi thẻ là một mẩu nội dung cụ thể, dễ hiểu, tránh thuật ngữ nội bộ.
- Viết nhãn thẻ trung lập. Đừng để lộ manh mối phân nhóm. Ví dụ đừng ghi "Hỗ trợ: Đổi trả" — chỉ ghi "Đổi trả hàng".
- Tuyển người tham gia đúng đối tượng. 15–20 người/nhóm đối tượng là đủ để ma trận tương đồng ổn định. Nếu có nhiều phân khúc (ví dụ khách mới vs khách VIP), tách riêng.
- Chạy nghiên cứu. Dùng công cụ như OptimalSort, hoặc thẻ giấy vật lý nếu làm trực tiếp. Yêu cầu người tham gia nói to suy nghĩ (think-aloud) nếu moderated.
- Phân tích. Xem ma trận tương đồng và dendrogram để tìm cụm tự nhiên; ghi lại các tên nhóm người dùng dùng để lấy làm nhãn danh mục.
- Dựng cây điều hướng dạng text. Chỉ danh mục và danh mục con, không UI. Có thể lấy từ kết quả Card Sorting.
- Viết nhiệm vụ theo mục tiêu người dùng, không lộ đáp án. Đúng: "Bạn muốn biết bao lâu thì hàng được giao tới." Sai: "Tìm mục Thời gian giao hàng trong Chính sách vận chuyển." (câu sau đã mớm chữ "Chính sách vận chuyển").
- Giới hạn 8–10 nhiệm vụ để tránh người tham gia mệt.
- Tuyển 30–50 người/cấu trúc để success rate đủ tin cậy.
- Chạy và đo ba chỉ số: success rate, directness, time. Xem thêm phân tích first-click.
- Diễn giải và lặp lại. Nhiệm vụ nào success thấp → soi first-click để biết người dùng "lạc" vào đâu, sửa nhãn hoặc cấu trúc, rồi test lại.
Lỗi thường gặp & mẹo
- Mớm đáp án trong câu nhiệm vụ (Tree Testing). Đây là lỗi phổ biến nhất. Nếu câu hỏi chứa đúng chữ trên nhãn danh mục, bạn đang đo khả năng đọc chứ không đo cấu trúc. Luôn viết nhiệm vụ bằng ngôn ngữ của người dùng, mô tả mục tiêu.
- Quá nhiều thẻ. 100 thẻ sẽ khiến người tham gia kiệt sức và bỏ dở. Nếu nội dung quá nhiều, hãy chọn mẫu đại diện.
- Nhầm vai hai phương pháp. Đừng dùng Card Sorting để "nghiệm thu" cấu trúc cuối, cũng đừng dùng Tree Testing để "sinh" cấu trúc từ đầu. Card Sort xây, Tree Test kiểm.
- Bỏ qua directness, chỉ nhìn success rate. Một nhiệm vụ có success 90% nhưng directness 40% nghĩa là người dùng cuối cùng cũng tìm ra nhưng rất vòng vo — cấu trúc vẫn có vấn đề cần sửa.
- Mẹu — dùng chính ngôn ngữ của người dùng làm nhãn. Card Sorting cho bạn "kho từ vựng" thật của người dùng. Đừng vứt đi để dùng từ ngữ marketing bóng bẩy.
- Mẹo — test trên nhiều phân khúc riêng. Khách hàng doanh nghiệp và khách hàng cá nhân thường có mô hình phân loại khác nhau; gộp chung sẽ ra kết quả trung bình vô nghĩa.
- Mẹo — chạy remote để tăng quy mô và giảm chi phí. Công cụ như OptimalSort/Treejack, Maze, UserZoom cho phép thu 50+ người trong vài ngày.
Bài tập thực hành
- Card Sorting nhỏ: Chọn một website bạn thường dùng (ví dụ một app đặt đồ ăn). Liệt kê 25 mẩu nội dung/tính năng thành thẻ. Nhờ 5 người quen làm Open Card Sort (có thể dùng giấy nhớ hoặc bảng Miro). Lập ma trận tương đồng thủ công: với mỗi cặp thẻ, đếm bao nhiêu người xếp chúng cùng nhóm. Chỉ ra 3 cặp có độ tương đồng cao nhất.
- Tree Testing nhanh: Lấy sơ đồ menu hiện tại của một website (chỉ text). Viết 5 nhiệm vụ theo đúng nguyên tắc "không mớm đáp án". Nhờ 5 người thực hiện trên bản text và ghi lại: họ có tìm đúng không, first-click là gì, có backtrack không. Tính success rate và directness thô cho từng nhiệm vụ.
- So sánh hai cấu trúc: Tạo hai phương án menu khác nhau cho cùng một nội dung. Chạy Tree Testing tối thiểu trên 6 người mỗi phương án với cùng bộ nhiệm vụ. Viết một đoạn ngắn kết luận phương án nào tốt hơn dựa trên số liệu, không dựa vào cảm tính.
Tóm tắt
- Card Sorting và Tree Testing là cặp công cụ cốt lõi để thiết kế và kiểm chứng cấu trúc thông tin — nền tảng nhận thức bên dưới mọi giao diện.
- Card Sorting (generative): người dùng gom và đặt tên nhóm thẻ, giúp xây cấu trúc và khám phá ngôn ngữ thật của họ. Ba biến thể: Open (khám phá), Closed (kiểm chứng), Hybrid (lai). Phân tích qua ma trận tương đồng và dendrogram.
- Tree Testing (evaluative): người dùng tìm đường qua cây điều hướng dạng text thuần, giúp kiểm chứng cấu trúc. Ba chỉ số: success rate, directness, time, cộng phân tích first-click.
- Sức mạnh lớn nhất đến khi dùng nối tiếp: Card Sort để xây → Tree Test để nghiệm thu → tinh chỉnh → test lại, tất cả trước khi thiết kế UI hay viết code.
- Cả hai đều rẻ, nhanh, làm được từ xa, và biến những tranh cãi cảm tính về menu thành quyết định dựa trên dữ liệu người dùng thật.