louisrosenfeld.com logotype

Home > Bloug Archive

May 03, 2007: The No-Knead Approach to Information Architecture (#4 of 5)

So far, we've banned the evil term "redesign," and discussed how important it is to have a sense of your site's primary audiences . Now comes the fun part, Step #3: determine each audience's primary tasks and information needs.

Duh.

I realize that this sounds painfully obvious. But can you describe—with even minimal confidence—the major needs that each of your primary audiences wants from your site?

It boggles the mind how few people responsible for web sites and intranets—Web masters, managers, product developers, information architects—have a reasonable answer.

And how many would know whether their sites are successfully addressing those critical needs?

So let's take a crack at this painfully obvious stuff.

I've been spending way too much time thinking about search analytics (although not enough time writing about it, but that's another story). In SA, we spend a lot of time talking about this chart:

Zipf Distribution

In SA, the Zipf Distribution is used to chart search queries in order of frequency (based on volume). The top 10% of all unique queries account for 10% of all searches. The top 20% account for 40% of all searches, and so on. The basic conceit is that our resources go further when they're invested in making the really frequent queries in the "short head" retrieve good stuff. (The other, more esoteric queries make up what's commonly referred to as the "Long Tail".)

But we can also use the Zipf Distribution to understand other user behaviors beyond search. Common navigational paths, as determined from analyzing server logs, chart the same way. So will your content: check your logs and you'll see that a handful of your site's documents get the lion's share of visits, while others are rarely if ever retrieved. A few metadata attributes do the bulk of the work. And so on.

This isn't true only when we look at web users' behaviors collectively. Talk to your company's switchboard operator (if you still have one), or the people who work in the information center or library. Or the security people down in the lobby. They'll tell you that they often answer the same questions over and over again. Life is just like that; we inhabit a Zipfian universe.

If that's true, then a little should always go a long way. In information architecture, we should focus our energies on the major tasks and information needs that users want to achieve on our sites. In fact, we often do that—albeit a bit half-heartedly—when developing personas.

Obvious, but it remains incredibly common for important people associated with our sites to completely lose sight of the "short head" of users' needs. They are preoccupied with boiling the oceans: seduced by redesigns that require ripping out the guts of enterprise applications, touching, skinning, and altering every damned document in every site, thrashing out comprehensive and unmanageable enterprise-wide taxonomies, smashing together whole silos of content, and believing that they can make and should seek to satisfy every user. All while their sites fail to achieve the simple, the required, and the obvious. That's why I'm bringing this up.

What does it take to refocus on each major audience's important tasks and information needs? We can rely on a variety of methods to get us to this point: search analytics, as I've mentioned, but also on analyzing other kinds of logs, such as server logs and generated from other interactions with our customers, like tech support logs. We can also apply qualitative methods here, such as user interviews and contextual inquiry, to generate a sense of what exactly it is that major audiences want.

But this isn't the whole picture. We have to account for the organization's needs too. After all, they're the ones footing the bill. We can divine organizational needs by interviewing decision-makers of all stripes: senior managers, department heads, product managers, and so on. Ask them these questions: "What do you think the major tasks are that each of our major audiences wants to accomplish? What are their major information needs?" Then you can show them just how different their perceptions are from the reality as described by log data and the other sources we mentioned above.

Once you can see these occasionally divergent needs side-by-side, you'll want to negotiate the differences between what users want and what the organization thinks they need. You may not be comfortable playing the role of negotiator, but there's no avoiding it in IA or any other flavor of UX, for that matter. And at least these negotiations take place within a reasonable context, with many of the political goals explicitly balanced by users' needs.

Once you've successfully negotiated these differences, you've arrived at a list that is helpful in two ways: 1) it's not just a collection of needs, but really a list of tactical goals for the site; and 2) each goal can be tested. Now you can go ahead and see how well your site is performing (in deference to our academic model, we're using letter grades here).

When you're all done, here's what you have:

chart of balanced user needs and wants

I hope you'll find this to be a useful diagram. With inputs from user and stakeholder research, this diagram lines up critical needs by audience, and helps you balance users' and the organization's desires. Then it forces the issue of how well your site is performing for each high priority. You identify and focus on the critical stuff, and everything else is icing on the cake: lower and low priority goals that you'll get to if and when you can.

If you get this far, congratulations, but remember that you're not done. The world is always changing, and what users want (and what organizations think they want) is always fluid. Don't see this step as a one-time exercise, but rather an ongoing process, repeated monthly or quarterly, that helps you diagnose problems, fix them, and monitor new challenges as they arise. So now that you've gotten comfortable with being a negotiator, it's time to assume the role of general practitioner, performing regular checkups on your patient.

OK, we'll wrap this up soon with one last posting.

email this entry

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 ); } ?>