“But all you have to do is option-click on that little “pi” symbol in the corner…”

I have a challenge for you.

“By the way, did you know that you could do X with our app?”

1. Write down a list of the coolest features in your application — the most useful, the ones that differentiate you from the competition, the ones with the highest ‘delight’ factor.
2. For the next week, each time you communicate with a customer, pick one of those features and ask that customer if they’re familiar with it.
3. Write down their response.

A lot of them are going to say “no”.

This may because they just started using your product, or because they’re not very tech-savvy, or because that particular feature is not relevant for them.   But more likely, it’s because those features are about as accessible as an Easter Egg:

• Your site doesn’t mention that those features are available
• There’s no inline help explaining why someone should try them
• They require a little workaround in order to use them… which is not explained on your site
• They’re only available to paid subscribers – but neither free nor paid subscribers know this
• They look ’scary’ (because it’s not clear what activating them will do.  Is there a chance it will lose data or undo previous tasks?)
• There are no demos, screenshots, or any other way to preview them

This is bad.

I mean, you built these features already.   You probably had a good hypothesis as to why they’d be useful.  You invested development and design time into implementing them.  But while they’re in “Easter Egg” state, you will not learn from them.

You can’t know if a feature is useful if no one knows it’s there.  And if you kill a feature while it’s in this state, you’re going to draw false conclusions.  Sure, no one complained.  You don’t complain about missing something if you didn’t know it existed.

So, take the challenge.  Figure out what customers don’t know about.  Anything “unknown” that is core to your business — that had better become the next focus of your attention: figuring how, as quickly as possible, to start “un-Easter Egg-ing” those features so both you and your customers benefit.

I’m going to come right out and say that, because I think we give ourselves too much credit for simply improving upon the status quo. And it’s really not that hard.  If you use a product regularly, it’s not hard to notice the little flaws or omissions that would make it better.

So then we think, great, our product will be better.  We will do all the things that our competitor does well, AND we’ll fix those flaws and add in those missing pieces.

Congratulations, you now have a superior product.  What you do not have: customers beating down your door.

You’ve done the first step: make it better.  But you still have several more steps:  make it even better.  And then, make it even better than that.  And then, when you’re convinced you can’t improve it any more, make it just a tiny bit better still.

There are two reasons why you need to keep improving your product to a point that seems like fanaticism:

Everyone exaggerates.

Your website says “The best way to do X” or “The easiest way to do X”.  Guess what? So does everyone else’s.  Your competitor – the one whose shoddy product inspired you in the first place – makes the exact same claim on their website.

People are fundamentally wired to not change their behaviors.

(I hear the phrase “users hate change” a lot, and I dislike it – it sets up that us vs. them mentality, that “if only our customers were smarter, they’d get it” excuse.  It’s not that your dumb users hate change. It’s that everyone, even smart people who pride themselves on trying new things, default to retreading familiar patterns.    OK, rant over.  Back to the post.)

It takes work to try a new product.

It requires learning (even if the new product is simple).

It requires risk (what if I invest time and then the new product doesn’t work?)

It’s much easier to use the thing you know, even if you the thing you know kind of sucks.   So even if I know, objectively and absolutely, that your product is 20% better than the alternative, I won’t switch.  Even if I’d recoup the lost time within a week, it’s not worth changing my behavior.  If your product is 50% better?  Maybe.  If your product is 200% better?  Now we’re talking.

Now, if you’ll excuse me, I have two products to make better.  Much, much better.

I started my career as a designer, so I find a particular irony in now being a vocal proponent of scrappy, get-it-done, ‘quick and dirty’ approaches.

But here’s how I reconcile it: “good enough” is not an acceptable end.  It’s a means to an end.  “Good enough” enables the pursuit of excellence.

I don’t know which workflow or messaging or feature is going to strike that perfect satisfaction within the user.  And neither do you.  (And don’t give me that ‘genius design’ argument – you are not Steve Jobs, and neither is anyone else except Steve Jobs.)

