idhub home Designing the Real World by Lon Barfield

 

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

Flexible Systems

‘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 …