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.

Yes, Companies Do Listen

In October, I blogged about a major flaw in the Tully's web site, tullys.com -- basically, there was no way to find a Tully's location unless you knew about their secondary site, tullyscoffeeshops.com. Yesterday, Tully's fixed it, not only providing the link but making it prominent. Yes, it could be better still, but now it's a lot better than plenty of other sites.

The surprising thing was the post on their Facebook page (The Power of User-Generated Feedback for Companies) where they credited me with inspiring them to action. That's great to hear. Helping people improve the experience for their users and customers is why I write it. When I help people in my UX consulting practice or for free in my monthly UX office hours, I get to see the benefit firsthand. But, with my blog, it's hard to see the direct impact.

Thanks, Tully's.

Why You Need Anecdotal Evidence

Have you ever heard the phrase "That's just anecdotal"? Usually, it's used to discount somebody's opinion about the way something should be. In UX terms, if you've observed a user, saw them have a problem, and want to respond to what you saw, you may have someone tell you it's just anecdotal -- in other words, you don't have hard, objective, statistical evidence, so forget it.

But there's a contradiction here. There's a belief that, if you gather enough anecdotal evidence, it magically becomes hard evidence. You can even see this in the latest ad campaign for Windows. Millions of people sent in their ideas, or were surveyed or studied, and their opinions -- anecdotal evidence -- is now real evidence. How does this magic work? Well, it can't. Two people who said different but similar things, or even the same things under different conditions, can't be lumped together in some statistical box.

But that doesn't mean that anecdotal evidence is worthless. Quite the contrary. It's invaluable (and Microsoft should be commended for actually listening to users). Anecdotal evidence provides you with something that hard data can't -- feelings. In a typical usability test or, these days, a web site A/B test, success is measured by whether or not somebody succeeds in a task. How about whether they frowned or smiled, tapped their fingers on their desk impatiently, hummed to themselves, or cursed at their computer?

I recommend that you gather as much anecdotal evidence as you can and let it infect your world view. Try to feel what your users feel, think like they think, and use that to design your products. And, after that, gather hard evidence on whether you were right or wrong and move forward from there. But, if you don't start with a feeling about what's the right thing to do, no amount of hard evidence will help you.