Section 10.3. Context

10.3. Context

For practical purposes, an investigation of the business context can be a good place to start. It's critical to begin projects with a clear understanding of the goals and an appreciation of the political environment. Ignoring business realities is just as dangerous as ignoring users. A perfectly usable site that fails to support business goals won't last long. The term "user-centered design" is valuable insofar as it moves the pendulum away from executive-centered design, but don't let that pendulum swing too far.

Of course, context isn't just about politics. We also need to understand goals, budgets, schedules, technology infrastructure, human resources, and corporate culture. Legal issues can also be important, particularly in heavily regulated industries. All of these factors can and should influence the shape of the information architecture strategy.

10.3.1. Getting Buy-In

Research is not a one-way street. While conducting your investigation, it's important to recognize the value of building awareness and support for your project. After all, you're not a scientist studying rats. Your human subjects will have their own set of questions and concerns. For example:

• Who are you and why are you asking me these questions?

• What's information architecture and why should I care?

• What's your methodology and how does it relate to my work?

The way you answer these questions will influence the level of support you receive throughout the project. Since most large sites today depend upon interdepartmental collaboration and decentralized content ownership, it's impossible to succeed without broad buy-in. For this reason, you'll want to weave elements of presentation and persuasion throughout the research process.

10.3.2. Background Research

When a project begins, an information architect's head is filled with all sorts of good questions.

• What are the short- and long-term goals?

• What's the business plan? What are the politics?

• What's the schedule and budget?

• Who are the intended audiences?

• Why will people come to the site? Why will they come back?

• What types of tasks should users be able to perform?

• How will content be created and managed? And by whom?

• What's the technical infrastructure?

• What worked in the past? What didn't?

But just asking the right questions is not enough. You need to ask them of the right people in the right way at the right time. You must be very focused in how you use people's time and realistic about who can answer which questions.

Consequently, it's good to begin with a review of background materials. Sometimes the best way to learn about the future is to dig into the past. Get your hands on any documents that relate to the site's mission, vision, goals, intended audiences, and content. Also, try to find documents that provide a broader picture of the management structure and culture. Organization charts are really valuable if you're an outside consultant, particularly when working on intranets. They capture an important component of the users' mental model of the organization and will help you determine potential stakeholders and user groups for interviews and testing.

A revealing exercise is to compare the vision that preceded the current web site with the actual site itself. In some cases, we've seen elaborate PowerPoint presentations, hundreds of pages long, that paint a tremendously ambitious picture of what the web site should be. And then we've looked to the Web and found a small, poorly designed site with limited functionality. This gap between vision and reality is a red flag, suggesting misunderstanding between the managers who produce the slides and the team who must build the site. Great visions are useless without the time, money, and expertise to implement them. In these cases, you'll need to rein in expectations quickly.

10.3.3. Introductory Presentations

When you're kicking off an information architecture project, it's worth taking time for an introductory presentation. It's good to get authors, software developers, graphic designers, marketing folks, and managers all on the same page in understanding the following issues.

• What is information architecture and why is it important?

• How will the information architecture relate to the other components of the site and to the organization itself?

• What are the major milestones and deliverables?

These presentations and the discussions they provoke can identify potential landmines and foster productive relationships between teams. They are especially useful in building a common vocabulary that helps people communicate with one another more successfully.

10.3.4. Research Meetings

In the early 1990s, we held full-day marathon meetings with our clients' web teams to learn as much as possible about mission, vision, audience, content, and infrastructure, and to begin fleshing out a framework for the information architecture. In those days of small, centralized web design teams, one mammoth research meeting would often suffice. Today, the design and production of web sites is often more complicated, involving several teams drawn from different departments. This distributed reality may call for a series of targeted research meetings. Consider the following three meetings and their agendas.

10.3.4.1. Strategy team meeting

In many organizations today, there's a centralized strategy team or working group that's been tasked with management of the web or intranet effort. It's this strategy team that sets the high-level goals, defining the mission, vision, intended audience, content, and functionality. This is the group that deals with the big balancing act between centralization and autonomy.

Because of the need to establish trust and respect, face-to-face meetings with this team are essential. Only by having these meetings will you learn about the real goals of the project and the hidden landmines in your path. And only during face-to-face conversations will you reach a comfort level that allows both you and your colleagues to ask the difficult but necessary questions.

It's important to keep these meetings small and informal. Five to seven people is ideal. If the group gets too large, political correctness takes over and people won't talk. As far as the agenda goes, you'll want to hit on some of the following questions:

