Writing for the web: the questions we get asked most

There is no clever trick in this one, just a handful of decisions worth making deliberately. The questions about writing for the web that come up most often on our calls.

Writing for the web is largely an editing job: the first draft is always longer than it needs to be. The version that survives contact with a real deadline is the simple one.

Do we need to care about this?

People scan before they read. None of that requires a large budget, only a decision and someone to own it. Check it against what you would want a competitor's site to get wrong.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. This is the sort of thing that compounds, quietly, in both directions.

How do we know it is working?

Cut the throat-clearing and start with the point. It is worth being explicit about, because assumptions differ quietly. Write the reasoning down alongside the decision, because the reasoning is what changes first.

In practice

Pages that answer a real question outlive pages written to fill a slot in a sitemap. 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
• Cut the throat-clearing and start with the point — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.