title: "Card Sorting & Tree Testing: Kỹ thuật khoa học để thiết kế cấu trúc menu"
series: "UX Architect: 40 bài Expert-Deep Dive"
part: "Phần 2 — Kiến trúc Thông tin & Tư duy Logic"
order: 12
audience: "Product Designer & UX Architect"
reading_time: "13 phút"
tags: ["card-sorting", "tree-testing", "information-architecture", "navigation", "research-methods", "config-driven-ui"]

Card Sorting & Tree Testing: Kỹ thuật khoa học để thiết kế cấu trúc menu

Cuộc họp bắt đầu lúc 2 giờ chiều, và đến 2 giờ 40 phút, cấu trúc menu chính của sản phẩm đã được "chốt" — không phải vì có dữ liệu, mà vì Trưởng phòng Sản phẩm nói to nhất, và không ai muốn tranh luận thêm trước giờ tan làm. "Xuất hóa đơn" được xếp vào nhóm "Tài chính" vì "nghe hợp lý", "Quản lý hợp đồng" bị nhét vào "Cài đặt" vì không ai biết xếp đâu khác. Ba tháng sau, ticket hỗ trợ khách hàng chất đống với cùng một câu hỏi: "Tôi tìm chức năng X ở đâu?"

Đây không phải là lỗi thiết kế giao diện — form đẹp, icon rõ, màu sắc chuẩn. Đây là lỗi ở tầng sâu hơn: cấu trúc thông tin (Information Architecture — IA) được xây trên trực giác của một cá nhân, thay vì trên mô hình tinh thần (mental model) thực tế của hàng trăm người dùng sẽ dùng sản phẩm mỗi ngày. Bài này nói về hai kỹ thuật nghiên cứu định lượng-định tính giúp một UX Architect thoát khỏi cái bẫy "họp phòng quyết định IA": Card Sorting và Tree Testing.

The UX Problem

Vấn đề gốc rễ ở đây có tên: groupthink có thứ bậc (hierarchy-driven groupthink). Trong hầu hết tổ chức, quyết định về cấu trúc menu — thứ tưởng chừng "nhỏ" so với chiến lược sản phẩm — lại thường được đưa ra nhanh nhất, ít dữ liệu nhất, và bị chi phối bởi người có chức vụ cao nhất hoặc giọng nói to nhất trong phòng. Lý do rất con người: mọi người trong phòng họp đều là domain expert, họ đã dùng sản phẩm ở góc nhìn nội bộ (internal mental model) hàng năm trời, nên cấu trúc "hợp lý" với họ được mặc định là hợp lý với người dùng.

Nhưng mental model của người xây dựng sản phẩm và mental model của người dùng cuối gần như luôn lệch nhau. Một kế toán viên nghĩ "Xuất hóa đơn" thuộc về nhóm "Bán hàng" (vì nó gắn với đơn hàng), trong khi đội sản phẩm xếp nó vào "Tài chính" (vì nó liên quan đến số tiền và thuế). Không bên nào sai về mặt logic — nhưng chỉ có một bên phản ánh đúng cách người dùng thực sự đi tìm chức năng.

Hậu quả của một IA sai không dừng ở "trải nghiệm không mượt". Nó tạo ra chi phí vận hành thực: tăng ticket hỗ trợ, giảm tỷ lệ kích hoạt tính năng (feature adoption), và tệ nhất — một khi cấu trúc navigation đã hardcode vào codebase, sửa nó tốn kém ngang một cuộc refactor nhỏ. Đây là lý do IA cần được kiểm chứng bằng phương pháp khoa học, không phải bằng biểu quyết trong phòng họp.

Design Framework

Hai kỹ thuật trung tâm giải quyết vấn đề này thuộc về nhóm generative research (khám phá) và evaluative research (kiểm chứng) — chúng bổ sung cho nhau theo trình tự thời gian, không thay thế nhau.

1. Card Sorting — khám phá mental model tự nhiên

Card Sorting là kỹ thuật cho người dùng thật thao tác với các "thẻ bài" (card), mỗi thẻ đại diện một chức năng/nội dung của sản phẩm (ví dụ: "Tạo hóa đơn", "Quản lý khách hàng", "Báo cáo doanh thu"...), rồi yêu cầu họ tự nhóm các thẻ này lại theo cách họ thấy hợp lý.

