(these are the things that you MUST send to your developer before your next project begins)
Imagine that you’re in the middle of your next development project. You assume that your developer is working hard on turning your design vision into reality, relieved that you can move forward on other things while the hard work of site development happens behind the scenes. But then you check your emails…
…and find that the project has come to a screeching halt because you forgot to send an essential file or bit of information to your developer. You scramble to send it out, hoping your mistake hasn’t had too much of an impact on the project’s timeline. Things seem to be humming along at a nice pace for a while, until…
…it happens again. And again. No matter how many times you look over the information before sending it out, you always seem to miss something. It’s frustrating for your developer, it negatively affects the project’s timeline, and it can even damage your reputation if it happens too frequently.
What if I told you there was a way to avoid all of that frustration?
Send the right things up front to put your next development project on auto-pilot
It’s that simple—and that difficult. Knowing what things are the “right things” to send isn’t always easy!
My clients often approached me with this question, so I decided to pull together a quick reference of all the most important things I need as part of the development process last year (and recently revamped it as part of an upcoming collaboration with my developer friend Krista). I’ll explain each item below…or, just scroll on down to the bottom to get your hands on the checklist right now. 😉
Assets to send (ie: “tangibles,” like files):
- Your mockups: Probably the single most important asset you need to send to your developer. Without mockups, there’s not much that a dev can do to recreate your vision! Make sure to include both editable versions (PSD, AI) as well as non-editable versions (PNG, JPG) in case your developer doesn’t have the necessary fonts installed on their machine, or use an app like Invision to take care of all that for you.
- Logo files: Include Retina and standard definition versions. If you’re using a submark or variation in the design—like as a replacement for the main logo on mobile—be sure to send it in both Retina and standard versions as well.
- ALL other images or graphics: Go over each mockup and make a list of every image or graphic you use, then be sure to include ALL of those images with the files you send to your developer. Images are one of the most-often missed assets since there are usually many of them throughout a website, so by making a list, you’re a lot more likely to catch and send them all. In general, graphics (illustrations, icons, etc) should be sent in standard and Retina versions; photos should only be sent in one version – check with your developer and see whether they prefer to receive photos in standard or Retina format.
- Copy/content: If possible, send a separate file with page copy/content in a format that can be easily copied and pasted into the site as your developer is building it. A Google Doc, Word document, or Pages document is perfect for this.
- Web style guide: More than just a brand board or moodboard, a web style guide covers how to style all important aspects of a website, from headings to form elements. This guide is especially important if there aren’t clearly marked examples of each element in your mockups.
- Code and license keys: If your developer will be using any premium themes, plugins, or extensions in your project, you or your client are normally responsible for purchasing and providing those before the project begins. Make sure to include copies of those as well as license keys (if needed).
- Webfont files or embed code: Will custom fonts be used in the project? Make sure to either send an embed code for your font service or copies of the font files so that your developer can create a usable webfont kit. And, before you do, quickly check your fonts’ licenses to make sure you’re clear to use them on the web! Many fonts require you to purchase web rights separately.
Get this information in a checklist
Information to send (ie: intangibles, like login information):
- Hex color codes: Your developer will thank you if you send a list of hex color codes along with your mockups. 😉 If you use Invision, the app will take care of this for you.
- Style notes: Is there anything you need to communicate to your developer about styling that isn’t obvious in your mockups or isn’t covered by your style guide? Some simple notes may really help clear things up.
- Interactivity: Should elements of the project be interactive (The answer is nearly always yes: think about things like hover states as interactivity, too)? How should they react to user input?
- Responsiveness: Ideally, you’ll provide mockups for each important breakpoint in your project, but sometimes that’s not practical. If you can’t provide a mockup, be sure to explain in as much detail as possible how a site should look and act for screens of all different sizes. Focus especially on very small screens (phones), small to medium-sized screens (tablets), medium to large screens (laptops), and extra-large screens (desktops, large monitors, TVs).
- Access information: Your developer will need access to your client’s hosting account in order to transfer the final site to your client’s server, but they may need to create a copy of the site before development begins for their local server as well. Providing that information up front takes care of both situations. If your client has an existing site, you’ll also need to provide access to that site: either through a new Administrator account for WordPress or through a contributor invitation for SquareSpace.
- Typeface fallbacks: Occasionally in the wild world of the internet, custom fonts don’t load properly. In that event, which web-safe fonts would you like your developer to specify as fallbacks for each typeface you’re using in your design? Try to choose the web-safe fonts that are as close to the original font as possible. You’ll usually want to include at least one fallback that’s widely available on Mac, one that’s widely available on Windows, and one generic fallback (like “serif”).
Want an easy-to-follow checklist covering this information that you can use when your next development project kicks off?
Fill out the form below to get instant access to the From Mockup to Code Mini-Toolkit, helping you put your next development project on auto-pilot right from the start!
Put your next developer collaboration on auto-pilot...
Leave a Comment