The goal of any site is for the right audience to find the right information. But beyond your actual content there are many things that can cause findability issues. These tend to be unanswered questions about your primary audience and whether or not you’re satisfying the need of that audience. Good information architecture can help guide your design decisions so that your users can effectively engage with your content.

Lou Rosenfeld offers up suggestions in his virtual seminar, 8 Better Practices for Great Information Architecture: Closing the Findability Gap. Lou believes information architecture offers long-term strategic value, and is more inclusive than some people may think. There wasn’t enough time to address all of the question during the seminar so Lou joins Adam Churchill to answer the remaining ones for this podcast.

Here’s an excerpt from the podcast.

“…I spent a lot of time talking about the Zipf Distribution, which is basically a rule of many sites that a little goes a long way. Things like, a few of the search queries that people do on your site account for a huge proportion of all search activity. So a handful of queries needs to work well in order for search overall to work pretty well. Or, a handful of your documents are the ones that most people are going to be accessing, or are going to be accessing far more than any of the other documents.

So really not worrying so much about the long tail of the Zipf curve, but the short head. And once you have a sense of what that short head is, you can start working on smaller problems that, when you solve them, go a long way…”

Tune in to the podcast to hear Lou address these questions:

• Are there any special considerations regarding intranets?
• How many audiences can a website reasonably handle?
• Is there a distinction between engagement and involvement?
• Web analytics and UX tell us different things. How should you balance knowing when something is wrong versus why something is wrong?

How do you use information architecture to solve findability issues? Share your thoughts in our comments section.

Recorded: December, 2011
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Adam Churchill: Welcome, everyone, to another episode of the SpoolCast. Lou Rosenfeld recently joined us for a virtual seminar entitled, 8 Better Practices for Great Information Architecture: Closing the Findability Gap. Now, the seminar yielded lots of good questions and comments, and we decided to have a follow-up conversation that we could make available as a podcast for you.

Now, Lou’s seminar spoke to new opportunities for information architects that add significant value to projects. We’re fortunate that Lou gives us a lot of time, and he’s graciously offered to come back and tackle some of the questions that he thought we could re-address from the seminar.

If you didn’t listen to this particular seminar, you can get access to the recording in UIE’s growing User Experience Training Library. There’s presently 80 recorded seminars there, all great topics from speakers like Lou from the world of Experience Design.

I wonder if that’s any coincidence that the two seminars Lou presented for us happened to be numbers 50 and 75 in our arsenal. Nice milestones for us, and with one of our favorite speakers. Hey Lou, welcome back.

Lou Rosenfeld: Thanks, Adam. I guess you’ll get me scheduled for number 100 pretty soon, right?

Adam: That would be awesome.

Lou: Excellent.

Adam: So, Lou, for those that weren’t with us in November for your presentation, can you share an overview with folks?

Lou: Sure thing. This sort of came out of a bit of frustration that I’ve felt the last couple of years that a lot of people see IA in a very limited sense, and don’t see it offering much long-term strategic value. I don’t think anything could be further from the truth.

So what I tried to do was at least map out eight directions that I called “better practices,” because I don’t think there are any such things as best practices in a field where nothing can ever be perfect. You can only make things better. But I laid out eight, and I’ll go through them really quickly right now.

One is just getting better at doing diagnostics, and I spent a lot of time talking about the Zipf Distribution, which is basically a rule of many sites that a little goes a long way. Things like, a few of the search queries that people do on your site account for a huge proportion of all search activity. So a handful of queries needs to work well in order for search overall to work pretty well. Or, a handful of your documents are the ones that most people are going to be accessing, or are going to be accessing far more than any of the other documents.

So really not worrying so much about the long tail of the Zipf curve, but the short head. And once you have a sense of what that short head is, you can start working on smaller problems that, when you solve them, go a long way. And I proposed something of a very simple rinse-and-repeat process for constantly diagnosing small things that have big impacts, and correcting for those and doing those on a regular basis.

That was the first one, maybe the most critical one. The second one, simply having better evidence, more balanced evidence. I trotted out one of my favorite diagrams, Christian Rohrer’s diagram of the landscape of user research, which breaks the methods we all know and love into four quadrants along two axes. One axis around attitudinal behavioral data, and the other around quantitative versus qualitative data.

What I’m simply suggesting is to be very careful not to do all of your research in one of those quadrants, to have balance across those four quadrants so that you have enough different blind men looking at the elephant and trying to get at true insight.

I talked a little bit about advocating on behalf of the long-term and the need to create anchors, things like missions and vision statements and elevator pitches, to counteract what many of us are dealing with in the trenches, which is constantly changing plans and directions, often due to ripple effects from management turnover and just things that are constantly reactive mode. We need anchors to stabilize our work so that our designs don’t go off the tracks and our teams don’t go off the tracks.

The fourth one was some thinking around measuring engagement and really looking at how we might do a better job of developing new metrics and ultimately better and new KPI around things that don’t have to do with clear cut conversions. How might we start thinking about developing metrics around engagement, around authority, around orientation?

Really around the stuff that I call “the metrics of in-between-ness,” the things that are beyond, again, those just sort of basic conversion measurements that we’ve been doing for years. Because there are more to our sites than the conversions. There are all kinds of other things that need to have to happen in order for people to have a good experience.

The next two, the fifth and sixth, are really areas of information architecture especially that people don’t think about and aren’t investing nearly enough, and in which there are fantastic opportunities. Those two areas are better contextual navigation within our deep content, and better search, especially across silos.

A lot of people think of IA as top down navigation. They talk about IA and search, which is wrong. IA includes any kind of finding. So I proposed a bunch of ideas around investing in contextual navigation, specifically things like content or domain modeling, as well as some ideas around improving search, especially taking advantage of opportunities both in how we allow people to enter searches through the search UIs that are involved both initially and through refinement, as well as the design of search results.

And then the last two, seven and eight. Seven was combining design approaches effectively, basically looking at opportunities to have better hybrids of what robots will do for us, things like search engines, that can do certain things really well, and what humans can do for us manually, things like best bet selection, and how you might put these types of things together in more effective ways than we typically do right now.

Finally, the last one, number eight, was around just remembering that things change, and that your design, your information architecture specifically, must respond to those changes. Looking at things like seasonality as a driver for how we present and organize information, how that type of thing can be formed by data. Looking, again, at how things are constantly changing in terms of users’ needs, and being able to respond effectively to those changing needs.

So that’s my nutshell version of those eight better practices for findability.

Adam: I love that concept, the metrics of in-between-ness. That was a great part of the seminar for me. Louise wants to know if you have any special considerations or approaches in regards to this closing the findability gap, in regards to her effort looking at their company-wide Intranet?

Lou: That was a really good question, and I hope I do a better job with it this time. We’ll see. Intranets are kind of an interesting animal in that so much of what they’re there for is to help connect people with expertise and to be part of a broader ecosystem. In other words, most intranets fail because there are easier ways to move information around, primarily things like email and sending documents as attachments, and overriding the hope for benefits of putting a canonical version of any particular document in one place that everyone can find.

Core information architecture is one of the reasons people bypass intranets and move information through other means that are less effective when it comes to things like version control. So they’re a slightly different thing. They’re part of these bigger systems, and there’s also other parts of these environments that go beyond HTML, things like CRM systems and so forth.

So, intranets, still, you’re going to find a lot of the same diagnostics are useful. You’re still going to see a Zipf Distribution for things like what content is being used most frequently. But you’re also going to have to look in other places, like are there certain types of our staff directory or our CRM system that are being used most frequently? Are certain tasks that span those different technologies, and how can we make those bubble up to the surface?

So the same things really apply, except that information architects who work on intranets are even more challenged in terms of integration. It’s not just integrating content, it’s integrating systems that house different types of content. It’s also integrating people and making sure that the systems don’t get in the way of the actual human connection. Because, again, a lot of times people want to find other people in their organization who have some sort of expertise, and that’s the killer app of the intranet.

So, again, I think a lot of the same things apply, but there’s often more silos to deal with, more fragmentation, and that creates just a bunch of new challenges for information architects. Also, a lot of great opportunity. So, if you are confounded and pulling your hair out of your head, I would flip it around and say, “Hey, you’ve got a great opportunity facing you.”

Adam: Kristin wanted to know, how many audiences a website can reasonably handle?

Lou: Well, I wish Kristin was on the phone, because I’d make her define reasonable. Reasonably, I’ll hazard a guess of three to five, and even that might be generous. My thinking goes back to Zipf, again, this idea that maybe there’s one or two audiences that are hugely critical. And then there are secondary audiences, maybe even tertiary that don’t get that same level of treatment, but get some form of treatment. So if you’re an academic website, those audiences might be students, people considering applying and considering being students, and staff and faculty.

So that’s three or maybe four audiences, and you have to really consider what their common needs are for each audience. What does each audience want? What are the tasks they need to accomplish? What are the things they need in terms of information needs that need to be satisfied? That’s sort of the high-level treatment where you might invest a lot of manual effort for each of these audiences.

But then, I think secondary audiences for an academic website might be the media, it might be alumni. It might be academics from other institutions. You may not have the resources to scale up so much manual effort for those folks, but you can still give them maybe a lighter treatment. Maybe less customized information for each audience, but maybe a single page that basically gives the lay of the land of the web environment for each of those audiences.

And then maybe tertiary audiences, I can’t just really think of off the top of my head, but those folks, you don’t do anything for them other than give them the straight robot-handled forms of access. Hey folks, we don’t know who you are. We don’t know if you’re that important, but you can use our search engine and you could use our very basic site hierarchy to navigate the site. Good luck, and let us know if we can help you. So that kind of tiered approach is what I think makes sense.

Now, the math, you know, is it one audience, two audiences that gets that Rolls-Royce treatment, is going to be very much dependent on how many resources you have at your disposal. So it all becomes an issue of scalability. But at least if you tease it into different tiers, now you don’t have to treat every audience the same way and feel the pressure to give every audience the Rolls-Royce treatment.

Adam: Luke wants to know if you draw a distinction between engagement and involvement. In other words, the example he offers up is that, he may interact with a power company’s site very intensely because he’s upset, he’s got no power, but he’s not necessarily engaged. Can you just say a bit about that?

Lou: Well, yeah, I think that’s a great example. I think what I had said in the presentation was, our goal ultimately is to design not experiences, but design for engagement. In other words, to give people an opportunity to engage with us in conversation and dialogue, and to feel ownership of that dialogue. In other words, not have our web environments just be sort of this way to project a one-way monologue to people, but to give them a way to talk with us. So we listen as well as we talk, and as much as we can to give them a sense of ownership about conversation, about the service itself, and what we may be providing.

