One of the most important steps to improving your conversion rates and usability is understanding what motivates your customers. If you try and build content for a "typical" user you might be making a big mistake. Each user is motivated in a different way, so you need to have content that speaks to those users in a individual manner. Often you can speak to all of them using a single page of content using a number of different calls to action. If you write content for only one of the user types you may be missing out on a big percentage of potential customers.

Follow these steps to creating personas

1. What are your user types
2. Model them (speak to CSR's, review your log files, research them on MSN ad labs, group keywords by user etc)
3. Plan content for each of the different types
4. Allow customers to self select the content

Brian Eisenberg "Chief Persuasion Officer" at FutureNow.com outline 4 types of users.

• Spontaneous - does the content look right...
• Humanistic - wants to read reviews...
• Methodical - reads everything, asks a lot of questions...
• Competitive - driven, what's in it for me...

Every landing could have a call to action for each persona (or content that speaks to that persona). However, no two sites are going to convert personas at the same percentage, your site might be heavily waited into one group. This creates the perfect opportunity to run a multivariate test. Move your content around, try different call to actions for each persona. This is a very simple way to get a big lift in conversion rates. Good luck.

Brian's personas presented at eMetrics May 2008 San Fran

Let's say you've just finished conducting traditional (moderated, one-on-one) user tests on a website. Naturally, you have noted whether or not each of your subjects managed to complete each assigned task. Perhaps you've even timed how long it took each subject to complete each task. My question is this: in writing up the results of the tests, how should you describe the performance results?

I recently read a report that was loaded with references such as "67% of users" did such-and-so, and "83% of users" did this-or-that. Personally, I think it is a mistake to name precise numbers like this.

User tests as I've described above are not intended to be quantitative/inferential in nature. Rather, they are qualitative, employed to gain insight into how real users interact with a website. If you start naming precise numbers (particularly as percentage points) you're implying the numbers are statistically relevant. They aren't. Generally, user tests are conducted on between 5 and 10 users, not nearly enough to gain statistically significant results.

By implying significance where none exists, you risk destroying your credibility. If anyone reading your report has ever taken a course in statistics, such numbers will jump out at them. They'll know right away that, given the small sample size, the numbers you've quoted can't possibly be statistically significant. And even though your report may be full of valuable insights, everything you have written will be tarnished because - in the reader's view - your findings are suspect.

Naturally, in presenting your results, you need to make reference to user test performance. But I think it's much wiser (and safer) to keep such references broad and conversational. For example:

• "In our tests, only our least web-savvy test subject failed to complete this task in a reasonable time. All others breezed through it."
• "Half of our subjects failed this task."
• "Four of our test subjects didn't mind the multimedia presentation on the Home page. But two subjects found it very annoying and indicated that in a real scenario, they'd have left the site immediately."

Note that in some of the examples above, I have in fact named numbers. But by keeping it conversational and not naming percentages, I'm not implying statistical significance. Not only is this more honest, it's also more credible: nobody can dispute my claims of significance, because I haven't made any.

The bottom line is this: in writing up user test reports, focus on the insights gained. Explain where users stumbled, and why they stumbled. Don't risk putting your recommendations into question by implying statistical significance.

I was at a friend's place for a pot-luck dinner last weekend. We were all hanging around in the kitchen and I happened to be standing by the microwave. The host handed me a gravy boat and asked, "Hey, can you nuke this for a minute?"

"Sure, no problem," I said confidently. I put the gravy boat in the microwave and closed the door. My eyes then searched for the "Min Plus" button. After all, that's how my microwave works. Aren't they all the same?

Nope. This one was littered with unfamiliar controls. Some obviously dealt with power levels, some set a timer. There were other controls for defrost functions, a cluster of specialized "one touch" buttons for Popcorn, Baked Potato, etc. But there was no "Min Plus" button to be found...

How do I just turn the damned thing ON??

Taking a guess, I pressed 6-0-Start, assuming that would give me 60 seconds. It works on my microwave - and my sister's too. Surely it must work on all of them?

Nope. The panel beeped with every press of a button, but beyond the beeping, the microwave stayed dark and silent.

Hmmm. Maybe I have to enter a power level first? So I pressed the "Power Level", then 9 (figuring 9 would be highish). Then I pushed "Time" and 6-0. THEN I pushed "Start". This has GOT to work, right?

Nope. By now, the other party guests had noticed the long series of unproductive beeps coming from the microwave, and they started to snicker. "Hey Straker, how many years did you spend in university?" one asked sarcastically. The kitchen exploded with laughter, and everyone's attention turned to the moron who couldn't figure out how to use the microwave.

To the amusement of all, the scene continued for another agonizing minute or so, as I tried any number of pushbutton combinations in a futile attempt to bring that dead hunk of metal and plastic to life.

I eventually bluffed my way through with a cheat. I pressed "Popcorn" figuring that would at least turn the stupid thing on. It did, and a round of well-deserved applause erupted. I bowed in triumphant victory.

So... what's going on here? Am I really a hopeless techno-peasant? Well perhaps that's part of it. But I like to think there's another reason I looked like such a fool: when it comes to microwave operations, there's no established standard. Every manufacturer uses a different scheme, so you can't transfer what you've learned from using your microwave and apply it to using someone else's. You're left feeling - and looking - stupid.

And what has any of this got to do with web design? Easy. If you don't want to make your visitors feel stupid - if you want them to be able to accomplish their tasks easily - stick with established conventions. Sure, it's nice to break new ground with a new and "better" navigational system or whatever. But think twice before taking such chances. Remember yours truly at the helm of a microwave. Don't make me use the "Popcorn" button to reheat the gravy. Trust me, it doesn't work well...

"My name is Michael and I am a web analytics... oholic?"

Yes, I'll admit it: I find my self logging into Google Website Optimizer at all hours - day and night, weekends included - to ensure our freshly-optimized pages are reaching their goals.

I also place bets with co-workers. We'll try to predict which version of a page will perform best, and by what margin it will beat the existing page.

It's embarrassing sometimes:

• Excusing myself from a dinner date, so I can log in to see whether my revised "buy now" button is outperforming the old one.
• Being caught squealing with joy because I've correctly predicted the lift a revised headline will make.
• Predicting a revised photo will improve conversions by 20%... only to find it reduces them by 23%. The agony of defeat!

No, this isn't a cry for help. Please, no interventions. I just wanted come clean and admit I have a new addiction.

Anyone else suffering similar symptoms?

My background is in advertising. Many years ago, I read the classic book by Claude Hopkins, Scientific Advertising. The crux of the book is very simple: that advertising should be based on A/B testing and numbers, not just creative hunches.

Hopkins' Scientific Advertising is one of those books that everyone in the advertising industry has read and raves about. David Ogilvy claimed it changed his life, even stating that no one should be allowed to practice advertising until they'd read the book seven times!

And yet, rarely do advertisers actually heed Hopkins' advice and test their ads, one version against another, to determine which approach works best. Instead, they take what they think is their best idea, and run with it. In other words, they guess!

I believe there are three reasons why A/B testing is so rarely done in traditional advertising:

1. Budget. It's expensive enough to produce one ad. Producing a second, test ad is seen as wasteful.
2. Inertia. A/B testing isn't part of the established process.
3. Ego. To succeed in advertising, you must have confidence in your ideas. To admit you're not sure which approach would work best is... well, something most people in the advertising industry just can't do!

And so, Claude Hopkins' ideal of scientific advertising remained largely unrealized despite its unquestionable validity. Advertisers paid lip service to the book's principles, but rarely implemented them.

All this is about to change, at least in the online world. With Google Analytics and Website Optimizer, there's simply no reason not to A/B test one page against another:

• The tool (Google Website Optimizer) is free
• The cost of producing an alternate web page is low (in many cases, free)
• Data collection is free and fast
• In no time, you know which version performs best

The only real hurdle is that learning how to use the tool takes a bit of time. However, given the enormous potential benefit, it's time well spent.

Hopkins wrote his classic book in 1923 and died in 1932. But I suspect that if he were alive today, he'd be a big fan of Google Website Optimizer!

Our newest offering, HippoTango, is all about service integration. The theory is that when each service works with and supports the others, the results are greater than the sum of the parts. It's a simple enough concept, but how does it work in practice?

As a very simple example of how HippoTango works, let's look at how Web Analytics and User Testing can work together.

Imagine you're using Google Analytics to monitor your web traffic. You notice that one of your product pages has an alarmingly high bounce rate. What do you do?

If you're using Analytics alone, you might have a hard time figuring out how to fix the problem. That's because Analytics only tells you what is happening on your website; it doesn't tell you why.

If, on the other hand, you run some quick user tests focusing on the problem page, chances are you will soon discover why your customers are abandoning that page. Once you know the full "what and why", correcting the problem is a simple matter.

Note that this doesn't mean User Testing is "better" than Analytics. After all, it was the information revealed by Analytics that led you to focus your user tests on the appropriate page. Without Analytics, you may never have known the problem existed.

To get the compete picture of how your website can be improved - to gain actionable insight - you need to use both services. And you need to integrate them seamlessly, so that each service reinforces the other. That's what HippoTango is all about.

It goes without saying that when you want to make a change to your website, that it is a great idea to introduce the new changes via an A/B or Multivariate test. The tests will let you know quantitatively whether or not the changes that were made helped or hindered your web visitors and your business.

When design your test there are a few things to consider. Should one do an A/B test or a multivariate test? How many combinations should the multivariate test include?

As a rule of thumb A/B/n test are good for testing one layout versus another (even though it is best to only vary one variable in a true A/B/n test) or when you don't have many successful conversions that will occur in a one month time period.

When doing a first test it is often best to do an A/B test to get a quick win and convince others in your firm of the value in testing changes to your website.

If your firm has already seen the light then you may want to move to multivariate testing. One thing to be careful of when running a multivariate tests is the number of combinations that are created when you design your test. You want to make sure that your site will be able to produce 100 successful conversions per combination in a month. So that means that if your site currently gets 700 people a month filling out your lead form and you want to test some new options that you shouldn't have more than 7 combinations in your test. Having 100 conversions per combination helps with the statistical significance of the test and having it complete in a month enables you to implement changes without waiting forever for result. If you can get results in 3 weeks as a results of a large number of success that is great, but when design a test a good rule of thumb is 100 successful conversion per combination in a month.

Too many people create tests that have too many combinations as a result of testing too many small changes. Focus on bigger items and fewer of them.

I was recently handed a copy of Seth Godin's book, The Big Red Fez: How to Make Any Web Site Better. I thought I'd share my impressions.

On the downside, the book is now six years old. That's a long time in Internetville; some of the ideas no longer seem ground-breaking. And all of the websites he critiques have been updated since the book was written.

Still, the book's main points - if no longer revolutionary - are sound. I'm going by memory here, as I've since passed the book along to coworker. But my main takeaways were:

• Don't assume your visitors are patient, focused and intensely interested what you're offering. More likely, they're distracted and impatient.
• Think of a web page as a direct marketing piece: each page should have ONE main objective.
• If you try to please everybody, you end up with a mishmash that pleases nobody. Focus on pleasing those who matter most.
• Each page's primary objective should be crystal clear. Think of your visitors as monkeys... and make sure they can find the banana!

Much of the above sounds obvious, but clearly it's not obvious enough: most websites still don't pass the "monkey looking for a banana" test. So it's good to be reminded of these fundamentals.

Big Red Fez, is a quick and compelling read, written in a lively style with a healthy sprinkling of humor.

Steve Krug's Don't Make Me Think is the ideal book for 5-hour flight. Big Red Fez, at just over 100 short pages with plenty of screen shots, is ideal for a 1-hour flight. Recommended.

Attention Ecommerce site owners!

A U.S. District Court ruled yesterday that:

• The Americans with Disabilities Act (ADA) applies to the Internet: Ecommerce websites must be accessible to the blind.
• The class-action lawsuit launched against Target by the National Federation for the Blind (NFB) may proceed to trial.

The NFB claimed that Target's website is not properly accessible to the blind, in violation of the ADA (as well as two California statutes). Yesterday's ruling was a huge step forward in their case.

This should serve as a wake-up call to Ecommerce site owners: make your sites accessible to the blind, or face expensive consequences.

What's a site owner to do?

The good news (to site owners) is that making sites accessible is something they should be doing anyway. The simple fact is, many features that make websites accessible to the blind also make them more accessible to sighted users. For example:

• Proper use of alt tags to describe images
• Simple layout, easy to use navigation
• Direct and concise copywriting
• Minimal forced device switching (keyboard/mouse)

Also, in the long-term, it's now more cost effective develop an accessible, properly built-site. Inaccessible sites using spacer gifs and clumsy table layouts end up being enormous headaches for developers, and get progressively worse with updates.

In comparison, accessible sites that separate code and design into different HTML and CSS files are much easier to update and redesign.

The bottom line?

The latest Target ruling makes it clear: website accessibility to the blind is not just "the right thing to do". It's a legal requirement.

However, making websites accessible is not as onerous as it sounds. It's something you should be doing anyway, for reasons beyond accessibility to the blind.

I had an interesting discussion with a colleague today. We had both read a recent eye-tracking study published by a prominent usability expert... and we both had essentially the same take on it: "So what?"

Much of the data are open to widely different interpretations. What does it mean when someone spends a lot of time looking at something? Does it mean he finds it appealing? Or is he just having a hard time understanding it?

If someone scans down the page quickly, does that mean the page has failed to capture his interest? Or does it mean the page was effective in communicating its message quickly?

Last month, I was in a usability seminar in Seattle. The seminar leader -- a very accomplished usability professional -- cautioned against reading too much into eye-tracking data. For one thing, test results depend very heavily on the instructions and tasks given to test participants. You can't necessarily generalize the results to the public.

He recommended that eye-tracking data should only be used as supplemental information. The more eye-tracking studies I read, the more I'm inclined to agree.