Chapter 17. Making the Case for Information Architecture
| What we’ll cover: |
| The unavoidability of selling |
| The ROI case for information architecture |
| The fallacy of ROI thinking when it comes to information architecture |
| Other ways to make the case for information architecture |
| The value of information architecture: a checklist |
Wherever information architecture is happening or could be happening, someone is trying to decide whether or not the pursuit is worth the investment of resources. And that person often needs a lot of convincing. You, as an information architect, must be prepared to make a case for what you do.
You Must Sell
Perhaps you’ve never found yourself trying to sell information architecture to a client; that’s what the sales folks do, or if you’re an in-house information architect, your boss worries about this. Your job is to just show up and generate those blueprints and wireframes. If this describes your attitude, skip this section. (But don’t be surprised if you suddenly find yourself unemployed.)
When it comes to others’ perceptions of information architecture, be prepared to change negative thinking into positive. Most people still haven’t heard the term “information architecture,” many don’t think it’s real or worth their attention, and many simply don’t understand the value of anything so “fuzzy,” especially when compared to concrete things like, say, the intensively marketed software tools that promise to solve their problems.
Some people do recognize the value of information architecture but don’t know how to convince their colleagues. And others implicitly recognize its value in theory, but simply don’t yet have the practical experience to tell the people in charge just how valuable it is compared with the many other ways they can spend their money.
You need to be ready for all of these situations—not just getting the point across initially, but being able to “sell” what you do on the ground. Because the worst can and often does happen after the sale. In fact, in a May 2002 survey of the information architecture community,[1] we found that the most challenging aspect of promoting information architecture was not getting the opportunity to promote it until it was too late in the design and development process. We’ve sold many large information architecture consulting engagements only to find that as soon as we sent our consultants off, some unanticipated and terrible event happened that jeopardized the entire project. For example, one person who hired us for a Fortune 50 company retired the day before we showed up for work. Worse, despite his assurances to us, he never had the political power within the organization to pave the way for our work. And even worse, he hadn’t prepared his successor in any way; the successor didn’t have a clear vision of the value of information architecture and obviously couldn’t advocate for it to his colleagues. So our own consultants had to sell their expertise on his behalf. This made it difficult for them to actually get any work done, but they were ready to sell themselves, and it made a big difference. If our people couldn’t have made a case for information architecture, the whole project would have been torpedoed.
So all information architects need to be salespeople at one time or another, both before a project is set up and while the project is underway.
The Two Kinds of People in the World
Now that we’ve covered the need to sell it, just what is involved in making the case for information architecture? That depends on the person to whom you’re making the case. To grossly overgeneralize, we’ve found that business people typically fall into two groups: “by the numbers” folks, and “gut reactionaries.”
The “by the numbers” people require data to help them make their decisions. They need to see figures: “If we invest X dollars into this information architecture thing, we’ll make or save 2X dollars.” They rationally consider return on investment (ROI) as the basis for their business decisions. Makes sense, right? Well, as we’ll see, it doesn’t. But you still need to understand this mindset because you’ll encounter it again and again.
“Gut reactionaries” do what feels right. They trust their instincts and often have plenty of good experience to draw on. They consider the intangibles when they make decisions. And they’re often suspicious of numbers and how well they depict the “real world.” The success of the case you make to gut reactionaries often depends on luck as much as anything else; the intangibles are as dubious as they are fuzzy. So, just in case, you’d better dust off that suit before sitting down with a gut reactionary.
Ultimately, when you’re making the case for information architecture, you don’t know which of these narrow and extremely unfair stereotypes will describe your client. So be prepared to discuss both the numbers and the intangibles.
Running the Numbers
OK, so here’s the big question: what is information architecture actually worth?
The best source of numbers is white papers created by such analyst firms as Forrester Research and The Gartner Group. These numbers often don’t focus on the ROI for information architecture per se, but they do address similar or overlapping areas of practice (e.g., user experience) or a hot technology (e.g., portals) that may involve a specific architectural approach.
For intranets, most utilize an opportunity cost approach to assessing ROI, drawing on a technique that was popularized in the web design community by Jakob Nielsen.[2] Table 17-1 shows the basic calculation.
| Factor | Cost |
| Time lost due to a design-related problem (determined through user testing) | 10 seconds/occurrence |
| Time lost over course of a year per employee (10 seconds/occurrence ×3 occurrences/day×200 days/year) | 6000 seconds (1.67 hours)/year |
| Cost per employee (e.g., $50/hour/employee, including benefits) | $83.33/employee |
| Number of employees that experience this problem | 5,000 |
| Total cost due to this design-related problem | $416,667/year |
For example, if the design problem at hand is a confusing labeling system, and you feel confident that investing $150,000 will make it go away, then you can claim an ROI of 178 percent ($416,667–$150,000 / $150,000). Not bad, especially if you consider that this particular design problem may be just one of many that can be addressed.
Here are some more examples of this opportunity cost approach:
Bay Networks invested $3 million into organizing 23,000 documents for its 7,000 users. Among other benefits, Bay estimated that each member of the sales staff would save a minimum of two minutes a day searching for documents, or roughly $10 million a year.[3] That’s a 233% return on investment.
In its November 2001 report “Intranets and Corporate Portals: User Study,”[4] Agency.com surveyed 543 employees from different companies regarding their use of portals. Respondents reported that portal use saves on average 2.8 hours per week, or 7 percent of their time. Assuming $55,000/year per employee (fully loaded), a well-designed portal would save employers $3,908 per employee. A 5,000-person company would therefore save about $20,000,000/year.
Applying this approach to intranet portals, Nielsen states that “The cost of poor navigation and lack of design standards is . . . at least ten million dollars per year in lost employee productivity for a company with 10,000 employees.”
The last two examples don’t provide investment costs, so we can’t determine the actual ROI. Regardless, the number jockeys will be extremely impressed.
These examples focus on ROI for intranets, which is measured primarily in cost savings. What about external sites, such as e-commerce sites, that are geared toward increasing revenue? The most powerful numbers come from examining sales lost due to sites that confuse and frustrate customers. For example, Creative Good tested the BestBuy.com e-commerce site and found that over 78 percent of customers’ purchase attempts failed.[5] Creative Good then designed a prototype of the BestBuy.com site with improvements made to, among other things, some aspects of the information architecture. Among customers who used the prototype, 88 percent could complete a purchase, exactly quadruple that of the live site’s rate.
It’s not clear what the improvements would cost, but Creative Good estimated that they would require less than one month to develop and implement. Let’s be conservative and assume that this effort cost $1,000,000 (a reasonably high number). If BestBuy.com’s current sales are $100,000,000, and the improvements only doubled (not quadrupled) sales to $200,000,000, the ROI would still be quite healthy: ($100,000,000–$1,000,000) / $1,000,000 = 9,900%!
There are many other similar and exciting numbers for e-commerce sites.[6] For example, IBM spent millions over a 10-week/100+ employee effort to improve ibm.com’s information architecture, resulting in a 400 percent increase in sales.[7] And Tower Records was able to double the rate of purchases made by visitors to its site by improving its search system.[8]
Many of the metrics used to judge a site’s success can be positively impacted by an improved information architecture. And for each of those architectural improvements, there is likely an exciting number that matches it. If LL Bean is trying to sell more ties, better contextual navigation from the shirts area to connect to matching ties might raise revenue. If the Sierra Club is trying to increase awareness of environmental issues, perhaps a more prominent link to its mailing lists and feeds would raise subscription levels. If American Express is drowning in costs associated with printing, maintaining, and distributing product literature to financial advisors across the country, a well-architected extranet might save them big bucks. And if Dell is trying to reduce technical-support call volumes, perhaps reconfiguring its site’s search system will result in higher usage levels and allow for a reduction in technical support staff.
Ultimately, certain aspects of information architecture, like any other UCD-influenced improvement, should have a direct and quantifiable impact on just about any site’s performance. Because the cost of information architecture work can be measured, ROI calculations should be attainable. And you should therefore be able to have fruitful and productive conversations with the “by the numbers” people.
Debunking the ROI Case
By now, you should be getting nervous because we italicized “should” three times in the last paragraph. Unfortunately, it’s almost always impossible to calculate true ROI for an information architecture. We can discuss it as theory, but information architects must be careful not to fall into the trap of false claims of attaining proven ROI numbers.
There are three major reasons why ROI measurements of information are, at best, unreliable:
- The benefits of a complete information architecture cannot be quantified
It’s generally possible to measure the value (and ROI) of some of an architecture’s individual components. For example, we may be able to determine how well users navigate a broad and shallow hierarchy versus a narrow and deep one. Or we might measure how users respond to one way of presenting search results versus another.
However, an information architecture is made up of many such components. And it’s generally wrong to measure an individual architecture component, as there’s a good chance that its performance will be impacted by that of another component. As mentioned earlier, users often integrate tools for both searching and browsing in a single effort to find information. Although the natural tendency is to separate these tools for testing purposes, it makes more sense to measure searching and browsing performance together—after all, that’s how the site is used. But measuring both concurrently is exceedingly difficult; it soon becomes apparent that you can’t isolate the impact on performance that each component makes.
Measuring the performance of a component of an information architecture is useful as long as such measurements are not confused with the measure of the overall architecture.[9]
- The benefits of many information architecture components can’t ever be quantified
Though an information architecture is greater than the sum of its parts, the performance of many of its parts can’t ever be quantified.
For example, many efforts to measure search performance focus on how long and how many clicks it takes users to find the answer. This is reasonable if users are performing only known-item searches, where there is a “right” answer to their question and a consistent and measurable endpoint to their search sessions. But as discussed earlier in this book, the majority of many sites’ users are not performing known-item searches. Instead, they’re looking to perform comprehensive research, learn a few tidbits about a topic, pick up some news, or be entertained. These types of searches usually don’t have an endpoint. If there is no endpoint, it’s not possible to confirm (and therefore quantify) success.
Another consideration is that many users don’t find what they need from a site. There are potentially huge numbers associated with this cost, but how would it ever be measured? In these situations, you might ask subjects if they were satisfied with their results. And their answers might suggest that they were indeed pleased. But when it comes to finding information, ignorance is often bliss: users don’t know what they don’t know. They may miss out on the best, most relevant content, but they simply have no idea that it exists.
- Most claims for quantified information architecture benefits can’t be validated
Most quantifications of information architecture, like those discussed above, can’t be proven. When we read about how many minutes per day an employee would save, or how many more sales a redesigned shopping cart would convert, we are essentially reading predictions. We ultimately have no way of proving that those minutes are used productively and not for playing Tetris, or that customers bought more or less due to the redesign. It’s unfortunate, but efforts at validation are rarely made because they’re too expensive and time-consuming. And many, many factors might influence a before-and-after outcome besides the redesign. Would an e-commerce site’s numbers go up because the information architecture was better, because more redundant connections were added to the site’s servers, or because the overall number of web users had grown? There are an incredible number of uncontrollable and, at times, unknown variables to consider that make it difficult, if not impossible, to validate such measurements.
Information architecture is a human issue. For that reason, it doesn’t lend itself to the type of quantification that one might expect of other areas, such as determining what type of router to purchase to accommodate more network traffic. Unfortunately, it is often confused with such technical areas by those who have insufficient knowledge of information architecture.
Numbers associated with information architecture should be seen for what they are: predictions based on soft numbers that haven’t been or can’t be validated. That doesn’t mean they’re not useful. ROI cases are simply one of many tools that, if they sound reasonably valid, make people feel comfortable with an unknown. And after all, we do have to survive, and sometimes the only way to convince a “by the numbers” person is to show them numbers.
But if you do provide ROI numbers to a manager or potential client, be honest that you’re not really proving anything; you’re simply predicting value that probably can never be measured but is real nonetheless. It’s our responsibility, not to mention in our own interest, to educate our market. After all, our work will always be easier and more effective if we’re selling to and working with smart people. If we continue to hammer away at the honest truth about ROI numbers, perhaps information architecture will eventually be broadly accepted as a valuable (but not quantifiable) field such as public education or psychotherapy.
Or, for that matter, management, marketing, human resources, and IT.
Talking to the Reactionaries
The “gut reactionaries” aren’t necessarily interested in numbers and often go with what feels right or is in line with their experience. This approach is excellent if the reactionary has direct experience with information architecture or related issues. Then you can simply draw on that frame of reference as you discuss future plans.
But what if the reactionary has no relevant experience to draw from? In such cases, we’ve found that telling firsthand “stories” is often the best way to engage and educate this type of person. Stories put him in the shoes of a peer who faces a comparable situation, feel that peer’s pain, and help him see how information architecture helped in that situation. Case studies also end on a useful note of redemption, but don’t sufficiently personalize the story by connecting the person you’re telling it to with his peer within the story.
An effective story should provide the listener with both a role and a situation to identify with. The role and the scenario should set up a painful, problematic situation so that the listener feels that pain and can see how investing in information architecture can help make it go away.
Following is an example of a true story that we’ve found useful in communicating both a problem scenario and a set of information architecture-based solutions. It goes like this:
A client who came to us was a mid-level manager of a huge technical-support operation for a Fortune 50 company. This person was responsible for the documentation used by thousands of operators manning the phones and answering customers’ questions 24/7. The answers to these questions had originally been published in huge three-ring-bound manuals that were expensive to produce, unwieldy to use, could not be searched, and were exceedingly difficult to update and maintain.
When the Web grew in popularity, the company decided to convert all of this printed documentation into HTML pages and house it on an intranet. And that’s exactly what it did: thousands of pages were converted, with no thought given to how the content would be browsed and searched in the context of a web site, how the content templates should be designed, or how maintenance would be handled. It was as if the printed manuals were dropped into an HTML meat grinder. The output was so bad that it caused some major problems.
The biggest problem was that the operators couldn’t find the information quickly, or at all. Speed was certainly an important factor; faster meant that staff could help more customers per hour. More importantly, it also meant that customers spent less time on hold getting angrier and angrier. But the site was so poorly designed that operators often had to look in ten or twenty different places to find all the information on one product because the content wasn’t labeled consistently. Of course, the staff usually gave up and ended up providing incomplete answers.
Sometimes staff would spend so much time searching for a single piece of information that when they finally did find it, they’d breathe a sigh of relief, print the information, and tack it to their cubicle walls so they’d never have to undergo that ordeal again. Of course, if that information was time-sensitive, like a product rate sheet, the support operator would be providing inaccurate, out-of-date answers from then on. Even worse, there were documented instances of operators making up answers. This wasn’t surprising at all: at $10 per hour, they simply didn’t have the motivation or loyalty to their employer or customers to go through the hell of sifting through the intranet.
As you might imagine, all of these factors—time on hold, and incomplete or wrong answers—had a devastatingly negative impact on customers, whose brand loyalty was damaged in a real, if unquantifiable, way.
And the impact on the support staff was also quite expensive. Training costs, already high, were going higher. It now cost $10,000 to train each one, a staggering figure considering that these employees earned only $10 per hour. Worse, turnover was 25 percent annually, meaning that even with expensive training, staff were finding work at the local fast-food restaurant comparable in pay and better in job satisfaction. Anything would be better than using that horrible intranet!
So the client had some huge headaches when they came to us. They’d already tried one consulting firm, which utterly failed. That firm’s consultants took a database design perspective, treating all this messy text like a data set. When that approach went down in flames, the client tried to fix their problems in-house, using their own staff. But it soon became clear that their people didn’t have the breadth of skills or experience with information architecture to take on a problem so huge.
Then they hired us to help them design a new information architecture. We helped them tackle the problem in a number of ways:
We worked with them to reduce the amount of content that the users had to sift through and the company had to manage by identifying what was and wasn’t “ROT”: redundant, outdated, and trivial content. We designed policies and procedures that reduced ROT at the point content was initially created, and that helped identify and weed out ROT throughout the lifetime of the site.
We devised ways to organize their content and standardize their labeling. Now their staff could browse through content, find what they were looking for where they expected to find it, and feel confident that everything they were looking for was located right there, all in one place.
We developed a small set of templates that were consistent with one another, and we taught their content authors how to use these templates. The result was content that was predictable: all the pages worked the same way, making it easy for operators to scan quickly for answers.
Finally, we taught their tech-support operators how to use and maintain controlled vocabularies to index their content. Three years later, they were still using our system, and it was still working. We did our work, trained our replacements, and got out.
There you have it: a painful situation and a happy ending. As you read it, we hope you identified with the actors and their problem (including its humorous aspects), and were glad to see it resolved. Telling stories is fun, doesn’t require messy calculations, and can be incredibly effective: stories enable your prospect, client, or colleague to take on the perspective of the story’s hero. In effect, the person you’re telling the story to inserts himself within the story, and in doing so lets his own imagination take over. Storytelling is really a participatory experience, and that participation will help educate “gut reactionaries” and others who are new to information architecture.
What’s your favorite information architecture story? You might document a past problem and how your information architecture design improved the situation. Or you might borrow from your own experience as a user frustrated by a site similar to your client’s. If you don’t have any good stories handy, just use ours.
Other Case-Making Techniques
Storytelling is just one way to make the case for information architecture. There are other approaches, and which one you select depends on many different factors, including whether or not you’re involved in a marketing effort, a sales call, or an interaction with colleagues during a project. (Most of these techniques are discussed at greater length elsewhere in this book.)
- User sensitivity “boot camp” sessions
The premise here is simple: get decision makers who aren’t too web-savvy in front of a web browser. Ask them to try to accomplish three or four basic and common tasks using their own web site (or, if none is available, a competitor’s). Just as you would in a standard task-analysis exercise, have them “think” aloud, and jot down the problems they encounter on a white board. Then review those problems, identifying which are caused by a poor information architecture versus other aspects of design. You’ll be surprised at how many of the problems are indeed information architecture problems, and the decision makers will be enlightened by, as information architect Steve Toub says, “eating their own dog food.”
- Expert site evaluations
Information architecture evaluations of a site can be done quickly and easily. You can probably identify 5 or 10 major information architecture problems within the first 10 minutes of exploring a site. Whether you deliver this evaluation in writing or in the context of a sales call, it can make a huge impression. Not only will you appear knowledgeable about your potential client’s site, but you’ll probably be exposing problems that they didn’t know they had, or that they were aware of but didn’t know how to articulate. Evaluations by outsiders, especially experts, are taken very seriously within organizations, because outside opinions often mean much more to internal decision makers than the opinions of their staff. If you’re an in-house information architect and have room in your budget, bring in an outside expert when you need to hammer home the value of information architecture to colleagues.
- Strategy sessions
These one- to two-day sessions are geared toward bringing together decision makers and opinion leaders, providing them with a brief introduction to information architecture, and then facilitating a discussion on the company’s strategy and how issues of information overload, organization, and accessibility can have a strong impact on that strategy. As with site evaluations, strategy sessions are often effective because they educate clients about a problem set that was an unknown, or because they provide language to articulate problems that were already known. Strategy sessions have an added benefit: because they’re done in groups, participants often discover that they are not alone in their “information pain.”
- Competitive analyses
A site’s information architecture issues can be riveting when the site is placed alongside its competitors. “Keeping up with the Joneses” is one of the most powerful forms of psychological manipulation, and you should use it here. Always look for opportunities to compare architectural components and features to help prospects and clients see how they stack up. You’ll find ample opportunities to slip in information architecture education in the process. Or if you’re working in-house, use competitive analyses to expose the differences between business units’ subsites within your organization.
- Comparative analyses
Not everyone has a competitor, but you can still compare your site to comparable sites. Also consider comparing specific features, such as search interfaces or shopping carts, with the “best in class” from other sites that may not be from the same industry.
- Ride the application salesman’s wake
Huge amounts of money are being invested by vendors of information architecture-related software applications (e.g., search engines, content management tools, and portals). Whether you partner with such vendors or simply pick names from their client lists, it’s often valuable to follow them into a client project. These vendors have already spent heavily on client education, so you can leverage their nickel, but because they focus on the “solution” provided by their own technology, that education is generally incomplete. Clients will inevitably need information architects to configure and add value to the technology, and therefore will be more open to your case-making.
- Be aggressive and be early
OK, this isn’t so much a technique, but we can’t overstate the importance of promoting information architecture as early in the process as you possibly can. For example, if you work at an agency or consulting firm, you should do your best to make sure information architecture is included in the marketing and branding that comprise your firm’s public face, not to mention its list of services. Your active participation in the sales process can ensure that information architecture is part of your company’s proposals and, more importantly, its project plans. And whether or not you work in-house or for a consulting firm, aggressively educate the other members of your design team; they need to know your value as much as anyone else. After all, it’s the intangible stuff, like information architecture, that gets pushed to the side when time and budgets get tight.
Whatever technique you use, consider these three pieces of advice:
- Pain is your best friend
More than ROI numbers—more than anything else—work hard to identify the source of a prospect or client’s pain. While this may sound obvious, there’s more to it than meets the eye. Although many people have heard terms like “information overload,” few have actually thought about information as important and strategic stuff. They may not have realized that accessible information is a valuable commodity, and that it takes special efforts and expertise to make it easier to access and manage. And many decision makers don’t deal directly with information systems like corporate intranets; employees do it for them. Your best tools here are stories that broaden perspectives, competitive analyses that produce anxiety, and experiences, such as “boot camps,” that force people to confront the pain their sites cause.
- Articulation is half the battle
Even when people realize what is causing them pain, they often don’t have the words to express it. Information problems are new to them, and unless they can articulate what ails them, no amount of consulting will help. That’s why information architecture is so important: it provides a set of concepts, terms, and definitions that provide the language to express information pain. If you can educate prospects and clients in the language of information architecture, you can communicate and begin collaborating on addressing their pain. Strategy sessions that begin with a one- or two-hour-long primer on information architecture are a great way to educate clients. Inserting some tutorial material into your initial reports or including a copy of your favorite information architecture book (!) are also useful ways to “spread the word.”
- Get off your high horse
Let’s face it: the term “information architecture” sounds pretty high-falutin’. The jargony nature of the term was the second-biggest challenge in promoting information architecture, according to our May 2002 survey. Be ready for this reaction with a good-natured acknowledgment of this problem (poking fun at oneself and one’s profession always seems to go over well). Then defuse the jargon with alternative, “real-language” descriptions of what information architecture really is and what problems it addresses. This is the precise moment that the elevator pitches described in Chapter 1 come in handy, so make sure you stock them along with the case studies and stories in your bag of evangelization tricks.
The Information Architecture Value Checklist
Whatever technique you use to make the case for information architecture, and whether you’re making a quantitative or qualitative case, there is a checklist of points that might be relevant to your case or story. Some of these points pertain more to intranets, while others are more relevant to external sites. We suggest that you first consider your situation (the type of site you’re working on, whether you’re a consultant or in-house information architect, etc.) and where you are in the process of case-making (pre-sales, sales, or while the project is underway). Then, as you prepare to make your case, review this checklist to make sure you’re not missing an important point:
Reduces the cost of finding information
Reduces the cost of finding wrong information
Reduces the cost of not finding information at all
Provides a competitive advantage
Increases product awareness
Increases sales
Makes using a site a more enjoyable experience
Improves brand loyalty
Reduces reliance upon documentation
Reduces maintenance costs
Reduces training costs
Reduces staff turnover
Reduces organizational upheaval
Reduces organizational politicking
Improves knowledge sharing
Reduces duplication of effort
Solidifies business strategy
A Final Note
Whichever points and approaches you use to make your case for information architecture, keep in mind how difficult this challenge is. After all, you’re promoting something that’s abstract, intangible, and new, and each situation demands a unique solution. This is generally a lot harder than selling a mass-produced tool that everyone uses in the same way, like a spreadsheet application, or something that can be grasped visually, like a graphic design firm’s portfolio.
On the other hand, the information stored in most web sites and intranets is growing at a ridiculous rate. And the content already on those sites may be good today, but will be spoiled tomorrow if there’s no good plan for maintenance. Problems associated with the information explosion are only going to get worse. In the long run, your efforts to market and promote information architecture should get easier as more and more people experience information pain. Hold firm: time is on your side.
[2] “Intranet Portals: The Corporate Information Infrastructure” (http://www.useit.com/alertbox/990404.html).
[3] Fabris, P. “You Think Tomaytoes, I Think Tomahtoes” (http://www.cio.com/archive/webbusiness/040199_nort.html).
[4] See http://research.agency.com/.
[5] “Holiday 2000 E-Commerce: Avoiding $14 Billion in ‘Silent Losses’” (http://www.creativegood.com/holiday2000).
[6] Another good article: Najjar, L. J. “E-commerce user interface design for the Web.” (http://mime1.gtri.gatech.edu/mime/papers/e-commerce%20user%20interface%20design%20for%20the%20Web.html).
[7] Tedeschi, B. “Good Web site design can lead to healthy sales.” ( http://www.nytimes.com/library/tech/99/08/cyber/commerce/30commerce.html).
[8] Guernsey, L. “Revving up the search engines to keep the e-aisles clear.” New York Times, February 28, 2001.
[9] A good source of evaluation techniques for information architecture components is the November 2000 ACIA white paper “Evaluating Information Architecture” by Steve Toub (http://argus-acia.com).