Over the past few years, we’ve seen front end development go through some significant changes in how we approach pretty much everything. Whether it be height/width, font sizes, icons, responsive - the way we set these values up on the front end has changed, and so too must our designers in order for our two worlds to truly start working in harmony. All too often I come across .PSD files (or even .JPGs yikes!) with their units set to points, the resolution set to 144 or sometimes even higher - what a nightmare! That’s just the tip of the iceburg, and it’s time for all of this to stop. Hopefully this post can shed some light on what truly needs to be delivered to a development team in order for them to get things done quickly, as close to perfect as possible, and with little back and forth between the two parties. Designers listen up because this is going to save you a lot of headache.
Bringing it all together with a Style Guide.
There is a tonne of documentation on the internet on why a style guide is a basic necessity for a website these days, so I’ll just briefly outline a few reasons below and provide a link to Yelp’s engineering blog post regarding the subject that explains their reasoning behind the Style Guide they set up for themselves.
a point of truth for all developers
a point of truth for all designers
provides detailed descriptions of common elements
gives clarity over the amount of components that are being used in the site
- allows for rapid site development at the beginning of the project
Additionally, your style guide should always contain the following elements:
typography (h1-6, paragraphs and any other types of headings)
buttons and links
form elements (try to stay away from customizing these anyways)
- grid system / vertical rhythm
Your best friend is now a grid system. Get to know him well, and don’t disrespect him by doing silly things like not using him for the odd page here or there. Front end developers will set up a grid system for the sole purpose of making sure that all of the widths of the layout and other various pieces of content match your mockups. My advice here is to always export a grid layer with your .PSD file so anybody can quickly check to see how many columns a certain block or area of the page is. There are many grid systems out there, so do your research and find one that suits your needs. The only thing I would warn about is to make sure that you have the proper values set for your columns/gutters/margins. There is a great grid system generator that can be used if it’s your first time working with one.
There are no half measures/pixels when it comes to font sizes.
Pure and simple, do not use a value along the lines of “24.5px” as a font size in your .PSD document. Some browsers will take that number and round up, some will not round at all, so why risk it? If your entire design is hinging on that .5 of a pixel, then you have probably been looking at your screen for too long. Go for a walk, come back, and change it to 24px.
Icons are now SVG, not rasterized images.
When delivering a page to a dev team, it’s a good idea to provide any and all icons in the page as their own individual .SVG files. Because of all those fancy retina screens out there, all of the image sprites that were so popular between 2008-2012 are now looking like nintendo 64 games being played on a plasma TV. Seriously though it makes your eyes water. What we do as developers is take those .SVG files and put them together as our own .SVG sprite that we can manage ourselves and add/edit/remove icons as need be. It is a scalable, and practical solution for handling iconography.
Set the resolution to 72, because nobody wants to open godzilla/computer crippling photoshop file that has it set to 300.
I get it. You have one of those huge iMacs that covers your entire upper torso and the only way to effectively work with all that sweet screen real estate in Photoshop is to have that resolution bumped up to 144 (or even sometimes 300...). Well besides the file size being out of this world and almost impossible to simply email to someone, the values of the units you are using will often conflict with what you have set up in your style guide (because you made one of course). A headline with the font size of 24px is now suddenly 48px, and now either the developer who has received this either doesn’t notice and uses 48px, or he has to take the initiative to reduce the resolution down to 72. So why don’t we avoid all of this confusion and just export everything out at a resolution of 72.
OTF is not the only type of font format that exists.
Your totally obscure font should be delivered to developers in the following formats:
If your font is hosted externally, that is totally fine - but you will have to provide the <script> that goes along with it so developers can make use of the font families. If you cannot download the font with the above formats, or you cannot find the appropriate <script> to bring them in externally, then I would highly suggest finding a different font that can accommodate these needs.
Vertical rhythm is also a thing.
Setting up a vertical rhythm system is a great idea as it gives your developers some consistency on how far apart to place elements vertically. Just like the Grid System I mentioned before, this is something that would be set up at the beginning stages of a sites’ development, and documented for all developers to take note of. For a detailed explanation on it and a good starting point, check out this tuts article.
Export those retina images separately.
We spoke about retina images previously, so let’s talk about the case where you actually do need to have retina images send around. Usually a designer will just have their high resolution image in the .PSD file, but we don’t want that - so let’s export it separately. This way you can provide the developer with a high/medium/mobile resolution set of images that they can then bring in depending on the context of the screen size. Your full deliverable would look something like this:
page-front-icons.zip (contains .SVG icons)
So this blog post may be perceived as a bit of a rant, but I would like to think that it is more about getting the conversation started about how to fix our processes so that we can all work together more effectively, therefore producing better websites for our clients.