Design for Searching and Finding Information
In a previous article I showed a schematic overview of UX Design by Jesse James Garrett. It has two distinctive approaches:
- information oriented – digital products that are hypertext systems to spread knowledge and fulfill information needs,
- task oriented – digital products that are software interfaces for users to perform direct actions and tasks.
Two such different goals require a different design approach as well. It is a mistake to assume that your design process will be the same for an informational system, and for a software application. Of course many digital products contain elements of both search and task, in which case these sub-systems should be designed with their specific goal in mind.
We will look at these two different approaches in two separate blog posts:
- This article covers several elements to think about when designing for finding and retrieving information,
- Designing for understanding (complex) systems covers various considerations for task oriented systems.
Before we dive in, it is important to note that good design will consider many of these elements, regardless of which type of system we are building. The overlap is substantial and the split into two articles needs to be seen from a practical point of view; putting everything in one article would have made that article far too long.
Why do People use the Internet?
The vast majority of people fire up their internet browser with a clear and specific goal in mind.
They use the web to retrieve information. People in general do not (!) use the web for pure entertainment. They have an information need.
Sounds simple enough, but we have to remember that there are many different information needs. And each of these comes with typical information seeking behavior. It is important that we understand both these needs and behaviors, so we can design our products accordingly.
This is one of the main goals of information architecture; to satisfy people’s information seeking needs.
A Quick Example
Let’s look at two different information needs.
- Looking up the phone number of a friend in a directory.
- Finding the best mortgage for your first apartment.
What is the difference between these two?
- The first is a search for something you know is there; the second is a search to learn about a new subject.
- The first has a fixed horizon; the second could have, or could not, who knows?
Your system’s architecture and functionality should be designed with these differences in mind. Different needs lead to different information seeking behavior. Searching for something you know exists is done differently from searching for the unknown.
Recognizing these different needs, behaviors, and their priority for your users is important. It helps you to determine where to invest your efforts and allocate resources as you begin to design your product.
Information Models
There are different models of what happens when people look for information. We love models. When visualized properly models provide insight across different disciplines, such as design, marketing and development, making it easier to get everybody on the same page.
Modeling needs and behaviors forces us to ask questions about what information users want, how much information is enough, and how users interact with that information, the interface, and the architecture.
The 'Too Simple' Model
This is the most commonly used information model and also is the one that almost always causes trouble and is unusable. We would be better of, if we stopped using this model altogether.
Input, output, end of story.
This is a simplistic and dehumanizing model for how people find, retrieve and use information. It treats the user as a system; predictable in behavior, rational in motivation. Nothing could be further from the truth.
Things rarely are this simple. Sure, this model works when:
- Users have a question for which there is a right answer,
- Users know (beforehand) where to find this right answer,
- Users know how to ask the right question,
- Users know how to use the system to ask this right question.
That’s a lot of assumptions.
For starters, people don’t always know what they want. They start by exploring your site, trying to find some sort of information. They just do not know what exactly it is they are looking for. And even if they do, there will be the issue of semantics; how to describe what they want in words the system understands.
People often stop their search for specific information in a state ranging from partial satisfaction to total frustration. Sometimes this is simply due to finding new information that changes what they are looking for altogether.
The “Too Simple” model also completely ignores everything that leads up to the search. It focuses on what happens while the user is interacting with the information architecture. No context, nothing. By oversimplifying the search, this model cedes so many opportunities to understand our users; to get into their heads and observe what goes on while they interact with our systems. Put differently, it completely ignores interaction design.
This model is useless in most cases, as it is built on the misconception that finding information is a straightforward process. Again, nothing could be further from the truth.
Information Needs
When someone visits a website or uses a digital product to find something, what do they really want? The best metaphor I have come across comes from the book “Information Architecture for the Web and Beyond” by Rosenfeld, Moville & Arango. Let’s borrow their fishing analogy:
The Perfect Catch a.k.a. known-item seeking
Sometimes users really are looking for a single correct answer. Like fishing with a pole, they look to hook the perfect fish. The best way is to find a data packed site and look it up. Like the too-simple model: input – output – done!
In this scenario the user knows what he is looking for, what to call it, and where he will find it.
Lobster Trapping a.k.a. exploratory seeking
But other times users are looking for more than a single answer. They don’t really know much about what they are looking for, and aren’t ready to commit retrieving anything more than just a few useful terms, or suggestions of where to learn more. They are not looking for the perfect catch, as they would not know when they had caught it. Instead, they are setting out the equivalent of a lobster trap; they hope that whatever stumbles in will be useful, and if it is, that’s enough.
This scenario is typically open ended, there is no clear expectation of a “correct” answer nor when it is finished.
Indiscriminate driftnetting a.k.a. exhaustive research
And then there are times when users want to leave no stone unturned in their search for information on a topic. This is like catching every fish out there, so they cast their driftnets and drag up everything they can.
To be successful here, the user often has multiple ways to express what he is looking for, and should have the patience to conduct his search using all variations in a systematic way.
I've seen you before, Moby Dick a.k.a. refinding
Finally, there are times the user has found some information they want to keep taps on. They want to be able to find it again quickly.
Bookmarks, apps like Evernote and such are useful tools of that trade.
The above image closely resembles an image from the earlier referenced book by Rosenfeld, Moville & Arango.
These are the four information needs that will cover the majority of your users’ needs. There are other variations of course, but if you consider these, you will be good to go (and doing better than most out there).
Information Seeking Behaviors
Now that we know what the different needs are, we can turn to the how. How do our users find information?
They enter queries into search systems, browse from link to link, scanning page content after page content, and ask other humans questions. These are the three building blocks of information seeking behavior:
- Searching,
- Browsing,
- Asking.
Add to these two other aspects of seeking behavior we need to consider:
- Integration,
- Iteration.
Users integrate more than one building block into a single search session. And they repeat the sequence over and over again to gain insight and reach their final goal; or until the moment they stop their search, successful or not.
To visualize this integrated searching, browsing, and asking process over multiple iterations, I am borrowing another image from the excellent book “Information Architecture for the Web and Beyond”.
This is a perfect example of typical seeking behavior.
An employee is looking for company guidelines on traveling overseas.
- She starts at the intranet portal and finds the Human Resources site.
- At that site she browses the policies pages and searches for “international travel”.
- Without the right answer, she then would send an email to Sue, who is responsible for that policy asking specific questions about his situation.
The information architecture of the intranet has to provide functionality which allows for this process; from broad search to specific data, allowing for fall-back in case the employee is unable to find what she is looking for. The fall-back here being the email address of Sue, regardless of whether the search could have been successful (the searched for information might have been on the international travel page, but our employee missed it).
Here we saw several iterations and we should keep in mind that the information need can change. Probably with each iteration as every single search, browse, question, and interaction with content will have impact on what we are looking for.
Another, and perhaps more realistic, way to look at seeking behavior was developed by Marcia Bates of the University of California. It rarely is a linear process and her “Berry Picking” model represents the messy way our minds work as we look for information.
In this model users start with an information need, formulate an information request (query), and then move in iterations through the system along complex paths, collecting bits of information (the berries) along the way. During this process they modify their request as they learn more about what they need and information is available in the system.
To facilitate Berry Picking you need to look for ways to support moving effortlessly from searching to browsing and vice versa. A common practice on e-commerce sites is the possibility to search within a category users entered through browsing, and allow users to browse categories found through a search.
Final Words
Designing an information architecture that allows users to find what they need in a seamless process, is one of the first important steps we need to take. Knowing and testing how our users go about their business, in all its complicated and unordered ways, is crucial when we want to understand how to develop the right structures and functionality.
Until next time!
