Two useful things to keep in mind when working in HCI (and more generally when considering systems); the
task-artefact cycle, and remembering not to lose sight of the task by becoming overly focused on the current (or to be) tools.
The task-artefact cycle is one of those "obvious once it has been pointed out" things. Quite simply you have a given task, and a decision is made to change/support the task by introduce new or improved tools. Once the new tools are introduced they change the task. This is an obvious statement as it reflects the intended goal of introducing new tools. There are some subtleties involved however. The task may not have changed in the intended way, there may be secondary effects and repercussions elsewhere within a complex socio-technical system, and the task may have been radically altered. Once a new tool has been introduced a task should be re-evaluated (and it is generally useful to measure the effect of an intervention). Of course this isn't always practical and a pragmatic approach needs to be taken scaled to the importance of the task and the scale of the change. The key message here is that more than you anticipated may have changed. Some examples:
- (from Freakanomics) People give blood for free. Giving blood is a Good Thing (tm) to do, and saves lives. In a bid to encourage more giving of blood They decided to provide a modest incentive. Blood giving rates dropped, because an altruistic activity to help others had changed to an mildly unpleasant and inconvenient paid-for activity that wasn't (generally) worth the reimbursement. An interesting example of mentally framing an activity.
- (partly based on hazy memories of listening to Radio 4) In the UK in the last few years sperm donation underwent some procedural changes. Details of the donors became more available, and eventual offspring from the donation now had a 'right' to be able to find out how their paternal genetic donor was. This may have extended to being able to make contact with dear ol' gene-sire. Sperm donation rates crashed. Even before this change was implemented I was really surprised that They didn't seem to see this one coming. I can only guess that there was a bit of a user-centred design failure in that They a) failed to take donors as a human component of the system into account, b) they failed to carry out an adequate information gathering exercise, or c) one way or another they decided to just push on with it anyway (which frequently happens when there is already a Plan, and High Ups Want It To Happen (note I'm not suggested this was the case here)).
- A frequent ideal for providing user-aids is to automate part of a task to free the human up to focus on the 'high level' stuff, e.g. letting designers be creative. One potential side repercussion of this is that the more 'mundane' tasks may be an important component of assisting the person in thinking through a problem, or providing juniors with critical experience.
- Writing text with modern word processing tools can potentially be described as being radically different. It is now far easier to reuse material from drafts, to rearrange text, to collaborate on the same document, create and disseminate documents.
- Calculators and spell checkers: an exercise for the reader
A frequent problem I encounter in HCI is that people get overly focused on the tools rather than the task. The task of an employee becomes to operate software, and various stakeholders lose sight of what the employee actually needs to do. Another common problem is what I call "serving the machine" where work becomes more about process and meeting the requirements of a tool. This can become more and more bizarre as corporate identity fades or layers of other tools and procedures are put in place. Serving the machine can become more and more important, even if the original reasons why something needs to be done have been forgotten, or rendered irrelevant. In a similar vein an organisation can be ruled by unhelpful metrics, simply because that is the metric that their system gives them, and hey here are some numbers or a graph and they must be important, right? Another case is when a set of metrics are provided on a dashboard results in everything else being ignored or no longer part of the corporate ontology.
I need a "Serving/Worship the Machine" mug/tshirt/banner/whatever to wave at stakeholders when they lose sight of the underlying task (or *mumblemumble* timesheets *mumble* days in advance *mumble* all because the report is generated too early *mumble*).
I'd like to think this topic could be extended to create a framework of tool use and task actions that will Help Save The World, but where would I find the time?
