Modules and Wholes

Most discussion of information architecture relates to finding information. There are articles people want to read, or catalog items people want to browse. What receives less attention in information architecture is how to organize user interfaces to perform tasks, particularly tasks involving complex, drawn-out processes. After recently working on an enterprise application, I have concluded that task-oriented information architecture involves unique issues.

One thing that makes task oriented information architecture a challenge is that it can be difficult to develop a solid understanding how users do their tasks, particularly if there is a lot of task variety. Consider the diagram below.

In creating an IA, the central question whether to organize screens around "objects" (concrete entities such as customers, or products) and then have screens relating to subordinate processes coming off each object. For example, first locate object 1, then do process 1 for object 1, then process 2, etc. Or, is the best way to organize screens first around processes, then have subordinate screens relating to object available while in the mist of a process?

For a one-off task, the question can be answered fairly easily. One can structure the task so that there is only one object and several process steps. Or less commonly, we force a process, and processing of all objects must be done at the same time. If you have more than one object or more than one process in these cases, you need to repeat the whole cycle.

A task oriented IA becomes much more complicated when you don't know in advance how many objects or processes might be involved. For example, if the IA needed to address the processing of travel-related information, we might need a certain elasticity in the IA to accommodate different scenarios. Some people will travel individually, others in groups (with several customers doing the same thing.) Some people will have accounts involving several trips. Customer representatives may need to process numerous items of unrelated customers at the same time. We don't know how many separate products (tickets, hotels) will be associated with any single travel journey. Groups may start with the same itinerary, so that doing processes together makes sense, but the group may break apart after a conference ends and then have separate itineraries. While my IA experience was not related to travel (I've tried to choose an example that might be easier to understand than what I worked on), I hope these examples give a flavor of some of the kinds of issues that can arise.

My experience suggests that traditional card sorting methods are not ideal for task oriented IA. The reason is that labels are often not meaningful outside a scenario. What makes sense when there is just one customer makes less sense when there is a group of customers. For scenarios to be really useful, one needs to cover off all the likely scenarios, not just the major ones.

When experimenting with task-oriented IA, here are some issues to keep in mind:

• Activity structure. Are tasks batched around a group of items, or around a sequence of events? Interestingly, the same mix of objects and processes may be done in different ways, depending on who is doing the work, and what the context is. How a customer representative processes a form will be different depending if the customer dropped in his local branch to deliver it, or whether it was mailed in and is sitting on a stack with other people's forms.
• Inputs. How is information received and entered? Does it come in a clump, or in dribbles? Are inputs calendar-driven, so you can predict when you will receive them, or can they arrive at any time?
• Time dimension. Are tasks done in parallel on the same timeline, or do they go on divergent timelines? Are sequences of activities fixed or flexible? Sometimes activities start at the same time, and get processes concurrently, though the services themselves involve different durations.