Có ba biến thể:

• Open Card Sorting: người dùng tự nhóm thẻ VÀ tự đặt tên cho từng nhóm. Đây là kỹ thuật khám phá thuần túy — dùng ở giai đoạn đầu khi bạn chưa có giả thuyết gì về cấu trúc IA. Kết quả cho ra insight về cả nhóm nào tồn tại trong đầu người dùng lẫn họ gọi tên nhóm đó là gì (quan trọng cho việc đặt tên menu — naming convention).
• Closed Card Sorting: bạn đưa sẵn danh sách nhóm (category) đã định nghĩa, người dùng chỉ việc xếp thẻ vào nhóm có sẵn. Dùng khi bạn đã có khung IA sơ bộ và muốn kiểm tra xem các mục nội dung có "vừa vặn" đúng nhóm dự kiến không.
• Hybrid Card Sorting: kết hợp cả hai — có sẵn nhóm gợi ý nhưng cho phép người dùng tạo nhóm mới nếu thấy không phù hợp. Đây là lựa chọn thực dụng nhất trong đa số dự án SaaS B2B vì tận dụng được cả tốc độ của closed sort lẫn khả năng phát hiện bất ngờ của open sort.

Kết quả card sorting thường được phân tích bằng dendrogram (biểu đồ cây phân cụm) hoặc similarity matrix — cho biết cặp thẻ nào thường được người dùng xếp cùng nhóm nhất, từ đó suy ra cấu trúc nhóm tối ưu về mặt thống kê, không phải cảm tính.

2. Tree Testing — kiểm chứng một cấu trúc đã đề xuất

Nếu Card Sorting trả lời câu hỏi "người dùng nghĩ các chức năng này nên được nhóm thế nào?", thì Tree Testing trả lời câu hỏi ngược lại: "Với cấu trúc menu ĐÃ ĐỀ XUẤT (dạng cây phân cấp thuần văn bản, không giao diện, không màu sắc, không icon), người dùng có tìm đúng đường đến chức năng cần tìm không?"

Người tham gia được đưa một cây danh mục (text-only tree — cố ý loại bỏ mọi yếu tố hình ảnh để đo lường thuần túy cấu trúc logic, không bị nhiễu bởi UI đẹp/xấu), rồi được giao nhiệm vụ dạng: "Bạn cần xuất hóa đơn cho khách hàng tháng này. Hãy click vào nơi bạn nghĩ tính năng đó nằm." Công cụ ghi lại: họ có tìm đúng không (success rate), họ đi đường nào (path), và mất bao lâu, có bao nhiêu lần "quay lui" (backtrack — dấu hiệu của sự lưỡng lự/nhầm lẫn).

Ba chỉ số định lượng cốt lõi cần theo dõi:

Quy trình chuẩn: Card Sorting trước để đề xuất cấu trúc IA mới → Tree Testing sau để kiểm chứng cấu trúc đó có thực sự hoạt động không, trước khi đưa vào thiết kế giao diện chi tiết (wireframe/UI). Làm ngược lại — thiết kế UI xong rồi mới tree-test — sẽ khiến bạn phải sửa cả cấu trúc lẫn giao diện cùng lúc nếu kết quả xấu, tốn gấp đôi công sức.

The "Architect's" Insight

Đây là phần phân biệt một UX Architect với một UI Designer thuần túy: kết quả card sorting không chỉ là tài liệu tham khảo cho designer — nó có thể (và nên) trở thành một cấu trúc dữ liệu (data structure) thực sự trong hệ thống.

Cách tổ chức phổ biến — và là một anti-pattern kiến trúc nghiêm trọng — là hardcode cấu trúc menu ngay trong code frontend:

// Anti-pattern: IA hardcode trong component, đổi cấu trúc = phải deploy code
const navigationConfig = [
  { label: "Tài chính", children: [
      { label: "Xuất hóa đơn", route: "/invoices/export" },
      { label: "Đối soát công nợ", route: "/reconciliation" },
  ]},
  { label: "Bán hàng", children: [
      { label: "Đơn hàng", route: "/orders" },
  ]},
];