• What are the goals for this site?

• Who are the intended audiences?

• What is the planned content and functionality?

• Who will be involved in this effort?

• When do you need to show results?

• What obstacles do you anticipate?

However, the key in these meetings is to follow your nose. Be ready to dig deeper into the most interesting and important topics that come up. The worst thing you can do is rigidly stick to a formal agenda. Think of yourself as the facilitator, not the dictator. And don't be afraid to let the discussion wander a bit. You'll learn more, and everyone will have a more enjoyable meeting.

10.3.4.2. Content management meeting

The content owners and managers are the people you'll want to engage in detailed discussions about the nature of the content and the content management process. These people typically have lots of hands-on experience and a perspective more informed by bottom-up realities. If you can establish a rapport, you might also learn a lot about the culture and politics of the organization as well. Questions for these folks include:

• What are the formal and informal policies regarding content inclusion?

• Is there a content management system that handles authoring and publishing?

• Do those systems use controlled vocabularies and attributes to manage content?

• How is content entered into the system?

• What technology is being used?

• What content does each owner handle?

• What is the purpose of the content? What are the goals and vision behind this content area?

• Who is the audience?

• What is the format of the content? Is it dynamic or static?

• Who maintains the content?

• What future content or services are planned?

• Where does content originate? How is it weeded?

• What legal issues impact the content management process?

10.3.4.3. Information technology meeting

You should meet with the system administrators and software developers early on to learn about the existing and planned technical infrastructure that will support the web site or intranet. This provides a good opportunity to discuss the relationships between information architecture and technical infrastructure, as well as to build trust and respect. Remember, you depend on these folks to forge the connection between ideas and implementation. Questions include:

• Will we be able to leverage content management software (CMS)?

• How can we create a metadata registry to support distributed tagging?

• Does the CMS handle automated categorization of documents?

• What about automated browsable index generation?

• What about personalization?

• How flexible is the search engine?

• Will the search engine support integration of a thesaurus?

• Can we get regular access to search logs and usage statistics?

Unfortunately, the IT groups in many organizations are swamped with work and don't have the time to support information architecture and usability efforts. It's important to identify this problem early and develop a practical, realistic solution. Otherwise, your whole effort can stall when implementation time arrives.

10.3.5. Stakeholder Interviews

Interviews with opinion leaders or stakeholders are often one of the most valuable components of the business context research. These interviews with senior executives and managers from a variety of departments and business units allow for broader participation in the process and bring new perspectives, ideas, and resources to the table.

During these interviews, the information architect asks the opinion leaders open-ended questions about their assessment of the current information environment and their vision for the organization and its web site. It's worth taking the time to explain your project to these folkstheir political support may be more important in the long haul than the answers they give during the interview. Sample questions for an intranet project include:

• What is your role in the organization? What does your team do?

• In an optimal world, how would your company use the intranet to build competitive advantage?

• In your opinion, what are the key challenges your company intranet faces?

• What enterprise-wide initiatives are occurring that the intranet strategy team should know about?

• Do you use the existing intranet? If not, why not? If so, what parts of the intranet do you use? How often?

• What incentives exist for departments and employees to share knowledge?

• What are the critical success factors for the intranet?

• How will these factors be measured? What's the ROI?

• What are the top three priorities for the intranet redesign?

• If you could tell the intranet strategy team one thing, what would it be?

• What question should we have asked that we didn't?

As with the strategy team meeting, these interviews should be informal discussions. Let the stakeholders tell you what's on their minds.

10.3.6. Technology Assessment

In our dream world, we would design our information architectures independent of technology, and then a team of system administrators and software developers would build the infrastructure and tools to support our vision.

In the real world, this doesn't happen very often. Usually, we must work with the tools and infrastructure already in place. This means that we need to assess the IT environment at the very beginning of a project so that our strategies and designs are grounded in reality.

This is why it's critical to talk with IT folks up front. You'll want to understand what's in place, what's in process, and who's available to help. Then you can perform a gap analysis, identifying the disconnects between business goals, user needs, and the practical limitations of the existing technology infrastructure.

You can then see if there are any commercially available tools that might help to close these gaps, and you can initiate a process to determine whether it's practical to integrate them within the context of the current project. (We'll discuss tools for information architects in more detail in Chapter 16.) Either way, it's much better to come to terms with these IT issues early on.