Interconnected

Principals of design: Never replace a human process with an automatic one.

An example | A new security feature on some cars is the ability to unlock the driver's door only. Of course before central locking this was a feature that came from free, but the introduction of an automatic process to replace manually unlocking/locking all the doors individually dominated the entire domain -- and now all the smaller human processes have to be reimplemented.

Another example | My mum's house has a large gate at the front, for the car. It used to always be open but since we got a new dog it had to be kept closed. Deciding opening and closing the gate was tedious, my mum had a remote-controlled gate opener installed.

Now the thing with gates is: People know how to use them. You open the gate, a gap appears. You close the gate, the gap goes. The gate opener was a level on the hinge side of the gate, with a button. The button had to be on the same side as the hinge, because of wires. So now there's no lever on the normal side of the gate; when people push the gate it doesn't open; the button (button!) to open the gate is on the opposite side of the gate to the one expected. Talk about cognitive friction! Of course, nobody knew how to use the gate, would force it open against the piston, and it broke. (A sign pointing to the button didn't work. "Reading" simple isn't in the "open gate" workflow, no matter what way you look at it.)

The gate is fixed. Next to the gate is a short run of fence which is converted into a pedestrian gate. Unfortunately this means that there's now a gate for people which looks like a fence, which has a lever to open right next to where the main gate lever should be. People are even more confused. The gate is broken again.

A broken gate hangs open a little. So the gardener, having the dogs outside all day, propped the gate closed. Now my mum comes back, presses the remote control, the gate attempts to open, jams against the pole and breaks.

Broken gate. The mechanism can be turned off, so we do that and use a piece of old rope as a temporary latch to hold it closed (people understand rope). But to hold it open so it doesn't swing into cars... When there was no piston the gate could swing all the way back and be held open by the hedge. But the piston restricts the amount the gate can open, so the gate is be propped open halfway by a bright orange traffic cone.

And we still don't have a remote controlled gate.

So why the problem with the gate? A human process was replaced by an automatic one -- but the automatic solution can never cover the whole domain so we end up introducing cognitive friction into unrelated processes (opening the driver's door individually; using the gate as a person not a car), which the solution has to be extended to allow for.

Better solutions for both of these examples would be to leave the human process untouched and augment the system with automation. The gate should be able to be controlled manually or by remote control. Not doing this is always going to lead to trouble of the unexpected kind.