• Been teaching my Adaptable Information Architecture workshop; last one of the spring is May 23 in NYC (and, yes, still some seats open). Planning more cities for Rosenfeld Media's fall workshop tour—likely in Toronto, Minneapolis, NYC, and Tel-Aviv.
• Hey, speaking of my workshop, Smashing Magazine just (minutes ago) published my very related article "Stop Redesigning And Start Tuning Your Site Instead".
• Consulting for a couple select clients whose names I dare not speak. Yes, I continue to make a living as an information therapist.
• Publishing new books like crazy! Rosenfeld Media has published eight titles so far, but it looks like—thanks to the perverse gods of scheduling—we'll double the catalog this year. John Ferrara's Playful Design debuts in a few days, and Rachel Hinman's The Mobile Frontier in a couple weeks. And we have about eight more in the pipeline (and more signings coming soon).
• And traveling (and usually speaking) like crazy. Highlights include WebVisions (in NYC and, soon, Barcelona), UX Hong Kong, the IA Summit in New Orleans, and, in about an hour, this talk at Confab in Minneapolis.
• Finally, planning something big that will launch in a couple weeks. In a nutshell, Rosenfeld Media 2.0. We'll tell you all about it in our next (free) newsletter.

In New York City, I'll be teaching my IA workshop on May 23; Rachel Hinman teaches Mobile Prototyping Essentials on May 24, and Steve teaches his usability workshop on May 25.

These are really practical workshops—very small, very hands-on—and a great way to boost your UX team's skillset quickly and cheaply. Please spread the word; hope to see you there!

P.S. We're looking to add a third city. What should it be?

I've taught my full day workshops probably seventy times over the past decade. I've increasingly downplayed what I call "top-down navigation"—you know, main pages, site hierarchies, and the such—in favor of the other two hugely more important areas of IA: search and contextual navigation. You know, the stuff that unlocks your deep content.

And site maps and wireframes? I don't think I've addressed them since the second edition of the Polar Bear book.

Well, it happened again today. I heard someone mention "IA and search". As if they're separate things. Folks, IA is all about helping people find information. That means helping users browse and search and ask questions, as well some other things, like orienting them.

(Worst thing is that I sometimes hear self-styled information architects talk this way.)

Well, dammit, once again I'm going to try to dispel some myths about IA. And offer some concrete suggestions about what IA can do for you aside from wireframes. On November 3, I'm teaching the UIE virtual seminar: "8 Better Practices from Information Architecture". During the talk I'll map out some new directions for what IA (and information architects) should be about, and some concrete areas where IA can make a difference for your organization.

Please join us. It's 90 minutes of your time. If I don't make a reasonable case for IA at this seminar, I'll surrender and just stew in my frustration. Silently alone. For eternity.

No pressure.

PS Code "ROSENFELD" gets you $40 off lifetime access to the seminar's recording. Once more, here's where to learn more and register.

1. First ask yourself if a book is the appropriate package for your content (and its users). 
2. If it is, ask yourself if you really want to spend at least a year of your precious time and effort to write one.
3. If you do, ask yourself if you want to publish it yourself, or if you see value in having a publisher work with you. Some people can pull off a book on their own; others like/need to have editorial, production, promotion, and distribution handled by someone else.
4. If you want a publisher, find the one whose audience most closely matches the one you wish to reach. While I believe that some publishers are far superior to others ;-) ultimately we do much of the same thing: match books with our audiences. 
5. If you have identified multiple publishers that might be appropriate, figure out which one will actually help promote your book. (You'll still have to do a lot of it yourself, but it'd be swell if your publisher would also shoulder some of the promotional burden.)
6. If one publisher seems to promise to promote your book more than others, then examine their track record and see if it's covered in bullshit.

That's it! Hope this helps.

(This one was kindly created by the incomparable Eva-Lotta Lamm.)

Onion-layer models help make the case for and rather than or approaches to solving problems. They are a powerful visual way to communicate the shades of gray that invariably color the solutions required by complex design challenges.

Here's an example that came up during a recent client engagement. Their challenge: work in a variety of new features—many which would require some sort of authentication—into their commerce site. Part of the challenge was the disturbingly large number of features that needed to be integrated. The other part was the risk of hitting users with too many features too soon or, conversely, hiding too many behind a daunting, crocodile-infested registration moat.

Clearly some sort of framework was necessary to introduce those features at the right pace and at the right time. If successful, this framework would transform visiting lurkers into fully engaged, fully registered customers. If not, we would all be screwed.

I came up with this simple approach for the onion layers:

• Layer 0: User visits the site (unauthenticated; no cookies, no nothing)
• Layer 1: User asks the site a question (for example, a search query)
• Layer 2: Site asks the user a question (would you like save this product to a wishlist?)
• Layer 3: Site suggests something to the user (you might enjoy these products ordered by people like you)
• Layer 4: Site acts on the user's behalf (we've gone ahead and saved these products to your account's list of frequently-ordered items)

