White space, as defined by Mark Boulton, “is the space between elements in a composition.” White space should be your default layout tool. One rule of thumb is never to introduce a design element if you could accomplish the same goal with white space. You will be surprised by just how much you can accomplish with white space alone.

While white space should be used in abundance, contrast should be used as little as possible. Design theorist Edward Tufte, who is responsible for the notion of the “least effective difference,” urges designers to use the smallest visual variation required in order to effectively communicate an idea. Practically, this means emphasizing what’s important and dialing back everything else.

To illustrate both of these points, take a look at this pricing chart from TypeKit and then look at the modified version:

Original version.

Modified version.

You’ll notice that the modified version contains a dark heavy border, not unlike the default border around HTML tables. Which version does a better job of minimizing visual noise? (The answer, of course, is the original.) Plenty of white space and minimal contrast help reduce visual noise and will make your application feel simpler.

When we were redesigning our content management system, we weren’t able to kill one complex feature in particular: the bulk edit function. In the previous version of the CMS, an entire column of a main screen was devoted to the bulk edit basket. The feature consumed about 30% of the screen real estate, but we found that very few people actually used it. Our solution was to introduce a single icon with a number beside it indicating how many items were in the basket. Clicking on the icon or number revealed the list of items in the basket through a modal dialog. This saved a huge amount of space and prevented the majority of users from being distracted from their primary task.

“When a small, unassuming object exceeds our expectations, we are not only surprised but pleased.”

• Line height (in pixels) ÷ body copy font size (in pixels) = 1.48
  1.5 is commonly recommended in classic typographic books, so our study backs up this rule of thumb. Very few websites use anything less than this. And the number of websites that go over 1.48 decreases as you get further from this value.
• Line length (pixels) ÷ line height (pixels) = 27.8
  The average line length is 538.64 pixels (excluding margins and padding), which is pretty large considering that many websites still have body copy that is 12 to 13 pixels in font size.
• Space between paragraphs (pixels) ÷ line height (pixels) = 0.754
  It turns out that paragraph spacing (i.e. the space between the last line of one paragraph and the first line of the next) rarely equals the leading (which would be the main characteristic of perfect vertical rhythm). More often, paragraph spacing is just 75% of paragraph leading. The reason may be that leading usually includes the space taken up by descenders; and because most characters do not have descenders, additional white space is created under the line.
• Optimal number of characters per line is 55 to 75
  According to classic typographic books, the optimal number of characters per line is between 55 and 75, but between 75 and 85 characters per line is more popular in practice.

Have any thoughts on what we’ve covered, or know of other useful usability findings? Please leave a comment below.

The biggest issues are usually discovered by the first one or two users, and the following testers confirm these issues and discover the remaining minor issues. Only two test users would likely find half the problems on your website. This means that testing doesn’t have to be extensive or expensive to yield good results. The biggest gains are achieved when going from 0 test users to 1, so don’t be afraid of doing too little: any testing is better than none.

Source: Jakob Nielsen’s AlertBox

Jakob Nielsen performed a usability study on the length of search queries in website search boxes (Prioritizing Web Usability). It turns out that most of today’s search boxes are too short. The problem with short boxes is that even though you can type out a long query, only a portion of the text will be visible at a time, making it difficult to review or edit what you’ve typed.

The study found that the average search box is 18-characters wide. The data showed that 27% of queries were too long to fit into it. Extending the box to 27 characters would accommodate 90% of queries. Remember, you can set widths using ems, not just pixels and points. One em is the width and height of one “m” character (using whatever font size a website is set to). So, use this measure to scale the width of the text input field to 27-characters wide.

Google’s search box is wide enough to accommodate long sentences.

Apple’s search box is a little too short, cutting off the query, “Microsoft Office 2008.”

In general, search boxes are better too wide than too short, so that users can quickly review, verify and submit the query. This guideline is very simple but unfortunately too often dismissed or ignored. Some padding in the input field can also improve the design and user experience.

Eye-tracking heat map of a baby looking directly at us, from the UsableWorld study.

