How can we help you? What are we up to? See our solutions » Contact us »

How can we help you?

×

What are we up to?

×

We would love to discuss your web development needs with you. Get in touch and let's get started!

C o n t a c t

Thank you for contacting us!

We will get back to you as soon as possible.

×

Specification Guide for Web Designers

(or "How to Make Your Code Monkey Love You When You Submit a Design to be Converted to Code")

If you are a graphic designer who creates designs for a programmer to convert to valid css and html code, check out the following guidelines. Your project will go faster, the end result will match your design better, and you'll prevent us from having to listen to coders mutter and mumble as they try to figure out exactly how you want that web page to look...

If you take a little extra time to follow these guidelines, your project will be more beautiful and more profitable, which is all good.

Web Fonts

As you probably already know, the beautiful fonts you used in your Photoshop file may not render properly in a web page. To ensure the fonts you use in your design will render properly to your web site visitors, you have several options:

Use Web Safe Fonts

Web safe fonts are usually installed on just about any modern computer, which that computer is a PC, a Mac, or a tablet. Web safe fonts are the old standard in web design, and it's hard to go wrong if you use them in your design. They have been around for a while, though, so some people consider them a little boring and old fashioned.

If you choose to use web safe fonts, check out http://www.w3schools.com/cssref/css_websafe_fonts.asp.

Free External Fonts

If you want to use fonts that are more unique, you have the option of using an external font. With external fonts, the font style isn't limited to whatever fonts the web site visitor may have installed on their computer. The fonts are instead loaded from some location on the web, usually either in web site's own directory or on some colossal Google server somewhere.

Google Web Fonts: Google web fonts are a great option for building a nice font family. We sometimes see mixed results using Google fonts, especially when using characters like #, &, and @, but it's a great resource you shouldn't ignore.

Be sure to download the fonts to your computer before mocking up your design so you will be able to see exactly how your fonts will appear. See https://developers.google.com/webfonts/faq if you want to use Google web fonts.

fontsquirrel.com: fontsquirrel.com is a great source for alternative fonts, plus just about anything with "squirrel" in the name sounds cool for some reason. Except "squirrelburger".

Anyway, we've found this to be a great place to start when looking for alternatives to web safe fonts. Start with @font-face kits at http://www.fontsquirrel.com/fontface -- there are plenty of choices there, and the kits make it pretty easy for your developer to install.

Just remember to allow a bit of extra time in the project budget if you plan to use these fonts -- you will spend extra time perusing fonts for just the right look, and the developer will require extra time to get the @font-face kit installed. Also, you will need to send the developer the link to the @font-face kit you're using.

Fonts for Sale

If you don't find something you like at either of the options above, check out http://www.fontspring.com and https://typekit.com/. You'll need to supply the web fonts to your developer along with your design.

Font Families

If you're really particular about how your fonts will appear, supply your developer with a font family for each font used in the design. A font family allows the developer to build a back-up plan in case one of your custom fonts don't work. When a web page is displayed, the visitor's browser will try to display your chosen font, but if the browser doesn't support that font for some reason, it will try the next font in the font family, and so on until it finds a font it can display. 

The last font in the font family should be a generic font that can be universally diplayed, so at least you have some control over how the page looks if the fonts can't be displayed as you originally intended.

Here's an example of a good custom font family:

museo-sans, Helvetica, Arial, sans-serif

Here you see the custom font first (museo-sans), then a fairly common font (Helvetica), then a really common font (Arial), and finally, the generic font that will ensure your visitors aren't going to see something that looks like it was printed on a 17th century printing press (sans-serif).

If you don't supply a font family, your developer will usually choose one. You may or may not like that... :)

Web Page Elements and Characteristics

It's important to define how you want each element on the page to appear -- many designers design a page in its "default" state, and then leave it up to the developer to determine how that dropdown menu background will look, or how a link looks when the visitor hovers over it, and so on.

Keep in mind that many developers don't work with the same brain hemisphere you do, so you may not be happy with the results if you leave these items undefined. Be sure your design files specify how the following items should look and act.

