The design process of making an information architecture begins with a list of various content and only a vague understanding of how it’s all linked together. The goal of designing information architecture is to find a way to structure the content, so it makes sense to the majority of people.
Card sorting as a technique gives us the ability to grasp how users see content and how they organize it in their heads. But once we create information structures with card sorting information as the basis, we also need to validate them. We need to find out whether our information architecture is working as intended.
What’s card sorting good for?
Structuring the content on your website in a way that is “just right” is an important problem that is also far from easy to solve. Especially when we recognize that “just right” means a lot of different things to a lot of different people. Everybody has different points of view, different life experiences, and different priorities. This is why people can have diametrically opposed opinions about the meaning of certain labels or in their approach to looking for information.
Card sorting is a technique that seems very easy to understand, even to people who hear about it for the first time. There’s something that just clicks about framing the discovery of mental concepts as a classification problem. Unfortunately, this simplicity is also the reason why people can overestimate what results from a single card sorting can accomplish. Can we put together an awesome information architecture right away, by copying the results of a card sorting, where we have asked the respondents to sort absolutely everything on our site into categories? It probably isn’t hard to guess that the answer that I’m going for is “No.”
Card sorting was never intended to magically design the information architecture for you. It serves as more of a guideline – it gives you insights for “which content probably should go together.” Furthermore, the design of anything complex should always be done in iterations. This includes card sorting.
Follow up general card sortings with specific ones with a higher level of granularity. Follow up open card sortings with hybrid and closed ones. Design information structures based on what you learn. And then, validate the results of the current iteration.
How to setup a Card Sorting study with UXtweak
You can setup your first study with UXtweak in just a couple of minutes! Check out this quick video where we explain this process step-by-step:
Following up on card sorting
Seek tasks and sort tasks are very different activities, and the ways in which we process information during them are also quite different. When our brain is in the process of sorting pieces of information, it’s using a lot of its capacity. It has to think deeply about the big picture while also trying to make sense of the task and even show creativity. It’s a generative exercise.
Meanwhile, in seek tasks, our brain is laser-focused on a single goal that it’s currently trying to achieve – to find the one thing that it’s looking for, while also discarding any information that it finds irrelevant. Just like when browsing the web in real life, the brain is lazy. It’s looking for shortcuts and often accepts the first solution that it can find, even if it’s not actually the best one.
Once we’ve used card sort as a guide to design an information architecture, what we really want to do is to check how people in the seeking frame of mind interact with it.
Tree testing
As we’ve said, card sorting simply offers help in understanding your users’ thoughts and in finding ideas for designing a good information architecture. What it doesn’t do is help with actually making an information architecture that you can be positive is right.
That’s what tree testing is for.
Tree testing is essentially a reverse card sort. Instead of receiving a set of cards and having to place them into categories, the information architecture is already known and what respondents have to do is produce the card relevant to the task by finding it in the tree. A good thing about tree testing is that it can be done without writing a single line of code.
Since navigation helpers and graphical elements aren’t present in a pure text version of your tree-like structure, we can be sure that we’re testing solely the information architecture itself. As a bonus, you can find and fix issues in your information architecture super early in the development phase, avoiding the cost of having to do so in a later stage of the project.
During a tree test, we ask the respondents to find something in the tree. Respondents look for an answer by traversing the tree from its root. The respondent has to click a group node in order to open it up and see its contents. In UXtweak’s Tree Testing tool you can do an analysis of absolutely anything the respondents did – where they clicked first, what path they took, how long it took them, and a lot more.
By interpreting the information that comes from it, tree testing can be used to make conclusive judgments about the tested information architecture. Problems that appear in tree testing would arise again on a real website, which is not something card sorting can really offer on its own.
For example, you might find out that only 50% percent of respondents managed to find the product in the right category, and even out of those, 30% went down a different path at first. By looking at the paths that the respondents traversed, you can find which category they considered to be a better option for the product in question.
