Continued from part 2

This series is looking at what design techniques/mechanisms are applicable to guiding a user to follow a process or path, performing actions in a specified sequence. The techniques fall roughly into three ‘approaches’. In this post, I’m going to examine the Poka-yoke approach. If you’ve been following the previous posts, you’ll probably have thought, “Well, all that’s pretty obvious.” And it is obvious – we encounter these kinds of design techniques in products and systems every day – but that’s part of the point of this bit of the research: understanding what’s out there already.

Poka-yoke approach

The mechanisms described in this approach are all based on technical (rather than explicitly human) factors, and involve designing the relationships between system elements.

Poka-yoke (Japanese: mistake-proofing) is an approach usually applied in manufacturing engineering, developed by Shigeo Shingo in the context of developing ‘zero defect’ assembly processes. The idea is to avoid slip-type errors by designing systems which prevent them occurring, prevent a user proceeding until the error condition has been rectified (control poka-yokes), or at the very least clearly warn the user of the error condition (warning poka-yokes).

Generally, when the design intent is for the user to follow a process or path in a specified sequence, a deviation from that sequence can be considered as an error, and thus the poka-yoke approach can be applicable outside its original field. Similar concepts, forcing functions, have been developed in interaction design, especially in the work of Donald Norman – the three main forcing function mechanisms, Interlock, Lock-in and Lock-out, broadly correspond to Shingo’s control poka-yoke category; all can help in assisting (or forcing) users to follow a process or sequence. In the warning poka-yoke category, the Arrangement detection mechanism is most relevant to this behaviour.

Interlock

An Interlock combines elements of both lock-ins and lock-outs (see below), and is probably the most familiar forcing function mechanism: the ability to use one function is dependent on another running or being started, another component (such as a guard) being in place, or some other condition being fulfilled.

Example: This Toyota Verso requires the clutch pedal to be depressed before the starter button will operate, to reduce the risk of starting in gear.

Car ignitions which cannot be operated unless the driver’s seat belt is fastened – a system originally promoted as ‘Interlock’ in the US – microwave ovens not operating unless the door is closed, and airline or train toilets where the lighting does not operate until the user has locked the door, are some of the highest profile everyday examples, but the principle of the interlock is extremely common in engineering and manufacturing industry, often in the context of a machine tool which will not start until a guard is in place, or where opening the case automatically cuts the power.

Interlocks are often specified when it is imperative – rather than merely desirable – that a user follow a particular sequence, or at least two steps of a sequence, in exactly the right order, but their use need not be limited to critical safety design problems. Ecodesign applications might include (for example) a car’s air conditioning system requiring the windows to be fully closed before operating, or a sink requiring the plug to be in before the tap can be left in a ‘running’ position.

Example: The ubiquitous interlock on a microwave oven ensures that the door is closed before the oven will start.

Lock-in

The Lock-in mechanism in this context (rather than an economic one) refers to a system arranged such that a process, procedure or operation is kept active – the user can’t exit the operation until a certain condition is met, or the ‘correct’ next step is taken. This can be implemented using sensors, logic processing, physical architecture, or a number of other ways.

As Norman puts it, this prevents “someone from prematurely stopping” an operation – this could mean letting some ongoing process run its course to completion before starting the next, or denying the user access to another function which might interfere with the current process. It can also prevent accidental cancelling of an operation – inadvertent deviation from a specified sequence – by introducing an extra ‘confirmation’ step.

Example: The confirmation dialogue displayed by some software when a user attempts to exit can be seen as a lock-in to prevent inadvertent ending of the application.

Lock-out

Lock-out is closely related to Lock-in: in this case, the mechanism makes it difficult or impossible for the user to start certain operations, or denies or impedes access to particular areas or functions. In the context of encouraging or forcing a user to follow a path or process in a specified sequence, a lock-out helps prevent inadvertent or mistaken steps in that sequence. It can also help prevent an operation being started too early in the sequence, and may also be implemented as an extra ‘confirmation’ step.

Example: This file backup application prevents a user modifying the properties of a scheduled backup task while it is running – ensuring that the correct sequence is followed.

Arrangement detection

Arrangement detection is a ‘warning’ rather than ‘control’ poka-yoke mechanism, and may be considered as a ‘feedback’ analogue of interlocks, lock-ins and lock-outs – providing a warning (audible, visual, tactile) when system elements are incorrectly arranged (physically or procedurally).

Arrangement detection is about warning the user that the path or process is occurring in an incorrect sequence, rather than actually forcing the user to follow the correct sequence. While there are a number of possible warning poka-yoke mechanisms alerting users to incorrect behaviour, arrangement detection is most relevant to the specific issue of sequencing.

Example: The seat belt warning on car dashboards (in this case a Fiat Punto) is an arrangement detection poka-yoke, providing a visual (and often also audible) alert that a belt is not buckled while the engine is running, or the car is moving.

In part 4, we’ll look at the Persuasive Interface approach to getting someone to do things in a particular order.