Tree testing and card sorting are two commonly used UX research methods to generate vs validate information architectures.
Card sorting's main purpose is to help organize feature or content requirements based on users' mental models. Tree testing differs from card sorting in that you test how users actually interact with the structure of a tree by asking them to find content and complete tasks. While tree tests are used to test the tree, card sorting development ensures that you translate the user's input from the creation of the website to navigation.
Participants receive a curated list of items (such as features or content in the navigation menu) presented in random order and are instructed to group them into categories that make logical sense for them. Depending on the sorting method used, this consists of:
- creating any number of categories they see fit and propose labels for these group (also known as open sort)
- or sorting the items within predefined categories that the product team preliminary specified (also known as closed sort).
Card Sorting can be conducted internally, by the team, or better, with a sample of representative end-users. In the latter case, conducting it in moderated settings (1-on-1 interviews using a Miro board or index cards/post-it notes) is a great opportunity to hear why participants decided on certain groupings and where they hesitated. Card Sorting in unmoderated settings is way more effective and allows testing for a larger number of participants (ideally 15-30) hence obtaining more certainty about how to categorize the product's features or content.
Candidate tree prototypes
Once predominant categories have been sorted out, the team can decide on a few tentative information architectures. These are unvalidated in the sense that many additional assumptions will go into their design, such as the placement of features that failed to reach proper agreements through card sorting, and the labels given to the menus. Being able to validate the information is critical though since it is the most basic and preliminary form to an interactive product intended to be navigated through in order to reach certain goals.
Tree testing being the first actual stage of navigation prototyping and testing, it is administered with real users (participants or testers), often in unmoderated settings, and primarily intends to gather quantitative data such as participants' performance in completing a scenario of tasks deemed critical to using the product. and to a lesser extent qualitative insights.
Running a tree test early can identify major flaws in prototyping as well as in your product's layout. It also helps you surface buried content that you didn’t know was buried in the first place! Since your hierarchy should be designed to be easy to follow and fluid, tree testing is really important to make sure that users find access to the right information, or else they'll churn convinced the content was never there in the first place. It helps product teams evaluate the effectiveness of an app's or website's navigation hierarchy and better organize the content on a product.
Card Sorting + Tree Testing Examples
For Card Sorting and Tree Testing examples, check out our:
- Mobile Payment 💵 app case study that combined a card sort in Miro with a series of tree tests in UXbeam to create a 7-task scenario and IA that were 100% Direct in just 8 iterations
- Dating app 💌 case study where ideation concepts for the pain-points associated with 4 dating apps in Q4'20 were prototyped and optimized using UXbeam Card Sorting and Tree Testing tools - resulting in an Information Architecture straightforward to users and fewer screens to wireframe for the team!
- Teamwork app 📝 slide deck depicting the elicitation and optimization (card sorts and tree tests, respectively) of the prototype for a collaborative web app similar to Slack, Yammer or Asana
How the two methods work together
Card Sorting and Tree Testing should be combined when:
- developing a new information architecture (for a new website or app),
- restructuring the navigation of an existing product
- or creating a new section of a product.
A Card Sorting exercise typically produces a handful of candidate structures. It is thus advisable to conduct tree tests afterwards in order to validate, tweak and refine any candidate menu structure with respect to a representative task scenario.
See how quick this end-to-end process can be accomplished in UXbeam: