Seth: I think the screws will continue to tighten on IAs. During the past few years, we needed IAs to explore and build site structures that didn't exist before. Clients were willing pay for creativity and novelty because they felt that Web users (and Wall Street) would reward that kind of innovation and jump onto anything new or cool. So, the demand for information architects was very high, and the barriers to entering the field were relatively low.

But, I see web applications of the future being developed with approaches that are like those used in the software industry, rather than some improvisational methodology. Team structures will probably look more like product management teams. So, the landscape is certainly going to look different.

Not all of us are going to want to work in this environment. Those IAs that are adaptable and can shimmy between opportunities will be able to ferret out some interesting opportunities. But, these may be outside the traditional web realm we've become so comfortable with. There are plenty of companies working with emerging technologies/services, (such as iTV and mobile) and they will need architects to help provide structure to the content so people can access the goods. And, I'm still not convinced that a central repository can be used to pump out the content in different formats to each device. I think there will still be a need for a lot of custom work to prep content for multiple devices.

Lou: Would you say that IA methodologies have typically been improvisational?

Seth: They've certainly felt improvisational at times. When I was at discovery.com in '96, the "methodology" that worked best for us was to ask lots of questions, work late, keep banging away until it felt right, and grow big hair. This approach didn't have a nifty name and we didn't diagram it in Visio, but we all knew how to work with it. Even by today's standards, those were some of the best sites that I helped put up.

But, that's a perspective from an internally run project. As the web consulting industry started to take shape, firms tried to create proprietary approaches that would separate them from the competition by giving the perception of a more disciplined and scientific focus on the work. It seems that just about all of the approaches were similar except for a few nuances or catchy acronyms. I've been in Thailand for a few weeks, and there is a common expression that I think perfectly fits some of the formalized IA approaches. "Same, Same but different."

I'm not sure there are obvious external benefits to building sites within the confines of strict methodologies. I have a hunch that neither users nor professional site critics would be able to tell if a decent site was created within the construct of a methodology or not.

I think methodologies have proven themselves very useful in the areas of client control/expectations setting and as resource estimation tools.

Lou: Are usability engineers in for the same troubles as IAs? Or is the distinction unimportant in terms of the economic situation?

Seth: I think usability engineers should be on good footing to survive the mayhem. Just as a point of clarification, the usability engineers I'm talking about are the researchers that handle the validation aspects of testing and measuring of usability. This is a different role from the usability engineer who '"bakes usability goodness right into the 'product".

These market conditions should be a boon for usability research. During the last few years, companies were willing to throw previous work away and spend big to rebuild their sites from the ground up, even when it wasn't really needed. It is clear we are now in a period of more cautious and controlled spending. Project dollars and resources will go towards activities that can deliver clear and fast benefits with minimal headache. I believe user research and usability testing fall into this category.

Lou: Interesting; so you're saying that usability research might be a counter-cyclical business?

Seth: Yes: usability test results can show where incremental improvements will make big contributions, and fast. As many of us know, a usability test with 5-6 respondents can be completed, from planning to reporting, in about a week. Usability findings highlight the areas in need of tweaks and refinements. These are often easy to implement--simple HTML edits and don't require any fumbling under the hood. Changing some editorial copy and moving some visual cues on a page/site can often make huge differences. But, as user sophistication and experience levels change, the same site should still be measured regularly to make sure it's still keeping pace.

Implementing results from a usability test is like getting a seasonal tune up for a bike. Look over the bike, adjust a few cables, tighten a few screws and it rides like a million bucks again. No need to replace all the parts or buy a new ride. The devil is in the details and a little regular maintenance can go a long way.

Lou: How much is our field at fault for not coming up with the "right" metrics? Are there indeed "right" metrics for measuring performance? Or is it as unrealistic to measure the value of an architecture as it is the value of a visual identity?

Seth: In a misguided effort to measure the effectiveness of an architecture, many researchers assess variables such as time on task (how long it takes a user to complete a given task) and error rate and recovery (the number of errors and how users recover). While these may be relevant in certain situations, like diffusing bombs or responding to 911 calls, I think they can be misleading when trying to measure the average user's experience on the Internet. I've traded in those tired metrics for two new ones: the frustration factor and user confidence of accuracy. Here's a brief description of the two:

