6 Things to Do Before Sending a Site Design to a Developer
Posted September 16, 2011 in Design, Web Design
As web designers, sometimes it is far too easy to look at a completed design and think it is ready for production. But any developer will tell you that bringing a design to life in code takes more than just a pretty design. To expedite the coding process and ensure the product more closely reflects the design, make sure you do these six things before handing off your next design and your developer will love you forever:
1. Provide or Rasterize Your Fonts
Let’s face it—the likelihood of a developer sharing all the same fonts as you is about the same as finding a unicorn in your liquor cabinet (before the liquor was consumed, friends). For any text that will be part of an image or graphic, it’s usually safe to rasterize the text. For text that will likely be formatted as HTML, the best option is to provide the fonts separately so the developer can change or copy the text if needed. Finally, if you have used a font that will be embedded into the code, be sure to provide the code or a link to the code so developer has access to that as well.
2. Create Seamless Background Tiles
Unless your background is a solid color, your developer will likely attempt to repeat an image across the background to expedite loading time. The problem is, if a background design has any texture at all, the tiles may have seams, giving the site a very 1995-esque appearance. Save them the headache and create your own seamless tile background.
After you create the tile, use it in your design by placing and repeating it. It’s important to do this before you send the file to your client so they see a close replica of what the final output will look like.
Finally, include the tile in the files you send to the developer.
3. Develop a Style Guide
If you haven’t been creating style guides, you will probably find that it is just as useful to you (and others on your design team) as it will be to your developers. Take the guesswork out of styling the site by creating a simple guide showing the hierarchy of headers, body text, and links, at a bare minimum.
Style guides should also include a color palette (with hexadecimal values, please). With a guide in hand, developers can jump headfirst into coding CSS, rather than muddling through your design and making guesses.
4. Include Rollovers
This isn’t something you need to (or should) depend on the developer for—it is, after all, your design!
For each menu or button, include a visual for what it should look like in the unused state, rollover state, and active (or as it is being clicked) state.
The illustration to the left is one example of what this could look like.
5. Organize and Name Your Layers
It cannot be emphasized enough how important it is to give each layer a meaningful name. Clean up the layers palette by grouping major elements into folders, and arrange everything in the same order as you would see them if you were scanning down the page of the design.
At the topmost level, the header, main content, side column, footer, and background should be visible, plus any other major sections of the site. It’s also wise to include each page as folder within the main section, rather than as separate files altogether—that way, if the header changes, it only changes in the one file and you don’t have to make the change on every other page (and the developer doesn’t have to guess which version is correct if you didn’t make the changes perfectly across all pages).
6. Clean It Up
Clear any guides that wouldn’t serve a purpose for the developer, and delete any layers that will not go into the website. Also make sure the file name itself isn’t a mess (website-version6-final-090211-v2 can be replaced with something simpler like website-final). Your developer will appreciate the time it saves from not having to wade through unnecessary elements to get what they truly need from your design.
Your Turn
These are just a few things that can make your developer’s job (and yours, in turn) much easier. What are your tips? Feel free to share them in the comments.
Images by Mandy Barrington
Related posts:
- Ten Things Every Beginning Developer Should Know
- Design and Code a site with Gimp, HTML and CSS
- Design and Code a site with Gimp, HTML and CSS (Part 4/4)
- Great Firefox Plugins For Any Web Designer or Developer
- 8 Web Development Mistakes that Make Any Site Look Bad
About the author: Mandy Barrington is the lead web designer at RYP Marketing, a company specializing in online marketing and website optimization. Check out more tips and advice on their blog.
The Unlimited Freelancer is Now Only $19
Unleash the true potential of your business. Get The Unlimited Freelancer and start transforming your freelance business,
now only $19.
Try searching "Getting Clients" or "Productivity"
Free Report
Sign up for our product discount list to get a free copy of Why Some Freelancers Thrive and Others Barely Survive. You can unsubscribe anytime.
Forum Discussions
Popular Articles
- SEO Techniques All Top Websites Should Use
- When a Client Can't Afford You: Why It's Still Better to Bid High
- How To Stop Scrambling For Clients And Get A Steady Stream Of Paying Gigs
- A Simple Way To Stop Clients From Rejecting Your Proposals
- 3 Reasons Your Rates Are Still Low (And How To Start Raising Them)
30 Comments
paul
September 16th, 2011 at 8:40 amthere’s an excellent resouce for this:
http://photoshopetiquette.com/
Mandy Barrington
September 16th, 2011 at 9:19 amThanks, Paul! We should all be Layer Mayors…haha! Great resource, that one’s going in my bookmarks!
Tony Crockford
September 16th, 2011 at 9:42 amI also ask my designers to send my a flat jpg or png for each template as reference.
I use Fireworks as it covers more bases, but sometimes it doesn’t handle photoshop layers as the designer intended – trying to work out which layers should be visible for which page can get messy, but with a flat image for reference it’s much easier.
The style guide should also explain dividing lines and borders – are they one pixel wide but anti-aliased or actually a two pixel line of two different colours?
And if everything is supposed to line up on a grid, please say so. zooming and measuring is frustrating – leave some guides in place.
Tony Crockford
September 16th, 2011 at 9:46 amand another thing, if boxes have backgrounds, and they’re supposed to expand with content, make the backgrounds big enough – recreating gradients for taller than illustrated boxes isn’t much fun.
And please consider that an expandable rounded corner box with a gradient background and a drop shadow over a textured gradient body background is quite tricky to code for all browsers. (CSS3 will save us all!)
:)
Mandy Barrington
September 16th, 2011 at 10:02 amAgreed, Tony—having at least a basic knowledge of the current CSS capabilities would greatly benefit any web designer, and could save the developer a huge headache!
I think Fireworks will be the next tool I really dive into trying to learn—after reading the article below, I think it could be really powerful web design tool. It seems most designers do use Photoshop, however, so it’s important to keep that discussion going!
Thanks for the tips!
http://www.reinegger.net/50_reasons_not_to_use_photoshop_for_webdesign.html
Rick
September 16th, 2011 at 10:17 amWow! I wish our designers did this! I am posting this to everyone of them right now
Catena Creations
September 16th, 2011 at 11:20 amI would add to this: Make sure you and your developer speak the same language. I worked with a developer last year who did NOT understand the concept of point sizes for fonts. He only worked in pixels. It took 3 days to redo the style sheet I gave him and get everything to where it needed to be.
I very highly recommend Fireworks. I have been using it since 2001 and much prefer it over Photoshop. It is much easier to use and to me, it makes more sense. It also has a bunch of great graphic effects under Window > Styles. Click on the Styles button, then click on the drop-down menu that comes up. The effects can be modified in Photoshop and Illustrator.
Tony Crockford
September 16th, 2011 at 11:25 am“I worked with a developer last year who did NOT understand the concept of point sizes for fonts. He only worked in pixels. It took 3 days to redo the style sheet I gave him and get everything to where it needed to be.”
Point sizing for the web is unreliable as it is affected by display DPI, that’s why developers use pixels or relative font sizing. The web isn’t print.
Murray Lunn
September 16th, 2011 at 11:47 amUgh, if I had to tell you how many times I had to work with a JPEG for design work I’d go crazy. I always made it important to do proper structuring in my PSD’s simply because I had been on the receiving end of jumbled messes far too many times; didn’t want to pass on that pain ha!
(Btw, also here in Tampa, cool to randomly see a local group here on FF)
Mandy Barrington
September 16th, 2011 at 1:22 pm@Rick—Thanks, glad you found this helpful!
@Catena Creations—Thanks for the Fireworks tips, sounds like a lot of people prefer that program. The language barrier is a tricky one, but measurements are universal…it’s interesting that your developer had difficulty understanding point sizes.
@Tony—I think points are still pretty common when specifying font styles, though there’s a lot of debate as to whether that’s a good thing! What font measurement unit do you recommend?
@Murray—yes, it’s hard to believe what people think you can magically do with a JPEG! Tampa is a beautiful area!
Catena Creations
September 16th, 2011 at 1:27 pm@Tony: Since I have been desiging Web sites for 14 years and designing print publications for more than 30 years, I am very well aware of the differences between points and pixels.
However, everyone commenting here and the blog author are talking about using Photoshop and Fireworks. Those programs only allow you to size type in POINTS. If you’re working with a developer who only understands PIXELS, it leads to confusion and frustration — which is what I experienced with this developer.
So I guess I would expand on my comment and state that when you create your style guide, be sure to put your font sizes in pixels, not points, and do the conversions before you send the information to the developer.
Tony Crockford
September 16th, 2011 at 1:32 pm@Catena
“So I guess I would expand on my comment and state that when you create your style guide, be sure to put your font sizes in pixels, not points, and do the conversions before you send the information to the developer.”
Now I understand you.
since a pt is not a px unless you have a 72dpi display, it is essential to design a layout that works with a variation in text size. What DPI will you choose for your conversion?
I’m hoping you understand that the font size you’d like isn’t the one that you’ll get in every device.
Tony Crockford
September 16th, 2011 at 1:58 pm@Mandy
“What font measurement unit do you recommend?”
I wouldn’t.
Visual designs that don’t allow for text to be bigger/smaller/different fonts *will* break.
You can’t guarantee that the font size you want will be the one that you get. A developer can make it look like that for *you*, but someone with an old or mobile browser may see something completely different.
This article suggests using the new CSS3 rem unit. All very interesting, but the reality is no matter what font and size you specify, someone somewhere will want it larger, or smaller.
Mandy Barrington
September 16th, 2011 at 3:08 pm@ Tony
You’re definitely right, there needs to be an understanding between the designer and developer that text will not possibly look the same on every device and browser. Designers should leave a little bit of leeway for that. My question was, when you actually marking up the page, what size unit do you use (ems, percents, etc.).
Tony Crockford
September 16th, 2011 at 5:30 pm@Mandy,
I’ve used ems, a mix of % and ems and px. I think the debate over which is best, still hasn’t been resolved. I like ems, as you can change the whole site by just changing the body font size.
Mo
September 17th, 2011 at 1:39 pmMake a style guide, organize and name layers, clean up the mess … Absolutely! But rasterize fonts and make such a nasty ugly rollovers (deprecated word) … that belongs to year 2005.
Nikhil Malhotra
September 17th, 2011 at 2:36 pmI agree with all the points…We should care for developers as well.Thanks for sharing:)
Aljiro
September 19th, 2011 at 8:48 amI agree with your points and from reading the comments here I can imagine how big a problem it actually is. I suppose I’m not aware since I both design and develop but I do know how to keep my design stuff understandable from when I check them a few weeks after I first made them.
ExcelAssist
September 20th, 2011 at 5:17 pmThese are so good to be aware of. @Tony Agree with you on the EMS flexibility and power.
Roberto
September 21st, 2011 at 3:58 pmAlso, remember to include some instructions on how the site should degrade on older or less capable browsers and devices. Specially on these days of mobile, laptops and tablets, sometimes with restricted bandwidths and smaller screens.
Ideally your developer should be able to help you with some of this, as he or she should be familiar with those capabilities and help you decide on things like font stacks, backgrounds, text shadows, etc. as well as some interaction and accessibility decisions (what happens if there’s no javascript? or if the visitor is color blind or needs to increase the font size?)
Sprinkler Buff
September 28th, 2011 at 2:11 pm@ Mandy
Awesome points! I am new to web design and am a bit nervous about submitting my first project over to the developer. This post was a HUGE help to me and I will be bookmarking it for future reference!
John
November 26th, 2011 at 7:02 pmThe seamless background tiles becomes a problem if not done right. I’m not sure why most people fail to do that.
reverse phone lookup
May 1st, 2013 at 11:46 pmHow much of an exciting piece of writing, continue creating companion
Trackbacks