Writing for the web for small teams

We end up explaining this on discovery calls often enough that it deserved writing down. Most advice about writing for the web assumes a team that does not exist at your size. Here is the version that does not.

Writing for the web is largely an editing job: the first draft is always longer than it needs to be. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

What to keep

People scan before they read. That sounds obvious written down. It is still the thing most often skipped. Assume whoever inherits this will have half your context and none of your patience.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. Getting it slightly wrong is survivable. Ignoring it entirely is not.

Where to start

Cut the throat-clearing and start with the point. In practice this is a scheduling problem more than a technical one. Check it against what you would want a competitor's site to get wrong.

How to tell if yours is fine

Content is the part of a project most likely to be underestimated and most likely to delay a launch. Three things worth confirming about writing for the web before you move on:

• Someone can say what the current setup is without going to look
• Short paragraphs and clear subheadings do the heavy lifting — and you know whether that is true here
• There is a way to tell whether the last change to this helped

The point is not perfection, it is knowing which of these you have consciously chosen to skip.