When working with big IT project, often clients will have the work divided between a couple of different vendors. One of the most common scenarios is having design and branding done by a Design Agency and the development done by a company that specializes on whatever technology will be needed for such project. That seems like it's a perfect combination but often the expectations of both companies are not aligned, causing some pains, delays and ultimately, wasted money.
Having faced with that situation before, we started working on an internal Design Deliverable Checklist that we can share with our partners, containing what we think would be the ideal deliverables for a smooth, fast flowing development. Here are some of the items:
- Wireframes should be considered final had been already reviewed by the stakeholders. That includes the labeling and possibly the copy on the wireframes. That should avoid change requests and re-works.
- Detailed anotations. It's always better to over-annotate the wireframes than leave vagueness in there. For some complex interactions, like animations it's often good to provide some links with examples, if possible. Also, make sure the annotations are labelled with numbers marked on the page.
- If any changes must be made to the warefrimes they should be listed in red for easy vizualization. The new document should also be named acording to it's version. In that situation would be a good idea to keep a change log as well.
- Always include a sitemap. Sitemaps help developers vizualize the whole scope of the project and plan the best way to takle the work.
The minimum elements to include in a style guide are Typography (h1-h6, paragraphs, lists, etc), Colours (brand, highlights, text, and links), Grid System (horizontal at least), Buttons and Form Elements.
All Colours should be printed in hexadecimal format ie: #f0f0f0
All font sizes should be printed in pixel format ie: 16px
Style guide should be delivered as a .PSD file with no flattened layers or as a html/css prototype.
.PSD file should be in 72ppi - if retina assets are needed then that is a separate request that will be made.
- include rollovers
All elements of the mockup should be captured in some way in the style guide.
All units of measurement in the PSD should be in pixels and should reflect what is in the style guide.
Hover states should always be represented and not hidden in layers that could be missed.
There should be no flat layers, all text (unless actually part of an image) should be inspectable. (Nothing should be rasterized)
A layer outlining the grid system should be included. This make sure that the mockup is following the grid system set up in the style guide and is a visual aid for the front end developer to make sure he/she is using the proper widths when building the page.
- Each page should be an individual PSD. This reduces the size of individual PSD files and is less resource intensive.
Assets will consist of three groups - icons, imagery, and fonts.
Icons: Should be exported as individual .SVG files, and be black in colour unless otherwise specified. The designer should aim for the icons to be exported as the same size, otherwise inconsistencies will arise when sizing is done on the website.
Imagery: Images that appear either within body content, or as background images need to be exported at the resolution desired. It needs to be made clear whether images are to be compressed or not, otherwise compression will take place for performance reasons (especially for mobile).
- Fonts that are not system fonts should be provided under the following formats:
- Make sure you have lincesses to use all the assets on your site / application.
Being able to deliver 100% of the list is not necessary, but the more compelte the list, the more efficiand your developpers will be able to work.