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
  • We accept several formats including (but not limited to): Adobe Photoshop, Figma, Zeplin, and InVision. If your design is in another format, please let us know.
  • We recommend against using vector based formats (such as with Adobe Illustrator), as the dimensions don't translate properly to web. These formats are better for print.
  • Whatever the 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 file is ‘in a mess’.
  • 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, almost 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 center-ing, 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.
  • 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
  • Whenever possible it is suggested to only use web-friendly fonts. A good site to verify safe fonts is: Wikipedia's "Core Web Fonts" . 
  • Syndicated fonts from services such as Google Fonts or Adobe Fonts are a good solution to make additional fonts in your design available to users who otherwise don't have them on their computer. 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).
  • When using a font visitors may not have, a workaround can be to create the text as an image. However, this is not ideal for accessibility, searchability, or edit-ability.
  • Fonts can also be embedded directly on the page, but this is not recommended (both for compatibility, performance, and because of licensing considerations).
  • We do not recommend using embed options from Fonts.com (in our experience, they provide typefaces as many individual files, making it difficult to integrate).
  • 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 antialiasing. When these effects are removed, it can drastically change the appearance of these typefaces. That said, many effects like drop-shadows are fine.
  • Fonts should also be rounded/whole numbers (so no 12.5px for example).
  • Some browsers will render fonts differently than others.
  • We recommend against using Helvetica.

 

Standards and Browser based-considerations

 

Accessibility
  • Accessibility for the web is a broad topic. It includes consideration for a wide variety of content formats and interactivity, and for a diverse range of users with varying disabilities (including visual, auditory, physical, speech, cognitive, language, learning, and neurological). Even if we strive to achieve full compliance in the programming, you may not meet compliance in other areas. For example, with your written content, or in context with this document: the design. So, it is important to be familiar with how your design can achieve accessibility compliance (for example color contrast). Some resources:
  • 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.
Mobile
  • For each unique page type you are designing, please provide a layout in desktop, tablet (portrait), and mobile (portrait). You should at minimum provide these 3 layouts for the homepage and one subpage. A good resource to see the most common screen sizes is: https://gs.statcounter.com/
  • Please include any altered interactive elements in your design. For example, if the menu collapses down to a 'hamburger' menu, include those mobile menu styles.
  • 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.

Assets
  • Repeating assets used in the design (such as textures) or icons can 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.
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!