louisrosenfeld.com logotype

Home > Bloug Archive

Dec 03, 2002: Information Needs Analysis

I occasionally like to ramble on about information needs. This is one of those times, so you've been forewarned.

Each user has a different type of information need depending on what he's trying to find and why he's trying to find it. If we can determine the most common information needs a site's users have, we can select the few best architectural components to address those information needs.

For example, if you are designing a staff directory, you might safely assume that most users are performing known-item searching. The user already knows exactly what she's looking for ("I need Joe's phone number"), she has the terms necessary to articulate that need ("I know Joe's last name is Shmoe; that's what I'll search under"), and she knows that the staff directory exists and that it's the right place to look ("Joe is an employee of the company; where else would I look?"). This type of information need would be best served by employing a search system. On the other hand, most other architectural components (e.g., a table of contents) probably wouldn't help much. So invest your IA resources in developing and maintaining your search system.

Another example: your site's users are often new or infrequent visitors. And perhaps your site's content scope is changing frequently thanks to mergers, spin-offs, and whatnot. So your information architecture probably should be very good at supporting orientation. If that's the case, invest in a table of contents or some other IA component that's effective at orienting users and communicating what content is contained in your site.

I've listed a few types of information needs and supporting IA components below. This isn't intended to be comprehensive by any means; in fact, I'm certain there are other types of needs, not to mention better classifications:

This Information Need... ...is Addressed by this IA Component
Known-item Search system, site index
Exploratory/orientation TOC/site map, guide, top levels of hierarchy
Open-ended Guide, hierarchy, search wizard, easy switching between search and browse, collaborative filtering
Selective research Search system, filtered results through use of search zones
Comprehensive research Search system, expanded results through use of thesaurus

This may all sound obvious, but oddly, there seems to be very little discussion in the IA or broader user experience communities about using information needs analysis as a design tool. That's probably because it's quite difficult to actually determine users' most common needs. Perhaps we could brainstorm some techniques a bit right here on Bloug; here are ones that I've tried or would like to try:

  • Extrapolating information needs from personae and scenarios. A colleague and I worked with an automotive firm that had spent considerable time developing personae and scenarios. So we assumed, right or wrong, that these would provide a picture of common usage patterns. We combed through the descriptions for specific instances of searching and browsing, then abstracted them to match the information need types mentioned above. Not scientific, but there wasn't budget for science...
  • Extrapolating information needs from user interviews or surveys. A slightly more scientific approach, you essentially generalize information needs from users' responses to questions regarding what types of information they want from a particular site.
  • Extrapolating information needs from search logs. Another useful technique if you have the firepower to analyze huge reams of data. A couple of Argus clients' search logs revealed that many users were typing a URL in the search box. If I recall correctly, Keith Instone called this a directional information need, and we made sure that the search system could recognize URLs and redirect users to the appropriate site. Just remember that you're looking at a somewhat lopsided pile of usage data here (just searching, not browsing).

Any other techniques you've tried or think might work? I'm sure a review of the Information Retrieval literature would unearth some, but I don't know who has the time. Maybe some IR god among you could suggest further reading, or better yet do the reading for us and report back here.

A final note: clearly, information needs analysis can be useful in determining which components you should select when designing an information architecture. And selecting the few best architectural components is one of the information architect's ultimate goals. But I don't mean to suggest that information needs analysis is the only way to choose what components should comprise your site's architecture; there are plenty of other factors to keep in mind, ranging from content structure and volume to such harsh business realities as budgetary constraints.

I'd just love to see some more discussion of information needs in the IA community.

email this entry

Comment: Eric Scheid (Dec 3, 2002)

I've riffed on your points already at the IAwiki.

To your three techniques I would add Contextual Inquiry and similar Ethnographic Research techniques. I'd also consider asking the support staff what the FAQ's are. Support staff can often be a wonderful mine of user-research data, since they are on the front line every day interacting with customers/users.

http://www.IAwiki.net/InformationNeeds
http://www.IAwiki.net/ContextualInquiry
http://www.IAwiki.net/EthnographicResearch

Comment: vanderwal (Dec 3, 2002)

I believe there is a semantic twist needed to the terms used here, it seems Lou discussing a *information use needs*, which would drive the *information needs*. This would also drive the need for a third column in Lou's two columnn matrix above. The third column would be *defines this Information Need* and the first two columns would be *Information Use Needs* (or possibly *Information Seeking Approach*) and *is addressed by this IA Component*.

You ask why? Lou states there is an information need, which is actually an element of a users approach to that information and they have an data item or item of information to be used to attract that information onto their screen. Lou outlines the approach needed based on how well defined the information item is to the user as they are approaching the information application. This relationship is defined in the first column. It is this relationship of the information item the user has (or perceives they have) and the information application they are interacting with to draw their perceived desired result to the screen infront of themselves.

