Photoshop layers should always be named and grouped in as *descriptive* and *consistent* a manner as possible.

For example, say you’ve designed a navigation bar for a website, and each button has both a hover and a click (or active) state, as well as having a background, an icon and a text layer. To best communicate your intentions, label and group these layers appropriately: each button should be grouped by its components (the background, icon and text layer) and the group labeled accordingly (e.g. ‘About page button’). Your other interactivity layers should then be immediately below this group and also appropriately labelled.

If you do not name your layers, you will often find that either you get lots, and I mean lots, of questions that seem obvious to you and can be quite time consuming to answer; or in some cases, the web developer may even simply ignore the unnamed layers, resulting in a very flat or static design. In other words, the developer might ‘kill your baby’.

This goes beyond knowing what’s possible in HTML, CSS, and JavaScript. If you care about every pixel, then I think you should want to understand every other layer of the stack (the various software technologies utilised in a site design). As long as you don’t spread yourself too thin, you’ll be a better rounded (and more employable) designer.

Don’t use layer FX unless absolutely necessary

This one is quite medium dependent. For a website that’s primarily targeting the desktop, and can make use of the full range of web browser styling features, layer effects can often be implemented without too much fuss. For a project targeting mobile devices however, layer effects can wreak havoc with the developers’ implementation and schedule. (And let’s not even get into how it can affect other mediums than the web, for example Flash or Unity games…)

Please be sparing with layer effects. That outer glow that adds a nice subtle effect to your text layer might look sublime in Photoshop, but do you know if it’s actually feasible to implement an outer glow using CSS? If in doubt, *check with the developer first*. Even if you find out from Googling that a technique is possible, bear in mind that not all developers have the same level of experience, and getting something cutting edge to work in older browsers can sometimes put a developer in an absolute world of pain.

Every designer worth their salt understands the importance of typography. Even some of us developers understand it. Since the CSS @font-face rule gained popularity (sometime around 2009), designers have rushed to embrace the new possibilities of using any font in their designs. Gone are the days of rasterizing headers, a practice that was incompatible with search engine optimisation: the new age of web typography is here, and it’s not going away.

Of course, most advances come with their drawbacks. The biggest drawback is getting sued for using fonts that you haven’t purchased for use on the web, and is often ignored or overlooked: check that all the fonts you want to use in your design have been properly licensed. People and companies can, and have, been sued for using fonts they don’t hold the rights to. Companies like Adobe have huge legal funds and aren’t afraid to use them to enforce their copyrights.

Other drawbacks can arise from the legal ones. Just like designers, web developers want – need – good tools, and implementing embedded fonts on the web is no exception. Some fonts will be available on Google Web Fonts or Adobe Edge Web Fonts, but many will not, and to embed them in a website can be time consuming if the tooling doesn’t support those fonts: to work in all browsers, embedded fonts need to be made available in 4 different formats (EOT, SVG, TTF and WOFF). There is a high chance that the more common unlicensed fonts will be blacklisted in the tools that can generate these formats, creating a big headache for the web developer.

If at all possible, start your design using only fonts available on Google Web Fonts and Adobe Edge Web Fonts. These two resources have several advantages:

1. They’re supported by large companies, so will not be going away anytime soon

2. They provide a complete “cloud hosted” solution for the fonts – Google’s web fonts are completely hosted by Google, so the web developer doesn’t need to worry about generating font files her or himself.

3. You can count on them being legal for you to use.

Finally there is one more drawback to using custom fonts: different operating systems and browsers have different font rendering engines. I’m sure most designers are aware that font rendering in Windows XP doesn’t look as good as on a modern Apple system. You might also have noticed fonts don’t look the same on different browsers on the same computer. Chances are, the more unique or unusual the font face, the bigger the chance there will be significant differences in appearance between platforms. A font can vary significantly in its appearance between your design in Photoshop and in your browser on the same computer.

The moral of this rather long-winded tip is if in doubt, *use Google or Adobe’s web font solutions*. You will be happier with a design that looks consistently great, and the web developer will be happy not having to spend hours trying to convert font files instead of working to bring your design to life.

I’m fortunate enough to be on both sides of the ball on this one. Working with Drupal and WordPress has taught me that even the smallest changes to the default can be huge, time-consuming problems.

Always work with your developers before you get final designs approved (it’s even better if they’re there in the beginning). You need to make sure you’re not causing hundreds of tiny headaches on decisions that don’t make too much of a difference, e.g. the date format on a blog post… could you live with Jan 4th 2012 instead of January 4th 2012?

This one is all about communication again. Some parts of your design will probably need explaining: how things should scale in different resolutions; where popup menus should appear (below each button? Or left-aligned below the whole navigation bar?); anything that should move or animate. If anything needs explaining, write a brief outline describing what layers are involved, and what should happen, so the developer can bring your design to life *as you designed it*.

This is also another part where technical limitations should be kept in mind, even if it’s just at the back of your mind: it’s always worth checking with your friendly web developer whether your custom animation or responsive design is possible, given the technical and time constraints of the project. On larger projects with many custom design elements, you should check with the project manager too to see if what you’d like to do will fit into the budget.

People will always appreciate communication about design decisions. Involve people and help them help you realise your design.

The most successful developer/designer relationships are founded by those with a mutual understanding of the other’s craft. Consider the following: Web designers are also developers, of the front-end family; likewise, developers are in fact designers, of the architectural breed.

Are you getting this? You’re both on the same team!

This fundamental understanding of not only the stomping grounds on both ends, but also how the professions truly overlap is vital to a successful working relationship. Think of it as knowing the strengths of the other. When you possess this knowledge, you can use it to empower your process – how you deliver assets, how you communicate, etc. – which, again, will lead to immeasurable harmony.