Is card sorting your game?

Card sorting is a method for classifying or categorizing content, names, icons, objects, ideas, problems, tasks, or other items by putting them into actual or virtual piles that are similar in some way. While card sorting is a common name for this method in user experience design, it goes by other names as well, including "pile sorting" (cultural anthropology), "free grouping," and "partitioning" (mathematics and statistics). Card sorting is a powerful tool for shaping information architecture in Web sites and software applications.

Card sorting can be done individually by researchers as a way to organize some data (personal sorting — the kind you might do to help you organize a report), by a group of participants trying to come to consensus about how to organize many items (group card sorting), or by multiple participants whose independent sorts are combined and analyzed for common themes or patterns. The purpose of this article will take you through the  process of planning, conducting, analyzing, and communicating the results of your card sorting. Tips and tricks are shared that can make your card sorting sessions both efficient and effective.

Card sorting is excellent for situations where you want the users' mental model to drive the information architecture of the product. You should use a card sort anytime you need feedback about the content, terminology, and organization of your product.

Unfortunately, many developers design products to conform to their own mental model of a domain. They may base their decisions about the information architecture or a product's layout on the underlying technology (e.g., the database). In the case of designing a Web site, some companies mirror their organizational or departmental hierarchy. Users are rarely aware of the developer's point of view, the underlying technology, or the company's departmental organization. As a result, they will have difficulty using a product design based on those considerations. This happens when the product is not well defined or each person on the team has a different understanding of the product. The exercise of identifying objects and defining them can be eye-opening for the development team and demonstrate the need for a card sort as well as other usability activities.

You can do a card sort for entire sets of information (e.g., a Web site's entire information architecture) or for subsets of information (e.g., the information within a specific Web page). In a large product, different sections have different users. In this case, you will likely want to conduct a card sort on each section by users most likely to use it. Additionally, you can compare novice versus expert mental models.

There are several types of information that you can obtain with a card sort:

·         Overall organization of the content or tasks in your product

·         Terminology employed by users

·         Labels users apply to different categories of information or tasks

·         Missing objects

·         Unnecessary objects

Users may not always have optimal mental models.  Designing a system based on flawed user mental models can clearly hamper user performance. For this reason, you should avoid including users in your card sort with no or little experience in the domain of concern. Obviously, if a user does not understand a domain well and have experience in it, that person's mental model will not be as efficient or even correct as that of others who do.

Group or Individual Card Sort?

You need to decide whether to conduct your card sort with several participants at once or one at a time. We conduct these sessions with several participants simultaneously because this allows us to collect large samples of data in a short period. You can conduct a card sort with as many people at a time as you physically have room for. In reality, even if you have a group of participants in the same room at the same time, they are not working together — they are each working individually.

The disadvantage with running several participants simultaneously is that you cannot collect “think-aloud data”, so you do not know why the users grouped the data the way they did. Although think-aloud data are helpful, participants typically provide enough information in their description of each group so that the need to collect data quickly and from large samples outweighs the benefit of having think-aloud data.

Some people dislike running a group card sort because they feel that the participants turn it into a race. I don’t know if that’s always the case, some people just are competitive and they probably use the internet the same way. It’s hard to say. It just makes sense to encourage people to take their time because we will be there for as long as they need to sort the cards.

If you have the time, a hybrid approach works quite well. After collecting data from a group of participants, run one or two individual card sorts to collect think-aloud data. This additional data can help you better understand the groupings.

Before you begin any user requirements activity, there are a number of things that you must be familiar with. Because these elements are common to all user requirements activities, now is a good time to double-check the list.

1. Introduction to user requirements
• Get stakeholder buy-in for your activity
2. Before you choose an activity
• Learn about your product
• Learn about your users
3. Ethical and legal considerations
• Create consent forms
• Create confidential disclosure agreements
4. Setting up facilities for your user requirements activity
• Create or acquire a facility for your activity
5. Preparing for your user requirements activity
• Develop an activity proposal
• Determine the time of day and duration of your session
• Recruit participants
• Develop an activity protocol
• Pilot your activity
6. During your user requirements activity
• Welcoming participants
• Dealing with late and absent participants
• Warm-up your participants
• Successfully moderate your activity