The *is Addressed by this IA Component* seems to define the interactive tools that a user interfaces with to get their desired result based on their item of information. This the first two elements in the matrix seem to be rather well defined (a little mulling my provide more to add) and the outlined approaches to gathering requirements for these elements are suitably outlined.

What is missing is a review of the information's structure and supporting elements. This draws on the information's needs that are required to support the users approach to the IA component. A search can be a very broad term of use as it may be a keyword search, full text, index search, etc. Each of these search types have different information needs. A keyword search requires the information element to have metadata assigned to it as the content of the text may not specifically mention the keyword (or key phrase). The title is often extremely important (Google uses the HTML title tag to display in the hyperlink of their returned results) and therefore this may be an information need that is a prerequisite for the IA component to work well when a user approaches with an information use need or the information seeking approach.

The structure of information can be used to augment information retrieval. A site index can be automatically generated from a set of index.html pages sitting in their well thought through directories. This takes understanding of the information use need, the IA Component, which drives the information need (in this case it is a relationship between heirarchial elements representing lower level elements and the heirarchial elements relationship to their parent elements). The information needs required to provide the IA component for a site index may also be a metadata element that defines the relationships of static or dynamic pages thoughout a site. This elements could also be used to drive a page's breadcrumbs if the information needs have been addressed.

This may seem to splinter the information, but thinking though the information needs may also provide efficient methods for information reuse. When I have approached large site or info application development I found it good to know the information needs as well as how much work would be needed to hit the minimum needs to provide the IA components so that the information use needs are addressed properly. Having this information, even in a rough guess will help the client decide how they want to approach the project and have the ability to scope the work.

Comment: James Robertson (Dec 3, 2002)

This is starting to enter the field of "knowledge management", which open up tools such as knowledge and process mapping, and some of the cultural approaches that Eric mentioned.

There is certainly a strong connection between IA, usability and the more practical aspects of KM...

Comment: vanderwal (Dec 3, 2002)

Click-stream analysis along with using session IDs or tracking IP addresses to see if the user jumped from a click path to a site-based search or to an external search (Google). Following just click-streams leaves guess work, but a user leaving the click-stream for search gives a better idea of not only what the user is seeking, but the user's vocabulary.

Having an IP address may also provide the ability to see the enterprise organizations who are seeking information from a site. One project I worked on was building an interface specifically for academia and IP tracking showed us that .edu domains made up more than the minimum usage expected. We were also able to track the Universities and tracked their usage with their expertise in the field of information being offered.


We also looked at the operating system in the site logs and new a large number of users, mostly from academia were using Unix/Linux variants and some Macs. This helped us structure the information offerings so that these user communities would be able to easily use the information. Datasets being downloaded would be a burden to transform if they were in an Excel format, but a comma-separated value could easily be used by the PC world as well as easily used in the xNix and Mac communities.

Comment: Peter Boersma (Dec 4, 2002)

Another way to extrapolate information needs is by looking at (successful) competitors or outside benchmarks. Follow the leader and all :-)

Comment: Rich Wiggins (Dec 4, 2002)

Web log analysis sits right up there with search log analysis. My guess is that it's a more mature field, given mature log analytics products such as Webtrends. I think the idea of comparing Web log info with search log info has a lot of power.

I really like Lou's chart. Let me ask where another kind of search fits in: the user lands on your site because a particular page ranks high in global Google, but it's not a content area that you specialize in. Do you just let the deep link handle itself, or is there a way to capture such accidental slices of popularity?

To understand the many and varied ways folks land on your site, you need to go to the referring search term info out of your Web logs. We want what somebody typed into someone else's search box, not ours.

Comment: PeterV (Dec 4, 2002)

"Do you just let the deep link handle itself, or is there a way to capture such accidental slices of popularity?"

