Week 9 - Information Architecture Strategy and Design

Information Architects do not typically have the luxury of one or many years to complete their projects. It’s usually a matter of weeks and months. Moving from research to strategy, then design follows tight schedules with specific deliverables required at specific deadlines. It’s usually a very blurry line between research and strategy, and even though the process of moving from research to administration in the IA life cycle might look linear at a high level, it’s usually a very highly iterative and interactive process with the IA switching back and forth between research and design, whilst maintaining tight budget and schedule constraints.

Putting in place of an IA strategy involves defining and realizing a high-level conceptual framework for structuring and organizing a web site or intranet. This provides any firm or organization a sense of direction or scope necessary to proceed into the design and implementation of the various phases involved in the IA life cycle. The IA strategy is typically detailed in the in an IA strategy report, communicated in a high-level strategy presentation, and made actionable through a project plan for information architecture design. It provides high level recommendations regarding:

·         Information architecture administration

·         Technology integration

·         Top-down or bottom-up emphasis

·         Organization and labeling systems (top-down)

·         Document type identification (bottom-up)

·         Metadata field definition

·         Navigation system design

Putting an IA strategy in place can meet major setbacks within the firm. The absence of a defined business strategy or content can lead to several conflicting discussions and questions from stakeholders that can easily derail the IA, like why the need of an IA strategy when there isn’t any business strategy or content in place. These questions shouldn’t derail the IA because it’s been proven that business strategies, content collections and information architectures co-evolve in a highly interactive manner. In fact, developing an IA strategy usually exposes gaps in business strategies and content collections. This can actually lead to major changes within the organization’s business strategy and content policy. In an ideal situation, the IA should work directly with the business strategy and content policy teams, exploring and defining the relationships between these three critical areas.

Moving from research to strategy shouldn’t be a clear cut, formal or isolated. Strategies for structuring and organizing the site should be considered by the IA before the research even begins. In fact, during the research phase, throughout the user interviews, content analysis and benchmarking studies, the IA should be constantly testing and refining the hypotheses mentally against the steady stream of data being compiled. The point where the IA realizes they’re no longer learning anything new by asking the same questions in the interviews , and are anxious to actually start fleshing out a couple of hierarchies, and start introducing their structures and labels to users, clients and colleagues actually defines when they should start moving from research to strategy.

Developing the IA strategy involves the transition from process to a transition between process and product, thereby creating work products and deliverables by applying methodology. Four steps usually define the IA strategy development process, TACT:

·         Think – convert research data to creative ideas

·         Articulate – diagrams, metaphors, stories, scenarios, blueprints, wireframes

·         Communicate – present, react, brainstorm

·         Test – closed card sorts, prototypes. The test results might lead to a new thinking process, hence re-initiating the cycle.

The results of the above process are strategy phase deliverables:

·         The IA strategy report – detailed strategy, direction, scope

·         The IA strategy presentation – high-level strategy, direction, scope

·         The project plan for design – teams, deliverables, schedule, budget.

The IA strategy is usually brought to life through metaphors, scenarios and conceptual designs. A metaphor can be a very powerful tool for communicating complex ideas and generating enthusiasm. The process of metaphor can be a real stimulant in working with clients and colleagues. The three most important applied in the design of websites are:

·         Organizational metaphors – leverage familiarity with one system’s organization to convey quick understanding of a new system’s organization

·         Functional metaphors – make a connection between the tasks you can perform in a traditional environment and those you can perform in a new environment

·         Visual metaphors – leverage familiar graphic elements such as images, icons and colors to create a connection to the new elements.

Scenarios are great tools for helping people to understand how the user will navigate and experience the site being designed. They also help the IA generate new ideas for the architecture and navigating system. Writing a few scenarios that depict how a certain group of people with specific needs can use the site can help provide a multi-dimensional experience that shows the true potential of the site.

Case studies and stories are a great tool to bring concepts of information architecture to life. These usually help a diversified, none-technical audience of both clients and colleagues get a clearer picture of your IA strategy by comparing and contrasting with other real life and past experiences.

Conceptual diagrams are usually pictorial representations of ideas and concepts.  IAs usually have to explain high-level concepts and systems, and conceptual diagrams come in very handy here. Their various concepts and ideas are put in the form of diagrams which can easily be visualized and understood by various audiences, including stakeholders.

The Strategy report presents the most detailed, comprehensive articulation of the IA strategy. It presents the previous results, analysis and ideas into a single document. This report is usually the largest, hardest and most important deliverable for the IA team. It forces the team members to come together around a unified vision for inform architecture, and requires them to find ways to explain or illustrate that vision so that clients and non-IA colleagues will understand their jargon. Organizing the report is one of the hardest tasks to accomplish since the IA strategy isn’t linear, but a report forces a linear presentation. A typical IA strategy report can contain the following major sections:

·         Executive Summary – a high-level outline of the goals and methodology, major problems and major recommendations

·         Audience & Mission/Vision for the site – restate the mission statement of the web site

·         Research – Includes lessons learned from Benchmarking, User interviews and Content Analysis

·         Architectural Strategies and Approach - re-define the main focus of the strategy and how it’s going to work by outlining the various strategies put in place.

·         Content Management – provides a reality check by discussing how these IA architecture recommendations will impact the content management infrastructure.

·         Recommendations – list of recommendations to be applied to the entire site.

The Project Plan for IA design should be created as a part of the strategy phase deliverables. This plan should address the following:

·         How to accomplish the various tasks

·         Time it’ll take to accomplish specific tasks