They are not the same things.

If I spent more time tweaking and revising, I would be happier.  But odds are, my customers wouldn’t.

So we start with “good enough”, and we watch and we learn.  And that’s how we know where to focus our tweaks or our ‘aw hell, scrap this whole thing and do it over’ attention.  And we do it again, and again, and again.  Good enough never is.. for long.

That doesn’t mean people are using them. Judging by local news radio reports and anecdotes I’ve heard the last few days, many people would rather drive 15-30 miles out of their way to take alternate bridges through heavily-congested traffic.

Not surprising.  It’s always hard to change ingrained user behavior.  But the other (fixable) problem is that the public transit agencies in the Bay Area have an atrocious first user experience.  Signage on BART is confusing – after living here for 10 years and taking it regularly, I still have to double-check which line I should take (walking back and forth to find the ONE map in the station that will tell me).   It’s difficult to find a timetable – if you don’t know how to check schedules online, you’re flying pretty blind.

Most people I know who’ve switched from driving to BART love it – the extra time to read, check e-mail, or nap.  The savings on gas, tolls, and car maintenance is a lot more than the price of tickets.  But the initial hurdle to get there is too much for most people.

Most product demos paint a picture of “what will be” – once you’re using this product, you’ll be faster. Smarter. More effective. More in control. Have more time.  Save more money.

But how you get there – the “first user experience” that carries you from uninitiated user to fully-engaged customer – often gets short shrift.  It doesn’t make for a sexy demo.  Users are only the “first-time” user once; from a pure time standpoint they’re probably spending less than 1% of the life of their usage in that novice stage.

In software, we tend to think of situations like this as an “edge case” – it happens, but rarely, and it’s not worth devoting resources to fixing it.

This mindset is reinforced by the fact that most software initially launches to a somewhat self-selected beta population of people who are either naturally tech-savvy, or have a problem so severe that they’re willing to overlook a painful first user experience because they need their pain solved NOW.

So the first group of users passes through that “first user experience” stage without a lot of complaint.

Then the next wave of visitors are exposed to the product and not many of them convert to loyal customers.  At this point, you may recognize that the first user experience is the problem.  But by now, your beta customers have started to demand new features.

You face a choice:

1. Invest time in improving your first user experience (so that you can attract new customers)
2. Build new features (so that you can keep your existing customers, and new customers would probably need those features anyways…)

Most of us have seen #2 win, time and time again.  After all, the newly requested features have been validated – customers have asked for them.  There’s no proof that fixing the first user experience will draw in more customers.   Most of us have learned that “if you build it they will come” is a dangerous philosophy for a product roadmap.

“What if we spend the opportunity cost to improve this “first user experience”, which, honestly, accounts for at most 5 minutes of a customer’s lifespan with us, and then we don’t see new customers?  We’ll have wasted time and money and jeopardized our existing customers!”

If BART (or MUNI, or any other local transit agency) wanted to increase ridership, they could do a lot by introducing clear new signs, easy-to-read maps, easy-to-read fare information, and instructions on how to get schedule information.    They could upgrade the confusing ticket machines.  Publicize how much the average consumer saves by not driving, the fact that the trains get wireless signal in most places.

But public transit agencies are losing money.  What if we invested money and resources into improving the first user experience and no one left their cars?   Once you have an established product or service, it becomes incredibly hard to take that leap of faith.  If you don’t solve this problem early, it may never be solved.

Unless you work for a company firmly grounded in lean manufacturing practices, I’m guessing none.   A process is defined; now it’s your job to follow it. Except:

He was talking about the difficulty of getting employees at his company to actually follow his security policies: encrypting data on memory sticks, not sharing passwords, not logging in from untrusted wireless networks. “We have to make people understand the risks,” he said.

It seems to me that his co-workers understand the risks better than he does. They know what the real risks are at work, and that they all revolve around not getting the job done.  - Schneier on Security: Risk Intuition