Vấn đề: mỗi khi kết quả tree-test tiếp theo (hoặc một vòng card-sort mới sau khi sản phẩm thêm tính năng) cho thấy cần dời một mục sang nhóm khác, đội kỹ thuật phải sửa code, chạy lại pipeline CI/CD, review PR, deploy — cho một thay đổi thuần túy về cấu trúc thông tin, không phải logic nghiệp vụ. Điều này biến IA — vốn dĩ nên là thứ có thể lặp nhanh (iterate fast) dựa trên dữ liệu người dùng — thành một thứ đắt đỏ ngang một tính năng mới.

Cách tiếp cận đúng của một Solutions Architect: xem output của card sorting/tree testing như schema cho một bảng cấu hình điều hướng (navigation config), lưu trong database hoặc file JSON được load động, tách biệt hoàn toàn khỏi code logic nghiệp vụ:

{
  "nav_version": 4,
  "groups": [
    {
      "group_id": "grp_sales",
      "label_key": "nav.group.sales",
      "order": 1,
      "items": [
        { "item_id": "invoice_export", "label_key": "nav.item.invoice_export",
          "route": "/invoices/export", "permission": "invoice:read", "order": 1 }
      ]
    }
  ]
}

Hệ quả kiến trúc cụ thể của quyết định này:

• Bảng nav_groups / nav_items trong DB (thay vì object hardcode) cho phép Product/UX team tự sửa cấu trúc qua một trang admin nội bộ, không cần đụng vào codebase của kỹ sư. Đây chính xác là mô hình mà nhiều module CMS/admin-config trong các hệ thống NestJS + TypeORM hay dùng: một entity NavigationItem với cột parent_id (self-referencing để biểu diễn cây phân cấp), order_index, route_path, permission_key.
• Versioning cấu hình (nav_version) cho phép A/B test hai cấu trúc IA khác nhau trên cùng một codebase — chạy tree test sống (live) với một phần trăm người dùng thật, thay vì chỉ test trên môi trường giả lập, rồi đo lường success rate thực qua analytics event.
• Tách label_key khỏi label đảm bảo cấu trúc điều hướng tương thích với i18n — vì kết quả card sorting về "tên nhóm" có thể khác nhau giữa các thị trường/ngôn ngữ (người Việt gọi "Xuất hóa đơn", người dùng thị trường khác có thể quen từ khác) — đừng trộn dữ liệu ngôn ngữ vào dữ liệu cấu trúc.
• permission_key gắn vào từng item giải quyết vấn đề thực tế mà card sorting thuần UX hay bỏ sót: cấu trúc IA "tối ưu" cho toàn bộ người dùng có thể không tương thích với phân quyền (RBAC) — một mục có thể tồn tại trong cây điều hướng của admin nhưng ẩn với nhân viên thường. Cache tầng Redis cho response menu-theo-role là hệ quả kỹ thuật tiếp theo cần tính đến khi lưu lượng lớn.

Nói ngắn gọn: card sorting là nghiên cứu UX, nhưng đầu ra của nó, nếu được thiết kế đúng ngay từ khâu kiến trúc dữ liệu, sẽ biến IA từ một quyết định "đóng băng trong code" thành một cấu hình sống (living configuration) — thay đổi được bằng một record update, không phải một lần deploy.

Practical Example

Giả sử một sản phẩm CRM đang tổ chức lại menu chính. Đội UX chạy Hybrid Card Sorting với 45 người dùng thật (nhân viên kế toán, sales, quản lý) trên 24 thẻ chức năng. Kết quả phân cụm cho thấy "Xuất hóa đơn" được 62% người dùng xếp chung nhóm với "Đơn hàng" (Bán hàng), chỉ 24% xếp chung với "Đối soát công nợ" (Tài chính) — trái với giả định ban đầu của đội sản phẩm.

Dựa trên kết quả này, đội dựng một cấu trúc IA đề xuất mới, rồi chạy Tree Testing với 60 người dùng khác (không trùng nhóm card-sort) để kiểm chứng. Kết quả:

Con số "40% người dùng không tìm được tính năng Xuất hóa đơn ở đúng vị trí dự kiến" (ứng với success rate trực tiếp chỉ 38%, tức khoảng 62% thất bại hoặc phải quay lui ở cấu trúc cũ) chính là bằng chứng định lượng thuyết phục để trình bày trước ban lãnh đạo — thay vì tranh luận cảm tính "tôi nghĩ nó nên ở đây", đội UX đưa ra một con số không thể phản bác bằng ý kiến chủ quan. Đây là sự khác biệt giữa "tôi nghĩ" và "dữ liệu cho thấy" — nền tảng để một UX Architect có tiếng nói ngang hàng với các quyết định kỹ thuật/kinh doanh khác trong tổ chức.

Common Pitfalls

1. Mẫu thử quá nhỏ để kết luận chắc chắn. Chạy card sorting với 5 người rồi công bố "kết luận nghiên cứu" là sai lầm thống kê nghiêm trọng — với dữ liệu phân loại đa chiều (nhiều thẻ, nhiều nhóm khả dĩ), độ nhiễu (variance) giữa các cá nhân rất lớn. Kinh nghiệm thực chiến: cần tối thiểu 15-20 người cho card sorting để dendrogram bắt đầu ổn định, và 30-50 người cho mỗi phiên bản cấu trúc trong tree testing để success rate có ý nghĩa thống kê. Con số càng nhỏ, kết quả càng dễ bị một vài cá nhân có mental model bất thường (outlier) làm lệch toàn bộ kết luận.

2. Tổ chức nghiên cứu nhưng phớt lờ kết quả nếu nó trái ý kiến ban đầu của team. Đây là lỗi nguy hiểm hơn cả việc không nghiên cứu — nó tạo ảo giác về tính khoa học ("chúng tôi đã test với người dùng") trong khi thực chất quyết định cuối cùng vẫn dựa trên ý kiến chủ quan ban đầu. Dấu hiệu nhận biết: kết quả nghiên cứu được trình bày, nhưng câu kết luận trong họp là "dữ liệu thú vị, nhưng chúng ta vẫn nên đi theo hướng ban đầu vì lý do X" — nếu lý do X không phải là dữ liệu mới, đây chính là bias xác nhận (confirmation bias) trá hình.

3. Nhầm lẫn giữa việc "test giao diện đẹp" với "test cấu trúc logic". Nhiều đội chạy tree test nhưng lại vô tình để lộ icon, màu sắc, hoặc bố cục trực quan trong công cụ — khiến người tham gia chọn đúng đường vì "nhìn quen mắt" (thẩm mỹ) chứ không phải vì tên gọi và cấu trúc phân nhóm hợp lý. Tree testing phải được thực hiện với cây văn bản thuần túy (text-only), tách biệt hoàn toàn khỏi mọi yếu tố UI — đây là điều kiện tiên quyết để kết quả phản ánh đúng chất lượng của IA, không phải chất lượng của thiết kế màn hình.

Checklist

• Đã xác định rõ mục tiêu: đang ở giai đoạn khám phá (cần Open/Hybrid Card Sorting) hay giai đoạn kiểm chứng (cần Tree Testing)?
• Số lượng người tham gia đạt tối thiểu 15-20 (card sorting) hoặc 30-50 mỗi cấu trúc (tree testing)?
• Người tham gia là người dùng thật (hoặc đại diện đúng nhóm đối tượng mục tiêu), không phải đồng nghiệp nội bộ đã quen sản phẩm?
• Danh sách thẻ/nhiệm vụ tree test được viết bằng ngôn ngữ nhiệm vụ (task-based: "Bạn cần xuất hóa đơn cho khách hàng...") thay vì tên tính năng trực tiếp (tránh gợi ý câu trả lời)?
• Tree test được thực hiện với cây văn bản thuần túy, không lẫn yếu tố UI/màu sắc/icon?
• Kết quả được phân tích bằng số liệu (success rate, dendrogram, directness), không chỉ diễn giải cảm tính?
• Kết quả nghiên cứu được đưa vào cấu hình dữ liệu (nav config JSON/DB), không hardcode cứng trong code component, để có thể lặp lại nhanh ở vòng nghiên cứu tiếp theo?

🔗 Bài viết liên quan

• Information Architecture (IA): Xương sống của sản phẩm
• User Flow & Task Flow

Bài trước: Information Architecture (IA) · Bài tiếp theo: User Flow & Task Flow