One important input that information architects receive from business analysts is swim-lane diagrams. If you need a reminder, search for “swim-lane diagram” on the web. These show how a process threads through the various participants involved in moving it from start to finish.  We have already mentioned how to analyze the information needs for a participant, given a specification of task requirements.  But the swim-lane diagram points to the collaborative aspects of solutions design.  As the process flow crosses a swim-lane, ownership of the process passes from one participant to another (let’s call them P1 and P2 respectively). At that visually unremarkable crossing point, we actually have a variety of considerations that massively affect the overall solution we are building.

Here are some of them:

• Participant Profile – what are some characteristics of the participants that influence solutions design
• Notification Method – how does P2 know he has been given ownership
• Collaboration Content – how do the participants message each other
• Allowed Actions – what are the allowed patterns of request and response.

These decisions affect both the information structures that we build and the user experiences we present.

To illustrate Participant Profile, consider an online credit card application.  The person applying for a credit card might participate in the process just once.  The agents who process credit card applications typically do so in large numbers.  A manager handling exceptions or escalations might have occasional involvement. This type of profiling highlights differences in process expertise and familiarity, and influences the decisions that follow. Note that this profiling is not user research.  From user research, we might additionally find there are different clusters of behavioural attributes for each participant, leading to their own personas.

Notification deals with how P2 knows that the ball is not in his court.  There are three common patterns; which one to adopt depends on the participant profile and other factors:

• Work queue: for high volume process participation, it is common to have a work queue, which might be called Credit Card Applications in the above example; design considerations include how to assign work items among agents, etc.
• Email with Link: for lower volume participation, such as the manager handling exceptions, it is common to send out an email with a link to the item needing attention
• Email without Link: in some situations, we send an email without any link.  This might be the case acknowledging receipt of a credit card application, or later, saying that the application has been accepted or declined.

Collaboration Content refers to any discretionary content provided by a participant.  This is often in the form of comments, but a priority flag assigned by P1 might be another example.  Design considerations include whether we are allowed to change the comments we exchange with our users, or whether these must be held unchanged and in their totality.

Allowed Actions is best is explained by an example.  Consider the following dialogues

• Business Card request:
  • P1: “please order me new business cards”
  • P2: “sure”
• Help Desk request
  • P1: “can you handle this printer problem for me”
  • P2: “that’s Peter’s area, please run it by him”

They differ in how P2 is allowed to respond.

The Business Card example comprises an INSTRUCTION which we expect will be fulfilled.  Even if it isn’t fulfilled, P2 has agreed to start the processing and later found a problem which was handled by one of the exception flows.

In contrast, the Help Desk example comprises a REQUEST, which may be accepted or declined by P2. This a realistic example in cases where it is hard to provide a rules-based assignment of resources to deal with requests, or where there are resource limitations.  In this case, we have to allow P2 to decline the request.  Detailed process design will determine whether P2 will find P3 to fix the printer, or kick it back to P1 to find P3.

In terms of swim-lane diagrams, the swim-lane for P2 should be considered an abbreviation for a sheaf of P2s with different attributes (printer expert, laptop expert), from which P1 has to make a choice.  This of course is another aspect of Participant Profiling.

This notion of Allowed Actions is valuable in preventing oversimplification of design.  The way I have presented it here is in turn an oversimplification.  The real world is full of other cases that we might want to consider in our solution:

• P1 no longer needs the printer to be fixed
• P2 said they could fix the printer, but can no longer do so and wants to get out of the agreement
• P2 said they could fix the printer, but ignores the request.

It also includes cases we probably wouldn’t build, for example “P2 will let us know next Tuesday if they can fix the printer”.

If you are interested in a deeper understanding of this, look up “conversations for action winograd flores” or “understanding computers cognition winograd flores” for the theoretical underpinnings, or www.actiontech.com for Business Process Software based on these approaches.  These aren’t always easy reads, but do serve to open our mind to the types of information needed to support business processes.