Time on Site is the Denominator

A major media company recently did a major redesign of their web site. When users complained about all the problems, and there were many, the sites (re)designers said the problems were the users' fault for not being familiar with the changes, and they pointed to an increase in the time users were spending on the site as proof that the redesign was successful.

It didn't occur to them that there was another very likely reason for the increased time on the site, namely that users were spending more time on the site because the site was harder to use and harder to navigate. In fact, parts of the redesign increased the number of steps needed to perform a number of common actions, sometimes significantly.

Underlying all this is that this major media company seems to not understand what time on site represents. It's not really their fault. Time on site is a phrase so prevalent these days that it gets 138 million hits on Google.

But here's the pivotal question: does the company get value from users spending more time on the site? In fact, they do not. Think about it this way. Which of the following two customers is more valuable to a clothing store?

• Alex goes to the store, spends an hour trying on pants to find one that fits and looks good, buys the pants and leaves.
• Pat goes to the store, tries on one pair of pants and discovers that they fit and look good, so buys them and leaves five minutes later.

The answer is obviously Pat, who left a happier customer. Because they hadn't spent an extra 55 minutes trying on pants, they are far more likely to buy other things, even before they leave, and they are more likely to tell their friends about their good experience.

If the store had measured time in store, they would have thought that Alex was a happier and better customer!

Time on site is still useful to measure — but in a different way. Here are two straightforward equations:

value received by users  time on site

value received by site (e.g., ad revenue)  time on site

Notice that time on site is the denominator in both equations. The first roughly measures how well you're satisfying your users while they're on your site, while the second roughly measures income over time.

Having visitors to your brick and mortar store costs you money, in terms of employee costs, utility costs, etc., even if the visitor buys nothing. The more visitors you have, the more employees you need, even if the visitors buy nothing. The same is true of your web site. Every minute somebody spends on your web site costs you for server time. Although the absolute cost may be smaller, it is not zero. The formulas above are obvious when you think about that plus the old standard ROI, or return on investment. If you measure and worry about about the return on investment for time on site, you'll have a much better understanding of how your site is doing.

What if you have an entertainment property? My company, Puzzazz, is a puzzle technology company that has built a popular free puzzle app for iOS. You might think we should measure time in app because more time in the app must indicate happier users. Nope. Take the people who solve just the New York Times crossword in Puzzazz. Some people can solve a Sunday NYT puzzle in a few minutes; others take an hour or more. Can we draw any conclusions about a user's happiness from the time it takes them to solve the puzzle? No. Different users are not comparable to each other for many reasons and doing things like averaging their times across different puzzles to determine value is not mathematically sound. Instead, we can look at things like puzzles per session and puzzles finished divided by puzzles started. Whatever your site or product is, you should spend the time necessary to figure out what the relevant metrics are.

It's certainly true that measuring your site's value and effectiveness is far more complicated than I lay out here. But it is even more complicated than measuring a number like time on site and expecting it to tell you much by itself. Especially when you use it as the numerator instead of the denominator.

Lose the Landing Page, Redux

I while back I wrote a blog post titled Lose the Landing Page. Today, I posted a link to it on a mailing list of tech startup entrepreneurs and discovered that some people didn't understand what I was saying.

So... some clarification.

When you get a new visitor on your site, what you do with them has nothing to do with how they got there, whether it cost you money to get them there (through a paid ad or however).You should want to convert every new visitor to a customer or repeat visitor (depending on what type of business you have). You just look worse if you don't convert a visitor you paid for.

I am not saying you should not do anything special depending on the source of the user. This can be appropriate, for example, you could do something different if a user comes via a particular ad campaign or through a particular search or from a partner site. But every such page has the same goal -- get the new visitor to become a customer or repeat visitor.

