Once the site map, wireframes, and design are nailed down, it’s time to hand off to the development team. Don’t forget that the architecture and design can be handed off first, and content can follow later.
Hand-off of design
If you want the site to match your design precisely, be precise: specify exact widths, heights, and lengths of each element in a design specification document. However, the design tolerances should include some padding. A few pixels of wiggle room are useful to accommodate cross-browser variations.
The design templates should be Photoshop or Illustrator files. Specify text sizes in pixels, not points. And remember there are no ‘half pixels’. A pixel is the smallest unit of measurement on the web. All the different page states required, such as those for mouseovers, should be held in separate layers. These should all be named as precisely as possible by use and locations, including the on, off, and mouseover layers.
If your directions are clear and comprehensive, you have every right to expect the web developers to follow them closely.
Developers prefer to receive all design files at the same time. However, if you know that changes are still being made to a particular section, hold it back as long as the timeline will allow; that’s better than making changes after programming work has begun, which will chew up time and money.
Hand-off of content
The form in which you supply content will affect the cost of implementing it. If you expect your web development partner to convert, optimize, or resize graphics, or collect and collate the content, this should be reflected in your budget and timeline. The programmers should be able to deal with any format you send, but following their guidelines will help the project proceed smoothly and reduce costs.
For example, photos and other graphics should be supplied ready for use, properly cropped, in RGB format and sized at 72 dpi.
The following file formats are typical for images on the web:
- JPEGs for images with complex backgrounds and shading, such as photos
- GIFs for text and simple colour images
- PNG files for transparent photo backgrounds or where a lossless format is required. PNG files offer better resolution and gradients than GIFs, but older browsers (such as Internet Explorer 6) may not display them properly.
Proofreading, copyediting, colour-correcting images, and other content refinement tasks will be important to the quality of the website. They should be factored into the schedule and budget. Whenever possible, copy should be final when it is sent to the developers for implementation. Remember that developers charge for their time; if content has to be revised after it is already in place on the site, this will drive up costs.
Execution
For larger projects, work is typically divided across a team of developers and a project manager, who can supply you and your client with project lifecycle information such as dates and milestones. If the designer is available to conduct interim reviews, these allow the developers to move forward with assurance. These reviews also help the designer understand the web development lifecycle, provide greater clarity on project progress, and help identify issues before the first client review date. This knowledge will help you manage client expectations effectively.
Testing and quality assurance
Don’t assume your files have been transferred perfectly: human error and disjunctions between programs may cause glitches. You should be prepared to participate in the quality assurance process and check pages and functionalities yourself at the first review stage. Make sure all the details that should be in place are present, all the links are working, and so on. The site should be tested not only with various browsers, but with various versions of those browsers.
First review and ‘scope creep’
At this point the client first sees the functional site. There may still be placeholder images and missing text – this is normal. A thorough review should then be conducted, focusing on site usability, content flow, and business requirements. Do not underestimate the time this will take, especially for a large site.
At this stage, many clients now suddenly think of changes they want to make (this is the deadly ‘scope creep’ you have probably heard about). Scope creep is virtually unavoidable, no matter how carefully everyone plans. Some things simply cannot be anticipated until you see a more-or-less functioning website. It is good practice to ensure every website budget includes a contingency of 15%–20% to cover unforeseen revisions and additions to the initial scope of work. It may be unpopular to broach this with your client at the outset, but to avoid the topic is worse; you may be setting yourself up for an unpleasant experience later.
Scope creep is not necessarily a bad thing; it’s an opportunity to make improvements, but there is an associated cost. Of course, bugs are the developers’ responsibility, but changes to content or functionality that aren’t in the wireframes are chargeable, whether they are things that everyone has overlooked or things the client wants to add.
Implementation may reveal refinements that would be good to have in place before the site goes live. In such cases, schedule and cost implications should be discussed by the client, designer, and developers before proceeding.
If timing and budget are tight, remember that changes can be pushed off until a post-launch phase. A website will continue to evolve throughout its lifespan.
From this point until the site goes live, it’s usually a case of filling in missing elements, correcting errors and dealing with rethinks. The hard work has already been completed.
Client sign-off
It’s always best to have documentation in case of misunderstandings. So far, you should have received a series of client approvals: the finalized project goals, the completed plan, the wireframes, the design presentation, and the first review. Now the client must sign off on the live site. We recommend getting it in writing (an e-mail from the client’s project manager is usually fine).