There are lots of good models for this sort of dialogic approach, ranging from the reference librarian's interview and expert systems design to permission marketing and Luke Wroblewski's concept of gradual engagement. And my layers here shouldn't be taken too literally. In fact, the client team quickly came up with a smarter and more sophisticated version of this model.

But the onion-layered approach is useful nonetheless, because it underlines the importance of gradualism. And it forces us to answer some important questions:

• How do we actually get user to move from one layer to another?
• Have we demonstrated the next level's value?
• Have we earned users' trust yet?

Design is rarely black-and-white, rarely a binary decision-making process. We need more models, even ones that are smelly and make us cry, to help demonstrate the power of and over or.

• Washington, DC: September 9
• Seattle: September 26
• London: October 4

This is part of the growing Rosenfeld Media UX Workshop tour, and I'll be joined by Indi Young, Steve Portigal, Anders Ramsay, and (in all three cities) Steve Krug.

As always, the sessions are small and intimate. Also highly practical and, I like to think, very engaging. And, as much as it pains me, we've cut prices (given how crowded the UX workshop calendar is getting, this is a given).

My workshop starts with a fiery version of my Redesign Must Die talk, and then digs deeply into the many more effective (and less expensive) alternatives. I can pretty much assure you that what you bring back to work will be far more valuable than the $495 you paid to attend.

If you'd like to learn more, check out the session description or peruse the slides:

D'oh.

Well, it is! Grab a copy of Search Analytics for Your Site: Conversations with Your Customers directly from Rosenfeld Media: US$39 gets you the book in paperback and (instant, DRM-free) PDF, ePUB, and MOBI. US$22 gets you the digital versions only.

The testimonials and tweets are nice; hopefully the Amazon reviews will be as well.

Apropos, UX Matters published a sample chapter and an interview with me, and SearchEngineLand has run the first of a two-part interview. (Thanks to respective interviewers Kristina Mausser and Shari Thurow!)

And more thanks to the many of you who helped and prodded me lo these many years to finish the thing!

Anyway, please grab a copy and let me know what you think. Even better, post your reactions on Amazon.

If this really is the case, then the rational path for large organizations is to to keep chopping themselves up into smaller pieces that enable communication, collaboration, and innovation. In my consulting, I've seen companies with successful product groups that are about this size. These groups have their own KPI and often their own P&Ls. All good.

But usually there is no equivalent group that owns the glue, the connective tissue between product groups. That means cross-promotion is often as poor as promotion is good. In other, non-commercial contexts—say a corporate intranet—that missing glue destroys divisions' ability to communicate and collaborate with each other—which is still kind of important if a large organization is to function at all.

Many senior leaders recognize the silo problem, but they solve it the wrong way: if one hierarchical approach to organizing their business doesn't work, try another hierarchy. Don't like the old silos? Create new ones. This dark tunnel leads to an even darker pit: the dreaded—and often horrifically ineffective—reorg.

Information architects have unique skills for addressing the problem of silos. We're great at creating connective tissue. But this is hard stuff to explain to non-IAs. And we're awful at making the case that we have something to offer.

I hate to use the dreaded 'R' word, but if information architects are going to remain relevant, we need to apply our skills to connecting content across silos in a way that senior leaders can understand. In other words, we have to demonstrate the value of doing a good job connecting content across silos in a quantifiable way. We need to come up with better metrics for two areas:

1. Contextual Navigation: Moving people horizontally between content and, ultimately, between silos of content.
2. Search: Enabling people to drill down quickly into a site's deep content, regardless of which silo owns that content.

Many identify information architecture with only its top-down elements, like main pages and site hierarchies. These other two pillars of IA are far more important, far richer in opportunity, and as yet unexplored and under-exploited by so many large organizations.

Metrics tend to find their way into KPI. Good metrics lead to great KPI. If we information architects can develop better metrics to help optimize these two areas, today's voids of in-betweenness will be transformed into tomorrow's valuable real estate. We'll see large organizations that have product managers, teams, and strong KPI built not for silos, but for the stuff in between silos. And a clear path from information architect to product manager will emerge to the delight and relief of the many information architects who are currently pondering their future relevance.

Just got asked to explain what's going on here, and realized I'd never done so outside the workshop context. So here goes:

One reason sites suck is that so many of us have forgotten why our sites exist. We get distracted, lose sight of priorities, and end up with sites that don't do the most important things users want. Such a site is kind of like Swiss Army knife without the, um, knife.

This simple little report card forces you to (re)prioritize what your site's there for in seven simple steps:

1. Identify critical audience segments
2. Determine what each really, really wants
3. Determine what stakeholders really, really want for those segments
4. Combine #2 (wants) and #3 (needs) through negotiation
5. Evaluate performance
6. Fix what's not working
7. Repeat regularly

