By Andrea Ames, Fellow and Alyson Riley, Member
If you read our article ”Helping Us Think: The Role of Abstract, Conceptual Models in Strategic Information Architecture” in this issue of Intercom, you know that we’re pretty passionate about models. We describe why we believe that modeling an information experience in the abstract is the key to an enterprise-level strategy for delivering consistent, scalable, effective information architectures. Here, we continue the discussion by describing how we developed and validated the IBM abstract, information experience models.
The IBM information architecture toolbox includes four abstract models:
- The Use Model: A complete, coherent collection of patterns that define ideal interactions between users and information—that is, the information they need, why they need it, what they’re doing when they need it, and how they will use it in that context.
- The Content Model: The standard building blocks of content, from the atomic, most granular level to larger “deliverables”—those concrete, stand-alone objects that humans recognize and use—including the subject and structure (presentation) of the content, a content taxonomy, and taxonomy relating metadata to appropriate content chunks.
- The Access Model: The vision for how your target users will find your information used to describe the organization, structure, and interrelationships of chunks of information and full deliverables, as well as the strategy for using a variety of access methods across an information space—methods such as search, browseable navigation, etc.—and providing a big-picture vision for overall navigation strategy, as well as patterns for specific access methods for individual collections of content or deliverables.
- The Information Model: The relationships between the other models, uniting them into a coherent whole and helping architects “put it all together” by standardizing the way we assemble the components of the other models in order to create an information experience for a specific kind of product or system.
So how does one go about modeling an information experience? An information experience is about users first, so let’s start there.
Developing a Use Model
To develop a strong Use Model, first develop scenarios that describe user interactions with the product or system. At the enterprise level, ensure that your Use Model defines scenarios for each type of system and subsystem in your solution, or each type of product or offering in your portfolio. For example, at IBM our Use Model scenarios address hardware offerings, software offerings, services offerings, and solutions that span offering categories. No matter your particular scope, ensure that your Use Model scenarios address questions, such as:
- Who are the users?
- What are their goals?
- What’s the purpose of the product, system or solution?
- What tasks will users do with the product? (Be sure to decompose high-level tasks into lower-level tasks or procedures. Identify prerequisite tasks and any dependencies for successful task completion.)
- Which tasks are the high-value ones necessary for achieving a broader goal, and which ones are tasks merely required as a result of product design or system features?
Next, develop a set of information-use scenarios that define the ideal, most effective ways for users to interact with the information they need. These scenarios should mirror the product- or system-use scenarios and answer questions such as:
- What information do users need to complete the tasks defined in the product- or system-usage scenarios, and at what points during product use is the information needed?
- What information do users need to achieve their broader business or personal objectives?
- How will users experience or interact with that information, both for their own goals and as required by product or system tasks? Be sure to address this question for each of the necessary tasks you have defined in your product or system lifecycle.
- How close to the product or system user interface does the information need to be? Is it the interface? Or does it support the interface? Is it task-disruptive to take the user away from the primary product or system interface to access the information they need?
The result of your Use Model development activities will be a standard set of scenarios that describe an optimal user experience with information as well as a standard set of user information requirements for specific product or system contexts.
Developing a Content Model
Developing a Content Model can be tricky. It steals concepts from data modeling, software engineering, library science, taxonomic wizardry, and time-tested technical communication. Put simply, a Content Model defines:
- Subjects of information, or a common collection of terms that describe what the information is about. Attempting to define common subjects in an enterprise-level taxonomy is not easy, but it’s a smart investment. A common subject taxonomy keeps an enterprise-level content space free of confusing synonyms and inconsistent terminology.
- Atomic units of information, or the information objects that you can’t break down into smaller pieces without making them meaningless. DITA (Darwin Information Typing Architecture) provides helpful hints: its information types (concept, task, and so on) and specializations are good starting points for some design contexts. Other design contexts may require different kinds of atomic information units; in a retail Web experience, for example, you may be working with atomic units like product specifications, price, and buyer reviews. Bottom line: identify and standardize your list of required information units.
- Information deliverables (or delivery vehicles), or how you combine atomic units of information and common subjects to deliver understandable, stand-alone information products that humans will see and touch.
- Presentation templates, or how you will use media to present the information deliverables for human consumption. Consider the templates necessary to ensure an integrated, consistent user experience; develop new templates by starting with those that are most impactful to your user’s information experience or that support business priorities.
When developing your Content Model, lean heavily on your Use Model by taking a look at what it tells you about your users’ information needs:
- What subjects and atomic units of information will your users need? For example:
- Do they need help manipulating elements of the product or system?
- Do they need help completing a complex task with serial sub-tasks?
- Do they need help determining how known concepts are expressed in the product or system?
- Do any of their tasks in the product or system require learning a new concept?
- How can you structure and combine these building blocks of information in ways that reflect the user’s task flow?
- What presentation style and media will best communicate this information to users given their skills and the tasks they’re trying to accomplish? For example, interaction or information? Text or images? Static images or moving images? Audio? Combinations thereof?
- What deliverable (or delivery vehicle) will work best? Product- or system-embedded information? Topics and multimedia in a hypertext environment? Animation with voiceover? Podcast?
An enterprise-level Content Model will typically include many combinations of presentation styles and deliverables. (It will also help you develop classification metadata, but that’s too big a topic to explore here.) Be sure that each combination is really necessary as specified by scenarios in your Use Model—otherwise, you introduce gratuitous complexity in your information experience. Less is more.
Developing an Access Model
An Access Model builds on discoveries made through Use and Content Model development by defining and standardizing the ways in which users find the information they need—the stuff we tend to think about first when we hear the term “information architecture.” It defines the overarching strategy for user access to information, and depicts (with text, images, wireframes, and prototypes) how a collection of access methods work together to accommodate the wide range of user behaviors when navigating to and within an information space. A comprehensive Access Model (Kalbach 2001) defines a strategy for supporting the following types of typical information-usage behaviors:
- Searching for and finding relevant information
- How will users find your information in the first place?
- How do your chosen approaches for information delivery impact its findability?
- What are the likely entry points into your information architecture—marketing pages, out-of-box materials, Google, “likes” on Facebook?
- How will your information architecture promote search engine optimization (SEO)?
- Following leads when searching
- How will users find their way through your information space once they’ve found it?
- Where do your users want or need to go next?
- How will you enable discovery?
- Scanning an information space to develop a sense of its contents
- How will you enable users to develop a good mental model of the information that a particular space contains?
- How will users self-locate within a navigation hierarchy or other kind of structure?
- Staying informed about updates or new content
- How will you ensure that users have the most up-to-date content?
- How will you communicate the availability of fresh or refreshed content?
- Evaluating information for relevance
- How will you help users discover the value of your information as it relates to their goals and needs?
- What techniques will you use to distinguish information objects from one another?
- Will you allow users to apply their own metadata to help themselves and others with differentiation?
- Using information to achieve a goal
- What techniques will you use for in-page or in-task wayfinding and discovery?
- Will you allow users to customize the information or the space for their own use, and if so, how?
Once you have defined your overarching Access Model, drill down into the user experience and interface associated with specific areas of access—things typically associated with IA work like navigation patterns, labeling schemes, and linking strategies. These access-related patterns may evolve as technology, business requirements, and user needs change over time; however, the overarching model will weather evolutionary pressure if rooted in a solid understanding of the audience and their goals.
Developing an Information Model
An Information Model pulls together the Use Model, Content Model, and Access Model. The Information Model provides guidance for combining the pieces of the other models to create a coherent whole. To create an Information Model, use the results of previous modeling work to define:
- A high-level information architecture that defines the entire information strategy and experience.
- One or more low-level information architectures that focus on the details of specific pieces of the total information solution. For example, business strategy or product usability issues might require an IA to give particular focus to the information strategy in support of a product out-of-box experience—one specific piece within an overarching information architecture.
Following an Information-Development Process
As with any kind of information, follow a good process to develop your models. After you’ve drafted them, be sure to validate your modeling work. It’s difficult to validate an abstract concept; as a result, consider:
- Conducting your own heuristic evaluation to ensure that the Information Model is comprehensive, complete, coherent, consistent and scoped appropriately
- Developing aspects of concrete information experiences and testing those, refining the model based on the data you collect
- Applying the model to one or more information experiences and testing those, refining the model based on the data you collect
Once you apply the Information Model to concrete product- or system-data—transforming the abstract model to a concrete architecture—you can do all the scenario-based retrievability testing, prototype walk-throughs, and Web analytics work that IAs normally do. When you do this kind of validation, be sure to test several different instances of the applied model to ensure that it works when instantiated with various types of products or systems.
Want more information?
Andrea and Alyson will be presenting the abstract IBM architecture models at the 2012 STC Summit, and Andrea will be digging deeply into the Access Model to discuss the IBM progressive information disclosure model. Join them for an interactive discussion of what the models do and how we apply them in our everyday roles as strategic IAs.
References
Kalbach, James. “Designing for Information Foragers: A Behavioral Model for Information Seeking on the World Wide Web.” Internetworking, Internet Technical Group newsletter. 27 January 2001. Available at www.sandia.gov/itg/newsletter/dec00/article_information_foragers.html.