Schneier writes about IT security, so his approach is to use a bigger stick.  If you increase the severity of punishment for security violations, then your employees will consider that a bigger risk than circumventing them to save a few minutes. I say to him, “good luck with that.”

If something is difficult to do, people will not do it. It doesn’t matter that they may be fired.

If you want compliance with processes, make them as easy and fast as possible to perform.

Product managers, you may not create your internal processes, but you can still push for change.  Next time you find yourself putting off a burdensome but necessary task, take a few minutes to think about how it could be streamlined.   Make a suggestion, mock something up, document the opportunity cost.

At a previous company, we used a bug database package with terrible UI.  Who cares, right? It’s an internal tool only.  Except that the terrible UI meant that you frequently typed in a long bug description only to hit the wrong button and lose all your data.  Even if you followed the workflow correctly, it took at least 5 minutes to log in, set up the right screen, un-select the irrelevant options, enter your data, and submit.

• Result: no one but QA and customer service ever filed bugs.  There were dozens of bugs that sales and engineers and account management and execs knew about, but never got around to filing.
• Result: Product Management prioritized bugs based on incomplete knowledge.
• Result: patch releases didn’t include those high-priority bugs, and account managers had to look foolish as repeated patches were released that still didn’t address that minor – but highly noticeable – bug.

Then we switched tools to a simple, web-based, single screen system.  Invested about 2 person-days in customizing the template with intelligent defaults, big textarea boxes for typing, fewer required fields.  Time to file a bug dropped from 5 minutes+ to 30 seconds.  There was no excuse to not file a bug – it took longer to complain about a bug than to just file the damn thing yourself.

• Result: everyone filed bugs.
• Result: Product Management had a really clear picture of the issues with their products and could prioritize effectively
• Result: the biggest and most noticeable issues were fixed promptly, and at least for issues that weren’t fixed, we knew about them.  Huge reduction in embarrassing surprised in front of customers.

Keeping your processes usable really boils down to one practice: whenever you find yourself doing something tedious, think about what’s making it long/difficult/frustrating and how you can reduce that.

Now, as it happens, my blender of choice is not a simple blender.

I’m a dedicated – but very non-fussy/pragmatic – gourmet cook, and I love my BlendTec.  (You may recognize the name from the “Will It Blend?” YouTube videos, which are brilliant.).

Simplicity is one way to think about it. Designing the whole product experience is another.

Saeed writes:

The usage scenario goes something like this:

1. Place the contents to be blended into the blending  container
2. Blend for 10-15 seconds (maybe 20 seconds in extreme cases)
3. Pour the contents out of the container

That certainly sounds like the types of usage scenarios I typically read in Product Requirements docs.  But it illustrates the difference between “designing the product” and “designing the whole product experience.”

There’s an exercise that most introductory programming courses use to illustrate how you think through a problem.  Students are asked to write out the steps for “explain how you would explain, unambiguously, how to make a peanut butter and jelly sandwich“.  Usually the professor then “acts out” one of the responses, and hilarity ensues as the class realizes that they forgot to explicitly state that you need to open the bread bag, or unscrew the lid of the peanut butter jar.

Follow your users into the kitchen to think about how it will be used in context.

1. Place the contents to be blended into the blending  container. — Wait a second, where is the blender?  It’s not on the counter.

Problem identified.  “Putting stuff in the blender” is not where your use case starts.   For many of your users, the first steps is getting the blender out.  Which raises a few questions:

1. Why isn’t the blender always on the counter?
2. Where is the blender stored?  Does the user have to bend over and rummage around in a blind cupboard?  Do they have to get on a step-stool to reach it?  Is it heavy?
3. When the person retrieves the blender, is it ready for use or does it need to be dusted/re-assembled?

Let’s go back to the original “Why” in the diagram and see if there is some way we can fix these issues as part of the product experience:

By exploring the situation a bit more, we’ve identified some new potential differentiators:

• Make it smaller
• Make it lighter / easier to move

These may not seem like revolutionary features, but they both reduce the friction of using the blender.

To make the blender smaller or lighter, you aren’t cutting features – you’re trading them for convenience.  For never having a user say “I don’t feel like bothering with the blender.”

Now let’s look at the other side:

Here we see two more areas to explore:

• Make it more useful
• Make it easier to clean

You can see where this is going.  Your customers do not think of your blender as being some separate entity. They don’t say, “OK, I’m going to use the blender now.”  They say “I’m going to make some soup.”

Your product success is dependent on how well you enable the experience of making soup.

Your product vision cannot start and stop with “turn the blender on” / “turn the blender off”.  

The kinds of questions you’ll want to ask…

1. Is the blender already out on the counter?
2. If not, where is it stored?
3. When the person retrieves the blender, is it ready for use or does it need to be dusted/re-assembled?
4. Do the food contents need pre-preparation (i.e. cut into small enough pieces for the blender to handle?)
5. How long did steps 1-5 take? During this time, was the person doing another activity that occupied their attention? (i.e. sauteeing the onions, which burned because it took too long to get the blender out and ready to use)
6. Place the contents to be blended into the blending  container
7. What type of items will the person want to blend? Would differing levels of time/speed be necessary for the blender to adequately blend them?
   
8. Blend for 10-15 seconds (maybe 20 seconds in extreme cases)
9. Pour the contents out of the container.
10. What parts of the blender need to be washed before the next usage?
11. Does the blender need to be disassembled before it can be washed?
12. Can the washable piece(s) be easily carried to the sink with one hand?
13. Does the blender need to be covered or re-assembled prior to putting it away?

Don’t narrow your product vision too soon.  Storage, kitchen design, dishwashing, and trying to get dinner on the table before 8pm are all part of your product universe.

You can embrace it and create successful products that your customers love, or ignore it and wonder why your product isn’t selling very well.

View the whole blender flowchart diagram as a PDF. (It’s pretty cool.)

Anatomy of a bad user experience – step by step:

1. Read an article about Hunch, remembered that I had a beta account.
2. Thought of a question that I wanted an answer to.
3. Went to hunch.com and tried to type it in – you CANNOT ask a new question.  If what you typed doesn’t match a pre-existing topic, there is no call to action to create one.
4. Logged in – maybe only logged-in people can create a topic?
5. Clicked on “Create new topic”
6. Got the above image – basically “no, you can’t do what you want until you jump through these hoops.”

I understand that the system needs to be “seeded” with information.  This is not the way to do it.

Any product where the first user experience actually uses the words “Come back when you’re done” needs an immediate rethinking.

The underside of the keyboard has a hole in it, so that if you spill liquid on the keyboard — and lots of us have done it, we know it happens — it will drain out easily.

Adding a hole was not a feat of technical engineering.  It didn’t require special materials or sophisticated machinery.  It was just a case of someone thinking about what it’s like to knock over your glass of water and curse and turn your laptop upside down banging on the bottom and hoping that the water will leak back out and wondering if a hairdryer will make things worse – and saying, “We know this will happen.  How can we minimize the damage when it does?”

This isn’t the kind of feature that’s going to win you points up front.  But someone is going to be saved by it, and that person is going to be a ThinkPad evangelist for life (or at least the next couple of years, which is pretty equivalent to “life” in the high-tech world).

“Facebook keeps trying to redesign that shell as though IT were the value that users keep returning for. It’s not – users are returning for THEIR friends and photos and updates. You can’t test-drive a data-driven site with fake data. It’s a lot messier to put the real thing out there and let people play with it – but it’s the only hope of getting truly representative feedback.”  (my comment on Listen Up, Marketers: The Focus Group is Dead)