Simple, eh? Yet a frightening proportion of organizations I've worked with can't:

1. Identify critical audience segments
2. Determine what each really, really wants
3. Determine what stakeholders really, really want for those segments

...and so, they're completely screwed when it comes to doing these things:

1. Combine #2 (wants) and #3 (needs) through negotiation
2. Evaluate performance
3. Fix what's not working
4. Repeat regularly

Really, how can you operate a site if you don't know who the primary audiences are, what their critical needs are, and what stakeholders want for each audience? Yes, I'm talking to you; don't try to hide.

And, buster, if you're not evaluating your performance on major tasks, how the hell can you know what to fix?

By the way, repeating this regimen regularly (step #7) is to costly, pointless redesigns as garlic is to vampires.

Some elaboration:

• Users' wants come from (drum roll, please) user research! I'm a big fan of site search analytics as one way of coming up with a priority-ordered list of wants, but you should use other approaches, like clickstream traffic analysis and inbound call analysis. Put another way, what methods do you use to determine which tasks to include in task analyses? Inject them into this column.
• Users' most common wants will account for a huge proportion of all their wants. See Zipf Distribution. Put differently, a little inevitably goes a long way, whether we're talking search queries, document usage, you name it. Use this strange law of nature (and IA) to your advantage.
• Users' needs are what stakeholders think users need. E.g., Stakeholder: "We think all applicants will want to know about our alumni profiles". You: <sarcasm>"Sure..."</sarcasm> So populate this column by asking stakeholders.
• What's this negotiation stuff in step #4? It's where you show your user data to stakeholders, compare notes, and combine what they've come up with anecdotally with your own evidence-driven approach. This is the hard part, but this is the stuff that separates UX mice from UX men. Uncomfortable negotiating? Congratulations: you've just hit your career ceiling.
• It's an academic example; so I used letter grades. Score things however you want; just score them, baby! That's how you'll know which need to be addressed.

Like this stuff? Then I've got a workshop for you (one more this spring--in Chicago, June 3).

Anyway.

This presentation is an updated version of my old Redesign Must Die talk, given a few years back. I think that the only slide to survive this redesi... (cough) new version is the infamous one featuring the kittens. If you care nothing for redesign and only for kittens, jump ahead to slide #5. Otherwise, prepare to witness my wrath:

I'll admit that I'd been wondering if this would be our last IA Summit. If it was, it'd be quite sad. But all things must pass, and a twelve-year run would be nothing to sneeze at. I know I'd be proud. But there will be an #ias12 (and in New Orleans, which is wonderful news).

Unfortunately, next year's event will once again be attended by a 900 lb. gorilla that, like me, has attended every IA Summit: a broken business model. The IA community's flagship event is owned by ASIS&T, an entirely different community's professional association. The IA community's own professional association, the IAI, has no ownership stake in the IA Summit. This is nuts.

I love and respect the people involved in both organizations. I'm the IAI's cofounder. I've known Dick Hill, ASIS&T's executive director for twenty years. Some of my best friends are information scientists.

But to have one community's organization handling the major annual event on behalf of another community continues to make zero sense. It's an historical accident (my fault, to some degree) that needs to get ironed out. Let's face it, #ias11 worked well despite this huge crack in the event's business model. We got lucky this time; we might not be so lucky next year.

Once and for all, we need to make this a jointly owned event. ASIS&T can continue to handle the business end of things, such as finding a venue, handling money, and so on. Having taken a risk on our community back in 2000, and having remained committed to continuing the event—even during some lean years—ASIS&T deserves the right to continue. And let's not forget: it legally owns that right.

The IAI should own the programming, promotional, and experiential aspects of the event. This is obvious, and I doubt anyone at ASIS&T would disagree. In fact, many people already assume (incorrectly) that this is the case. The IAI must own at least some aspect of its own community's keystone event, and the IDEA conference, as wonderful as it is, is not that event.

Sure, the IAI could create a competing event. But that will create marketplace confusion, not to mention bad blood. It could also fragment the IA community itself. Let's not go there.

ASIS&T could say no to sharing. But they'll eventually lose much of the volunteer juice that handles programming, promotions, and the event's experience. This is what will kill off IA Summit—if not immediately, within five years. Besides, saying no would weaken the IA community by denying our representative organization official ownership of (and revenue from) our own main event. ASIS&T, which has been wonderfully supportive of the IAI all along, has no interest in seeing that happen.

So let's do joint custody. It won't be simple and it won't be easy, but it can and needs to get done. The alternatives present some huge, ugly, we-don't-want-to-go-there risks. And the kid looks like a winner, at least the morning after Denver.

And let's fix this problem now, while there are good feelings and great energy, while there is momentum, and while our backs aren't against the wall.