Stewarts article brings to mind the problems with capturing process and tasks when observing users perform their jobs in the early stages of contextual design. The last thing the observer wants to do is to influence what the user is doing. Asking questions on how to improve and working through the logic of the tasks and conditional elements of the task will come later. Understand the conditions the user has in place, don't ask why at the beginning, just capture as if you were going to have to repeat the exact same task.
The next step after capturing the information allows for understanding why there is a "wrk" button (using Stewart's example). Understanding what is behind the conditions will help build an application that is used as it maps to the user's cognitive understanding of the process. Some of these conditions may/can be broken when they are built into an algorithm. Breaking too many of the conditions can create an application that is quite foreign to the user and therefore possibly shunned.
One method of getting through the non-essential conditions is to use a transitional process. This would entail keeping some of the non-essential conditions in an applications interactive process with the user, i.e. sending an e-mailing to verify a fax was received. Including a verification notification for delivery of information may be included as it is engrained in the user's work pattern. As the user's learn to trust and respect the information in the new application they are using is reliable the verification notice may be altered to show only information not delivered or turned off completely.
Getting back to the starting point, if an observer would propose turning off the verification process and notification in the task capturing procedure there may be one individual that understands why there is not a verification process. The application being developed may be for many users that use the standard procedures. The user being observed may offer suggestions and these should be captured.
Web Mentions