Last week, I previewed the upcoming Facebook redesign, and my first impression was: it looks fine.  Visually, the alignment looked clean – the preview image was easy to scan.  I liked the concept of the invitations over on the left-hand side where they took up less space.  I went so far as to think, good, they’re going to avoid the complaints and unhappiness that their last redesign caused… until I started using it.  It just doesn’t “work”.

The Facebook redesign may have looked fine as a static mockup, but Facebook isn’t a brochure-ware site, it’s data-driven. Without a unique user’s data, it’s just an empty shell.

I’ve heard quite a few people complain that the new design is “ugly”.  I know design is subjective, but respectfully, I say: you’re wrong.

The new Facebook isn’t a visual design problem.  It’s an interaction design problem.  You may not particularly like the bigger fonts or the rounded corners, but if the interaction still worked, you’d hardly notice them.

What does it mean for interaction design to “work”?  It means that the things your website allows users to do aligns with the things your users want to do.  It means that you’ve watched the way users work through a process and you’ve mirrored that process in your application.  This mirroring is usually what people mean when they describe a site or application as “intuitive”.

“Intuitive” isn’t limited to applications, either:

“What we didn’t get was the passion this very loyal small group of consumers have. That wasn’t something that came out in the research.”-Neil Campbell, president, Tropicana, North America to The New York Times upon pulling its revamped packaging in February after consumer complaints.

I’m sure Tropicana showed the new branding to plenty of sample consumers.  But did they do it within the interaction of actually buying orange juice?

I’m not a regular juice purchaser, but after reading that NYTimes article, I went to my Safeway and scanned for Tropicana on the shelf.  It took me quite a few seconds to locate it, because the new branding looks like every other orange juice out there.  Think of a distracted mom, with a kid in the cart, trying to quickly grab her family’s favorite orange juice.  Do you want to put obstacles in the path of that task?

The previous Facebook design respected that there were two modes of using the site – quick scan and killing time.  The two views of the News Feed supported these modes: a selective stream of news with a one-click ability to adjust how much/little news you got from an individual, and an unadultered stream of everything your friends were doing in real-time.   The new redesign merged these into a combined page with neither selectivity nor real-time updates.   Now neither group is happy.

It’s easy to dismiss people complaining about Facebook as college kids with too much time on their hands.  Users DO hate change, and sometimes you may need to force it upon them.  But you need to understand how change impacts their interaction with you and your product.  I’ve heard several people say, “wow, I was so productive at work today because the new Facebook just doesn’t interest me anymore.”  Good for their employers.  Bad for Facebook.

Related: Streams, Affordance, Facebook, and Rounding Errors

An organism needs to invest energy in being beautiful. You won’t see healthy skin on a sick animal, because maintaining a healthy coat is too ‘expensive’. A sick peacock isn’t as spectacular as a healthy one. Or a genetically damaged chimp isn’t going to have as symmetrical a face. As a result, most creatures evolved their definitions of beauty in a mate to match the displays of healthy creatures.  (Seth Godin, Beauty as a Signaling Strategy)

Great argument for why “looking good” has benefits beyond those that can be quantified.  An elegant design or a little bit of flair can rarely be directly connected to a 2% higher utilization or 4% efficiency gain, but it sets a tone, an expected level of values.  It’s the tip of the iceberg: if we care this much about this little detail that you can see, just imagine how much care we put into the massive underlying platform that isn’t immediately visible.

The reverse is true as well: I’ve been mortified during customer demos when a big, obvious, sloppy misalignment or typo was present in our beta application. 

The customer won’t notice, said the engineer who didn’t have time to fix it.

If you can’t spell correctly, how can we trust you to run our business, said the customer.

It’s going to be tempting in this economic climate for companies to cut back on “beauty” – whether that means preserving a page layout by not bombarding it with ads, or taking a few extra seconds to make a customer service call more effective.  But product managers should think about what that says about your overall “health” as a company.  Do you want to look like a wounded animal?  Now is not the time to have a vulnerable-looking product.