·         Responsible party/parties for each task

·         Task deliverables

·         Task dependencies

This plan forms the bridge between strategy and design and can be integrated with plans from other teams (integration design, content authoring or application development) toward a structured schedule for overall site design. Short-term plans usually define a process of design changes that can and should be made immediately to improve the IA. The long-term plan presents a methodology for fleshing out the IA, noting interdependences with other teams where appropriate.

Without any form of presentation and discussion, the best recommendations may never “Go Live”. It’s often a best practice to make one or more presentations to the stakeholders to understand your recommendations. This might be just a single presentation to the web site or intranet strategy team, or dozens of presentations to various departments to achieve organization-wide understanding and buy-in.  The IA needs to think about these presentations from a sales perspective since success is usually defined by the extent to which you can communicate and sell your ideas in a clear and compelling manner.

The landscape shifts dramatically when we cross the bridge from research and strategy into design. The emphasis moves from process to deliverables since the IA is expected to move from thinking and talking to actually producing a clear, well-defined information architecture. Ideas must be committed to paper to shape the user experience. The work in this face is so strongly defined by context and influenced by tacit knowledge. The design decisions made, and the deliverables produced will be informed by the total sum of the IA’s experience. The IA paints on a vast, complex ever-changing canvas. Although design focuses on deliverables, process is as important during design as it is during research and strategy.

IAs should follow a set of guidelines for Diagramming an Information Architecture. They rely upon visual representations to communicate their work, whether it’s to help sell the value of IA to a potential client or to explain a design to a colleague. Even though there’s limited information on how best to visually represent information architectures, there are a couple of good guidelines to follow as the IA documents her/his architecture:

·         Provide multiple views of the Information Architecture

·         Develop those views for specific audiences and needs

·         Whenever possible, present IA diagrams in person, especially when the audience is unfamiliar with them.

·         Work with whomever you’re presenting your diagrams to – clients, managers, designers, programmers, to understand in advance what they will need from it.

Communicating visually is a very important component of an IAs design job. The most frequently used diagrams are blue-prints and wireframes. These focus more on the structure of a site’s content than its semantic content. Diagrams communicate the two basic aspects of an information system’s structural elements – content components and connections between content components. A variety of visual vocabularies that provide a clear set of terms and syntax to visually communicate components and their links is now available to help IAs and other designers create diagrams. A good example is Jesse James Garrett’s. Visual vocabularies are at the heart of the many templates used to develop blueprints and wireframes.

Blueprints or site maps show the relationships between pages and other content components, and can be used to portray organization, navigation and labeling systems. High level blueprints are often created by IAs as part of a top-down information architecture process. During the design phase, high level blue prints are most useful for exploring primary organizational schemes and approaches. They map out the organization and labeling of major areas, usually beginning with a bird’s-eye view from the main page of the web site. They are great for stimulating discussions focused on the organization and management of content as well as on the desired access pathways for users. Detailed architecture blue prints communicate detailed organization, labeling and navigation decisions to colleagues on the site development team. They map out the entire site so that the production team can implement the plans to the letter without requiring IA involvement during production. They must present the complete information hierarchy from the main page to the destination pages. They must also detail the labeling and navigation systems to be implemented in each area of the site. Of course, they’ll vary from project to project, depending upon the scope.

Wireframes depict how an individual page or template should look from an architectural perspective. They stand at the intersection of the site’s information architecture and its visual and information design. They describe the content and information architecture to be included on the relatively confined two-dimensional spaces (pages), hence they themselves must be constrained in size. Developing wireframes also help the IA decide how to group content components, how to order them, and which groups of components have priority. Wireframes are usually created for the site’s most important pages – main or home pages, major category pages, and the interfaces to search – and other important applications. They present a degree of look and feel, and straddle the realms of visual design and interaction design. Several best practices are available when creating wireframes.

Content mapping and Inventory bring another dish to the plate during design and production. Here, the IA completes the bottom-up process of collecting and analyzing content. Content mapping is where top-down IA meets bottom-up. The process of detailed content mapping involves breaking down or combining existing content into content chunks that are useful for inclusion in your site. A content chunk is the most finely grained portion of content that merits or requires individual treatment.  Since content is often drawn from multiple sources and in various formats, it must be mapped into the IA so that it will be clear what goes where during the production process. A byproduct pf content mapping is a content inventory describing available content and where it can be found. Depending upon the size and complexity of the web site and the process and technology in place for production, there are many ways to present this inventory.

Content models are micro information architectures made up of small chunks of interconnected content. They support the missing piece in so many sites (contextual navigation that works deep within the site). They rely on consistent sets of objects and logical connections between them to work. They are as much an exercise as a deliverable. While the primary output is a useful IA deliverable that informs the design of contextual navigation deep within a site, the process also generates two invaluable secondary benefits – first, content modeling forces us to determine which content is most important to model. Second, it also forces us to choose which of the many metadata attributes are the ones that will make your content model operational.

The development of controlled vocabularies is associated with two primary types of work products – metadata matrixes that facilitate discussion about the prioritization of vocabularies and an application that enables the IA to manage the vocabulary terms and relationships. The IAs job is to help define which vocabularies should be developed, considering priorities and time and budget constraints. A metadata matrix can help the IA walk clients and colleagues through the difficult decision-making process, weighing the value of each vocabulary to the user experience against the costs of development and administration.

Design Collaboration brings together all parties involved in putting everything together toward developing the site – IAs, visual designers, developers, content authors, or managers. Design sketches and web prototypes are two of many tools used for merging different ideas.