A transactional system has information going in both directions: Users enter information into the system as they do their business, and other users pull information out. The information going into an online e-commerce system is highly structured and the user has no control over where the information goes and to a large extent, what it looks like. But when the system is used to support product or service development, the user has considerably more latitude. Or at least, should have.
After all, we’re talking about project contributors here, and the goal of any project should be to allow all contributors to be as productive as possible, and if that means allowing them to post defects, or change source code, or alter feature priorities, or update the notes attached to a requirement, then the last thing you want to do is get in the way.
Unfortunately, with greater freedom comes greater responsibility. The user is expected to properly categorize the information he or she is adding to the system. If the system is set up to support a hierarchy of information, the user is expected to put the information in the right place in the hierarchy. The problem is that you encourage your users to add such information at the same time that you throw organizational roadblocks into their way. What can you do to mitigate the pain?
One such method is to automatically fill out as much contextual information as you can. If the user is involved in only one project and they create a defect report, then chances are pretty good that the defect relates to their current project. Unfortunately this is not always true – sometimes they are part of a team that is working on a number of projects simultaneously, and the users bounce from one project to the next. So another approach is to remember the last project the user touched in some way or other, and use that one as the default. Of course, this could still be wrong, so it is important to remember a few possibly relevant contexts for the user, and put them on the top of a drop-down list of contexts. All possible contexts must be allowed but the most recent ones should show up first.
Ultimately one of the best methods is to allow the user to declare his or her current context by some means, but it has to be quite easy and it has to be quite visible. The worst situation is where the user must declare a context using an unnatural gesture – that is, a gesture he keeps forgetting to do for whatever reason – and then he gets penalized for not making the gesture. For example, when fixing defects in my favorite IDE (integrated development environment) let’s say the SCM (source code management) system assumes I’m working on Defect A when in fact I’m working on Defect B. Every change I make is logged to Defect A. After a couple of hours, I realize that some or all of those changes must be switched to Defect B. It had better be really easy for me to shift them over to Defect B! Even better, when it is not clear to the SCM system what the context should be, maybe it should ask. True, the best software is invisible. I don’t like to get in the user’s face, but sometimes it’s important enough that you should. In this case, the software had better be truly helpful – if not, the user will disable it. What would be helpful in this situation? Present a list of currently open defects and development tasks, backed by another list of assigned defects and tasks which the user can open in a single gesture, backed by a method to access all the items in the repository and open them in a minimum number of gestures.
Good navigation systems present a series of contextual layers to the user, usually immediate, local and global. I call this the “rule of three” for navigation, and it also applies to tasks that require the establishment of context such as the above scenario. Here as in navigation, each layer of context is less likely than the previous layer. While this should be pretty obvious to anyone developing user interfaces, it is by no means ubiquitous because it is so hard to achieve. How does the development environment know what the user is most likely to want to do? It has to know what the user’s role is. It must know what they usually do. It has to keep track of their daily schedules and looming deadlines. It has to be deeply linked into to all the other applications the user needs each day. It must be the medium into which the user is immersed when they are doing their job.
This is by no means a new idea. In fact, Intel researchers are already working on something that they call immersive connected experiences, and other research groups are working on this type of technology too. But it is difficult, as you can see from the fact that it is a research program and not a real product. Now I’m very keen to see it come to fruition, but in the meantime we can consider commercially viable intermediate steps that will help us get closer to the goal.
Let’s consider another example: Product line documentation. The purpose of a product line (as opposed to individually crafted products) is to reuse research and development as much as possible. Thus for example the same documentation artifact can be added to the complete documentation package for product A, and product A’, and product AA, and product A” assuming they are all minor variations of each other. When the technical writer finishes a documentation snippet, she should be presented with a list of other products to which the snippet is likely to apply, at which time she can select the product, or mark it as “not sure” (and later somebody who can make that call will do so), or mark it as “close, but needs further refinement” for one of the other products. This kind of suspecting method is very useful because it doesn’t send an email to the person responsible for the decision – he will find it on his to-do list for consideration at the right time.
There is a real commercial benefit to understanding the user’s context. The more closely you track what the user is doing, the better you can track her hours on the various projects in which she is involved. Better tracking not only allows you to bill your customers (internal and external) better, but it also allows you to better predict future projects. You can never go wrong with quality data.