The organization of a Web application's features can be determined in a lot of ways. In simpler tools, the answers usually present themselves. After all, an application with few features really can't hide much, so each feature is often equally as important as the next. But more complex solutions, like intranets and company-wide accounting systems and such, are a different story altogether. In cases like these, we can learn quite a bit from the world of information architecture.
Information architects have been spinning complicated globs of data into works of organizational art for years, and this expertise has carried over to the Web, where it helps keep sites like CNN.com and NYTimes.com on the straight and narrow. From this world of expertise, we can gain incredible insight into how users would organize features if the choice were theirs, and learn how users search for things on the Web.
The Boxes and Arrows article "Four Modes of Seeking Information and How to Design for Them" (www.boxesandarrows.com/view/four_modes_of_seeking_information_and_how_to_design_for_them), written by Donna Maurer, discusses four principle ways that users search for content within information-based Web sites. The four methods Maurer talks about are:
These four methods certainly encapsulate most of how I find information online. Although the article isn't specific to Web applications, it does provide a useful clue into how users might try to locate operations within a Web application.
Addressing each of these modes is simple enough to achieve, especially now that you know about them. To put this in context of an application, pretend you're designing an application that lets users record podcasts, associate them with a feed users set up themselves, and list the individual shows on their own page within the site.
For known items, when a user knows what she's looking for, logical keywords are generally enough to get her on the right path. A quick way to head her toward recording a new podcast is to use words like create and record in the main navigation. To help her set information about her feeds so she can better market the podcasts to other people, words like describe and settings will catch her eye while she scans her account pages. These are trigger words that will make it easy for users to find what they need. (We'll talk more about trigger words later in this chapter.)
In another instance, the user might be looking for information on ID3 tags (metadata associated with an audio file), but may not know the term for such information. All he knows is that he wants to provide information about the author of his podcast, the publication date, duration, and other details. In this case, where the user is in exploratory mode, a button labeled Podcast Details could provide access to all these things on a single screen.
If the user is looking for information on how to apply a different theme to the podcast player that appears on her page, but doesn't know that the word theme is typically how color palettes and font styles are categorized ("don't know what you need to know"), you might avoid using the word theme altogether. In this case, surfacing several words all associated with themes will be helpful to newer users who haven't yet made the association.
For example, a menu named Themes can be used as part of the main configu-ration screen for the podcast player, but a "quick tip" on the page that informs the user she can change the color of her player will lead her to the Themes screen, where she will then learn about themes. Even better, you might show the player on the same page where the user creates his podcast, and simply provide a couple of options to change its appearance, bypassing the Themes screen altogether and keeping the creation process in the context of what other users will see once the activity has been completed.
Finally, a list of recent activities the user has performed or a favorites list could be just the thing for helping the user remember the name of the podcast he listened to last week on another user's page so he can jump straight back to it and send the URL to his friend. This method of enabling the user to "re-find" information will make the information-seeking task effortless. And without even realizing what makes your application so great, the user will be on his way in seconds flat, happy as a clam that he found what he needed without a lot of trouble.
There are almost certainly more than four modes of seeking information (for example, knowing what you're looking for, but having no idea where to look), but these four provide an excellent base. Providing for these four modes alone should keep us all busy for a while.
Card-sorting exercises can be a great way to learn how users think things should be organized within an application. Typically used by information architects to help determine an understandable navigation scheme within an information space, like a Web site, card sorting can help us organize application features just as well by revealing to us what trigger words our users associate with the types of features we plan to include.
Card sorting for applications starts with a simple stack of index cards. The idea is to write down all the features you plan to build, hand the stack off to some appropriate users, and ask them to sort the cards into stacks according to how they think the features should be organized. The exercise is very simple to perform, produces results quickly, and is inexpensive, so it's a viable option for any company looking to solve an information design problem quickly.
The first step in performing a card-sorting exercise is, obviously, to determine the list of things that need to be sorted. And while this may be a simple enough task, as it's a quick matter of writing down the names of each of the features on separate index cards, it's important to keep the stack of cards down to a reasonable size so participants in the card-sorting session don't get overwhelmed by the sheer volume of things to organize. If your application has a lot of features, try to organize some of them on your own, or split the work into two sessions so each group can take on a smaller set.
Also, while writing down features on the cards, avoid using keywords in the feature or operation names that imply an organization, like "Insert table" coupled with "Insert form." It will be far too easy for participants to latch onto the term insert and name a menu by that name even if it's not the most appropriate. And avoid using terms that might end up being used as menu, panel, or toolbar names. The whole point of the exercise is to see how users group the features.
Participants in the session should be people who will actually use the application once it's built, as this will help ensure the right people are doing the organizing. This group should be kept small so it doesn't become too difficult for you to keep the session focused on moving forward.
During the session, the only real goal is to get the participants to organize the cards in whatever way they see fit. To facilitate this, the session should begin with a quick explanation of what they'll be doing. Hand them the stack of cards, set down a second stack of blank cards, and instruct the participants to sort the cards into stacks of related groups and write down a name for each group on one of the blank cards.
Your goal as mediator is to keep things moving forward. If the group gets stuck on a certain card or debates at length how to name a certain stack, encourage everyone to move the unnamed cards to a separate stack to be sorted later. Simply flip the proverbial coin to choose possible names for card stacks that don't immediately beg specific names, and write them down as title cards instead of fixating. It's not important that every last detail is worked out, only that some initial impressions are made so you can better determine how users in your target audience associate the different features and operations within the application.
It's important as well to take notes during the session. Try to record the suggestions and confusing points that emerge from discussion during the card sort. These, along with the final stacks of sorted cards, will help you determine how to name and group all kinds of things in your application. Menus and toolbars, for example, can easily be organized according to how users in the session think they go together.
When all the cards have been sorted, thank everyone for their time and take the stacks back to your desk to start sorting out the details.
Yes, that was a very bad pun. Sorry about that.
One thing to note here is that if your application has multiple types of users, each using the application in a different way, you should consider holding card-sorting sessions with groups of users from each type. By doing this you can compare the differences and decide how to accommodate each of the groups in your design.
For more information about card sorting, check out James Robertson's very thorough article "Information Design Using Card Sorting" at www.steptwo.com.au/papers/cardsorting. It's aimed primarily at more typical information architectures, like that of a Web site focused on information rather than interaction, but knowledge you gain from the article can certainly be applied to application design as well.