• Frustration Factor: At what point in a process does a user freak and quit out of frustration? If you can learn to identify (or avoid) the signs of fatigue and the catalysts for frustration, time on task is no longer important. As long as the user stays enrolled in the goal, and doesn't mind, don't worry how much time they are spending. But, this measurement relies heavily on context. A user's patience for the same activity is impacted by a lot of things (such as urgency, location, and the nature of the activity). It's sometimes a moving target that is difficult to assess in a "lab setting". I've had good success having users self-report when using the product in an unsupervised environment.
• Confidence of Accuracy: Web sites are very good at delivering a false sense of confidence. It's common for people to think they've completed an activity and that it's done and they no longer need to worry about it. People think they've completed a task when they really haven't. Ever happen to you?

It reminds me of taking a test in school and thinking that I aced it. But, when the grade came back, it's clear that I was overly confident. That's a much bigger shock than knowing I did poorly on a test, and getting a grade back that confirms that suspicion.

On the Web, this false sense of security can help assassinate a brand and goodwill because the frustrated user will put the blame for the problem where it belongs, on the company that runs the site.

I can't even count how many times I thought I've completed my intended task successfully, but really didn't. Of course, I find out at the most inopportune times. I know I can't be the only one.

Lou: Can you provide a few examples of the "confidence of accuracy" problem?

Seth: Sure; it seems that they're happening to me all the time. Just a few recent costly and inconvenient examples from recent months:

Thought that I booked an airline ticket when I actually only reserved it for 24 hours. By the time I realized the mistake, the fare had gone up $400. Ouch! It took a long time to negotiate that one back down to the fair price.

Thought I ordered an MP3 player, but call customer service four days later and find that there was a problem processing my credit card. I went with the default expiration date they set up in the drop down menus, but apparently they system didn't check card validity in real time.

Thought I'd setup Billpoint properly so I could collect credit card payments for my Ebay auctions. Didn't find out there was a problem until a buyer told me their card payment had yet gone through and the money never appeared in my account. Three months and fifteen messages with Billpoint still haven't resolved this issue.

It's not a huge problem if a user makes an error, and clearly knows the consequences. Receiving errors can lead to the increase in the frustration factor, but as long as it is recoverable and the user does so, it's not the end of the world. Sloppy, perhaps, but not a show stopper. The more significant problems are when people think their transactions have been completed, when they really haven't.

And, even though these things are a pain for me and may change my perception of the company, there are also financial implications for the company trying to provide the service. Every time I have to take a transaction offline and deal directly with people is a hit against potential profitability or ROI. And, in a small way, it's a triumph for me as a consumer to know that these avoidable errors are costing companies money.

Lou: At this point do you see information architecture in a different light? Is it more or less important than you thought it was?

Seth: Now that I have chosen a stable of favorite and most often used sites, as a consumer and general web user, IA is less important to me. I have invested time to learn my favorite sites inside and out, regardless of their intuitiveness. They have earned my wallet share both for good service and because they have me locked in with high barriers of switching. So, even if a new site comes online with killer IA, they're going to have a hard time getting me to use the service because I'm sticking with the tried and true. I just don't surf all over the place like I used to when the Web was new to me. I've been acting like a creature of habit for a good while now. No surprises there, because that behavior pattern is pretty predictable for long terms users. I think I've turned myself into a "recurring revenue" stream.

Lou: What else are you pondering with your newfound free time?

Seth: I've taken some of my free time and headed off to Southeast Asia for a stint. It's a pretty great place to ride out the storm and regain some perspective. I've met a few of our techie compatriots out here on the road and we all agree it's a pretty good alternative to hammering out sites. And, it's great to be in a part of the world where you don't have to try and explain your profession of IA or User Experience something or other. The idea is so foreign to most local folks here (northern Vietnam, this week), that we quickly move on to far more interesting conversations.

It's amazing how a few days trekking in the hills of Thailand can stretch out the muscles and eliminate the imprint of the Aeron chair from my backside.

Lou: Maybe I'll run into you during my own Really Long Road Trip. Happy travels...