Luke’s example is great, because it’s like well, my power company makes me angry. So I’m very involved with their website, but not in a positive way. Well, again, I would look at that as an opportunity to create something positive. I know as a retailer at Rosenfeld Media every time we have a negative customers experience, and there’s not that many, but when we do we can usually win people over and give them a sense to at least make them happy, to take lemons and make it into lemonade.

But ultimately, what can we do when we have their attention? Can we help them? Can we give them something? Can we give them something that might give them a reason to come back in a way that makes them feel like they’ve dealt with a human, and they’ve been listened to and that they have certainly a better impression that might pave the way for a future engagement?

The power company, you know, if you look at that example, yes, who would ever want to engage with a power company? Well, most of us probably would. If we have a better sense of being listened to and engaging in a dialogue with the power company, we might be willing to let the power company know that there’s a problem that might be affecting the community, and might be willing to be on the lookout for issues that would be helpful to them.

We might be willing if they give us the opportunity to report on their level of customer service, how helpful, how gruff are the people they send out into the field? What would we like them to do in terms of alternative energy? They may be doing lots of surveys, but what about direct feedback? Hey, I would be willing to put solar cells in my roof, and I would be willing to spend this amount of money to do so. Those are the kinds of conversations that those companies aren’t very good at having, but probably really would benefit from.

So even the power company should be — not can be — but should be designed for engagement. And often a negative interaction might be the doorway to a longer-term and more positive form of engagement.

Adam: Lou, one of the things that came up during the seminar I thought was fairly valuable, I wanted you to say a bit more about it, and it was this. That with web analytics alone, we know something’s not working, but we may not know why. With UX alone, we may know why but not necessarily know whether it’s working or not.

Lou: That’s right. This goes back to the second point I made about doing balanced user research, and having essentially a balanced set of evidence to use to drive your decision making. I mean, ultimately that’s what we do is we’re making decisions and we need evidence to make those decisions well. That’s what design is ultimately about, and when we have a balanced set of inputs, a balanced set of types of research, what that does is, if it’s balanced we not only get a better picture, but the sum is greater than the parts. We get just better insight overall at whatever problem we’re trying to solve, whatever we’re trying to accomplish.

So, I think there’s a lot of interesting dichotomies in the work that’s done inside most organizations that haven’t necessarily put together things like web analytics and user research. In fact, I believe I presented a slide about all those different dichotomies in the presentation people are welcome to look at. But one of them is, what versus why? So here you have all these people in one part of the organization. Maybe in one silo, maybe they’re associated with Omniture, whatever it might be. They’re the web analytics team, whatever you call them. But I have all this really rich stuff that describes what is going on based on behavioral data.

Now, if you’re on the user research team and doing task analysis, which is a totally different thing, might you want to know something about the common information needs that come out of web analytics to influence the type of task analysis work you’re going to pursue? Because that’s expensive work, and it would be really good if you had some foundation that was based on behavioral data to help you shape that agenda for task analysis.

So there’s a nice kind of complementary nature of, hey, you know, we user researchers, we’re really good at figuring out things are they way they are. We can do this sort of attitudinal research. We can talk to people, we can observe them, we can have them think out loud. But what are the good questions that we should be checking out with users in doing those studies? Well, can we go back to the data to help shape that agenda? It’s just, again, one example of how these things can come together so that the sum is greater than the parts.

And there’s a whole host of not only examples, but more importantly, opportunities. I think the organizations that figure out how to combine what are currently siloed and all these organically-evolved pockets of research and put those together in ways that are optimized from making insights are going to ultimately make good decisions. And that’s really what I’m trying to get at there.

Adam: Well, this was awesome, Lou. Thanks for circling back with us.

Lou: My pleasure.

Adam: For those listening in, thanks for your support of the UIE Virtual Seminar Program.

That’s what the legal secretary told me when we were studying her firm’s intranet home page. In fact, the page was pretty sparse in layout. The text was nicely laid out in a readable font, with different weights given to headings and body text. Overall, it was organized and readable. Cluttered just didn’t seem like the right word.

Yet, the legal secretary was quite firm on this. She wasn’t the only one. Half of the firm’s employees we interviewed used the word “clutter” to describe the page that looked anything but cluttered to us.

It might be tempting to rework this home page with more whitespace, more organization, more emphasis on the visual design. However, that wouldn’t have produced any better results.

Over the years, we’ve learned that users have a different meaning of “clutter” than the designers do. It’s not the visual design the users are reacting to. It’s the actual content.

The law firm employees were telling us that the page didn’t have links and resources they needed. The page was full of stuff — mostly things the firm’s marketing group wanted everyone to know — but very little of what was on the page helped the employees do their jobs. Everything they needed was on the intranet, and they knew it, but the home page didn’t lead them to it.

The page was cluttered.

Clutter is what happens when we fill a page with things the user doesn’t care about. Replace the useless stuff with links, copy, and content the users really want, and the page suddenly becomes uncluttered.

Dictionary.com’s definition of Clutter is found on a page, ironically, filled with clutter.

That’s exactly what we did at the law firm. Our design team uncovered those resources the users needed and organized the page to have exactly what the users needed to do their jobs well.

Those users loved the new page. In our evaluations, nobody used the word clutter. They used words like useful, helpful, and awesome.

Here’s the best part: We put the old and new pages side-by-side. The new page definitely had more text, less whitespace, and more dense information design. Yet, when we asked the users to tell us which one was more cluttered, they were unamimous: the old design was the cluttered design.

Are your users complaining about clutter? Maybe you should look at what they actually are seeing.

This is a sample of Lou Rosenfeld’s, Beyond User Research, from the 2011 IA Summit.

UX professionals have made a lot of progress in large organizations. Companies realize the importance of connecting with their users more and more. User research is becoming firmly rooted as companies strive to produce better products and services for their users. But user research itself can be narrow in focus and full of biases. Lou Rosenfeld of Rosenfeld Media, suggests that by breaking down the silos that exist between other research practices, we can create a complementary research experience. This will produce even better analysis and therefore, better products as a whole.

In an attempt to map out organizational structure, Lou offers a set of dichotomies. In terms of research, web analytics folks and UX professionals both bring important insights to the table. But they focus on different things. It’s this separation of insights that lead to the silo effect. Even though these insights would be completely complementary, the cross-pollination that would require this enhancement to the research often is not occurring.

It boils down to the differences in how people think. User experience people tend to shy away from quantitative data and take a more qualitative approach. Neither is a bad approach to take, but the differences between empathetical and analytical thinking, for instance, provide vastly different results.

By combining the efforts of these different practices we can arrive at tremendously useful insights. For example, Lou explains that by adding data to typical personas you can enrich them and enhance the design process. The personas may then align closer to the analytics data simply by adding what they would search for, resulting in a deeper understanding of your users.

Lou is presenting a UIE Virtual Seminar, 8 Better Practices for Great Information Architecture: Closing the Findability Gap on November 3. There are new opportunities for Information Architects to add significant value to projects. There exist new metrics for measuring engagement with your site visitors. These measures will guide you towards design decisions that let your users find what they’re after. Learn more about Lou’s seminar.

This podcast was recorded at the 2011 IA Summit. For details about next year’s summit, visit IAsummit.org.