And now the baby is looking at the content. Notice the increase in people looking at the headline and text.

Here’s an eye-tracking study that demonstrates this. We’re instinctively drawn to faces, but if that face is looking somewhere other than at us, we’ll also look in that direction. Take advantage of this phenomenon by drawing your users’ attention to the most important parts of your page or ad.

On many forms, labels are put to the left of the fields, creating a two-column layout; while this looks good, it’s not the easiest layout to use.  Users scan the form downwards as they go along. And following the label to the field below is easier than finding the field to the right of the label.

Positioning labels on the left also poses another problem: do you left-align or right-align the labels? Left-aligning makes the form scannable but disconnects the labels from the fields, making it difficult to see which label applies to which field. Right-aligning does the reverses: it makes for a good-looking but less scannable form. Labels above fields work best in most circumstances. The study also found that labels should not be bold, although this recommendation is not conclusive.

Tumblr features a simple and elegant sign-up form that adheres to UX Matter’s recommendation.

Other Resources

• Introduction To Good Usability
• Web form design guidelines: an eye-tracking study

Have any thoughts on what we’ve covered, or know of other useful usability findings? Please leave a comment below.

The simplest way to horizontally and vertically center a DIV
This article covers centering a DIV, both vertically and horizontally, using CSS. While many code snippets out there show how to do this through the use of parent and child DIVs, this particular method uses a single DIV and is much simpler.

New CSS Sticky Footer – 2009
Here’s a sticky footer technique that’s completely cross-browser compatible. It even works in Google Chrome. And it doesn’t require an empty push DIV either.

Simple Page Peel Effect with jQuery & CSS
This tutorial combines jQuery and CSS to create a page peel effect. Most sites using this effect are Flash-driven, so this is a nice alternative if you’re not crazy about using Flash (or don’t know how).

Equal height boxes with CSS
Here’s a basic example of creating equal-height boxes (faux columns) using CSS. It works similarly to cells in a table, but without the messy table bits.

Adaptable view – how do they do it?
Letting users manually change the way your site appears can greatly improve the site’s usability and the likelihood that users will have positive experience (and come back for more). This tutorial shows you how to implement adaptable viewing techniques for your site.

CSS: The All-Expandable Box
Here’s a tutorial for creating a CSS box that will expand in all directions to fit the content contained within it, instead of just vertically. It works especially well if users increase the font size but making the entire box larger, instead of just shifting the content around and making the box longer vertically.

Four Methods to Create Equal Height Columns
Here’s another tutorial for creating equal-height columns in CSS, this time covering four different techniques. The techniques covered work in all major browsers (even IE6).

Vertical Centering With CSS
This post covers a variety of the best techniques for centering CSS elements vertically on a page. It also covers how to create a simple little vertically-centered website using the techniques.

CSS vertical center using float and clear
Here’s another tutorial for creating a vertically-centered CSS box using float and clear. It even works in IE5 for the Mac, just in case.

Cross-Browser Inline-Block
This tutorial covers how to create an inline-block layout that works with varying levels of content without breaking the layout.

The CSS “Ah-ha!” Moment
Here’s a post talking about the “Ah-Ha!” moment most designers have at some point in their careers, where some vital bit of design knowledge suddenly makes perfect sense. In this case, it’s the relationship of CSS boxes within a layout.

An Indepth Coverage On CSS Layers, Z-Index, Relative And Absolute Positioning
This article gives a comprehensive overview of CSS layers, relative and absolute positioning, and Z-Index properties.

The CSS Overflow Property
Here’s a complete run-down of how the different settings for the CSS overflow property work. It includes visible (the default), hidden, scroll, and auto, with illustrated examples of each.

Absolute, Relative, Fixed Positioning: How Do They Differ?
The differences between absolute, relative, and fixed positioning with CSS can be confusing at times. This article shows the difference between each one and when it’s appropriate to use one or another.

display: inline-block
Here’s a cross-browser (mostly) compatible method of creating inline blocks in a variety of styles. There are some differences, though, between the vertical alignment interpretation between browsers.