One of the simplest and most robust findings from behavioral economics is that when people are faced with a choice they tend to stick with the default option. This sounds like something that shouldn’t have any effect on people. Common sense leads us to believe we’ll always choose whichever option benefits us the most, regardless of the default. Although this intuitively makes sense, numerous studies show that’s not the case. For example, most countries have an option for people to donate their organs upon their death. In America, the default choice is to not donate organs, meaning they must specifically check a box on a form (an “opt-in” system). As a result, the consent rate is only about 28%. In contrast, Belgium’s default option is to donate organs (an “opt-out” system), in which about 98% of the population consent to donation (read the fully study here [pdf]).
There are many explanations for this behavior. One reason is that making a choice takes effort (even if it’s only checking a box), whereas sticking with the default is effortless. Another reason is when decisions have unclear costs and benefits that are difficult to evaluate (such as organ donation), defaults can imply the “recommended” option, thus saving people the time of thinking through the choice themselves. It also sends the signal that this is the option most people choose and is a safe bet (which reinforces the idea of social proof).
Applications to Web Design
Applying this insight to web pages is fairly straightforward: when presenting people with a choice, provide a default option. The simplest method is to pre-populate form fields with the most common choice. For example, the checkout form of an ecommerce store whose customers are mainly American should have “United States” already chosen as the default country. Obviously, there may be customers from other countries, but they would have to select an option were it left blank anyway. This decreases friction when completing a form, decreases errors, and increases usability.
The previous scenario is useful, but unlikely to increase conversions significantly. Defaults really shine when people are faced with a less clear-cut choice. For example, if you have multiple service plans, highlighting one will guide people to that option. Deciding which option to make the default is something you should A/B test, but a good approach is to use existing customer data to preselect the most popular option. For example, if you have multiple pricing tiers, you could highlight the most common one.
No recommended plan
The most popular “Plus” plan is highlighted
Another strategy is to select the option you want your potential customers to select (such as the one that earns you the most profit). This will subtly nudge potential customers towards this option. For example, Optimizely ran an experiment recommending their Gold plan and saw a 20% increase in signups to that option.
Recommending pricing plans is just one way that default options can be applied to web design. Consider experimenting with your forms, account settings, preferences, or anywhere else people face a choice. By providing a default option to fall back on, you’re doing a favor for your customers and yourself.
Further Reading
Read Eric Johnson and Daniel Goldstein’s full study on defaults, titled “Do defaults save lives?” (2003).
In my previous post, I explained how to use image sprites semantically. But as with all image spriting, setting each sprite’s size and position is a pain. Compass can automate this, but it’s designed with the assumption that all your sprites will be background images of elements. Even so, Compass provides a number of under-documented functions that can help automate my technique.
Refresher
First, a quick summary of my previous post. The standard way to sprite images is to set the sprite sheet as the background-image of an element, and set its background-position to the coordinates of the image you want to display. But if your image is part of the content, then semantically it should be in the markup as an img tag. To accomplish this, set the img tag’s src to the sprite sheet, and use a container element as a “window” to let one sprite show through at a time. For the specifics of how to do this, read my post.
Automate this with Compass
As I mentioned, the most difficult part of spriting is setting the image size and position for each sprite. Luckily, Compass can help us, but their spriting documentation is geared towards the standard technique, and thus doesn’t provide much help to accomplish my method. But fear not! Compass can still help us.
Create the sprite sheet
The first step to doing any spriting in Compass is to @import a folder of images. Compass will generate a sprite sheet image, and create a number of variables that we can use to get the size and position of each sprite.
@import"sprites/*.png";
Sprite Dimensions
Next, we need to get the dimensions of each sprite, and set the container element to that size. Compass provides a sprite-dimensions function, which takes 2 parameters: the sprite map Compass generated, and the name of the sprite (i.e. the filename, sans extension). Then it outputs the width and height of the sprite. If you have no idea what you’re supposed to pass as the sprite map parameter, you’re not alone. After some digging, I discovered Compass assigns the sprite map to a variable named $<folder>-sprites. In this example, that makes the variable the awkwardly named $sprites-sprites.
The next step is to set the top and left properties of the image tag. Once again, Compass provides us a helper function: the aptly named sprite-position. Like sprite-dimensions, it also takes the sprite map and sprite name as parameters. But unlike sprite-dimensions, it provides us the left and top properties concatenated in a string, e.g. “20px 120px”. This seems weird and inconsistent at first, until you realize it’s designed to be used as the value of the background-position property. To help us access each value individually, SASS has a function named nth, which returns the value at the position you pass it (starting from 1). And don’t worry about converting that string to an array — SASS will automatically convert strings to arrays, splitting the string on spaces. So that gives us:
So now we have all the pieces in place to position each individual sprite, and all we need is the name of each image. For example:
@import"sprites/*.png";.sprite-container{display:block;// or inline-block
overflow:hidden;position:relative;&.my-sprite{@includesprite-dimensions($sprites-sprites,"my-sprite");img{$position:sprite-position($sprites-sprites,"my-sprite");position:absolute;left:nth($position,1);top:nth($position,2);}}// ...etc. for each sprite
}
The obvious flaw here is that you need to write code for each sprite in the sprite sheet. Luckily for us, Compass has one more trick up its sleeve to help automate this: the sprite_names function. Pass it a sprite map, and it outputs a list of sprite names. Then we can use @each to loop through the list, and generate the size and position of each. Bringing it all together, our code looks like this:
@import"sprites/*.png";$sprite-names:sprite_names($sprites-sprites);.sprite-container{display:block;// or inline-block
overflow:hidden;position:relative;@each$spritein$sprite-names{&.sprite-#{$sprite}{@includesprite-dimensions($sprites-sprites,$sprite);img{$position:sprite-position($sprites-sprites,$sprite);position:absolute;left:nth($position,1);top:nth($position,2);}}}// @each
}// .sprite-container
Conclusion
Whew, that was a whirlwind of Compass code. But once you get it all set up, it works quite well. You can add and remove sprites as you please, without needing to update a single line of SCSS. Happy spriting!
Update (9/1/2013): Read my follow up on how to automate this with Compass.
Spriting images is a well-known, well-documented way to speed up page load times. The standard technique is to set a sprite sheet image as the background-image of an element, and position it so the proper sprite shows through. This works great for icons and other images that aren’t part of the actual content, but not so great for images that belong in the page content.
The problem
Images that are part of the content should be in img tags. This is correct semantically, good for accessibility, and good for interoperability. With the typical approach to spriting images, you would need empty container elements that have a background-image property. Those empty elements have no semantic meaning, and are worthless to screenreaders and other crawlers that may access your page. This is the situation I found myself in on Optimizely’s homepage when I sprited the customer logos and benefits graphics.
The solution
Solving this problem is actually fairly simple. First, you’ll need markup similar to the following:
<divclass="sprite-container sprite-track"><imgsrc="sprites.png"alt="Graphic of tracking elements on a web page"></div>
The .sprite-container element acts as a window that only lets one sprite show through. It has the same width and height as the sprite, and has overflow: hidden to prevent the other sprites from showing through.
Then the image needs to be positioned so the sprite we want shown is at the top left corner of the window, which is accomplished by setting position: absolute and the top and left properties correctly. SCSS:
.sprite-container{display:inline-block;// or block
height:275px;// size of the image we want to show
width:400px;overflow:hidden;// prevent the other sprites from showing
position:relative;// so the image can be positioned absolutely
img{position:absolute;}&.sprite-trackimg{left:0;top:-210px;}// other sprites
}
Generating this CSS can be a pain, but I will discuss how to accomplish this with Compass in my next blog post.
Closing Thoughts
This method lets us use sprites in img tags, which is more semantic than empty divs or spans (depending on the use case). However, it has a couple of drawbacks. First, it requires a container element around your image. This could add unneccessary bloat to your markup (in my case the image already had a parent element). Second, and greatest of all, the image src attribute now references an entire sprite sheet, when technically it should only reference the actual image that it’s showing. Screenreaders won’t care at all, but some services may use this image for other purposes. For example, Facebook grabs a representative image of your page when a link is shared, and it could grab a sprite sheet instead of the actual image. That’s no good.
Ultimately it’s a tradeoff between having a container element and actual img tag in your markup versus an empty element whose background image is a sprite. Overall, I think the pros (semantic HTML; better accessibility) outweigh the cons (container element; src attribute is a sprite sheet). If you want to use sprites with actual img tags, this is a solid technique. If anyone has any thoughts on how to overcome the drawbacks, hit me up @jlzych.
Update (9/1/2013): Read my follow up on how to automate this with Compass.
On optimizely.com, we just switched our typeface from Proxima Nova (via Typekit), to Gotham (via Hoefler & Frere-Jones Cloud.typography). Gotham has long been what we used in Photoshop mocks, but we made the switch mostly because it just looks better. We’ve long known that Typekit can be a bottleneck to our page load, so I took this opportunity to compare the performance impact of each service.
Note: these are just some quick comparisons of the speeds based on my machine using optimizely.com. Your experience may vary.
Typekit
To use Typekit, you must insert JS in the head of your page, like so:
It’s well known that script tags in the <head> of the document block page rendering. If the Typekit service is down, or slow, the page can take a significantly long time to render.
Based on a few pageloads on my Macbook Pro and looking through Chrome’s timeline, Typekit’s JS takes about 300ms to download and 900ms to download the actual fonts, for a total of about 1100ms. Additionally, the script sets a timeout fires until the fonts have loaded, consuming processing power (typically not an issue, but could potentially be significant on mobile). Finally, 410kb of fonts are downloaded (font size and download time both depends on the OS and browser).
Cloud.typography
To use Cloud.typography, you need to add a <link> tag in the <head> of your page, like so:
Unlike Typekit, Cloud.typography requires you to host the font files on your own servers (CDN, web server, etc.). Depending on your infrastructure, this could be a big advantage over Typekit. But Typekit also servers its fonts over a CDN, so this is unlikely to be much of a gamechanger, speed-wise.
When the page loads, one request is made to fonts.css. Their server then does some work to determine which CSS file to redirect to (based on OS and browser), and then sends back a response of 302 Moved Temporarily with the Location header set to the path of one of the CSS files you uploaded. Most fonts are encoded as data-uris in the stylesheets (unless you’re IE and need references to .eot files). This means there are 2 requests (for most browsers), and all the work of determining which fonts to return to the user is done on their servers (instead of on the user’s machine via JS with Typekit).
Based on a few pageloads in Chrome on my computer, the fonts took about 800ms to load (~200ms for fonts.css, and another 600ms for the CSS file with the actual fonts). The fonts are 251kb in Chrome, but are between 100 and 500kb depending on the OS and browser.
I also did some tests on webpagetest.org from various locations, and found in total the fonts take between 300ms (France and Russia) and 1000ms (Brazil and San Jose) to download (this includes the 302 response from fonts.css and downloading the CSS file from your servers). Unfortunately I don’t have this comparison data for Typekit.
Takeaways
On optimizely.com, Cloud.typography edges out Typekit for load times (about 800ms vs 1100ms on my computer, or about 27% faster). Part of this can be attributed to the obvious fact that the size of the fonts is smaller with Cloud.typography, which is largely because we’re serving fewer fonts to the user than we did with Typekit.
However, Typekit blocks rendering by having a <script> tag in the head of the document, whereas Cloud.typography uses a <link> tag that allows the page to continue rendering progressively.
Additionally, Typekit taxes the user’s machine by executing Javascript to determine which fonts to load, whereas Cloud.typography does this on their servers. Although the JS is pretty minimal, it could impact older or more resource-constrained machines. Personally, I like that Cloud.typography moved this logic off of users’ machines and onto their servers.
Conclusion
In the end, both services are solid and the speed difference is minimal. I like Cloud.typography’s approach of only having a link to a CSS file instead of executing javascript, and the ability to host files yourself is nice. But which service you choose should ultimately come down to whichever fonts you like more.
Looking for a way to get users to engage with your product or service? Just tell them everyone else is doing it. Although we like to think of ourselves as independent beings who make our own decisions, studies show that touting popularity and ubiquity is a very effective form of persuasion.
This is known as social proof.
Generally, we don’t like to stand out from the crowd. Our lizard brains tell us it’s dangerous to deviate from the norm. In prehistoric times, deviating from the group meant getting attacked by predators. Predators are not much of a concern anymore, but studies show that sticking with the norm still persists and affects us in other ways. For example, one study tested the effectiveness of wording in persuading people to use less electricity. Four different placards were placed on the doors of residents, which informed them:
They could save $54 a month on their utility bill.
They could prevent the release of 262 pounds of greenhouse gases per month.
It’s the socially responsible thing to do.
77% of their neighbors already used fans instead of air conditioning, a decision described as “your community’s popular choice!”
The last group reduced energy consumption by 10% — the highest of any group. This means it was more effective than saving money, espousing benefits, or explaining it’s the “right” or “moral” thing to do.
You can use this same phenomenon to increase conversions on your site through A/B testing, whether that’s signing up for a service, donating money, or using a product feature.
Spillnow.com ran a test that demonstrates this phenomenon well. The site is a place for people to spill their guts on anything bothering them, and other users can respond with advice and encouragement. However, they had an issue with too many people venting and not enough users responding. In order to increase responders, they added this text to the “spill” form: “50% of people go on to be responders.” This simple piece of text increased the number of users who respond to other people’s spills by 27% (from 48% to 61%).
Another great example is Basecamp’s homepage, which has multiple types of social proof.
At the top of the page they say, “Last week 7,389 companies signed up for Basecamp to manage their projects. Today it’s your turn.” The main content features a woman saying she uses Basecamp (the picture also has the added benefits of making the statement more believable and trustworthy). And at the bottom, they say, “97% of customers recommend Basecamp. Find out why →”. These are all great ways to demonstrate that lots of people use your service and increase clickthrough.
And this is just the tip of the iceberg — there are many ways social proof can be used across your site. These are all quick, simple changes that can be added to just about any page using our A/B testing tool, without requiring design or engineering resources. If you’re looking for a way to get users to click your call to action, use a product feature, or engage with your site, then social proof is a great way to boost conversions.
