This page was created specifically to guide graphic designers and creative directors who are designing for the web.

It’s critical you understand the limitations and considerations of the design-to-web process to set expectations for the final product. Not understanding the information in this document can cause confusion later on, or produce a result that looks different from the original design or from what you expected – and so we encourage you to contact us (details below) if you have any comments/questions/concerns. Moreover, not adhering to these standards can increase your budget, or even prohibit your project from beginning.
 

File formats
  • Layout submissions should be in the layered, PSD file-format. Proper naming and organization of layers into logical groups can greatly reduce slicing time. In some cases the project will require additional budgeting if your PSD file is ‘in a mess’.
    (We also accept formats such as: Adobe XD, Zeplin, and InVision - but if you use something not mentioned here, just ask!)
  • In most situations, it's preferred to NOT use Layer Comps in Photoshop.
  • Please do not include frames that show your design inside a web browser, unless they are intended to be part of the programmed site.
  • Blend modes (such as 'multiply') are something difficult to slice because it's dependent on the layer(s) below it. Blend modes should not be used unless it is the intention for the object/layer using a blend-mode to merge with the content below it.
  • (optional) We recommend creating a typography layer. This usually involves a list of all typographic elements such as H1, H2, etc., Paragraph, Italics, Strong, Lists, Form labels, Blockquote, etc. We can provide an example if required.

 

 Dimensions
  • The dimension of your layout must be sized to the final desired width and height. In other words, send your template at 100% size. For example, if you send your design as 10,000px wide, it will appear as this dimension in your browser!
  • Consider most every website built today is 'mobile friendly (display-agnostic): in other words, it adjusts - either fluidly, and/or from fixed breakpoints - based on the screen size viewing it. Your design should take this into account. See Mobile section below for additional considerations.
  • We recommend even numbers for width/height/layouts as it makes it much easier to divide in half evenly (for centering, and overall positioning).
  • If you are using a grid system (such as Bootstrap) please include the column/gutter dimensions (in an annotated layer, or just as a note alongside the design)
  • A good place to better understand popular browser dimensions is the GlobalStats StatCounter.

 

DPI and Quality
  • The design should be in 72dpi raster format. Do not send your entire design in vector format.
  • If you require any image/graphic assets to be displayed for retina screen (@2x), please indicate these and supply separately. We highly recommend using a vector format for these such as SVG where ever possible for optimization and compatibility reasons.

 

Fonts
  • Some end-users do not have certain fonts on their computer which your design may be using. This can produce undesired results. As a safeguard, it is suggested to only use web-friendly fonts. A good site to verify safe fonts is: Wikipedia's "Core Web Fonts"
    If a unique font (non web-friendly) is necessary, a workaround can be to create the text as an image. It’s important to note that this can inhibit search-ability, unless extra programming is added. This will mean more production time required.
  • Syndicated fonts selected from services such as Google Fonts or Adobe Fonts are also acceptable. Using syndicated fonts will add extra page load time, so we recommend minimizing the amount of these used (not just font families, but weights/styles for each family as well).
  • Fonts can also be embedded directly on the page, but this is not recommended (both for compatibility, performance, and because you are required to have the license)
  • We do not recommend using embed options from Fonts.com (in our experience, they provide typefaces as many individual files and it is not as intuitive to incorporate).
  • A valuable and common icon font set is Font Awesome, we recommend using this in place of graphic icons as it can reduce load times for your coded site (and make it easier to maintain).
  • Most web browsers have client-side accessibility controls allowing them to change things such as the size of their fonts or the zoom level of the overall page. These client-side controls cannot (and should not) be overridden.
  • Any text in your design that is intended to be true-text (not as part of an image) can not contain any special effects like anti-aliasing. When these effects are removed it can drastically change the appearance of these typefaces. That said, many effects - like dropshadow - are fine.
  • Fonts should also be rounded/whole numbers (so no 12.5px for example).
  • Some browsers will render fonts differently than others. We strongly recommend against using Helvetica.

 

Standards and Browser based-considerations

 

Accessibility
  • Some user’s browsers and operating systems have accessibility settings that change appearances for people with disabilities; this is a client-side controlled feature and your design may be distorted in these situations. For example, Windows-based operating systems allow the user to turn on 'high contrast colors' for people with vision impairment – these greatly affect the appearance of a website, and cannot be controlled by programming inside the website.

 

Assets
  • Repeating assets used in the design (such as textures) or icons should be supplied separately (i.e. in a 'resources' folder) to make it quicker & easier to convert to web.
  • Social Media Icons. If your design includes social media icons (share/follow buttons) it is important to reference where you pulled them from as the API's that provide them can be limited in the design customizability.

 

Mobile
  • For each unique page type you are designing, please provide [at minimum] a layout in desktop, tablet (portrait), and mobile (portrait).
  • It’s important to remember that a finger is not the same as a mouse pointer, and that certain mouse behaviors cannot be replicated by touch-screen devices (for example, "hovering" your mouse over something). You should indicate any nuances in your design between cursor and touch behavior (for example, perhaps there is a "swipe" motion required on mobile).
  • A finger is a also a lot less precise than a mouse pointer, and users will have a hard time clicking on small links or buttons; something to be mindful of. Recommended 'hitbox' of no less than 36x36 px.
  • When designing a 'responsive' site (one that adjusts to the screen size being used), consider the following:
    • be mindful of the difference between 'fluid' and 'fixed'. For Fixed responsive, we generally need a PSD for each 'breakpoint'. For fluid, you may have to provide additional 'in-between' breakpoints to show how elements adjust. Generally, Fluid responsive is a more costly exercise for the testing time alone.
    • your content should flow in an orderly/predictable manner: For example, if you have elements that sit side-by-side "A,B,C" on a desktop screen, but stack on top of one another [in a different order] on a mobile screen "A,C,B", this adds programming overhead and requires additional time to customize.
    • If you're unsure about the smallest breakpoint for responsive, we recommend designing to fit on a 320x640px screen: this is a mid range that seems to cover the majority of the modern smart phones.
  • As mentioned above, some devices have higher pixel density screens known as 'retina' (@2x). So for any static graphics you wish to have high DPI compatibility, we recommend providing a vector format for these (such as SVG). Alternatively we recommend supplying a graphic that is double the resolution of the one that appears in the design. This will make the graphic appear much smoother on these high pixel density screens.

 

Brownie Points

These specifications are not necessary, but if you follow them - we will love you for it :) In all seriousness, following this section just saves you time & money.

  • Proper layer grouping, naming, organization.
  • Don't leave any 'test' or 'draft' layers that are no longer used in the final design but are remnants of early concepts. Even if they are hidden they can create confusion, it's best to simply remove them.
  • Create an annotation layer. This involves using a layer (or group of layers) to make notes related to certain functionalities or consideration during design-to-web. The notes should be simple but help direct the slicer with something that might have otherwise missed.
  • If you have a box-element in your design containing content, using guides will help us accurately replicate your margins in code.

 

Copyright and Legal
  • Any assets or files (including typography and content, stock photography, fonts, and so on) that you provide us are entirely your responsibility and it is implied you have proper permissions to use them. If you are to provide us with stolen or unlicensed materials, we cannot be held liable for any consequences that may result in using these with your website.
  • This document is owned by Webbuilders Group and cannot be duplicated or copied without proper consent.

Comments or Questions? We encourage you to ask us!