Every thing you show a new visitor can do one of two things: give them a reason to stay or give them a reason to leave. You want to maximize reasons to stay for people who are potential customers (and, it's also a good idea to give people who are not potential customers reasons to leave, so you stop wasting time on them).

One of the best things you can do is provide immediate value and one of the worst things you can do is waste the visitor's time with irrelevant information. Guess what an awful lot of "landing pages" do?

To cite a recent example, it's undoubtedly true that pictures of families perform better  on a "landing page" than dancing squirrels, it is extremely likely that actually providing value to visitors would preform better. What is that value? Well, it depends on your business. Note the use of the word "business" there, not "site". You're running a business, right? Your web site is just a manifestation of your business -- it is not your business.

And what is the genesis of a typical landing page? It usually goes like this: "Gee, we don't know what to show people when they arrive at our site. Let's show them a page full of information." The process you should use goes like this "When somebody arrives at our site, what are they looking for? How can we provide value to them so that they turn into a customer of our business?" (again, notice the use of the word "business").

If you're building a landing page just because you think you're supposed to have one, stop debating between families and squirrels. Lose the page instead and focus on giving your visitors value.

Caveat: yes, there is a bit of oversimplification here. But not much.

The Business Card Experience

One of the first experiences that many people have with your company is with your business card. In Japan, there's an art to presenting a business card -- you hold the card with both hands on one of the short ends and present it forward. When appropriate, give a deferential bow with your head.

While we don't do things so formally in the US, you can can either make a great first impression or you can blow it. Last night, somebody handed me a business card with an unreadable name on it -- it was his signature digitized. It didn't help that the card also told me nothing about what his company did. A card like that can be an obstacle, rather than an aid.

Fortunately, designing a good business card isn't hard:

• It has to be readable. No yellow on green or psychedelic backgrounds.
• Leave breathing room between elements. If it's all jammed together, it's not readable.
• Cluster similar elements. Don't put your phone number in one corner and your fax number in a different corner.
• A very common layout for business cards is a triangle, with information in three areas. For example, name and title in top middle, company logo in lower left, and contact info in lower right. Triangles are common because they work -- they allow people to focus quickly on each area. Other layouts work too -- just think about how people will read your business card.
• Don't right-align text that's hard to read that way -- for example, a street address.
• Usually, your name and your logo should be the largest elements. Put another way, whatever is most important should be the most readable.
• The larger the logo, the smaller the company. Look at cards you've gotten from people at Microsoft, Amazon, Google, etc. If you want to project a bigger image, downsize your logo. The worst thing you can do is fill your card with your logo.
• Unless you're a company the size of Microsoft, avoid putting multiple logos on your card.
• Downsize the text too, but not so small that people need glasses to read it. I've gotten business cards with which they should have supplied a magnifying glass.
• There's nothing wrong with a tagline, especially if your company name doesn't immediately tell people what you do. A tagline is not a paragraph.
• If you want to do something unusual -- a photo of your product, an array of images, a QR code -- the back of the card is a great place to do this. Don't clutter the front. If you can make the back useful all the better. Many optometrists have space for your prescription on the back. Puzzazz business cards have a puzzle on the back.
• If you're a normal business, don't go with an off-size supplier. Moo cards, cool as they are, are bigger than standard business cards. Use them for personal cards to show off your kids or your photography. Vistaprint cards are smaller than standard, which is a bit less of a problem. While you're at it, business cards are a different sizes in Europe, Japan, etc.
• Ignore most of the blog posts on cool business cards -- aluminum, origami, little boxes, etc. If you're an artist, a designer, or Woz, these are great options. The rest of us should stick with something a bit more normal. There are plenty of simple ways to stand out, such as a color choice, an impressive back, a paper choice or even a cut corner. Puzzazz cards have eight different logo colors, so people can choose a card with their favorite color (and there are ten different puzzles that go on the back).
• At least one side must be matte in a light color with room to write on. Everybody writes on business cards (except in Japan, where it's a major faux pas). While we're at it, glossy business cards are generally harder to read.
• Did I mention it has to be readable?

And, if you're still working on a logo for your company, check out these posts:

One Thing About Logos
Designing the Puzzazz Logo

Delivering UX

In April, I ordered a pizza from Papa John's web site for carryout. And why is that important today?

Their web site isn't very well done, but, though clunky, it mostly works. This post is about one small but significant flaw.

You see, four months ago, I chose carryout instead of delivery. And today's order automatically defaulted to carryout as well. So, while we were waiting at home for the pizza to be delivered, it was sitting on a shelf at the restaurant getting cold.

I wouldn't be surprised if the Papa John's web staff thinks it's my fault. After all, the menu page has a small box off to the side that says "Carryout" on it. It's so in-your-face that I only noticed it when I went back to the site. It's sandwiched between the boxes for the shopping cart, Papa's Points, and an ad for their mobile ordering app -- on a page with more than 70 ordering options and tons of tiny text. It's also equally ignorable on the shopping cart page, and not prominent on the Checkout page (it's at the top, with my address, not at the bottom, next to submit order). Did the developers really think that this information was that unimportant? And did they really think that almost everything on the page should be the same font size?

And, aside from all that, is it actually true that people order the same way every time? Should have a default rather than a choice on the checkout page (like two buttons "Order for Delivery" and "Order for Carryout")?

There are so many ways to fix this problem that I'm going to leave it as an exercise for the reader. Pick one or two or three -- but there's no excuse for lack of clarity.

On the positive side, the Papa John's staff was quite courteous. They remade the pizza and delivered it, no extra charge. But the problem could have -- and should have -- been avoided.

When is Bad Good?

I frequently give people conflicting advice in both my UX consulting and my UX Office Hours. What's right for one product is frequently wrong for another product.

Case in point: two people, one after another, one of whom I told that he should get rid of all his icons and use text, and the other who I told to get rid of all the text and use icons.

Person 1 had an interface where each icon appeared exactly once. All were cryptic. The icons needed to be large because they all represented complex functions, so there was no text with the icons (even if there had been, it would have been tiny). Better to use just text and lay things out neatly as in an on-screen menu.

Person 2 had an interface that included a monthly calendar. Inside the days, there were one- and two-word indicators that applied to the individual day. A small calendar filled with small words just becomes a big mess, hard to see what's going on. But, since there were only a half-dozen different things in the calendar, and each was easy to represent by a simple, highly recognizable icon, switching to icons would instantly make it less cluttered and more usable.

But, yesterday, I gave some advice I've never given to anyone before. For a commercial product, I told him his input format should be a text file.

Why? Well, his product has two classes of users, like many crowd-sourcing products. The millions (hopefully billions) of people who will flock to his site to use it, and the thousands (and hopefully millions in the long run) who will provide the content for the first group. Initially, the people in that second group is probably tens of people. Every bit of energy he spends on them is time he didn't spend on the group that matters more, the visitors.

Is there a risk? Certainly. There's always a risk, and we talked about how to minimize the risk by what the text file looks like and how it's used. And we did spend time talking about a design for a "v2" that would be a step up from the text file. But I think the risk of not shipping while trying to build the perfect product for the content providers, or even trying to build the v2 we talked about is greater. Shipping is about focus and, in this case, I think focus is about delivering the right product for the people that matter the most. If he hits his goals of billions of visitors and millions of people putting content up, then he'll have ample time for v2 and v3 of the content provider tool.

Enabling Experiences

Something great happened during my free UX Office Hours at StartPad yesterday.

Usually, I help people, then they go off and I never get to see what's happened. Occasionally, I see a product launch (like PicTranslator). The same is largely true in my consulting practice, though there have been a few notable exceptions with really big companies.

This isn't by accident. As you might expect with a UX consultant, it's by design.

I've noticed that many consultants see it as their job to make their job take longer. And many companies see consultants in that role -- they hire consultants to fill chairs. Instead, my number one goal as a consultant is to enable my client -- enable my client and then leave. We've all heard the old saw, with apologies to vegetarians, "Give someone a fish and they eat for a day; teach them to fish and they can eat for a lifetime." I want to enable my clients to build their product without me, rather than convince them that they can only build their product with me. It's probably not the business-savvy way to build a thriving consulting practice, but I sure feel better about it and I have happy clients.

Enabling is even more important when you only have an hour, which is what you can get for free in my monthly office hours. I can draw you a pretty picture or design some piece of your system, but then what?

Back to the great thing that happened yesterday.

A few months ago, somebody came in and asked me to critique the design he'd been working on. I told him to throw it out. Sounds harsh, I know, but it was completely wrong for what he wanted to do, the customers he wanted to serve, and how he hoped to enable them. I'll could go on. We spent most of the time talking about UX strategies that would work for his customers. I even drew some pictures on the whiteboard showing some examples.

Yesterday, he came back and showed me his new design. It bore almost no relationship to what he'd brought in earlier -- it was light years better. Honestly, it didn't look like the stuff I'd drawn on the whiteboard either. He learned something and then applied it, and he applied it in the way he thought made the most sense for his customers. I told him that he could ship with his design as-is and be ok. Yes, we could make it better (and we spent the hour discussing how to do that), and, yes, if he spent oodles of time on it (which I recommended against), he could make it way better, but the difference between the first and second versions was great to see, and it looks like he's on a good path.

It was one of those rare instances where I got to see what happened, and it felt pretty good.

Tomorrow, I'll write about another lesson from the same session: When is Bad Good?

Opportunities

One of the speakers at Ignite Seattle 8 was Wendy Chisholm, who works for the UW and is co-author of Universal Design for Web Applications. Her talk was about incorporating accessibility into design. I won't go over what she said here -- it'll be up on YouTube soon enough and you can watch it for yourself (I recommend it).

But I want to write about the following equation that she included in her presentation:

Inclusion = Innovation

Her point was that many things that are done for the purpose of inclusion (to make things more accessible) result in innovations from which far more people benefit. It's a good argument, the same one made for the space program and I agree with it completely. I would go further, though:

Constraints = Opportunities

This statement is fundamental to the way I design things and the way I approach many things in life.

One of my favorite personal examples is the competition to design a memorial for the World Trade Center. I entered, along with more than 5,000 other people. There were a lot of requirements given for the memorial, including such things as boundaries, elevation, and required ramps and staircases. I looked at each of the requirements and asked myself how the requirement was an opportunity. How could I design a memorial such that not only was the requirement met, but it was essential? What design would make it so that people visiting the memorial could not even imagine it being any other way? Maybe they'd even think the requirement was my idea rather than something forced on me. This is one of the hallmarks of great design -- when the design is so obviously correct that you can't imagine how it can be otherwise.

My design met every single requirement and it did so organically, embracing the requirements, not fighting them. I was particularly proud of the way the ramps (that were complained about by entrants) were the linchpin of the experience my design would have provided. In contrast, every finalist ignored many (sometimes most) of the requirements. And in the other entries that I looked through -- and there were many great entries beyond the finalists -- the ramps requirement was the most ignored. It turned out that the requirements weren't really required, something I might have known if I had any background in architecture. To state the obvious, no, I didn't win the competition, not even close. As was clear from the finalists, they were looking for something monumental and my entry wasn't monumental -- I designed an experience, not a monument.

It shouldn't have been too much of a surprise that the constraints were fluid. This happens all the time in the world of computers. But that shouldn't stop us from embracing the constraints as we know them. By turning constraints into opportunities, we get innovation.