- building
- tools
- creators
The person using the thing you built is not the person you imagined while building it.
You imagined someone calm, at a desk, reading the labels. The real user is finishing a nine-hour stream at three in the morning, running on nothing, using one hand, and they are going to click something without reading it.
That is not a criticism of them. That is the operating condition, and if you design for the calm version you have designed for a person who does not exist.
What that changes
Three rules cover most of it.
It must be impossible to lock yourself out
Any system with roles and permissions can be misconfigured into a state where the owner cannot get back in. A bad row, a failed migration, a mis-click on their own account.
So the owner's access should not be a database row. It should be above the database — hard-coded, checked first, unaffected by whatever the data says. It feels crude. It is the single highest-value line of code in most admin tools I have built, and the fact that it never gets used is exactly the point.
The corollary: if you hard-code it in more than one place, those places must change together, and someone should write down where they are.
Bad input should degrade, not break
Somebody is going to paste the wrong thing into the wrong field. Not because they are careless — because at 3am a URL and an ID look like the same thing.
The wrong response is to crash the page. The right response is to notice the value is not the shape you need and quietly render without it. The post publishes, the video is missing, they see it and fix it. Nothing is lost.
Validate at the point of use, always, and choose the failure that keeps the rest of the page alive.
Nothing important is one unconfirmed click away
Delete needs a confirm. Publish needs a confirm. Anything that emails a hundred people definitely needs a confirm.
And where possible, make it undoable rather than confirmable — an archive flag beats a delete, a scheduled send beats an instant one, because a five-minute window to change your mind is worth more than a dialog box that gets clicked through on reflex.
The documentation you will never get read
You can write a beautiful setup guide. It will not be read. Not out of disrespect — reading documentation requires a state of mind that does not exist after a long stream.
So the interface has to carry the instructions. Label the field with the constraint, not the name: not "YouTube ID" but "YouTube ID (11 characters, not the full URL)". It looks clumsy in a design mockup. It is the difference between a support message and no support message.
Why this matters more for creators than for companies
A company has a person whose job is to use the internal tool. They will be trained. They will have a colleague to ask.
A creator is the entire staff. There is nobody to ask, no runbook, and the tool is being used in the gaps between the actual job. Every bit of friction lands on one exhausted person, and if the tool is annoying enough, they will simply stop using it and go back to DMs.
Build for the tired version. It is the only version that shows up.
← All writing