Remember, some of these items may be different on different pages of the page. For example, your main headings on the page (<h1>) may be one thing in the main section of the page, but the heading in the sidebar may be totally different.

  1. Link styles ( <a> )
    1. Font Weight: Should links be bold or normal? Italics?
    2. Link color: What color should a link be? Will it change color on hover? When a link has already been visited? When the user clicks the link?
    3. Link Underline: Will links be underlined by default? Will that change when the visitor hovers over the link?
  2. Page Headers
    1. Types
      1. <h1> Typically 24 - 28px, (Page Header)
      2. <h2> (Page Subheader)
      3. <h3> - <h6> ( Not always used in the design, typically h3 only is styled)
    2. Font Weight (Bold or Normal)
    3. Font Colors
    4. Text Case (All upper case? Mixed case? All lower case?)
  3. Images <img>
    1. Should images have a border by default? 
  4. Unordered lists <ul> ( Bulleted Lists )
    1. Do you want to use a custom bullet graphic?
    2. How far should bullets be indented?
    3. How should bulleted lines be spaced?
  1. Paragraph Text <p>
    1. Font-size
    2. Font-family
    3. Line height
    4. Top, bottom, left and right margins
  2. favicon.ico
    1. This is the 16 x 16 image that can be found representing the site on a browser tab or in the URL address line, depending on the browser.
    2. Here is a useful tool for making favicons: http://www.favicon.cc/
  1. User Interface Elements
    1. Menus
      1. Dropdown menus
        1. Top Menu Items
          1. Font family
          2. Font size
          3. Color
          4. Background Color and/or image
          5. Mouse over Interaction (What changes when user mouses over the menu item? Color? Background? Underline?)
        2. Sub-menu Items
          1. Sub-menu container
            1. Background color
            2. Width
            3. Border colors and size. Solid, dotted, dashed?
            4. Margins
          2. Font Family
          3. Font size
          4. Font color
          5. Mouse over Interaction (What changes when user mouses over the menu item?)
      2. Utility/Footer Menus. Typically a horizontal list of links
        1. Font weight (bold or normal)
        2. Link color (Not hovered)
        3. Link color (On hover)
        4. Link underline (Not hovered)
        5. Link underline shown(On hover)
    2. Forms
      1. Font size
      2. Appearance of fields
      3. Spacing and layout of fields
      4. Buttons: Background, color, font, behavior on hover?

Web Page Layouts

Many web sites have only two page layouts: the home page has one layout, and then all the subpages may have another layout. Larger sites may have more subpage layout options. Be sure to supply examples of each to your developer.

  1. The basic layouts
    1. Home Page
    2. Subpage layout
  2. Other possible layouts
    1. Blog Page: How will the listing of posts appear? How will a specific post be laid out? Will commenting be allowed? If so, how will those look?
    2. Gallery: How will the albums in the gallery be listed? How will the thumbnails be displayed? How will the image look when the user views it?
    3. Store catalog
      1. Catalog listing
      2. Catalog item details
      3. Catalog search and search results
      4. Shopping cart
      5. Shopping checkout
    4. Error pages -- what will the visitor see when they receive a "page not found" error?

There are many other possible layouts -- be sure to think through the possibilities for your project and supply information to your developer about each possible variation.

Testing Your Design

Be sure to simulate the way your design will look on different screens. Sometimes we see designs that look great on a 22" widescreen desktop monitor, but when we view the design on a Macbook, all we can see is the logo at the top of the page. If your design makes users scroll around just to see the main message, they're likely to leave without going to the trouble.

  1. If possible, view the design on different screens
    1. Laptop screen - Typically 1280px x 800px
    2. Common screen - Typically 1280px x 1024px
    3. Wide screen display -  Typically 1600px x 1200px
  2. Above the fold design test -- consider what it being displayed to the user when they first view the page.

Design Tips from a Developer

This stuff is so important, one of our developers came out of that dark place where developers like to live to outline these items for you. Here are some practical tips he developed as a result of years of converting designs to markup. Thanks, Mike, for sharing. 

1. Be careful where the drop down menu of a horizontal menu appears in a design.

  • The background color can sometimes blend with the background of the page, making it difficult to differentiate from the other content on the page
  • Right aligning a horizontal menu can sometimes cause issues when there isn’t enough room for the submenu to appear (we can usually program around these issues, but you need to ensure your project has sufficient budget to allow us to take the time to write around the issues). 

2. Use web safe fonts and @font-face kits, where possible.

3. Do not use bold on hover for menu items unless the default state is already bold. Bolding text changes the width of text, so bolding only on hover may cause any surrounding text and images to shift.

4. What a web developer loves to see in your .psd or .png design file:

  • Examples of link styles
    • Color
    • Hover Style
      • Text color change?
      • Block color change?
      • Underline change?
  • Menu design details
    • Menu item link color
    • Hover style
      • Text color change?
      • Block color change?
      • Underline change?
    • Horizontal menu submenu design
    • Vertical Menu
      • Sub menu item design for at least 3 levels.
  • Example of header tags (H1 - H3) in all content areas on a page. 
  • What do bulleted lists look like?
  • Design comments in the design that explain what is expected.

It's also a great idea to include a flattened jpg of your design along with your layered design file. Sometimes the layered files take on a mind of their own when opened on a different computer, so the .jpg file will alert your developer if problems occur.

Additional Reading

And finally, have a look at these articles -- they do a great job of laying out some great design practices in today's world of web:

What the Heck is Responsive Web Design?

Mythbusting the Responsive Design Myth

Less is More: Fundamentals of Minimalist Web Design

Visual Direction in Web Design

Understanding the F-Layout in Web Design

Designing for the New Fold: Web Design Post Monitorism

Employing AIDA Principles in Web Design

UX Myths