I have that on a website of mine. Check my usage statistics: the term "Betty la Fea" (A Colombian soap opera) is the nr.1 search term people use to get to my site about Colombia (http://poorbuthappy.com/usage/usage_200211.html#TOPSEARCH) and the pages that mention this get lots of traffic, although it is not exactly the focus of the site. The traffic costs me, so my dilemma is: do I want to get rid of these visitors, or can I convert them into useful users (however I define that)?

Comment: ben hyde (Dec 4, 2002)


Your first example seems way too narrow. And in what way do needs correspond to tasks? TA coupled with a persona approach is something that I have found very useful.

So now to the directory example. The idea that you can acurately predict what starting point someone is coming from seems pretty unlikely. This means you are not considering the full range of user 'needs' within a given context.

I can see the benefit of designing for particular existing knowledge or apporaches. But shouldn't this be considered in parrallel rather than in isolation.

The user in the staff directory example may not know the person's name but in fact be looking for someone with a certain job title, responsibility or who works at a particular location. This means the architectural components and the information displayed in the search results may well be just a crucial as the search categories.

Comment: Rich Wiggins (Dec 4, 2002)

Well I think we may be taking Lou's staff directory example a little too literally, but as the search admin for a large midwestern university, I must admit that users do the darndest things, and you can't always predict. If the staff directory search does Soundex (or better) near miss matching AND does Joe versus Joseph, maybe search is all you need. But people often search under a variant of the name and get thwarted. Then they send me email asking why Professor Joe Higgenbotham who did the treatise on nematodes isn't in the directory.

So a drill-down A-Z list of surnames may work better in some cases. If the user knows roughly how to spell the surname they scroll to the spot with the data.

Here's a challenge for all you IA folks, in the spirit of Lou's topic: go to Michigan.gov and find the phone book. I double dare ya.

Comment: Ben HyDe(Sign) (Dec 6, 2002)

I did your test - I found it/them - and in not too many clicks (under contact - quick links) - if that is what I was supposed to find?

Interesting that the search results weren't useful first time around, as I searched for phone book -were you trying to trick us- and got 17990 results and no sign of the directory on the first page - however a search for 'phone directory' worked just fine.

This raises the question of end users terminology and highlights that link importance (i cannot think of a better term) is crucial when displaying results - if the phone directory is commonly searched for / used - then shouldn't it always rank high on the results for a 'phone' search whether accompanied by book or directory?

Does anyone know how many or whether search engines prioritise results offered in relation to general popularity of pages? I know this happens on searches such as the ACM DL and Amazon.

I still feel that a ballance between search and browse is crucial - and that search results need to be presented in such a way as to highlight other options for finding things - ie browsing.

Jared Spool has written alot about why it isn't good to rely on search. And his recent newsletter is about Knowing Your User - which is very akin to Lou's idea of knowling their Needs. Jared argues that you need to consider: intentions, context, knowledge, skills and experience. These types of insights are best discovered from focus groups or talking to people who interact directly with users (sales, support etc.) but the issue is often that these people do not have a say in how services themselves are designed. So to conclude, maybe there is a need for not only participatory design that includes users but that also includes those who know the users (needs n' all).

see: http://www.uie.com/Articles/five_things_to_know.htm

Comment: Lou (Dec 9, 2002)

Well, the conversation has drifted from the original topic a bit, but it's been fun nonetheless.

I agree with the made in some of these postings that we should look at more than just information needs. Most definitely. OTOH, I still feel that this approach is underutilized and merits some additional attention from the IA community.

Comment: Annie Warner (Jun 17, 2003)

Thank-you so much for your article on the web. My tutor insists we research a little into Needs Analysis but I had never heard of it before. I will get back to you after I have studied it it, begining here.

Comment: r h n (Aug 18, 2004)

Thank you for opening up the discussion on information needs and thank you for the explanations.

There seem to be several, perhaps an infinite variety of "information needs", i.e., information needs of children, information needs of scientists, information needs of physically/mentally challenged people, information needs of adults, information needs of students, information needs applicable to cultural/ethnic populations, and son on.

One approach would involve the determination, using all the different research tools: thought experiments, scientific surveys, questionaires, observation & analysis, annecdotal, key informants, depending on the available budget and time, the needs for each segment under study/consideration.

I am sure this is a tedious and labor-intense method, but these studies would lay the basic foundations once published in the various Information Architecture/AI/KM/etc. journals to refer and update with longitudinal studies. Once these fundamental studies are carried out and published then the information solutions (websites, reference services, library programs, virtual information services, etc...) can have an authoritative design and a measurement tool/standard to determine strategies/goals/objectives and to establish how qualitatively/quantitatively are these information needs solutions to be considered effective.

Add a Comment:

Name

Email

URL (optional, but must include http://)

Required: Name, email, and comment.
Want to mention a linked URL? Include http:// before the address.
Want to include bold or italics? Sorry; just use *asterisks* instead.

DAYENU ); } else { // so comments are closed on this entry... print(<<< I_SAID_DAYENU
Comments are now closed for this entry.

Comment spam has forced me to close comment functionality for older entries. However, if you have something vital to add concerning this entry (or its associated comments), please email your sage insights to me (lou [at] louisrosenfeld dot com). I'll make sure your comments are added to the conversation. Sorry for the inconvenience.

I_SAID_DAYENU ); } ?>