Wednesday, May 03, 2006


task oriented information architecture

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:

Comments: Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?