The two minute rule that decides whether a site survives

How they die

I built sites for small businesses for four years. They almost all fail the same way, and none of them fail at launch.

They launch well. The client is pleased. Then stock changes, or prices change, or an offer ends, and updating it requires either me or a content system that is too fiddly to face on a phone in the evening.

So it does not get updated. Six months later the site lists things that are no longer available at prices that are no longer accurate, and it is now doing active harm: somebody arrives, sees something wrong, and concludes the business is careless or closed.

The site did not fail because the client was lazy. It failed because updating it was harder than not updating it, and that was decided by whoever built it.

The rule

A routine update takes under two minutes, on a phone, or the project has not succeeded.

Not “is possible”. Under two minutes, standing next to the thing being described, on the device actually in their hand, without a manual.

It is a harsh standard and it is the right one, because the alternative is discovered six months later when it is somebody else’s problem.

What it forces

The rule cascades through the whole build, and that is the point.

Photographs upload and process without thought. No resizing, no format questions, no instructions about dimensions. Take the picture, upload it, done. If a client has to think about image size, they will stop adding images.

Derive everything derivable. If a field can be computed, computed, or defaulted, it is not a question. Every field on a form is a reason to abandon the form.

Nothing is mandatory that they cannot answer immediately. A required field they would have to look up means the update waits until they are at a desk, and the update at a desk does not happen.

Common actions are one action. Marking something sold or unavailable is one tap from the list, not a form with a save button. It is the most frequent operation and it should cost the least.

It works on a middling phone on a variable connection, because that is the actual device and the actual connection.

What it rules out

Worth being explicit, because these all feel like good ideas when proposed.

A full content management system with a page builder. Powerful, and nobody with a business to run learns it.

A workflow with a draft and a publish step. Reasonable governance for a team of five. For one owner it is a second action they will forget, and then they will wonder why the change did not appear.

Anything requiring a desktop. If it needs a laptop, it happens at the weekend, which means it happens some weekends.

The test

Hand it to them and watch, without helping.

Not a demonstration where you drive. Ask them to add a real item, right now, on their own phone, while you sit quietly and take notes.

Every hesitation is a defect. Every question is a defect. Every moment they look up for reassurance is a defect. It is uncomfortable to sit through and it is the most information you will get about the project.

I have watched somebody stop halfway through because a field asked for something they did not have to hand. That field was optional in my head and required in the form, and I would never have found it any other way.

Why this is an engineering problem

It is tempting to file this under client management. It is not.

The decision that determines whether a site is alive in a year is an engineering decision about where complexity sits. You can put it in the build or you can put it in every future update. Putting it in the build is a one time cost paid by somebody who is good at it. Putting it in the update is a recurring cost paid by somebody who is not, and they will stop paying it.

What carried forward

The same principle scales further than I expected.

Operational software has the same property. If a task somebody does sixty times a day takes six interactions instead of two, they either work around it or they stop doing it properly. The two minute rule and designing for the tenth repetition are the same idea at different scales.

The question is always: who pays the cost, how often, and are they equipped to. Almost every interface decision I make now comes back to that.