Quantcast
Channel: development – Telepathy – User Experience (UX) & Web Design Blog
Viewing all articles
Browse latest Browse all 28

How to Make the Perfect Web Design Style Guide

$
0
0

With the growing size and level of detail in web projects today, style guides are becoming increasingly important to have for both small and large team environments. In many cases, development teams (often remote) rely on style guides to understand structure, hierarchy, and complex interface interactions. In our company, when multiple designers collaborate on a single project, they depend on style guides to keep design elements and interactions consistent throughout the large multi-page website or web app. In either situation, a style guide should act as the trusty anchor that keeps all creative design intentions correctly interpreted and translated. So be aware of the mindset others will have when using your style guide and tailor the experience into an enjoyable one. Oh and by the way, if you like the tips below, be sure to grab the PSD used in this post for your own reference! 

Developers who look at your style guide will often be thinking:

  • How can I take these elements and keep my code as dry as possible?
  • Oh dear, don’t make me play the “What’s different about this visual element?” game…
  • Are there any minor details (such as hover interactions, form inputs, etc…) that need to be included?

Fellow designers opening your style guide will want to know:

  • What are the visual elements that I should be strictly adhering to?
  • Where do I have room to expand on the existing visual style and structure?
  • What design elements and interactions should I pay attention to so that I can continue a cohesive experience?

While I’ll admit there isn’t a catch-all style guide solution for all web projects, there are at least a couple key tips to keep in mind when creating the perfect style guide for your next project.

14 Golden Rules for Creating Style Guides


1. Clear presence of structure.
Is your layout divisible into three columns? Maybe all of the elements are fluid in width but a fixed structure in height? These are structural elements that should be clearly presented when new onlookers see your style guide, so make sure you have the usual suspects (widths, heights, columns, sectioned elements) easy to understand.


2. Can’t-miss irregularities.
While we may all like to believe that we create every pixel in our PSDs perfectly, little irregularities do crop up from time to time. Because of this, it may sometimes be difficult for the casual onlooker to determine what is an intentional irregularity versus an unintentional one. If that awesome hero image is supposed to stick outside of the div, make a point of calling it out through a Photoshop note or text note (see tip #3). Otherwise, prepare to have it dismissed as a mistake and ultimately ignored!


3. Notes & text notes.
There are two great ways of calling attention to important highlights in your PSD: 1) Photoshop notes, and 2) manual text notes grouped into a nicely labeled layer group. Photoshop notes exist purely for the need to add more context to areas in your PSD and are commonly understood by Photoshop veterans as the go-to tool for this purpose. On the other hand, another trick your fellow collaborators will love is manually writing out notes, placing them on top of their related content, and grouping them all into one hidable folder. Why is this so useful and awesome? Because as of CS6, sifting through Photoshop notes one-by-one is still a bit of a chore; therefore, having all of your notes open and skimmable saves tons of time and effort!


4. Fonts, weights, sizes, line height, and color hexes, oh my!
Nothing is more tedious and frustrating than trying to uncover what font/weight/size/line height/color was used for the typographic elements of your PSD… especially if you don’t even have that font installed on your desktop! So here’s a special secret that will make you the prize in any fellow collaborator’s eyes: Denote all of these elements clearly with a Photoshop note or text note (tip#3) like this…

Open Sans Reg 14/24 #444

Which basically means…
Font name (Open Sans)
Font weight (Reg)
Font size / line height (14px/24px)
Color hex (#444)

Note: While you could be extra savvy and actually state the number weight your font should be (i.e., 200, 400, 600, 800), you might not be the right person to determine whether that weight is relevant to how the rest of your project is coded or designed. Therefore, it’s best to just keep the weight as a simple reference of light, regular, bold, extra bold, black, etc…


5. Same styles with a twist.
Sometimes you’ll find yourself needing to break out of the structure you’ve created in your style guide. Perhaps all your subheaders are 24 em, bold, and a hex color of #ff1; in a couple cases though, you might need to emphasize this subheader in a different way such as by using a different hex color of #f00. In this case, it can be difficult for a casual observer to notice that the color is all that you’ve changed. Save them the trouble of playing the “what’s different with this picture” game by clarifying for them what exactly is different, either in a note (tip #3) or within the typography’s placeholder content!


6. Be descriptive, not semantic with header hierarchy and typography pairing.
More often than not, style guides include a suggested header hierarchy (e.g., This is the H1, This is the H2, Here’s an H3, Use this for H5s, etc…). But whether the person creating the style guide understands header semantics or not, they simply have no way of truly knowing if those suggested styles will be appropriate when implemented in development. So instead, consider being descriptive with your headers and typographic pairings. Try using words like Primary header, Secondary header, or Headers used for sidebar widgets. If you have a certain header and body style for block quotes or testimonials, state that it’s only for those cases. Descriptive placeholders can go a long way in helping others understand what kind of context elements in your layout need to be used in.

7. All that text wrap. In a perfect world, headlines are only 4 words long and don’t drag onto a second line. We, however, live in the world of multi-screen devices and long titles. On a typical handheld device, your headers and subheaders will wrap to a second, or even third, line. Even if they don’t, your client may later choose to be a little more verbose with their headlines. In any of these cases, it’s absolutely essential to indicate line heights for any potential typography that will wrap to more than one line.


8. Image treatments and examples.
If you’re giving any sort of general treatment to your images, such as a subtle border or opacity interaction upon hover, be sure to call this out in your design. Note when this treatment occurs and give multiple examples that show the variety and extent of the visual treatment.


9. The absolute-must margins and paddings.
Depending on how fluid or fixed your layout is, margins and padding can often end up being guesstimated, approximated, or on the flip side, immovable and rigid in size. Given the wily nature of web browsers and operating systems, it’s important to do everything in your power to minimize the unruliness of how margins and padding end up with the end user. If you’ve crafted the ideal white space that makes or breaks the breathability of your site, call it out. Use a shape layer that collaborators can instantly select so they can find out exactly how much breathability is needed for the design.


10. Cursors and gesture hints.
Digital representations of cursors and gestures go a long way in conveying exactly what digital elements need to come to life upon certain interaction cues. If you have some complex hover, click or swipe interactions, use a representative icon that mimics what something would look like in that second of interaction.


11. Labeled layer groups.
This one’s an obvious one but absolutely important to mention anyway: label your layers and groups. It’s one of many things that will make your collaborators navigate through your PSD with much ease.


12. Normal, hover, visited links, buttons, and navigations.
Text links, buttons, and navigational states will always be regular faces in style guides. Remember, have instances of every type (normal, hover, visited, active) of state each one of these link elements would be and help out your fellow collaborator by stacking the various states as close to each other as possible. Oh and labeling these states isn’t absolutely necessary, but it doesn’t hurt if you have the time to spare!


13. Have good form with form fields.
If your project involves form fields then be sure to understand all of the complexities that need to be thoroughly mapped out and designed. Any type of form field will typically require you to consider any number of the following:

  • normal input field state
  • focused input field state
  • position of labels
  • alignment of labels
  • placeholder text
  • active text
  • entered text
  • submit button alignments
  • (live) error validation
  • submission load graphics (if applicable)


14. Pagination, unique visual elements, and more.
Does your project contain unique traits to it that require specialized styling for certain elements? Be sure to include answer to these if so. Frequent unique elements you’ll come across include pagination, blog tags and category filters, sidebar elements, search fields, and dropdowns.

Don’t forget to download the PSD used in this post for your own reference when creating future style guides! 


Viewing all articles
Browse latest Browse all 28

Trending Articles