Talking about Information Models…
With the assistance of very proactive information users, I developed and evolved an information model which I call an “Info Pack” and which provides a bridge between business information requirements and the information provided with a software product.
An Info Pack is an information model that defines
- the structure of information relationships
- the access mechanisms available to users
- content that meets user task objectives
I have developed Info Packs as performance support for a range of user activities from project life cycle support to minimal mentored learning programs. The Info Pack has worked for users because, like a good house plan, it addresses the three issues of structure, access, and content.
What is an Info Pack?
To the user, an Info Pack is a Help file with a permanently visible table of contents (TOC) that has between 10 and 15 main topics. There are no apparent sub-topics but each main topic expands to detailed information through pop-up topics, supplementary windows, and numerous attachments.
The first main topic is a relational diagram that shows how the objects in the information domain relate to each other. The remaining topics present information that supports user task outcomes. If appropriate, I include two standard topics: a confusion resolution, “Why does…?” topic, and a general reference topic that provides alternative access to the attachments that are also accessed, in context, from the main topics.
Attachments may be
- documents (task check lists, reference papers, cheat sheets, or quick-try out tutorials)
- sample source files (code, templates)
- short presentations
- video clips of application use sequence
Project-wise, each main topic, its pop-ups, and supplementary windows form a single document file within the Help authoring project. Installed, an Info Pack is a directory that contains the Help file, attachment files, and supporting files.
The main topics play a key role in making the Info Pack model an enabling model. They are the visible structure of the information domain and its internal relationships. Together with the indexes and the standard topics, they are visible access mechanisms to information. Finally, because they are themselves familiar groupings of task outcomes, they present “content that meets user task objectives.”
How do you develop an Info Pack?
The design and development process for an Info Pack follows a simple analysis flow that identifies the physical attributes of the product that the user sees: main topics, graphics, and attachments. I use the following “rules of thumb” to determine which content is presented in which way.
1 Analyze users and their tasks to determine what users are trying to achieve (task outcomes).
2 Discard task outcomes that are not important to the user for business or personal reasons.
3 Group related outcomes. Each group of outcomes becomes a candidate main topic in the TOC.
4 Identify user tasks within each group of task outcomes. Choose significant tasks where people fall over and hit roadblocks (if your user audience is starting up) or where good techniques extend user options and increase productivity (if your user audience is middle to experienced). Also consider tasks where the organization’s own way of doing business is significant. The user tasks you identify drive the development of the content of the main topics.
5 Identify conceptual misunderstandings about the tools that support user tasks and the processes that users follow. Present information to clarify concepts through text and graphics in the main topic.
6 When user tasks are supported by application software, identify parts of the interface that “hide” the functionality the user needs. Obscure but strategic functions are good candidates for a commented video attachment like a Lotus ScreenCam® clip.
7 Identify tasks that need “good practice” guidelines and consider providing those guidelines through a document attachment that has hints, a check list, or a “human” procedure. Here, gather from others. Some users may already have material you can attach. Good practice guidelines are the sorts of things that people print and pin up.
8 Identify tasks where cloning and customizing is a good startup or ongoing strategy. Such tasks invite attachments of code, templates or samples.
9 Identify tasks where guided try outs or walk throughs build confidence. Develop a meaningful task scenario with skeleton instructions that give the user opportunities to explore. Be sure to include warnings about fall-over points. The scenario may suit delivery in a document attachment or a supplementary window.
10 Does the organization have business or methodology references that apply to some tasks? Attach them near the task information in the main topic.
What drives what you write, draw, attach? A desire to deliver performance support that the user can find easily and that provides value when the user reaches for the support. Nothing is included that is “I’d like to tell you this.” Everything is driven by “you are likely to ask this question,” “you will probably forget to do this,” or “you will fall in a heap if you don’t know this.”
The early Info Packs that I developed targeted users of a software product but because my objective was to build the user’s feeling of being in control, I included survival information about other software products that were always an impediment to customers using the target product successfully.
The model has been very successful. For example, the success of an Info Pack that supported a complex product release caused customers and field support personnel to demand Info Packs for all subsequent product releases. I am sure the success of the Info Pack came down to some simple principles: the information was readily accessible, the information targeted customer and field concerns such as software migration, and the attachments reduced the lead time to acceptable user performance… very much in the spirit of the principles espoused by John Carroll and other minimalist travellers.