Will word for food » Writing for the Web

I’ve just finished doing some project management/editing for a printed newsletter. I know, I know - I’m a web writer. But I do dabble in print jobs too, and it can make a nice change.

I thought I’d pull together a list of some of the things I’ve learnt from this - and another recent writing job. If nothing else, it’ll stop me making these same mistakes more than once! Several of the below points might seem obvious, but it’s always worth reminding yourself of them…

1. Quote for a specific number of (or amount of time doing) revisions at the outset, or at least add enough time into your project plan for changes.  You’ll never write something which is approved straight off - writing doesn’t work like that and arguably shouldn’t work like that. If a client signs it off with no questions they’re not checking it. With the best will in the world, you’ll always end up with typos. But by specifying how many revisions you’ll do, and by planning time to do them, there won’t be any surprises.
2. Linked to this, of course, is allowing time for client sign-off. I’ve worked in places where sign-off is done quickly by one person, but that’s the exception rather than the rule; I’ve also worked in places where I’ve signed off work I’ve commissioned, in order to pass it to my direct boss to sign off so she can pass it to her boss to sign it off, who then told my boss it was OK, who then told me, so I could pass that on to the agency. Public sector are the worst at this, but in heavily regulated industries (pharma and finance spring to mind) it can take a while as well. Find out what your client’s sign-off process will be, and try to plan for it.
3. Stick to word counts. It may seem obvious, but lots of people think they can get away with a few words over here and there. Well, you can’t. If you do that the person editing it - who’s in the position to pay your bills and to ask you to do work for them in the future - will get a bit angry at having to get it trimmed down. If you really think a longer version would be better, send a trimmed and a full version - do all the work for the person paying you and they’re more likely to pay you in future.
4. Get it done on time, and if you can’t, don’t promise new deadlines and repeatedly miss them. If there’s a valid excuse for missing a deadline, explain early and work out a compromise. Don’t just let it slip again and again. Perhaps you can submit what you’ve done so far for sign off and while that’s going through the system finish the rest? Because content is often left until last on a web build (which isn’t, perhaps, the best idea) the whole project can depend on you getting your writing done. With design and technical build, there’s often another job which can run in parallel so a slightly late bit of work doesn’t impact massively.
5. If you’re working on a regular blog or publication, gather a collection of easily editable stand-by stories. If someone misses a deadline (and can’t explain why), drop them from that issue and think twice about getting them to write for you again.
6. If you’re working on a big document or website, send a sample as early as you can. Even if the project’s on the to-do list and you’re not starting it immediately, spend an afternoon pulling something together to send to the client as soon as you can. If you write the whole thing only to be told it’s the wrong style, too colloquial, too technical, or just plain wrong… well, you’ve only got yourself to blame.
7. Never assume about a job if it means doing less or more work that you originally thought. Actually, never assume. I assumed on a site that pages I’d not been asked for would, after all, need to be copy edited - they were completely out of style with the rest of the site. Half-way through re-writing them, I found out they would be part of phase II. I’d wasted about a day writing stuff I wasn’t getting paid for! Of course, I could have assumed I didn’t need to do those pages only to find there was a mistake on the part of the client - less of an issue, I grant you, but they’d still need to be done. If you have any questions about the brief, ask them as soon as you can. This is another good reason not to sit on a project if you don’t need to start immediately; the sooner you can find issues not identified in the brief, the better.
8. Bite your tongue - but not too much. Yes, if the structure of the site you’re working on makes no sense or makes your job harder, then suggest some changes - but don’t just go ahead and do all your writing work assuming your excellent IA suggestions will be taken up. They might not be excellent; the IA might be addressed in a later phase; more than either of these, however, you’re not getting paid to restructure the site. Open that can of worms and you’ll end up with nothing more than a missed deadline, an unhappy client, and a lap full of worms.
9. If you’re working to an incomplete design, think! There’s no guarantee that the brilliant “related links” box you’ve just written for will still be there at launch. You don’t know for sure that the section of the page you’ve lovingly crafted thinking that it’ll be highlighted for you won’t just be pasted onto the bottom of the body text. Always, always double check with the designers.
10. Notate like mad. If you’re not placing your text direct into a CMS, notate evey link and say where it goes. Explain if you want special formatting on some text. Most importantly, explain your annotations - you don’t want them to end up in the text when an over-zealous developer does a copy and paste job…

This post contains: