How to create Information architecture

how to do information architecture and how to design information architecture
JohenCorner Profile Pic
JohenCorner,France,Professional
Published Date:02-08-2017
Your Website URL(Optional)
Comment
Making the Case for Information Architecture17 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 cli- ent; 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 blue- prints 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. 365 You need to be ready for all of these situations—not just getting the point across ini- tially, 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, 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 consult- ants 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. http://www.surveymonkey.com/DisplaySummary.asp?SID=106148&U=10614882722. 366 Chapter 17: Making the Case for Information Architecture 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 cli- ent. 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 For- rester 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. Table 17-1 shows the basic calculation. Table 17-1. ROI case for investing in the Sun intranet’s information architecture 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 6000 seconds (1.67 hours)/year occurrences/day× 200 days/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 con- sider 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. That’s a 233% return on investment. “Intranet Portals: The Corporate Information Infrastructure” (http://www.useit.com/alertbox/990404.html). † Fabris, P. “You Think Tomaytoes, I Think Tomahtoes” (http://www.cio.com/archive/webbusiness/040199_nort. html). Running the Numbers 367 • In its November 2001 report “Intranets and Corporate Portals: User Study,” 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 sav- ings. 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’ pur- † chase attempts failed. Creative Good then designed a prototype of the BestBuy.com site with improvements made to, among other things, some aspects of the informa- tion architecture. Among customers who used the prototype, 88 percent could com- plete 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 conser- vative 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. For exam- ple, 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. And Tower Records was able to double the rate of purchases made by visitors to its site by improving its search system. See http://research.agency.com/. † “Holiday 2000 E-Commerce: Avoiding 14 Billion in ‘Silent Losses’” (http://www.creativegood.com/ holiday2000). ‡ 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). § Tedeschi, B. “Good Web site design can lead to healthy sales.” (http://www.nytimes.com/library/tech/99/08/ cyber/commerce/30commerce.html). Guernsey, L. “Revving up the search engines to keep the e-aisles clear.” New York Times, February 28, 2001. 368 Chapter 17: Making the Case for Information Architecture 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 environmen- tal 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 coun- try, 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 architec- ture’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 ten- dency is to separate these tools for testing purposes, it makes more sense to mea- sure 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. Running the Numbers 369 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. 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 per- formance 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 ses- sions. 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 com- prehensive 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 satis- fied 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 rele- vant 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 cus- tomers 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 con- sider that make it difficult, if not impossible, to validate such measurements. 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). 370 Chapter 17: Making the Case for Information Architecture 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. Unfortu- nately, 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 num- bers” 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 architec- ture 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 edu- cate this type of person. Stories put him in the shoes of a peer who faces a compara- ble 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 iden- tify 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. Talking to the Reactionaries 371 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 opera- tion for a Fortune 50 company. This person was responsible for the documentation used by thousands of operators manning the phones and answering customers’ ques- tions 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 tem- plates 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 con- sidering that these employees earned only 10 per hour. Worse, turnover was 25 per- cent 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. Any- thing 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. 372 Chapter 17: Making the Case for Information Architecture 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 pro- cedures 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 con- tent 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 con- trolled 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 calcula- tions, and can be incredibly effective: stories enable your prospect, client, or col- league 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 imag- ination take over. Storytelling is really a participatory experience, and that participa- tion 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.) Other Case-Making Techniques 373User 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 enlight- ened 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 evalua- tion 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 informa- tion 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, partici- pants 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 pow- erful 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. 374 Chapter 17: Making the Case for Information ArchitectureComparative analyses Not everyone has a competitor, but you can still compare your site to compara- ble 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 architec- ture-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 inevi- tably 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 ser- vices. 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 infor- mation 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 “informa- tion overload,” few have actually thought about information as important and strategic stuff. They may not have realized that accessible information is a valu- able 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 infor- mation systems like corporate intranets; employees do it for them. Your best tools here are stories that broaden perspectives, competitive analyses that pro- duce anxiety, and experiences, such as “boot camps,” that force people to con- front the pain their sites cause. Other Case-Making Techniques 375Articulation 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 infor- mation architecture is so important: it provides a set of concepts, terms, and def- initions 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 ses- sions that begin with a one- or two-hour-long primer on information architec- ture 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 infor- mation architecture, according to our May 2002 survey. Be ready for this reac- tion 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 jar- gon with alternative, “real-language” descriptions of what information architec- ture 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 pro- cess 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 376 Chapter 17: Making the Case for Information Architecture • 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 archi- tecture, 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 every- one 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 grow- ing 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. A Final Note 377 Business Strategy 18 What is business strategy doing in a book about information architecture? Do they have anything in common? After all, we didn’t have any business strategy courses in our library and information science programs, and it’s safe to say there are very few information architecture courses in the MBA curriculum. In truth, these two fields have existed independently and in relative ignorance of each other heretofore. This historical isolation is about to change. As the Internet permeates our society, managers and executives are slowly recognizing the mission- critical nature of their web sites and intranets, and this awareness is inevitably fol- lowed by a realization that information architecture is a key ingredient for success. Once they’ve seen the light, there’s no going back. Managers will no longer leave information architects to play alone in the sandbox. They’ll jump in and start play- ing, too, whether we like it or not. The good news is they’ll bring some toys of their own to share, and if we look at this as an opportunity rather than a threat, we’ll learn a lot about the relationship between strategy and architecture along the way. In practice, information architecture and business strategy should have a symbiotic relationship. It’s obvious that the structure of a web site should align with the goals and strategy of the business. So, business strategy (often called “business rules”) drives information architecture. What’s less obvious is that the communication 378 should go both ways. The process of information architecture design exposes gaps and inconsistencies in business strategy. Smart organizations make use of the feed- back loop shown in Figure 18-1. Drives design Informs practice Business Information strategy architecture Infuses innovation Exposes gaps Figure 18-1. The feedback loop of business strategy and information architecture On a more theoretical level, we believe the emerging discipline of information archi- tecture has much to learn from the established field of business strategy. This is not an accidental match-up; the two fields have much in common. Both suffer from a high degree of ambiguity and fuzziness. They’re intangible and don’t lend them- selves to concrete, quantitative return on investment analysis. Also, both fields must embrace and influence the whole organization to be successful. Information archi- tects and business strategists can’t afford to work in ivory towers or be limited by narrow departmental perspectives. And finally, information architecture, along with the umbrella disciplines of experi- ence design and knowledge management, creates new opportunities and challenges for business strategy innovation. As the Internet continues to blow gales of creative destruction through our industries, firms that see technology as their salvation will die. Success will belong to those who understand how to combine technology, strat- egy, and structure in keeping with their unique position in the marketplace. Informa- tion architecture will play a role in this vital and relentless search for competitive advantage. The Origins of Strategy Dictionary.com defines strategy as “the science and art of using all the forces of a nation to execute approved plans as effectively as possible during peace or war.” As this definition suggests, strategy has a military history. In fact, its etymology leads us † back to ancient Greece, where we find the term “strat-egos” (“the army’s leader”). Early works such as Sun Tzu’s Art of War and Carl von Clausewitz’s On War are still often quoted in the business world. The concept of “creative destruction” was first formulated by economist Joseph Schumpeter (1883-1950). † “The Historical Genesis of Modern Business and Military Strategy: 1850–1950,” by Keith Hoskin, Richard Macve, and John Stone, http://les.man.ac.uk/ipa97/papers/hoskin73.html. The Origins of Strategy 379Famous Fighting Words “The best strategy is always to be very strong; first in general, and then at the decisive point...There is no higher and simpler law of strategy than that of keeping one’s forces concentrated.” —Carl von Clausewitz “Hence that general is skillful in attack whose opponent does not know what to defend; and he is skillful in defense whose opponent does not know what to attack.” —Sun Tzu “It is a common mistake in going to war to begin at the wrong end, to act first and to wait for disaster to discuss the matter.” —Thucydides “What is our aim? I answer in one word. Victory—victory at all costs, victory in spite of all terror, victory however hard and long the road may be, for without victory there is no survival.” —Winston Churchill This explains why the language of business strategy is filled with military terminol- ogy—positioning the marketplace as a battlefield, competitors as enemies, and strat- egy as a plan that must be well executed to assure victory. It also helps to explain why the field of business strategy has been largely dominated by men who project power and confidence and who convincingly build a case that their plan or model or philosophy is the “one best way.” This is a world where indecisiveness is taken as a sign of weakness. And yet, notice the use of the term “art” in both the dictionary definition and the title of Sun Tzu’s famous text. This is an acknowledgment that business strategy is not pure science. It involves a certain degree of creativity and risk taking, much like our nascent field of information architecture. Defining Business Strategy Over the past few decades, Michael Porter, a Harvard Business School professor and successful entrepreneur, has played an influential role in leading and shaping the field of business strategy and our understanding of competitive advantage. In his brilliant book On Competition (Harvard Business School Press), Porter defines strategy by contrasting it with operational effectiveness: Operational effectiveness means performing similar activities better than rivals per- form them. Operational effectiveness includes but is not limited to efficiency. 380 Chapter 18: Business Strategy He notes that operational effectiveness is necessary but not sufficient for business success. He then answers the question, what is strategy? Strategy is the creation of a unique and valuable position, involving a different set of activities. He goes on to explain that “the essence of strategy is in the activities—choosing to perform activities differently or to perform different activities than rivals.” It is this strategic fit among activities that provides a sustainable competitive advantage, which is ultimately reflected in long-term profitability. Alignment So how do we align our information architecture activities with business strategy? Well, we need to begin by finding out what strategies our business is pursuing. This can be nearly impossible in large organizations. As consultants to Fortune 500 firms, we’ve rarely had much access to the senior executives who (we assume) could articulate their company’s business strategy. And the people we’ve worked with often haven’t had a clear idea about the overall strate- gic direction of their organization and how their web site or intranet fits into that bigger picture. They’ve often been left in the dark. While we wait for the senior executives and corporate strategists to become more involved in their sites, there are things we can do. Stakeholder interviews provide an opportunity to talk with senior managers. While they may not be able to rattle off a concise explanation of their company’s strategy, these managers can be helpful if you ask the right questions. For example: • What is your company really good at? • What is your company really bad at? • What makes your company different from your competitors? • How are you able to beat competitors? • How can your web site or intranet contribute to competitive advantage? It’s important to keep digging. You need to get beyond the stated goals of the web site or intranet and try to understand the broader goals and strategy of the organiza- tion. And if you don’t dig now, you may pay later, as we learned the hard way. A few years ago, we had an uncomfortable consulting experience with a dysfunctional busi- ness unit of a Fortune 100 firm. We had completed an evaluation of the company’s existing web site and were in the process of presenting our recommendations to a group of senior managers. Halfway through the presentation, the vice president of the business unit began to attack our whole project as a misguided effort. The thrust of her assault can be summed up in the following question: “How can you design our web site when we don’t have a business strategy?” Defining Business Strategy 381 Unfortunately, we didn’t have the understanding or vocabulary at the time to clearly answer this question. Our ignorance doomed us to a half hour of suffering, as the VP cheerfully pulled out our fingernails. It turned out that her hidden agenda was to get us to write a blunt executive summary (which she could then pass to her boss), stat- ing that if this business unit didn’t have more time and resources, their web efforts would fail. She was asking the right question for the wrong reasons. We were more than happy to satisfy her request for a brutally honest executive summary (connecting the dots between our IA and their BS), and we managed to escape the relationship with only a few bruises. The more permanent outcome of this engagement was a personal conviction that information architects need a good understanding of business strategy and its rela- tionship to information architecture. Strategic Fit Let’s draw an example from Porter’s On Competition to learn how to connect the dots between business strategy and information architecture. Porter uses “activity- system maps” as a tool for examining and strengthening strategic fit. Figure 18-2 shows an activity-system map for Vanguard, a leader in the mutual fund industry. No first class Bonuses tied to cost savings travel for execs Efficient investment Very low rate No Loads management of trading approach Very low Long-term Active Strict cost expenses passed investment shareholder control on to client encouraged education Limited Straightforward Online Direct advertising client communication information distribution budget and education access Figure 18-2. An activity-system map for Vanguard As Porter explains, Vanguard is widely respected for providing services to the conser- vative, long-term investor, and the company’s brand is very different from that of competitors such as Fidelity and T. Rowe Price. Vanguard strives for a strategic fit between all its activities, from limiting the costs of advertising and business travel to fostering shareholder education and online infor- mation access. Low costs and informed investors go hand in hand. 382 Chapter 18: Business Strategy This strategy is no accident. As founder John C. Bogle explains, early in its history, Vanguard established “a mutual structure without precedent in the industry—a structure in which the funds would be operated solely in the best interests of their shareholders.” Noting that “strategy follows structure,” he suggests that it was logi- cal to pursue “a high level of economy and efficiency; operating at bare-bones levels of cost, and negotiating contracts with external advisers and distributors at arms- length. For the less we spend, the higher the returns—dollar for dollar—for our shareholder/owners.” What’s exciting is that this strategy is evident in the design of Vanguard’s web site, the main page of which is shown in Figure 18-3. First of all, notice the clean page with minimal branding. There are no fat logos or banner ads; usability is obviously a high priority. Second, notice the lack of technical vocabulary for which the financial industry is renowned. Vanguard makes an explicit point of using “plain talk.” Figure 18-3. Main page of the Vanguard web site And as you explore, you see an emphasis on education, planning, and advice woven throughout the site. Tools like a site glossary, a site map, and a site tour help cus- tomers to navigate and educate themselves at the same time. John C. Bogle, “The Vanguard Story,” http://www.vanguard.com/bogle_site/october192000.html. Strategic Fit 383 Vanguard’s web site is distinctive, and that’s how it should be. It’s different by design and reflects the company’s unique strategy. For web sites, structure follows strategy, and the best companies exhibit individuality in both areas. That’s why Dell.com is different from Compaq and IBM, and Landsend.com is different from L.L. Bean and J. Crew. Rather than copy their competitors and engage in zero-sum price wars, these compa- nies work to understand, leverage, and strengthen their unique positions within their industries. And their web sites are increasingly acknowledged as important strategic assets that can be used to achieve competitive advantage. Exposing Gaps in Business Strategy Information architectures should solve problems and answer questions. Conse- quently, information architects must find problems and ask questions. In our quest to understand how context, users, and content all fit together, we often expose seri- ous inconsistencies and gaps within business strategy, particularly in how it relates to the web environment. In many cases, the problems are fixable. A company known for excellent customer service has neglected to integrate customer support into its web site. Or a widely respected online bookstore risks violating its customers’ trust by secretly featuring search results for publishers who pay a fee. In a healthy organization, the architect can raise these issues and get them resolved. In other cases, the problems are symptoms of an organization in real trouble. Con- sider the following examples, with names omitted to protect the guilty. • A Global 500 company has recently been through a large merger. The U.S. divi- sion has a formal, centrally managed, top-down corporate intranet. The Euro- pean division has several decentralized, informal, bottom-up departmental intranets. Stakeholders on opposite sides of the Atlantic have very different goals and ideas for their intranets. The plan? Design a single integrated intranet to fos- ter the sense of a single, unified company. The reality? Two disparate cultures clashing on a global scale. The tail of information architecture can’t wag this dog. • A Fortune 100 company decides to enter the e-commerce gold rush by throwing 40 million into development of a consumer health portal. After discovering dozens of domestic competitors, they decide to target several European coun- tries, all at once. One tiny problem. They know almost nothing about the health- related information needs or information-seeking behaviors of the people in those countries. And they never get to find out. Eventually the plug is pulled on this out-of-control e-business. When we find ourselves in situations that feel crazy, it’s human nature to pretend things will work out. We assume the executives really do know what they’re doing and that the master plan will become clear soon. But painful experience suggests 384 Chapter 18: Business Strategy