[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Lou Rosenfeld: We have this fragmentation problem which I’ve already said things live in silos not just content but now insights that ought to help us figure out what to do with content and other design issues.

We’ve got differentiation. We don’t really understand what that CRM stuff is about. I’ve never seen one of those things before. Yet, I sense it might be good to look at if I’m doing any kind of design work.

And then most importantly this combinatorial issue, the synthesis of all those insights into something that approaches an organizational brain, an organizational or institutional way to make smart design decisions.

So that’s kind of what we’re facing. In my limited experience with this, I’ve tried to map it and I think a lot of us are pretty good at doing this sort of mapping of an organization and how it works. It’s almost like the same sort of urge that we use, that got us into doing things like site maps and wire frames.

I came up with a bunch of dichotomies. I couldn’t map it so let me run through some of these dichotomies. What I’m finding is, there’s a lot of people who are really good at figuring out what is going on and there’s a lot of other people often not the same that are really good at figuring out why those things are going on.

So for example, people draw on information that comes from analytics research, the quantitative data. They may learn something really interesting. But it’s all behavioral stuff. They don’t really know what was going on in a user’s head.

They can draw up and infer interesting hypothesis but they can’t test those hypothesis. That’s something that people who are really good at doing user studies for example like a lot of us, are really good at.

We, on the other hand, aren’t always so good at knowing the right questions to ask. And I’m kind of going to start focusing a bit on two areas of practice, web analytics and user research but these are the ones I know best.

This is really even more complex when you introduce all the other perspectives but let me just focus on these two. A lot of web analytics people can tell you what is going on. They can’t tell you why. A lot of us can tell you why things are the way they are but we don’t know what to test necessarily.

We don’t have the right questions to explore without the data to help us figure that out. There’s a whole kind of a breakdown between qualitative and quantitative people. I love this diagram with the two brains in there. I wish I had come up with it.

I’m not sure how well you can read it but numbers versus emotion, analysis versus empathy, the brain versus binky? Is that what it is? So you know, we have different ways of looking at problems, different ways we try to solve problems and we often are comfortable with different types of data or evidence to help us solve those problems or at least to help us understand what the problems might be.

So that’s a big breakdown. A lot of what I’m saying right now, I’m trying to make a point and by making that point, I’m going to over generalize quite a bit but I think a lot of us kind of would fall into one of these categories.

I don’t know that anyone is equally comfortable with qualitative and quantitative data. I’ve met very few people that seemed to be able to do that. In many cases, I think some of us make for qualitative studies because we’re really uncomfortable with quantitative data or vice versa. It’s just the nature of how our minds work and what we’re comfortable with.

A lot of us are in the business of making sure our organizations reached their goals. Web analytics people as an example, they express goals as KPI, things that are measurable, key performance indicators.

A lot of us in this room have been trained to think more on behalf of the user and what their goals are and how to identify them and make sure they’re using them. Sometimes those things are very easy to mesh together especially in commerce sites for example. Often, they’re not.

We have to resolve these things but we’re not always so good at it because usually, whoever is making the decision has a bias in one direction or the other. In effect they’re thinking with half a brain.

I think a lot of us are really good at measuring the world that we know. Certainly, again, on the analytics side, you start with your KPI based on metrics and you say, “I’m going to look at all that data and figure out whether we’re performing against the goals that we’ve set out for ourselves as an organization.

Are we doing well? Are we not doing well? Contrast that with looking at data for patterns, looking at data for things to emerge that were unexpected. That kind of emergent data analysis is really looking to learn about the world we don’t know and therefore we don’t know how to measure.

And then yet another, I’m sure there are more dichotomies. There’s a breakdown between the comfort level and understanding of statistical data versus descriptive data and you could have people who make very strong arguments, garbage in, garbage out in both cases and they’d both be right probably in both cases.

But that’s not how they see it. Usually, we have a bias toward one direction or another. We like one, we like the other, usually not both but they tell us very interesting, but different things that often fit together nicely, as we’ll see.

I’ve tried to, like I say here, reduce this to a very over generalized, over simplified set of dichotomies that I’ve just gone through. This is just a summary of what those are. And this is just for two areas. This is just for web analytics and user experience.

But if you look at these, I hope what you’re starting to see is not just the differences but the fact that they come together quite nicely, that they’re very complimentary. That’s where that’s where combinatorial effect that’s coming in where the insights that one has fit quite nicely with the insights of the other.

Now, I can’t map this. It’s just not in my wheelhouse but I bet some of you could. What I’m really hopeful for is that someone like Alex Osterwalder who wrote the Business Model Generation book. Is anyone familiar with it? Fantastic.

He actually created and published it with a bunch of people, created a whole new business model around publishing just to do one book. Amazing. But he did a whole bunch of mapping of essentially business models. It’s over simplified but damn it, it’s useful.

We need something like that to take all these types of insights and put them together in a way that would be really useful for us especially making design decisions. So without a map, why bother even trying?

You know, if we can’t map, this is really a hard problem, what’s the value of jumping in? Well, for one, we can really, really learn quite a bit from each other’s data, right? So let me give you an example.

This is one of my favorite things in the world. It’s a little bit of site search analytics code little snippet of stuff. All you really need to know is that if you look at it, the orange stuff like “vincense plate” is what was searched.

There are a few other things that you can maybe figure out, an IP address so you know who it is, the time-date stamps, you know when it happened. The zero next to the last bit of information is how many search results there were.

Now, look at another line. Same time, roughly two seconds later, same IP address. Now they’re searching license plate and I got, I think it’s 146 results. Interesting, what’s going on here? Maybe they spelled it right but well what happens next?

Oh, it’s a different user and they’re searching on a real mouthful. This is a state government site and this user was searching that site for Regional Transportation Governance Commission. People search things that long? They know what those things are even called? Do you know what government agencies are called?

As you’re looking through this, I bet you each one of you are already putting on your analysis hats and saying, “You know, obviously typos are an issue. How would I fix that problem? Maybe I would turn on the spell check on the search engine.”

Now did they get what they wanted when they were searching on the license plate or not? You don’t know. Is that a common thing that people search and what about this mouthful in the last line?

Basically, each one of us should probably have a whole bunch of different ways of looking at this data and we would start ferrying very different hypothesis, just a couple of examples.

I think a lot of people from, to over generalized analytics community, would be wondering things like are we converting on license plate renewals. A lot of other people like me would be saying, “What are people searching for the most? Is it license plate coming up a lot?”

If so, are we giving that information very easily, are we presenting it on the main page so they can renew their license plate easily and so forth. So we look at the same data, tiny little snippet of data and we probably are all starting to come up with different conclusions or at least different hypothesis and thinking about what we do next differently.

What the next action would be could be very different if you’re looking at this as an interaction designer versus an analytics person versus a content strategist. Another way we can really benefit each other is by helping improve each other’s design tools.

So I grabbed an Adaptive Path persona and you know again, I love site search analytics but there are lots of other types of analytics out there that you can do this with but I threw some site search analytics data in there.

So you got your typical persona stuff, right? And then, why don’t we add some data? Wouldn’t that enrich in a new way “what does Steven search?” Now I can actually go to my analytics people and say I could use some of that data.

In fact, maybe my personas might match up well with your audience segments. Maybe you can start putting these things together in some new and far more powerful ways. We can really help tell each other’s stories.

I love this example. Adaptive Path again, Jeff Veen and a team were working on a product to make analytics data more easy to understand. I think it’s called Measure Map. Is that right anyone? Measure Map.

Google liked it. In fact, Google basically bought Measure Map but they really bought the team. And they’d already purchased the analytics application that they were going to make into Google Analytics but they wanted that team to work on it, to help tell the story of the data in a way that maybe someone from the web analytics world wouldn’t have thought.

A good starting point is crucial. It sets the tone for everything that comes after. All too often, projects are unsuccessful or labor through growing pains because the importance of this starting point was overlooked. When done right, the kickoff to a project will leave the team energized, inspired, and engaged.

Kevin believes that kickoff meetings are the time to identify business strategy as well as company culture. It’s also important to assess any risks associated with the project in the kickoff meeting. Getting as many people involved at the onset of a project will help make the connection between project goals and the brand of the organization. It ensures everyone is on the same page.

Kevin Hoffman is User Experience Director at Happy Cog. Kevin will be presenting a full-day workshop at the User Interface 16 Conference, November 7-9 in Boston. For more details about Kevin’s and the other 7 workshops, visit UIConf.com.

Here’s an excerpt from the podcast.

“…The kickoff meeting gives you a great opportunity to establish a shared vocabulary, some shared vision and really, more than anything, establish culture and your working culture between two or more organizations. By establishing that culture, people are much less likely to become interrupters and more likely to become information resources.

For internal teams, projects tend to run usually a lot longer than they do with consulting projects. So you might be doing a redesign for your main website or for an intranet that could take 18 months or two years, depending on the size and complexity of the organization and the project. And after about six months of anything people get tired.

But if you have a good kickoff meeting where you’re establishing your expectation of energy and kind of being really open with a broad set of stakeholders in your organization in a more workshop collaborative format, it creates a positive energy that people will remember…”

Tune into the podcast to hear Kevin address these questions:

• Do you get others from the organization involved in the meeting than just the core design team?
• Is the meeting as much setting the course for the project as establishing constraints and boundaries?
• What is the goal in establishing a shared vocabulary?
• How long is your typical project kickoff?
• How much work is done prior to the kickoff meeting?
• What can I do to establish a vocabulary and vision if I’m not the one leading the meeting?

Do you have experience facilitating project kickoff meetings? Share your thoughts in our comments section.

Recorded: July, 2011
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Jared Spool: Hello everyone. Welcome to another episode of the SpoolCast. I’m Jared Spool. I’m your cruise director for the day.

I am very excited to be talking today to Kevin Hoffman who is the Experience Director at Happy Cog and going to be speaking at the User Interface 16 Conference in November of this year, 2011, on creating great kickoff meetings for projects. I’m very happy to be able to talk about that with Kevin today.

Kevin, how are you doing?

Kevin Hoffman: I’m doing well. Thanks for inviting me to hang out this morning.

Jared: Well thank you for joining me and hanging out here.

So, kickoff meetings are this thing that we don’t really think about. You know, when we’re putting together this massive project and we’re thinking about what the design could be and the delivery dates and all this stuff, it’s almost the last thing we think about.

But it turns out that if we don’t do that right, if we don’t get that project started off on the right foot, awful things can happen, right?

Kevin: Yeah, I think so. I think it’s been my experience on both internal teams and doing consulting projects that people put about as much thought into the kickoff meeting as it takes to create that little line on a Gantt chart that shows in a project plan where it’s going to happen.

They’ll decide who needs to be there, but it usually ends up being not dissimilar to an Alcoholics Anonymous meeting where you go around the table and just kind of introduce yourself and your role. If it’s an external consultant, usually you’re introducing people to yourself for the first time, so there may even be some basic orientation like “who is our company?” and “why are we here?” and “who hired you?”

The kind of problems that that will create for a consultant or a third party is that kind of the classic swoop and poop. Where high level stakeholders will be coming in later on in the project because they didn’t know who you were, they didn’t happen to know that this was going on.

The kickoff meeting gives you a great opportunity to establish a lot of shared vocabulary, some shared vision and really, more than anything, establish culture and kind of your working culture between two or more organizations, as the case may be. By establishing that culture, people are much less likely to become interrupters and more likely to become information resources.

As I alluded to before for internal teams, I have a long background working on internal teams in higher ed and non-profits. And the risk for internal teams, I think a kickoff meeting can establish kind of an energy baseline.

For internal teams projects tend to run usually a lot longer than they do with consulting projects. So you might be doing a redesign for your main website or for an intranet that could take 18 months or two years, depending on the size and complexity of the organization and the project. And after about six months of anything people get tired.

But if you have a good kickoff meeting where you’re establishing your expectation of energy and kind of being really open with a broad set of stakeholders in your organization in a more workshop collaborative format. It just kind of creates a positive energy that people will remember.

So a month later when they think of something that’s relevant to the project, they’re going to be excited to talk to you about it.

Jared: So I like this idea of establishing an energy baseline, I mean, just getting everything going on this high energy element, getting people excited.

And the people we’re talking about here are not just the folks who are going to be up to their elbows in pixels and wireframes, you know, the core design team. We’re talking about getting stakeholders and various other folks from the organization involved, right?

Kevin: Yeah, absolutely. I think really … I’ve never seen it work exactly this way, but it kind of, sort of follows this pattern. Where, at Happy Cog, if we’ll do our kickoffs correctly and we have enough time to plan them, which isn’t always the case but it’s usually case, the level of engagement in our partner organizations tends to follow a reverse pyramid. In that, the longer the project goes, the fewer people we’re directly corresponding with.

We want to correspond with a decent number of people at the beginning of a project especially in a meeting, not just via one-on-one interviews or phone conference interviews. We really want to kickoff the project with that first meeting with as many people as possible.

Because we’ve found that as open and honest as people are willing to be our direct contacts, there’s always a larger picture of an organization. That you can only get from talking to as many different appendages on that elephant, as opposed to just kind of taking the elephant’s mouth’s word for it. And having that better picture allows us to identify risks for a project early on, address those risks. And, if we need to, occasionally be really frank about what we may not be able to do, as opposed to it coming up three months down the line.

Jared: I think that’s really neat.

What you’re doing here is this combination of sort of setting out a picture of where you think you want the project to go. While at the same time trying to reveal as many of the constraints that that project’s going to be under. And also set some of the boundaries as to, you know, where things start to get into science fiction and unrealistic expectations.

Kevin: Yeah, absolutely. The other thing I feel like it’s really important to convey in a kickoff meeting, and the way we do workshops generally is that, if we’re taking the time to do a workshop, there are two things that I want to make sure are clear to the participants.

Number one, we’ve taken the time to prepare ourselves for the work at hand. So we don’t like to kick off a project without doing a lot of research. If all we can do is landscape research and just really look at the design problem and how different people are solving it, that’s great. But more than often what we prefer to do is do a lot of one-on-one interviews with stakeholders and some light audience research before we go into that meeting.

So we’re coming into that workshop with a more sophisticated idea of the design problem at hand. But we’re not coming in with the solution. We’re inviting all of these people to this kickoff meeting because we think we have a good idea as to what the problems are. But we really want to collaborate with you and work together to develop the framework for starting to build that solution.

And in a best case scenario for us, usually working with smaller organizations, we’ve seen that actually lead to design decisions during the first meeting. Where, you know, we’ve decided, for example, page priority for a particular page on the site or a particular e-commerce process, where in that kickoff meeting we’ve said, “You know what? This is the primary design goal of this page and these are the three or four most important kinds of content that are going to support it.” And that’s the best case scenario.

But in the worst case scenario, with larger clients if we have a kickoff meeting with, let’s say, 80 or 90 participants which has happened from time to time, that sets kind of a project awareness in a larger organization of 500 people or more, sometimes a lot more.

And that really pays off down the line in terms of people looking forward to the next meeting that they’re going to have with you. And ending up with a really good meeting structure for complex, longer projects where people expect they’re going to have a chance to have their voice heard. And it’s not like they’re fighting to participate in the project.

In fact if you think about it, a big kickoff meeting is great. In that if you open it up, if you kind of have a philosophy of anybody can attend this meeting if they want to, they just have to let us know who they are and it kind of eliminates that, “You didn’t talk to me” vibe.

Jared: I want to talk about for a second something you said at the very beginning which was, this helps the team sort of establish a shared vocabulary and a shared vision. And I’m curious if you could say a little bit more about that shared vocabulary.

Kevin: Sure. We’ve worked with lots of different companies. Sometimes they’re non-profits and smaller, sometimes they’re non-profits and larger. Sometimes they’re for profits and very large. And sometimes they’re startups where they have a decent investment and it’s a small group of people.

What I have found more recently, or I’ve observed more recently, and this is kind of an ongoing observation, is, if I was to generalize. The larger an organization is, seemingly the less time it has to actually remember and pronounce out loud particular phrases and repeated words. And the more things become acronyms.

So, recently we pitched some work to a very well known computer manufacturer and electronics retailer. And in the correspondence alone, I had to sit down with our business development person every couple of minutes and say, “I don’t know what this word is. I don’t know what these three letters mean.”

There was just all kinds of internal jargon that was preventing me from being able to understand what the strategic request was. Because every time I would hit a term that was unique to that culture, I would hit a brick wall and have to say, “I don’t understand what this really means.” And, therefore, how it might affect the strategy I would recommend for this particular project.

So by getting in a room together and being very open and unafraid to say, “Hold on, does everybody know what XYZ is? We keep talking about XYZ.” Nine times out of ten it’s something you already know or it’s something you knew but just forgot. But I would say 10 percent of the time there are some pretty complex ideas that get almost compacted for consumption so that people in an organization can be more efficient.

And when you’re joining that organization, it’s a lot better to collaborate on that learning than it is to send an email requesting a glossary. Because I would say 99 percent of the time those glossaries don’t exist. Those cultures just continue to develop without documentation.

And to really get up to speed and work at the level that our clients expect us to, we need to know what all those things mean. So when I say shared vocabulary, it’s a little bit more on the consulting side, getting up to speed on the vocabulary of the client.

But at the same time, we try to construct activities in a workshop format that allow us to give them kind of a micro taste of what our process is. And what kind of things we’re going to show them over the life of the project. And how we expect feedback to come back to us so that we can use it to continue to iterate on whatever we’re doing.

Jared: So, is some of the vocabulary that you’re also establishing around things like what differentiates a good outcome from a bad outcome? I mean, is there a terminology that sometimes gets created in these workshop meetings that then gets referenced throughout the rest of the project?

Kevin: Yeah, absolutely. We pay close attention to everybody but particularly high level stakeholders. So that, when we deliver strategic recommendations in the form of a brief or in the form of an early prototype, we can reference concepts, specific words, specific ideas that came up in that kickoff meeting.

So there’s a fluid feeling to the process, not that we’re just throwing things over a cubicle wall or across the Basecamp wires as the case may be. We’re actually having a conversation for the duration of the project, and that kickoff meeting is the introductory hello in that conversation. It’s the first date.

In any great relationship, a personal relationship you want to have a first date, ideally, where you feel like you made a connection and you want to build on that connection. So to just throw away your first date as a, “Oh well, we’ve already agreed that we’re going to work together. So let’s just get lunch”, you know, is kind of a waste of everyone’s time and energy.

Jared: And you mentioned also this idea of a shared vision. And I guess some of this we sort of have been not really talking about this. You and I have talked about it before, but we haven’t talked about it here which is, this is not just, you know, a 45 minute meeting that you get together with, right? This is an event that goes on for a considerable amount of time. How long is your typical kickoff workshop?

Kevin: I would say it varies based on the duration of the project.

So if we’re doing a project that exceeds a year, a yearlong or 18 month or two year engagement, our kickoffs generally fall between a full day and two days. If we’re doing projects that are six to nine months a minimum of four hours.

Jared: So you’ve got these things that are four hours to a couple of days and so in this real work is getting done. This isn’t, like you said, this isn’t like an alcoholics anonymous meeting where everyone goes around the room saying, “Hi, I’m Jared and I’ve been at this company for 12 years.” Everyone goes, “Hi Jared.” You guys roll up your sleeves and you do stuff.

Kevin: Yeah. We try to come to come into a kickoff meeting armed with a significant amount of insight into the client’s perspective on the problem and a significant amount of insight into the market that the problem is designed to address. And that includes the audiences that something is intended to reach, but also it includes competitors and even things that are going on in design solutions that are analogous to what we see the problem as being and what our clients are telling us the problem is.

Many, many times it’s been my experience that if you come to a kickoff meeting with something that has nothing to do with the vertical that the clients in. So ,if they’re in widgets and you come in with something going on in cupcake sales that’s completely analogous and makes total sense, that people will be very responsive to that. And they’ll feel like you’ve thought about the problem.

So then during the meeting, the work that we do is we actually say, “So how do we make cupcake sales work for widgets? How do we actually do that?” And that usually takes the form of a lot of sketching and prototyping. It takes the form of a lot of frank discussion about prioritization and understanding the dualities of particular things that people are asking for? One thing I’ve heard a lot of recently is, “We want it to be really easy. We want people to be able to do things in one click and we want it to be obvious.”

“But we also want them to do a lot of cross sell and up sell and make sure they can find any product they need.” And at their core those two things could be done in ways that they would be at odds with each other. So really working on articulating conceptually how we can make those two things happen at the same time. And lots of other design goals and various user interface challenges that we want to hit, we want to address those as well. One example that I can think of from a kickoff meeting not too long ago probably in the last nine months.

There was a workshop that we did about search user interface. So spending a good hour in small groups thinking about what the current search metrics were telling the client, what their referral search metrics were telling the client, not just internal but the referrals as well. And then what they actually wanted people to do as a result of a search. Not just being able to find the thing that they need. Like, I need product X I want to type it into the box and it shows up, but what do they want people to do with product X after that? And how do we design search and search results to balance those user goals with the real business needs that the client had.

Jared: So, this is really interesting to me. So one of the things that I hear you saying is that there is a lot of work that you do before the kickoff. So the kickoff isn’t the very start of the project. It’s not the moment that everybody starts the billable hour clock or you know, gets the first say, “That’s where we started.” You’ve done a whole bunch of work to get into this kickoff meeting.

Kevin: Yeah. Generally during the sales process we try to establish the expectation with clients that before we meet with you we’re going to want to do research and that may take on average about two weeks. Usually we do it in less. But from the time we sign a contract to a kickoff meeting two weeks is reasonable. Now we have I would say a third of the time at Happy Cog and I’m sure this happens on internal teams and with other consultants. You get clients who have a check ready to go and they just want to start tomorrow.

And from time to time we do do that and we try to have enough of a playbook of kickoff activities in our pocket that if we have to jump into a productive meeting quickly with a client where we don’t have a lot of in depth understanding of the problem. We spend a day reading as much as we can and we tend to do a lot more listening in those situations. But most of the time we will spend just to throw out a random number, a minimum of a dozen one hour interviews with key stakeholders. And from time to time upwards of 30 and once or twice many more than that.

Just learning about a client’s organization, learning about the design problem, learning about people’s expectations especially if it’s someone who isn’t necessarily our point of contact but somebody who has a very different perspective on why this project is happening. We want to hear all those things up front. So we can start to connect some dots and identify some of that science fiction as you said.

Jared: And one of the outcomes of this you mentioned was the shared vision. This is something that I’ve noticed with teams that we work with that haven’t done a good job of this upfront. You start talking to people, “So what is this thing going to be like” and everybody is working on a different project. So it sounds like part of your goal with these kickoff meetings is to get everybody walking out of the room believing that you’re all working on the same thing.

Kevin: That would be the best case scenario and I don’t think that’s impossible. I do think that a more realistic way to put it is I want everybody walking out of that room expecting to see a vision in the very near future. And there shouldn’t be anything in the vision that we articulate that doesn’t feel like news to them, like, “I’ve never heard about this before.”

So for example, in a kickoff meeting we might spend some time talking about how social networks or you know, things like Facebook might integrate into a particular experience and why it makes sense or it doesn’t make sense. We won’t articulate a detailed vision for the social component of a project probably until the brief, but they know its coming and they’re ready to read it and tell us what they think.

Jared: OK. So a lot of folks who are listening are probably not in a situation where they can just call a meeting that gets all the stakeholders together and make all this work. They probably work for someone else who is probably leading these kickoff meetings. What advice would you give them for getting those meetings to be productive so you can get that shared vocabulary, you can get that shared vision started and start bringing that out.

Kevin: This is something I don’t think is only related to kickoff meetings. I think there’s a lot of really good techniques and approaches that apply to any kind of meeting situation where things are not going the way you would like them to go. So one of the things that I’ve said in the past and I will still say is that the more you educate yourself about any type of approach for designing human interaction, and I mean in person human interaction not electronic human interaction, in a meeting.

If you know of good ways to build consensus, if you know of good ways to explore a design problem, if you know of good ways to kind of iterate in a discussion or ways to facilitate large numbers of people getting a chance to get their voices heard. The more you know those techniques the more you can rely on them when things don’t go the way you need them to go.

So for example if you’re in a meeting where you feel like the point is to generate ideas and the quantity of ideas is very low, you’re not trying to evaluate quality. If you have sticky notes and sharpies in the room, in your conference room in advance and you’re familiar with KJ technique or other techniques, you can always suggest those as a participant. Like let’s just try this for five or 10 minutes and introduce things that maybe get people out of their comfort zone in such a way that it forces them to refocus their attention on the task at hand, and not just, “Ah, I’m stuck in another meeting” or “I’m stuck in this kickoff meeting.”

So I think that’s the first thing is knowing what some of the things that you’re trying to get out of a kickoff meeting are. Whether it’s problem exploration or consensus or problem definition, and then knowing what the best ways to design human interaction to get at those things are and suggesting them when you need to. The second thing I would say is if you’re a participant and you’re not a leader, you have the right to demand agendas and demand clear agendas.

And if it’s not clear enough or it doesn’t address what you need it to address, you have the right to suggest agendas and say, “I need this item added to this meeting.” Now, inevitably what that leads to more meetings and I realize that. But at the same time if you don’t suggest it you’re really spending just as much time not doing the work that you need to do and not getting the things addressed that you need addressed in order to move forward.

So, you know, I would say sometimes it’s OK to have more meetings or an additional followup meeting for a kickoff meeting as long as you’re getting stuff addressed the way it needs to be addressed. An example of that would be the way normally in which high detailed technical discussions happen with our kickoff meetings. We like to have our developers and our technical experts at our full kickoff meetings which is an expense.

It’s a real expense to have a developer in a room for eight hours focusing on UI and project strategy. But then if we can take someone who’s got that level of knowledge or has been a part of that discussion and then immediately afterwards put them in a smaller discussion that focuses on server architecture and CMS choices and other highly technical issues, our projects have a lot more of singular vision.

And in the future when I’m doing IA work or UI work and I say to a developer, “You know, this is how we need press releases to function and this is how date search works.” Not only do I know the technical things that they have thought about in advance, what systems and what limitations of those systems are, but also they know why it’s important. And that makes that kind of gap that sometimes happens between concept and production much, much smaller.

Jared: Plus they can come back and actually suggest things up that you may have not thought of.

Kevin: Exactly. And that happens a lot with us.

Jared: It feels like that these meetings are very productive and that to some extent there’s this kickoff workshop but it’s just the start of something that goes on for a while. And they’re mini little workshops that happen throughout the project that feed off of that and keep going, right?

Kevin: Yeah. Absolutely. With our larger clients we actually have kickoff by phase. So we have project kickoff, we have IA kickoff, we have visual design kickoff, and we have development kickoff. And we tailor those meeting attendee lists directly towards the amount of cohesion we detect at that point.

So a lot of times our development kickoffs if we know there’s an internal development team, we’ll just invite them to our offices and really go through every single design page by page and say how would we code this? You know? And collaboratively sketch out how the line by line code is going to fall into place. Now I don’t attend all of those meetings. I attend some of them when I can but it’s the same workshop methodology applied to coding and we apply it to visual design and Brand and we apply it to IA but it works at all levels of the project.

Jared: So in essence here what we’re talking about is developing just a great set of facilitation skills and tricks that let you make a group of people in the room be really productive in terms of moving the project forward and getting everybody’s sort of, point of view into the design and the designs direction into the folks.

Kevin: Yeah. Exactly.

Jared: That sounds incredibly useful. Well this has been really, really interesting and I can’t wait for your workshop which is going to be at the User Interface 16 Conference in November in Boston. To our audience if you’re interested in attending that you can get more information on Kevin’s workshop at the UI16 conference site which is cleverly called UI Conf, U-I-C-O-N-F.com. I highly recommend you check that out. Kevin thank you so much for taking time to talk with me today about this.

Kevin: It was my pleasure.

Jared: Excellent. And I want to thank our audience for listening once again and as always I want to thank them for encouraging our behavior. Take care and we’ll talk to you in another Spoolcast.

Subscribe to our podcast via

Information architecture exists in all levels of design, from the most abstract to the most concrete. Everything from thinking about the content of the site, right down to embedding a navigation strategy, determines the structure of a website. Once that structure is in place, it begins to shape and guide the design process.

Dan Brown is one of the Principals of EightShapes. Through his experience, he has developed a set of principles for information architecture. In this podcast, Dan joins Adam Churchill to address the questions he didn’t have time to answer during his virtual seminar, 5 Simple Principles for Improving Your Information Architecture.

Here’s an excerpt from the podcast.

“…Back when information architecture was first forming, one of the things, I think we all pretty much agreed on is that, any given web page on a website should answer two questions, maybe three questions for users. “Where am I in the whole scheme of things?” “Where can I go from here?” and maybe, “What’s the overall range of things that are available to me?”

I think one of the reasons why I appreciated this question is I think the nature of that question is changing. It becomes less about “where am I,” in relation to the overall website. It may be too big to really get our arms around and maybe more about “where am I,” in the local neighborhood of content that we have. I’ve been thinking about the relationship between navigational structures and an urban environment.

What’s interesting to me about urban environments is that they have this fractal organization where, as you zoom in, you see the same patterns over and over and over again, but at a smaller and smaller scale.

And I think we can say the same thing about navigation, especially as websites become much, much bigger that it’s difficult to represent the full range of information that’s on a website. But at the same time, we can represent the range of information in this neighborhood, so to speak. I think it’s important to answer those questions at a neighborhood level.

Let’s say we’re on a high tech website like an IBM or an SAP. We’ve done work with very similar clients where they deal with lots, and lots, and lots of different kinds of high tech products and services. It’s really hard to represent the breadth of the things that they sell on their marketing websites on a single web page.

Again, this trend to streamline the amount of content, to try and limit the number of choices, really gets us to say, when someone lands on a page about a particular product, let’s give them a sense of, what other products are nearby. Use that product as a filter for the whole range of products and really zero in our neighborhood based on that.

My partner, Nathan, calls this a greater emphasis on local. So focusing more on what’s immediately relevant to me because I’m looking at this page. We shouldn’t deny the user escape hatches. We shouldn’t deny the user, in a sense, an airport or a train station that would take them to a whole other city if they wanted to.

So to be more concrete about that metaphor, I need to convey to users that there are other places to go on this website. But the bulk of my navigation is really going to focus on what’s immediately relevant to the content that I’m looking at right now…”

In the podcast, Dan answers these additional questions:

• How does information architecture interact with content strategy?
• What are some examples of real-time user driven navigation systems?
• What are the key characteristics of a “fat footer”?
• What are some examples of exemplars on an intranet?

As always, we welcome your thoughts and questions. Please share with us in our comments section.

The Most Valuable UX Person In The World

She builds her wireframes with real wire from ancient hand-smelted Ukranian steel.
Her worst personas could kick the ass of your best personas.
His pattern library is now in the Library of Congress.
When she explains good design visuals, the only thing Edward Tufte can add is “What she said.”
He’s organized his wine cellar in order of awesome.
Wikileaks is ready to release her sketchbooks just because they’re cool.
He only sketches on the front of the napkin.
He built the world’s biggest web site, using only his left hand.
Last season’s American Idol featured her concept maps.
His research finds customers desire to research his behavior.
He is the only person Don Norman agrees with.
She makes her own icons out of straw.
Software bugs specifically ask for her to fix them.
He defined the damn thing, then moved on.
Her study participants screen themselves. Out.
Her interactions are the basis for everyone else’s designs.
Scalpers sell tickets to his project kickoff meetings.
He is already coding in HTML6. And has been for a decade.

They are the most valuable UX person in the world.
“Design well, my friend.”

What would you add to this list? Leave your own ideas of the Most Valuable UX Person In The World in the comments. I’ll be sprinkling your best suggestions through out my presentation, giving you full credit.

Oh, by the way, the early bird price for the Summit ends this Friday, February 18. Sign up here. I’d love to see you there.

Subscribe to our podcast via

When approaching your information architecture, you’ll realize most sets of content can be organized in more than one way. You need to figure out which works best for your audience, your content, and your project’s goal. There are many approaches to choose from—alphabetic, geographic, format, organizational structure, task, audience, subject/topic—just to name a few. In her UIE Virtual Seminar, Organization Schemes for Web Content, Donna shares the most popular approaches, and offers tips on when and how to use each.

Donna’s a freelance information architect, interaction designer and writer, and happens to be one of our favorites in all of those categories. She is the author of two fabulous books: Card Sorting from Rosenfeld Media, and more recently A Practical Guide to Information Architecture, part of the Five Simple Steps series, which takes her seminar’s topic even further.

Here’s an excerpt from the podcast.

“…Sometimes with the information architecture work coming up with the categories and the concept and like what schemes are you going to use and things is relatively easy. Sometimes the real trick is coming up with the words that you are going to use to describe them so the labels.

And this could be really tricky. When somebody approaches your staff and they got something in their head and they are looking for it on screen we need to make a connection with what they have in their head and what they are saying. So, we really need to make sure we understand the terminology our users use and make sure that is available to them.

Said like that, it sounds not too hard, you do some user research, you understand what your users say, and you make sure you use those labels.

The trick with that and boy this can be hard is that often users use terminology that might be out of date. So in Australia the thing you get at the end of the tax year from your employer that then you use to do tax stuff is called I think it’s called now “pay as you go certificate.”

However, for years, it was called a group certificate. It has not been called for, oh man, at least 15 years I suspect but people still use the word group certificate.

So people will use old terminology, they will use the accurate terminology and if you try to use that in an interface people who prepare the content and who know the most about the content [laughter] will have kittens and validly because language is all about trying to be fairly privies so were communicating well with each other.

So, people call things particular things so that you communicate an idea. We definitely do not want to use terminology that users use if that terminology is inaccurate because people who do know it will go, ‘what?’ and you just never win that war with your content office because it is wrong.

The thing we really need to do is build bridge between those two things. So, if you got something that leads straight forward you can use the user terminology. But, if you got something a bit more complex, sometimes scientific, we’ve got to bridge between them…”

If you thought that was interesting, you’ll also hear Donna address these questions.

• Do you always start an IA by doing a card sort first? How strictly do you adhere to what the users suggest in a card sort?
• How do you test a scheme once you hit the magic point?
• With a very large site which includes a wide variety of topics, how would it be best to test that scheme?
• How do you deal with competing or multiple schemes on the same site?
• What are some of the best practices for naming tasks so that users can recognize them easily?

As always, we welcome your thoughts in our comments section.

From our research in what makes up the most successful teams, it turns out they are both right. And they are both wrong.

A team with three people, each of whom has basic skills in visual design, information architecture, and content design, will produce about the same results as a three-person team where there’s a specialist for each area. But the teams that do the best have three individuals, each of whom have advanced skills in all three areas.

The implications of this are clear: if you want to create a best-of-breed team, you need to constantly be raising the skills and capabilities of every team member in the critical design areas. Specializing in three areas is much more valuable than specializing in one.

In this issue of UIEtips, we revisit an article from 2009. In the article, I discuss the interplay that happens in-between visual design, information architecture, and content design. I talk about how the areas interact and how to ensure you’re creating the best designs. I hope you’ll enjoy it.

Read the article, Information Interplay: Visual Design, Information Architecture, and Content.

By the way, if you’re looking to advance your skill set, you should attend this November’s User Interface Conference. Some of the full-day workshops include visual design, designing with scenarios, and content strategy. Review the all the workshops at UICONF.com.

What are you doing to boost your skills in these three areas? We’d love to hear from you. Share your experiences below.

Explore the 8 workshops offered at this year’s conference . Register for UI15 by October 8 with promotion code BLOGPOST and get $400 off.

How we present our information is critical, yet it’s something we haven’t discussed as frequently as we should. Often we’re trying to fit our information into formats that don’t work effectively. All too often we let the underlying technology, such as our content management system, dictate how we present our information to the user. Yet we have control over these things and we should use it.

In this week’s UIEtips, we’ve turned to our favorite information architect, Donna Spencer. She’s written a great article on the different schemes for presenting information, such as when it’s instructional, geographical, or time-based. You’re sure to find great inspiration in her classifications—an idea so perfect I’m envious I didn’t come up with it first.

Read the article Classification Schemes—and When to Use Them

If you find Donna’s article as interesting as I did, then you’ll want to join me for her UIE Virtual Seminar on 9/16. She’ll dive deep into this topic, showing exactly how to create the most effective pages based on the underlying nature of the information. This seminar will likely be one of the best of the year, so don’t miss it. Get more information on Donna’s webinar, Organization Schemes.

Have you come up with your classifications for your pages? What’s worked? What challenges have you encountered? We’d love to hear your thoughts below.

Your site’s search engine produces all sorts of useful information. Spending time with your site’s query data—data that is semantically rich—will help you answer questions about your users’ behavior and intent. You’re likely to learn some unanticipated lessons about your site.

Why spend time with your search log’s data? It will give you more usable content, improved search engine performance, as well as better navigation and metadata. Your users will achieve more on your site. You’ll sell more, engage more, and reduce frustration.

Lou Rosenfeld, who helped establish the field of information architecture, will show you how to take advantage of your site’s query data, data that’s sitting on your server right now. He’ll show you how to set up and run simple reports and queries to get you started towards better dialogue with your customers.

Do you spend time on your site’s search analytics? Maybe you use Google analytics or some other tool? What sort of time does it require? Other resources? Share your experiences below.

Join us January 12 for our next webinar: Leveraging Search & Discovery Patterns For Great Online Experiences, with Peter Morville and Mark Burrell.

The abundance and variety of search implementations present a challenge to designers: How do we leverage the behaviors our users are developing to ensure they find the content they’re seeking? By understanding how people interact with search implementations, we can create effective designs that deliver great experiences for both searching and discovering.

We couldn’t have timed this seminar better. In just a few weeks, Peter Morville will put his new book, Search Patterns, to press. And Mark Burrell and his team at Endeca have been working hard to release their new UI Design Pattern Library for Search & Discovery. So, this is the perfect time to talk about how to leverage patterns for better search designs.

This seminar is perfect for you, if you’re working on providing the best experience with your site’s search implementation. Bring your entire team and schedule extra time to talk about what you’ve learned—you’ll want to implement Peter and Mark’s ideas right away.

This winter, Peter’s new book, Search Patterns, published by O’Reilly, will hit the stores. But you won’t have to buy it, because as soon as it comes off the press, we’ll send you a copy—just because you attended this seminar.

Thanks to Peter, Mark, and the great folks at Endeca, we can include this must-have book. We’ve seen an early draft and we’re amazed by Peter’s talent to explain these topics so clearly. The beautiful full-color illustrations and screen shots don’t hurt either.

Register your team today, and reserve your copy of Search Patterns.

Do you use design patterns? What questions do you have about them? Where do you go, or where would you go to find them? Share your thoughts and experiences below.

On January 7 Peter Morville will discuss Search Design Patterns, and in the same session, Mark Burrell will tell you how to then use them.

Later in the month, on January 28, Steve Portigal will present to you his thoughts on studying your users in their own context, Ethnography.

During last year’s UIE Roadshow, our audiences couldn’t get enough on the topic of personas. So, on February 18, we’ve asked Tamara Adlin to talk about The Power of Ad-hoc Personas. Personas can be your ticket to lasting organizational clarity… and it doesn’t take a ton of costly research.

With his book, Prototyping: A Practitioner’s Guide just hitting the bookstore shelves, Todd Zaki Warfel will help you flesh out your design ideas, test your assumptions, and gather real-time feedback from users on March 29.

In the Spring, look for Kristina Halvorson to help you with your content strategy and Louis Rosenfeld to dive deep on Search Analytics. And there is much more in the works.

Until December 3, you can still sign your team up for the UIE Virtual Seminar Subscription programs . Not only is it a tremendous savings, but you get the benefit of lifetime access to each recording and the ease of registering and paying just one time.

We also plan to unveil our plan for our User Experience Training Library. Believe it or not, there is a method to our madness.

Have you ever attended a UIE Virtual Seminar? What do you like best about them? How has your team maximized what it gets out of these learning events? Share your thoughts and experiences below.

Once they made it to the page with their content, they still struggled. The navigation links and categories were so unclearly written that users weren’t at all sure where to click. They had to work very hard just to figure out what content was available to them on the site.

The content was disorganized, confusing, and lethargic. Fortunately, we knew exactly who to turn to discuss and solve these types of problems, world renowned information architect, Donna Spencer.

Back in August 2008, I interviewed Donna. In our conversation, Donna and I discuss how the best information architects successfully tackle specific content challenges. Donna shares the essential skills separating the best information architects from the rest of the pack. I think you’ll really enjoy her insights.

Read the article – Four Essential Skills for Information Architects: An Interview with Donna Spencer

Last year, Donna presented an outstanding workshop at the User Interface Conference, Information Architecture Essentials. It was ranked so highly, we decided to bring it back for the User Interface 14 conference. It’s a great place to learn what it takes to become a great information architect and I highly suggest you check out the session.

How have you tackled your site content challenges? In your experience, what skills do the best information architects possess? Share your thoughts and experiences below.

Subscribe to our podcast via

Donna Spencer is our long-time, go-to expert on the topic of Information Architecture. We’re happy to bring her stateside again for the upcoming User Interface 14 conference. Recently, I spoke with her, all the way from Australia, in advance of her trip to Boston.

I asked Donna, what happens when, one day, you’re asked into the boss’s office and they drop “the web site” and “information architecture” into your lap? Regardless of your experience, where do you begin? Donna says your first question should be, “Why do we bother to have a web site in the first place?” “What’s its purpose?” She says if you don’t get this out of the way first, you’ll run up against it when you’re further along the trail and it won’t be easy to deal with.

One strategy Donna likes is to work backwards. Start with what should not be on the site. Sometimes pruning your unnecessary or no longer timely content is an effective way of honing the site. You should ask, “What’s the value of this content? Is this still relevant?” Before you can answer this for certain, you need to research your users’ needs thoroughly. Along with establishing the site’s purpose, knowing your users is the most important step to begin with. These two items will work hand in hand.

I asked Donna, once you have these established, should we just dive right into the homepage and start making changes? Generally, the answer is no. A few initial homepage tweaks aren’t always bad, especially if you can get some quick wins there. Hopefully your research has revealed the site sections in most need of assistance. Starting there will often be productive. You should most likely start with the content pages, where more people enter your site and where they spend most of their time. Be sure that your content pages work for their specific content, as all your content will not likely be all cookie-cutter. Generally, Donna shies away from using Lorem Ipsum text for content page designs. Also, if you know your customers don’t generally begin on the homepage, don’t create your navigation by starting with the homepage.

Your goal should be to get something informed in front of people quickly. At some point you’ll need to take what you know and create a first draft. You’ll have to make some of it up. Don’t expect it to be 100% right. Check it against your research, show it to people within the organization, and tweak. Show it to users and see if it functions well. The good and bad should become apparent once you put it through these paces.

These points are of course just a few of the highlights from our conversation. Please join us for the complete discussion in the podcast. If you found this useful, you’ll likely also be interested in Donna’s full-day workshop at UI14, Information Architecture Essentials, Best Practices for Organizing Your Site’s Content, which was UI13′s highest-rated workshop, newly revised and updated. You won’t want to miss it.

Have you had the task of redesigning your site’s IA just dropped in your lap out of the blue? Where would or did you start? Let us know in the comments!

Subscribe to our podcast via

A few weeks back we held a UIE Virtual Seminar with Pete Bell and Daniel Tunkelang of Endeca. These guys are the experts we go to when talking about designing for facets.  As always, we had a number of excellent questions from the live audience that we couldn’t attend to during the seminar, so I got together with Pete and Daniel to record this podcast and cover a number of those remaining questions.

If you didn’t attend the live seminar, and are interested in how to make the jump from a standard on-site search to faceted search, then you’ll still enjoy this podcast. If you find yourself wanting more afterward, don’t forget you can still purchase a recording of the session for another 90 minutes of Faceted Search.

During the podcast, Adam asked Pete and Daniel to dig into these questions:

• Should we show counts for each facet? What about when using multiple selection?
• Can you elaborate on the mixing and matching of precision and recall results to construct facets?
• Is there a best practice for deselecting facets?
• Most search interfaces assume a flat list of results. What happens when you mix up different types of results, and how would you distribute them across a page?

Tune in to hear more about designing for facets. Still have questions? Start the discussion in our comments, below.

I also like to tinker with recipes, experiment, or even make one up from scratch. Sometimes I find inspiration for a dish at a restaurant, or from a bottle of sauce that I find at Trader Joe’s. This is when I really explore all my options with the ingredients I have on hand. I create my own recipe and cooking process. I test out a bunch of ingredients, and see how the flavors blend together. If it doesn’t work, I make up a new process and recipe next time.

It’s not much different when it comes to creating an information architecture. There are lots of steps, variables and so-called ingredients that goes into an information architecture. You may be looking for a set process to follow, but often times there isn’t one. You just have to make it up as you go. And sometimes it turns out more complicated than you thought.

In today’s UIEtips, our good friend and IA expert, Donna Spencer describes some of the steps she goes through when creating an Information Architecture from scratch. You may want to try her process and experiment with it the next time you need to create an information architecture.

Last year, Donna dazzled everyone at the UI13 conference, so we asked her to come back and do another session at this year’s UI14 conference in November. Learn more about Donna’s workshop, Information Architecture Essentials.

What’s your process when creating an information architecture? We’d love to hear your thoughts below.

There’s an on-going debate in the design community: are teams better off with generalists or specialists? Those taking the generalist side argue that a breadth of abilities helps more. On the specialists’ side, they claim it is the depth of specific abilities delivering the benefit.

From our research in what makes up the most successful teams, it turns out they are both right. And they are both wrong.

A team with three people, each of whom has basic skills in visual design, information architecture, and content design, will produce about the same results as a three-person team where there’s a specialist for each area. But the teams that do the best have three individuals, each of whom have advanced skills in all three areas.

The implications of this are clear: if you want to create a best-of-breed team, you need to constantly be raising the skills and capabilities of every team member in the critical design areas. Specializing in three areas is much more valuable than specializing in one.

In this issue of UIEtips, I discuss the interplay that happens between visual design, information architecture, and content design. I talk about how the areas interact and how to ensure you’re creating the best designs. I hope you’ll enjoy the article.

By the way, it’s no accident that this November’s User Interface Conference has full-day workshops on visual design, information architecture, and content design. We recognize these are critical skills for every team, so we made sure we found the best experts to show you what it takes to succeed. You’ll want to bring your entire team. And if you register by Friday, August 28, you’ll get the lowest conference rate available.

What are you doing to boost your skills in these three areas? We’d love to hear from you. Share your experiences below.

People come to your site to get the information they need, by exploring, discovering, and making comparisons. You want them to successfully sift through all of your content, quickly and effectively. Faceted search delivers on that promise, in spades, but not without good planning and a great strategy.

Pete and Daniel will show you before-and-after looks at e-commerce, media, corporate, and intranets sites. They will teach you the essentials you need to launch your own faceted search system and
discuss the pitfalls you’ll want to prepare for.

Faceted Search: Designing Your Content, Navigation, and User Interface
with Pete Bell & Daniel Tunkelang of Endeca
Thursday August 20, 2009, 1:30pm ET
90-minute online presentation
Register to join us on August 20, watch Pete’s preview, or learn more details here.

Special Offer – Be one of the first to get Daniel Tunkelang’s new book, Faceted Search (published by Morgan and Claypool) for free when you register for this UIE Virtual Seminar. Choose from book or PDF version. Details to follow once you register for the UIE Virtual Seminar. Read an excerpt from the book here.

If you’re knee-deep in implementation, or working with folks who are designing for facets, be sure to set time aside for this presentation. And remember to look out for your free book after the presentation!

In advance of the presentation, we’d love to hear from you. Is your organization considering the move to faceted search? What will you do differently? We’d love to hear your thoughts, questions, and concerns. Please share your thoughts below.

Users arrive at your web site with the simple goal to find something that’s important to them. If they find it, whether they search or not, they’ll be happy. When they don’t find it, frustration follows.

Teams often turn to a sophisticated built-in Search capability to help their users find what they seek. However our research has shown that technological magic isn’t going to make the users successful. Instead, it’s a simple understanding of what the users are seeking and how they look at it. We’ve put together the next UIE Virtual Seminar to address this Search issue.

Be prepared to see how Search fits into your site in an entirely new way. Not only will you come away with solid insights from the most up-to-date research, you’ll be chomping at the bit to start making improvements right away. And you’ll be on your way to the world of User Happiness.

UIE Virtual Seminar
Search, Scent, and the Happiness of Pursuit
with Jared M. Spool
Thursday July 9, 2009, 1:30pm ET
90-minute online presentation

Read more about the Search, Scent, and the Happiness of Pursuit, or see the great preview Jared put together, to help you understand what to expect out of this seminar.

In advance of the presentation, we’d love to hear from you. What does your team struggle with when designing for Search? What type of feedback do you get from your users on how well they accomplish their goals on your site? What does a successful visit mean? We’d love to hear your thoughts, questions, and concerns. Please share your thoughts below.

You won’t find this to be any more true than in the design of effective search results pages. Search results look easy. After all, the engine has done all the heavy lifting. It’s taken the user’s query and scoured through the millions of bits of data to narrow the results down to a presentable set. All you have to do now is just display the results, right?

Well, after watching hundreds of users try to accomplish their goals with hundreds of web sites, we can now say, without any hesitation, that it’s not easy to produce a great search results page. In fact, we’re confident that it really takes a lot of hard work and skill to make something that will create a delightful experience for your users.

In today’s UIEtips, we look back at an article originally published a year ago, Producing Great Search Results: Harder than It Looks – part 1. Fortunately, having now watched all of these users, we’ve seen some really interesting patterns in how the most effective search results pages pull it off. And, over the next two weeks, we’ll share those with you.

Read my article, Producing Great Search Results: Harder Than It Looks, Part 1.

If you’re looking for ways to improve search on your web site for your users, then you’ll want to attend the next UIE Virtual Seminar that I’m presenting: Search, Scent and the Pursuit of User Happiness. In
this seminar, I’ll share some of Search’s best-kept secrets such as: a hidden resource on your server that shows you exactly how to make search more effective, and why focusing on “searchers” is a
design strategy that gets teams into trouble. Learn More.

Have you been working on your search results pages? Have you noticed design patterns that have made your site more effective? We want to hear about your experience. Share your thoughts with us below.

(I once bumped into the editor of my favorite magazine and told him his publication lived on the back of my toilet. His response? ”That’s the highest praise you can ever give a magazine editor! Thank you! You’ve made my day.”)

While it’s great to always have something to read nearby, finding a specific item is close to impossible. There’s no order or organization that even comes close to making anything easy to find. Not ideal for someone who has made their living helping people create usable information resources, eh?

Now, imagine if every other asset in the house (such as clothing, dishes, or financial records) was equally as randomly distributed. The house would grind to a halt.

Yet many organizations find themselves almost in that situation daily. Every week, we hear from clients who have Intranets where every user complains how hard it is to find the things they need to do their job.

Enter the taxonomy. Once you start to organize the information, you need to identify the right way to classify and store that information. And taxonomies go well beyond just the categories on a web site. Done well, they become a tool that you can use repeatedly to structure and optimize almost every business practice.

In today’s UIEtips, we have an article about one such application: using a taxonomy to create faceted navigation. Stephanie Lemieux,from Earley & Associates, shares her tips on what facets are and how teams can implement them effectively. If you’ve been wondering about this guided approach to navigation, this article is a must read.

By the way, we’re very excited about Stephanie Lemieux and Seth Earley’s upcoming UIE Virtual Seminar, New Ways to Think About Taxonomy: The Role of Taxonomies in Your Organization. This is our first seminar on this critical topic — a must for anyone who needs to improve the way their business is managing their critical information assets. Space is limited so register early for the May 7 seminar.

Have you implemented faceted navigation in your web site? What challenges did you run into? Share your experiences below.

UIE Virtual Seminar
New Ways to Think about Taxonomy:
The Role of Taxonomies in Your Organization
May 7, 2009, 1:30pm ET
90-minute online presentation

We’ve asked Seth Earley and Stephanie Lemieux, experts in creating and maintaining sophisticated taxonomies, to broaden your thinking about how a taxonomy can make your life easier, whether you’re designing a public-facing web site or a large-scale intranet. In this 90-minute online session, you’ll see detailed examples of taxonomy applications and how to leverage key design principles across your organization. Stephanie and Seth will provide a better understanding of your own taxonomy and the navigation of your information. You’ll get your content management system under control and improve your search results.

To help you understand what to expect out of this seminar, Seth & Stephanie put together a great preview for you:

When people disagree, it’s often because they think I’m suggesting that we stop putting breadcrumbs in our designs. I’m not suggesting this at all.

I’ve defined a design cop-out as something that happens when the designers focus on treating a symptom instead of addressing the root problem. A cop-out is a red flag that should be raised in the design process, to ask the question, “is there a better way to solve the problem?”

At doteduguru.com, blogger Michael Fienen wrote a thoughtful rebuttal to my article with many of the questions I often get when I start talking about my thoughts on Breadcrumbs. Responding to Michael’s points makes for a nice way to talk about these issues, so I thought I’d take some time to do that.

Surfacing the Content

In the original article, I said:

The idea behind how breadcrumbs should be used is simple: the user ignores them until they get to a page that isn’t quite what they wanted. They discover the trail of links and click on the one most likely to contain the correct path to what they were originally seeking.

To which Michael responded:

I think [this idea] is patently incorrect. A user doesn’t necessarily click on a bread crumb because they think it will take them somewhere better or put them on a correct path, nor is there any reason to believe they are used only by lost visitors in the first place. They click them so that they can surface up in a web site and potentially begin navigating anew.

Micahael’s not the first to suggest this. Many information architects I’ve talked to hold this, as we see it, common misconception: breadcrumbs are not only a loss-recovery mechanism—they also serve as a tool for “surfacing the content” of the site.

What’s interesting is when we’ve studied users, both in the lab and in the wild, we almost never saw them interested in “surfacing the content” or learning more about the site. Sure, they want to find the content they desire. If the target content is on more than one page, then they need to get to the subsequent pages. But beyond the user’s explicit target content, we never see them show any interest in the other available content on the site.

Since our early studies on the web, more than 12 years ago, we noticed that users are always on specific missions when they come to sites. With only one exception, users never visit a site “just to see what it has.” (The one exception? Web designers.) They always have a mission:

• Buy a new winter coat and accessories
• Find out what my portfolio is worth
• See if my favorite blogger has posted anything new
• Figure out a nice gift for my niece even though I have no idea what 15-year-olds want these days

Even the last one, where the user can’t describe the outcome, is not about the site. It’s about their niece’s gift. That user (like every other user) would want to surface all the content related to their goal, but will show no interest in content that’s unrelated. Only designers are interested in seeing what’s on a site.

In our studies, almost 94% of quests on web sites have a single objective. When the user reaches the target page, they’ve accomplished their goal. (Or, at least the “finding” portion of the goal. There still may be transactional component, such as purchasing.)

So, in 94% of the tasks, if the user turns to the breadcrumbs, it’s likely because they couldn’t find their target page and are lost. That leaves at most 6% where the user completes their initial objective and needs to start on a subsequent objective: “Ok, I’ve bought the down jacket. Now I’d like a matching hat, scarf, and gloves to complete the outfit.”

Michael’s argument is even if multi-objective quests happen infrequently, the breadcrumbs still serve a useful purpose, revealing the rest of the content to the user:

Assuming you have taken the slightest modicum of care with building bread crumbs, users will recognize them as a reflection of the hierarchy of your site’s information architecture, making them a tool that users have no reason to ignore if they are viewed as an aid to going where they want to go.

But that’s the point: users don’t care about the hierarchy of the site. The thousands of users we’ve observed for the last 12+ years clearly tell us that users don’t care how the site is constructed. Users only care how to get from they page they are current at to the page containing the content they seek. Even with repeated use, they’d prefer that each site visit just have clear scent. Memorizing the nooks and crannies of an information architecture is not their desired outcome.

Secondary Navigation

Michael agrees with this statement from my original article:

We’re recommending that when teams see users needing breadcrumbs, they look for other holistic design solutions. They’ll need to watch users and see the circumstances leading up to how the need arises. In almost all cases, they’ll find a better way to solve the problem than traditional breadcrumbs.

He goes on to say:

The key to successful bread crumbs is that they should be a secondary navigational tool. But, I would argue that people don’t use them because they need them, they use them because they see them as a means to get to where they want to go. As far as the user is concerned, that might be a quick link, an A to Z index, a menu, or a bread crumb (and all of these, minus menus, are generally secondary tools). The thing is most users neither know these terms nor care about them. All they care about is “I click here and go where I want.”

Michael is correct that users don’t distinguish between what he calls secondary navigation and the other types. The idea he proposes, “I click here and go where I want,” is a basic notion behind thescent of information theory: if the target content gives off good scent, users will click on it.

Let’s return to our down-jacket purchaser, now looking for matching accessories. If that user’s trigger words (such as “scarf” or “hat”) appear in the quick link, A-to-Z index, or breadcrumbs (Michael’s secondary navigation tools), then all is well.

Yet, on many sites, it’s dumb luck if the site designers have included the trigger words in those tools. In most cases, the designer hasn’t researched the specific trigger words users will want. Instead, they produce a set of generic terms (“accessories” or “outerwear”, for example) that may or may not resonate with the user.

So, I’d go further to say that all the secondary tools that Michael mentions are also cop-outs: fixing symptoms (in this case, providing a standardized navigation element) instead of the users specific problem (getting match accessories). (I wrote how sitemaps, which are parent to A-to-Z indexes, are also cop-outs in another article.) If I asked any designer worth their weight in salt to design a way for someone who just picked the down jacket to find the desired matching products, I’m betting, of all the design alternatives, Michael’s list would be the last choices.

Michael continues,

I agree with Jared that given perfect IA, smart menus, and intelligent visitors, bread crumbs are a waste of time. In reality, few people run sites that function in such a static bubble that one person has control over every facet of how information is disseminated. [...] It’s like saying “In a perfect country, we wouldn’t need laws to punish robbers, because no one would steal from each other.” The reality is, people do steal. That doesn’t mean we shouldn’t strive to stop them, and shouldn’t minimize the problem, but you still must address the issue. So what do we do? We create a ton of secondary navigational elements, build them nicely into our layout, and let the user decide how they want to combine them to go where they need.

In the stealing analogy, it would make sense to look at the economic conditions driving people to stealing. Solve those and the robberies diminish. Focus only on punishment and you end up spending your resources building more prisons indefinitely.

I’d say the same is true for breadcrumbs. Users don’t want choices in their navigational tools. They want clear scent to the content. It’s the designer’s responsibility to provide that. Anything else is just a cop-out.

Breadcrumbs are Simple to Implement

One of the most common objections to my argument is “breadcrumbs are so simple to implement that there is no harm to just doing it.”

Unfortunately, this isn’t true. On a site of any decent size (greater than 500 pages), breadcrumbs become very difficult to implement well.

Often, in an attempt to make life easier, the designers use the category hierarchy as the breadcrumb links. On the surface, this sounds like a good idea. After all, if the categories are well thought out, then they should work in breadcrumbs as well as anywhere else.

Alas, that isn’t the case. Breadcrumbs stand by themselves as solo links. The categories are usually created to be shown as a collection. A category may have a clear meaning when shown alongside its siblings, but is often baffling when shown alone.

Take this example from Michael’s post – the breadcrumbs from NewEgg.com:

It’s not clear what the siblings are. I’m betting most folks would be surprised to find “Networking”, “PCs & Laptops”, and “Apple” to be listed as siblings to “Computer Hardware”, for example. Arriving at links that would describe the entire category well are difficult and usually require more than one or two words. That’s where it becomes difficult to implement breadcrumbs.

Throwing the Baby Out

As I’ve said before, I’m not suggesting that designers stop implementing them. I’m just trying to prevent the knee-jerk reaction of always including them under some misguided notion that they always improve the site.

In the best case scenario, they take no effort (as in automatically compiled by the CMS) and are ignored by users—thus are no harm done. But, that’s rare and unlikely for most situations.

Good design understands why every pixel is in the design. The designer knows how every element is directly serving the user in each instance. Automatic design (“every page needs breadcrumbs at the top, whether we have evidence it helps or not”) rarely accomplishes this.

But, here’s the rub: In the end, it doesn’t matter what I say. It only matters what happens with your users on your site. If Michael’s observations of his users shows that breadcrumbs are the most useful way for them to achieve their objectives, then I think his site should have breadcrumbs—cop-out or not. (And I’d like to learn more about his situation, because I’m always interested in proving my theories wrong.)

Does your site need breadcrumbs? The only way to know is to watch users. It’s simple, really. When we see someone click on one, we stop them and ask what they’re hoping to accomplish. That gives us a use case to work with. If the use cases point to a breadcrumb element being the best solution, then we go ahead and make that work.

Some find my labeling specific elements (like breadcrumbs) as cop-outs is harsh. But, that’s the point. Had I said, “breadcrumbs might not help as much as you think”, you probably wouldn’t have given this topic as much thought.

My purpose is to get you to think twice about using them. If I’ve made you seriously question your usage of them, then I’ll sleep well.

The same is true of the article topic in this week’s issue of UIEtips, Design cop-out #2: Breadcrumbs. Like site maps, breadcrumbs are hard to do well. And they are also a treatment of the symptom, with the real problem that the user is on the wrong page to begin with. Work to ensure the only place users end up is on the right page, and you’ll no longer need to provide breadcrumbs to rescue them.

Read the article – Design Cop-out #2: Breadcrumbs

Information architecture — organizing the site’s content to make things easy to find — is just one of the full-day, in-depth seminar topics we’ll be covering at the User Interface 13 Conference, October 13-16, in Cambridge, MA. If you want to learn state-of-the-art techniques from the world’s most renowned experts in design and usability, this is the place you need to be.

What are your thoughts about breadcrumbs, site maps, and other design cop outs? How have you tackled the key challenges in your site’s information architecture? We’d love to hear your thoughts.
Leave us a comment below.

The problem comes when the patches become, in our minds, mainstream functionality. We call these design cop-outs — when designers patch the symptoms instead of addressing the core problems.

Design cop-outs come in many different flavors. For example, you might let users choose options instead of designing it for them. Sure, some personalization is probably OK, but why should the user decide between a “minimized database” or “maximized for search”? How would the user know any better than the design team what is appropriate?

This is the cop-out: instead of doing the research to determine what will best serve the users, the team opted to leave the finishing touches to the user. In turn, the user is wholly unequipped to make the right decision and becomes frustrated because they are being asked.

In this issue of UIEtips, we explore another common cop-out: the site map. Sure, site maps seem like a useful tool. (After all, the site map is an invaluable developer tool for tracking the entirety of the site.) But, for users, it can become a catch-all for content the team doesn’t know how to organize.

Read the article: Site Maps: An Information Architecture Cop-Out

Thinking about organizing your site’s content is the domain of information architecture. At this October’s User Interface 13 Conference, we’ve invited Donna (Maurer) Spencer — world renowned expert in information architecture — to give a full-day, in-depth seminar to get you started on this all important topic.

What has your team done about your site map? Have you discovered it’s an essential part of your site? Or are you trying to reduce it? Share your thoughts and experiences below.

The Scent of a Web Page: The Five Types of Navigation Pages
Date: July 17th, 2008 — 1pm ET / Noon CT / 11am MT / 10am PT

You work hard providing top-notch content on your site. Will your users find it? If they don’t find it, all that effort is for nothing. What can you do to guarantee that users find the content they’ve come
looking for?

In July’s UIE Virtual Seminar, I’ll present our most up-to-the-minute research on how users navigate sites. You will learn best practices for designing the different types of navigation pages, including the Home Page and Content Pages.

You’ll come away from this seminar understanding why trigger words are critical to users successfully finding their content, why the best sites prevent users from using Search, how exposing a site’s hierarchy can increase the success of the user, and how designing longer pages helps users find what they seek.

You can read the full seminar details here.

Brian Christiansen and I recorded a special episode comprised entirely of questions from our customers. Last week, we held the UIE Virtual Seminar: The Scent of Information: Getting Users to Their Content. During the seminar, we received far more questions than time would allow answering. As is tradition, we put together this follow-up podcast to answer even more of your excellent questions.

In this episode, we discussed where you can find your users’ trigger words, talked about our 7-12 word link recommendation, discussed if you should replace your home page with your site map, and shared some examples of sites that handle long links well. Tune in to hear these and the answers to other questions from our seminar attendees.

If you missed our live seminar, a recording of the session is available for viewing. See The Scent of Information: Getting Users to Their Content for details.

Still have questions about our research into the Scent of Information? Ask them in the comments below!

This week, I had the pleasure of speaking with Donna (Maurer) Spencer, a world-renowned information architect and owner of the freelance agency MaadMob, based in Canberra, Australia. For nearly 10 years, Donna has been a prominent player in the information architecture world, sharing her experiences for designing some of the most challenging clients around: large government sites.

For this interview, I asked Donna, “What separates good information architects from great information architects?”

Donna said that she believes that great IAs can think structurally, can synthesize many inputs at once, can work strategically, and can work in the smallest details. A good IA can get by doing these things very occasionally, or not at all. But, great IAs do all of these constantly, bringing more value to the project.

Over the years, Donna has come into contact with some diverse and multi-talented IAs. She noted that one thing they all have in common is they all do more than just information architecture. Donna told us how she keeps herself balanced by also practicing other user experience disciplines, such as interaction design.

Donna also suggested that perhaps the strongest skill the great information architect needs is people skills. It’s one thing to build a quality taxonomy or navigation system, but if you cannot interface with your own team or the client, you may find your usefulness diminishes greatly.

This was a great interview. We had a lot of fun making it and I’ll bet you’ll enjoy listening to it.

This October, Donna present a full-day workshop, “Information Architecture Essentials: Best Practices for Organizing Your Site’s Content”, at the User Interface 13 Conference in Cambridge, Massachusetts. It’s a great place to learn what it takes to become a great information architect.

We look forward to your questions and thoughts on this podcast. Do you agree with Donna about what it takes to become a great information architect? Is there anything she left out? Let us know what you think in the comments!