Sending clear update requests

Summary — We all prefer websites that are clearly written and easy to understand. The same goes for the development process. Following the suggestions below will save your developer time and confusion, which will save you headaches and money.

Clarity is key

You’ve sent a clear update request to your web developer when it leaves them with no questions. If they’re left wondering…

  • Where does it go?
  • When can/should/must it be published?
  • Is this in addition to what’s there or does it replace something? (and what — exactly — does it replace?)

…then the time-consuming follow-up questions begin.

No one wants this.

Suggested content change/addition request

Include a 1-line summary (this makes a great email subject line):

“Please [add|update|replace|delete] this [page|photo|paragraph|sentence|link] at [affected page’s title and/or web address] [immediately|by noon tomorrow|after 9 am Thursday].

E.g.: “Please delete the following sentence on our Home page ASAP.”

  • specify exactly what’s to be done:
    • if a person is being added to a list of people, where does the new person go in the list? (Is the list alphabetical by last name, by seniority or title, by geographic location, or to match their position in a group photo…?)
    • If it’s an event, include the date, time, venue, cost, rain date/venue, contact info, appropriate web addresses (e.g. for venue or transportation), accessibility info, parking availability & pricing, etc.
    • If it’s a photograph, include caption and alternative text, along with photo credit information (you do have the right to use the photo?), and
  • be precise when referring to businesses, places, or people — abbreviated, colloquial, or unofficial names used in correspondence will only confuse things. Saying an event’s “at the rink” only helps local people who think of, say, The Tantramar Veterans Regional Civic Centre as the rink. Anyone coming from out-of-town will be left in the dark (and don’t say that they can just Google it; the way to make your site easy to use is to not offload effort onto your visitors).
  • think: does anything else (on the same page or elsewhere on the site) need to be updated or deleted because of this change?
  • is everything included? In the appropriate format;? Including translations? Links?
  • don’t forget to attach attachments!
  • explicitly state any deadlines and/or embargo dates, including times (and timezones!)


That’s really all there is to it. Beyond clear instructions, how best to send updates depends on the content itself.

Sending copy and copy changes

  • For simple additions, put the text in the body of the email. If you like, use a word processor to check spelling, but there’s no need to attach a Word or Pages file for a few lines of text. Having to open (or install!) a word processing application just takes time.
  • For small edits that involve deletions and insertions, consider marking up a printout or PDF of the existing page with a pen and sending a scan, photo, or screenshot. As above, any copy being added should be included as text in the body of the message, to facilitate copying/pasting, to reduce the chance of typos.

Text formats to avoid

In almost all cases, pasting the text into the body of an email is enough. Email can support bold and italics.

  • Microsoft Word/Google Docs — don’t assume that because you or your organization use so-called industry standard software that everyone else does, too.
  • PDFs — extracting text from a PDF can be dicey, depending on a variety of factors.
  • A picture of words — if you’ve made a poster and have sent along an image of it, expecting someone to retype it, you’re asking for errors and omissions to be made, and you’re paying developer rates for a typist’s skillset.

Sending images

  • Ideally, photographs will be sent as high-resolution, RGB TIFF (.tiff/.tif) files.
  • Send the largest, highest-quality images you have that have had the least-possible manipulation (every time you re-save a JPEG, for example, it re-compresses it, throwing away more data). Images that are too large to attach to email can be shared via whatever file-sharing service is popular this week (iCloud Drive/Dropbox/Google Drive/
  • Don’t send images that have been “prepared for web”. In this era of multiple devices of many different resolutions, optimizing images for delivery is anything but straightforward. This is literally why you hire a web developer. Decisions about compression levels, dimensions, pixel-density, and file format are besed on many factors, and trying to save time by doing your developers’ job for them will only make it harder.
  • Photos prepared for print have likely been converted from their original RGB colour-space to CMYK. These files are not ideal for web use. Provide the original RGB files whenever possible. (It may be helpful, early in the process, for your web team to coordinate with your agency to discuss optimizing print-based workflows for the benefit of your website. Relatively minor changes to a print-based pipeline can yield much higher-quality images on your website. Unfortunately, converting back from CMYK to RGB doesn’t undo the damage from the previous conversion.)
  • Microsoft Office and images don’t mix. Images collected in Word or PowerPoint get scaled and compressed, lowering image quality to the point of making them useless. Attach image files directly to your email, without putting them into a Word or PowerPoint file, or use a file-sharing service.
  • Non-photographic images. Logos, wordmarks, charts, drawings and other types of non-photographic images come in a variety of file formats (.ai, .eps, .svg, .pdf, .dwg, etc.). Ask your developer, don’t convert formats, and don’t paste them into Office files.