A Designer’s Guide to Dev Handoff – The Design Process

The Design Process

During the design process, it’s easy to overlook that navigation graphics should have at least three states of user interaction that will need to be defined in a stylesheet. Place each state on its own layer and name that layer to correspond to its function. As an example, using the following for the layer names of a top navigation element (topnav, topnav:hover, topnav:active) will help to establish a common naming convention and language that both the designer and developer mutually understand and recognize.

Create sprite groups of navigation or button layers or layer groups to ensure that what you envisioned as a designer will get executed in the code. Position the default state as the bottommost layer within the group with the hover and active states above. Sprite groups are images that can all be combined into one larger transparent image using a common horizontal and vertical spacing that developers position on a website through code to determine which image in the sprite is displayed. This helps the user by loading the website faster since fewer files will need to be downloaded.

When creating sprite groups, it is also recommended that a consistent height be used for all of the states so that it is easier for the developer to calculate the background-position of the elements while coding the CSS. If this is not possible because of different heights for default, hover, active, etc. ensure that a common design point, such as top left or right corner, exists.

Form Fields

Web browsers have default styling applied to form fields that is usually pretty bland and basic. Depending on the operating system, as well as the targeted browser, designers may wish to create custom for fields, buttons, drop downs, checkboxes and more.

One of the longest standing and most commonly requested modifications to a form has been for custom “submit” buttons. When designing custom buttons for a form, ensure that you also include the various states that may be required by the button. For instance: hover or active.

Custom input fields have become more common place, especially since HTML5 allows for placeholder text. Keep in mind that when you are designing custom form fields, like input boxes or textareas, you can also incorporate placeholder text. This text can take the place of “label” copy or be used as a compliment to it.

One of the most complicated form elements to reliably style cross browser are drop down/select elements. Often times the select element only allows for minor customization or must be completely custom built from other elements to match the creative. Keep close contact with your developer when designing custom for elements as custom built elements often require custom scripting to ensure the element functions as expected. This could lead to complications with the timeline and/or budget.

Interaction & Messaging

You should be careful to consider error states, error messaging and additional notification styles. Work closely with UX/IxD to plan for proper messaging and interaction.

Logged In/Out

Often times an interface can take on slightly different UI components based on whether or not the user is logged in or not. If your interface allows for logging in/out states, ensure that the layouts exist for both and the layer comps are clearly named and the layers are plainly grouped.

Error Messaging

Error messaging refers to numerous elements/events.

  • Form errors – form field states/messages
  • Overlay/Tooltip error notifications
  • 404/500 Error Pages

Modals and Messaging

Overlays for messaging, image lightboxes, custom messaging, etc should also be considered. Don’t forget to specify the “semi-transparent” modal overlay background color, opacity values, drop shadows and stroke styles. Based on the decisions from the UX team, you may also need to include a “close” button – which could truly be a button or an “X” in one of the upper corners of the modal.


Web safe fonts (including licensed web fonts) that are meant to be used for headings, sub-headings and body copy should not be flattened (rasterized) and remain as editable text layers. By leaving the text layers editable, developers can select that layer and check the Character Panel for all of the values that will need to be ported over to their stylesheet. All text not intended for, or able to be used as, live text will be converted to graphics.

In order to maintain the visual integrity of the layout, it is best to always use whole number values for fonts. Example: 14 not 14.25. While Photoshop allows you to use decimal point values, HTML is not as forgiving and work-arounds can lead to undesirable results in various web browsers so use the whole number values ONLY for your font sizes.

Leading should be limited to whole numbers just like the font sizes.

Your kerning should be kept to ‘0’ as often as possible. When designing a website, legacy browsers do not reliably support kerning in the same way newer browsers do.

Finally, consider that each custom font that is specified in your PSD needs to be made available to the web page.

Multiple fonts can add dramatically to the load time for a web page. Custom, licensable fonts do not typically include the bold or italics glyphs within a single font file. Instead the different variations of a typeface also require an additional font file to accommodate the additional glyphs. Designs should be limited to only two or three font families, taking care to limit the amount of font weights and types.

Special Cases for Fonts on iOS

When designing for HTML IVAs that are targeted at iPads and built on 3rd party platforms (e.g. – eve, iRep, Skura), you can freely use fonts that are native to the particular iOS version that is being targeted (iosfonts.com). This permits special flexibility over designing for websites since the iOS fonts are already present on the device and do not need to be loaded independently in order to use the font face. Try to stick to this practice when designing for the iPad, however, if a specific brand font must be used, please also provide the name of the specific iOS font family that closely resembles that font to be used as a fallback in case the requested custom font happens to fail. This is rare but has been seen to randomly happen on different presentation platforms.