The Last Step Everybody Skips

I opened my own product, found something I had kept, and could not get it out.

The opened card offered six things. 고정, pin it. 크게, make it bigger. 크게 보기, view it large. 원본 열기, open the original. 잊기, forget it. 닫기, close.

Six affordances, all working correctly, and not one of them gave me the thing.

The loop nobody finishes

The loop this product is supposed to serve:

anything → drop → understand → keep → find → recognise → reconnect → REUSE
   ✓        ✓         ✓          ✓      ✓        ✓            ✓          ✗

anything → drop → understand → keep → find → recognise → reconnect → REUSE
   ✓        ✓         ✓          ✓      ✓        ✓            ✓          ✗

anything → drop → understand → keep → find → recognise → reconnect → REUSE
   ✓        ✓         ✓          ✓      ✓        ✓            ✓          ✗

I had built seven of those eight steps and polished them for months. The eighth was a button that downloads a file.

Downloading is not reuse. When you need a link you need it in your clipboard, not in your downloads folder. When you need the words from a note you need them where the cursor already is. When you need the image you need the image, the real one at its real size, and opening it in a new tab is a different task that happens to end somewhere near the right place.

The last step of any loop is the one everybody skips, and the reason is structural rather than lazy. By the time you reach it you have built everything else, the remaining gap looks small, and the energy is gone. Small gaps at the end of long chains are where products quietly fail, because the person experiences the whole chain as whatever the last step was.

A person does not evaluate your pipeline. They evaluate the moment they tried to use the thing.

What handing back actually requires

The fix is not a copy button. It is a different answer per kind of thing, because the thing means something different each time.

Table 1. Five kinds, five answers. A single generic "copy" would have been wrong four times out of five.

That last row is two extra syllables doing real work. Copy the text that was read rather than copy text. What you are about to paste is not the document. It is a machine's account of the document, and if it is wrong the label already told you where to look.

And one bound that I like more than any of the features: nothing is offered that cannot carry at least twelve characters. An option to copy something that turns out to be empty is worse than no option. It costs a press and a moment of confusion, and then it teaches the person not to trust the interface, which is expensive and permanent.

The gate

The verification had to be built differently, and this is the part I would keep above everything else in this piece.

It would have been easy to test that the button calls the clipboard function. That test passes when the feature is broken.

// Passes whether or not anything reached the clipboard
expect(clipboardSpy).toHaveBeenCalled()

// What the gate actually does, 19 times
await press(button)
const actual = await readClipboard()
expect(actual).toEqual(theThingTheyAskedFor)

// Passes whether or not anything reached the clipboard
expect(clipboardSpy).toHaveBeenCalled()

// What the gate actually does, 19 times
await press(button)
const actual = await readClipboard()
expect(actual).toEqual(theThingTheyAskedFor)

// Passes whether or not anything reached the clipboard
expect(clipboardSpy).toHaveBeenCalled()

// What the gate actually does, 19 times
await press(button)
const actual = await readClipboard()
expect(actual).toEqual(theThingTheyAskedFor)

Not "was the API called." What is actually on the clipboard now, and is it the thing the person asked for.

The rule underneath is the same one that governs writes to a store: an operation is proven by observing its effect, never by observing that it was requested. A success response means the message arrived. Reading it back means something happened.

Where this goes beyond software

I have started seeing the missing eighth step everywhere in our own studio work, and it is not a comfortable thing to notice.

• A brand system delivered as a beautiful PDF that nobody can extract an asset from.

• A research document with excellent findings and no statement of what to do on Monday.

• A moodboard that captured a direction perfectly and gave the person holding it no way to act on it.

• A presentation that convinced everyone in the room and left nothing behind that could convince anyone who was not there.

In each case the work is genuinely good and the loop is genuinely unfinished, and the gap sits at the end where the energy ran out. The client receives it, says it is beautiful, and then quietly does something else, and we conclude they did not understand it.

They understood it. They could not take it anywhere.

The question before calling anything done

Can the person actually take the thing away?

Not see it. Not understand it. Not approve it. Take it, and use it somewhere else, without asking me.

That question has changed our deliverables more than any critique has. A logo package now ships with the formats people actually paste into, not only the formats that are correct. A research document ends with the three decisions it implies. A colour is given as a value someone can type, not only as a swatch on a page.

None of that is design work in the sense we usually mean. All of it is the difference between work that gets used and work that gets admired.

Immediate connection, which is the same idea

Bret Victor's 2012 talk is usually remembered for the live-coding demonstrations. The underlying argument is broader and, I think, the same argument as this one: that creators need an immediate connection to what they are making, and that any delay or indirection between an intention and its result is a cost paid by the work itself.

Video. Bret Victor, "Inventing on Principle" (2012).

A download is an indirection. So is a re-encode. So is a preview standing in for an original. Each one is small, each is defensible on its own, and together they are the distance between having something and being able to use it.

Six buttons, all working, none of them the one that mattered. That is the most accurate picture of unfinished work I have.

Sources

• Bret Victor. “Inventing on Principle” (2012). youtube.com/watch?v=PUv66718DII

Related reading

• Better at What the Thing Is Once It's In

• The Bytes Are the Fact. The Name Is a Claim.

• A Cat That Doesn't Perform

• The Grasshopper Was Already There

More from the Moc Mallen Studio journal