|
columns in date order (most recent first):
Left
or right
Interruptions
Sequences
Infra-red
Information
technology
Broadcasting
Funny
noises
Goodbye
Off and
on
Documentaries
Real time
Flexible
systems
Forms
A user
group of two
People
flow
Loops
Take-out
service
Stereo
vision
International
standards
Contact
Blank
Sound
Terminology
Specifications
Junk
Marks
and scratches
Paths
Telephones
Length
Pointing
Video
Video conferencing
Shopping
Slider controls
Snooze functions
Cafés
Safety
catches
Powerful
functions
Children
Food
Waiting
Labels
Elavators
Buttons
Coffee
|
These
columns discuss interaction design in the world around us. You can
find more of them in the book Designing
the Real World
‘No
one has ever asked me that before’. What was I asking? Well
it was quite simple really. On Monday I had bought some flower pots
and compost at the garden center, and arranged for them to be delivered
on Friday. Fine, that’s part of the service they offer. But
what I had done then was to go back a few days later and buy some
more stuff, chairs this time, and ask to include them in the delivery
that was still waiting to happen on Friday.
This was not part of the model of their service. If I had just arranged a separate delivery of that second load of stuff that would have been fine, but I would have paid for the extra delivery and they might have dispatched it as a separate delivery. Merging it with the first delivery would save me money, make their delivery process more efficient, and it could also benefit their sales since being able to add more to my impending delivery is likely to entice me to buy more big, heavy stuff.
As it was, although no one had asked such a thing before, it was a simple matter to dig out the old order and add the new things to it with a pen and then put the things in the holding shed with the other stuff. But the key thing was that this was an informal solution to the problem; Mike had to get Frank on the phone and they sorted it out between them, it was possible to grab a pen and add a few more things to the delivery schedule etc. With real-world processes like this you can do that, when the organization gets bigger and when things get more rigorously set in processes it becomes more difficult, and nowhere is this more apparent than when a process is automated by computers.
I recently had problems with the acceptance of my credit card for payment because the system would only approve the transaction if the credit card details matched those in the database and if the address details also matched. This meant that the person I was speaking to filled the details in and then pressed on a button to make the system try and match them. It then came back with a no or a yes. As my address is a bit vague and as the operator couldn’t see the information in the database we had to try submitting several variations before we managed to hit upon the version that was actually stored in the database and allow the transaction to happen. Now if Frank or Mike had been there with their trusty pen they would have flicked through the filing cards, found the matching credit card number and when I said ‘Manor Cottage, Norton Malreward’ instead of ‘Manor Cottage, Church Road, Norton Malreward’ they would have said ‘That’s near enough for us, thank you’.
The lesson is that when you are automating a process in an interactive system you obviously have to think of the main process that you are supporting, but you must also think of the other possibilities, and work out which of them you are going to support and which of them you are not going to support.
One way to avoid this or at least to postpone solving the problem is to include free text comment fields in key parts of the interface. This allows users to annotate things and can also be used retrospectively to catch parts of the process that were missed in the initial requirements drafting. Consider the comment field associated with Macintosh files, although not widely used, when they are used they are used to support all sorts of different processes. It is the digital equivalent of a Mike and a Frank and a quick fix with a pen.
Moving processes from the real-world to the digital world means that we lose some of the advantages in flexibility of the real-world; the Franks, the Mikes and the quick changes with a pen. However, we gain much in speed and efficiency by getting rid of some of the problems associated with paper processes in the real world, one such is the ability to lose key bits of paper down the back of cupboards and such like. One large medical insurance company that had experienced problems of this nature installed a company-wide, digital system with a gateway between the real-world and the digital world consisting of a post room where every paper communication that came in was immediately scanned into the system with a date stamp. This gateway room was a clean room with just post trays and a bank of scanners on simple tables. No objects or cupboards down the backs of which the Mikes and Franks of this world could lose forms.
So when you are transferring processes from the real-world to a digital system you must ensure that you migrate the useful things from the real-world to the system while getting rid of the non-useful things.
And incidentally, this wasn’t the original subject I had planned for this month’s column, all I know about the original idea was that it was really good and that it was written down on a bit of paper which got lost down the back of something in my study. It will turn up one day
|
|