I’m going to discuss two more reasons which extend beyond the design team.

The first one will not be a surprise to anyone who reads this blog regularly — most products are poorly designed because the product leadership failed to get out of the building and talk to customers.  Another way to state it is an overvaluing domain expertise.

Don’t get me wrong – complex products require a product manager who understands the rules of the game. I don’t want to use brokerage software created by someone who doesn’t know a 401K from a 529 plan.

But it takes more than knowing the conventions and constraints to build a great product experience.   You need to be able to anticipate your customers’ concerns and fears, to know where they’re likely to be confused and need reassurance, to understand the context in which they’re using your product.

When you have deep domain knowledge, it’s hard to remember what it was like when you did not have that information.  (see: the “curse of knowledge”, popularly explained in the book Made to Stick).

When I worked with financial software, I commonly heard product managers and engineers explain a certain workflow with “but this is the logical choice!”  How many people do you know who are logical about their money?  Money is emotional.  Things that threaten our money (or anything that is important to us) scare us and turn us into irrational creatures.

Products that are designed by rational humans but used by irrational humans… usually doesn’t result in a positive user experience.

To overcome this, you need to make a conscious and deliberate effort to understand your customers.  What is their mental model? What are they concerned about? What is their comfort level with this task?  You need the ability to put aside your domain expertise and see your product through the eyes of the uninitiated — and this is a challenge.

Most of us work really hard to become experts at something, and it goes against our nature to spend time pretending to not be experts.

The final reason why most products are poorly designed is that the product development process doesn’t get feedback fast enough.

Raise your hand if this sounds familiar:

Company: “Oh, we always do user testing to identify any usability issues or confusion with our products.”

Me: “That sounds good.  When do you usually do your testing?”

Company: “We do our testing when we have a real working beta; that way we’re testing the real app so we get the most accurate results.”

Me: “So, if your testing uncovers major issues, how long do you have to address and fix them?”

Company: “…A few weeks.”

User testing is too often just lip service.  If your product is fundamentally wrong — and if you made the first 3 mistakes I discussed, it almost certainly is — you can’t just patch that up in a couple of weeks. Not only would that require your engineers working 36-hour days, but now your whole organization is invested in the thing that has already been built, is already working, was already promised to customers.

Even if you made incredibly good guesses, even if you talked to customers before you started building — if you wait until the product is 90% complete to get feedback, you might as well have not bothered.  You’ll learn what you should fix in the next version, but for startups, you may not have the luxury of a next version.  This version needs to meet a minimum value threshold or you’re headed for the deadpool.

The way to fix this is simple.

Get feedback sooner.  Build that into your schedule:

• Interview customers before you start building and use that feedback to identify changes to your requirements.
• Show early mockups to customers and iterate based on that feedback.
• Show early prototypes to customers and iterate based on that feedback.
• Find ways to manually emulate the “finished product” experience and share that with customers, iterate based on that feedback.  And, of course
• Look for ways to build the 2-week version and then another 2-week version and then another 2-week version — instead of the 6-week version where you’ve invested a lot of all-or-nothing time.

Sounds like a lot of work.  But the hours you spend on gathering that feedback pale in comparison to the hours you waste when giant features or releases have to be thrown away and redone.  (And let’s not even talk about the morale hit…)

Why do so many products have crummy design?

Many designers do not (fully) use the product they are designing. Sometimes this is due to laziness on the designer’s part; much more frequently company culture and the product management/engineering organizations are to blame. Why?

Many applications — especially B2B applications — are difficult, if not impossible, to use in an isolated manner.

A single designer who sets up a project in a project management application may be able to input tasks, but they are not truly “using” the product and experiencing the use cases they are designing for unless it has real projects and real team members interacting with it.

For any product that relies on customer data (and nowadays, that’s almost everything: personal financial applications, social, local, analytics, healthcare), you can’t really recognize what is difficult or unclear unless you are looking at your, relevant, personal data. Sample data is a poor substitute (though better than nothing!)

The other reason is that, in many organizations, designers are brought into the process too late.

Instead of being included in early discussions where business goals and constraints are identified, designers are often thrown a fully-written spec and told to “make this pretty”.

This is basically impossible: all the visual design in the world can’t save features and workflows that shouldn’t have been spec’d in the first place.

So how do we fix this?

Here are some of the things that are needed:

• Product management needs to involve design early in the process
• Product management needs to explicitly define problems, business goals, and constraints
• Design needs to also have access to other teams who are familiar with customer problems — customer support*, sales, engineering — and the company culture needs to support a “there are no stupid questions” mindset
• Executive management needs to buy-in to the idea that designers aren’t just there for ‘making it pretty’ (i.e. schedules need to support designers taking part in early meetings)
• Executive management needs to lead, top-down, a company cultural expectation that “everyone uses the product, no exceptions.”
• Design, product management, and engineering need to collaborate to provide internal tools that support use of the product (e.g. sample data, test accounts, training)

*Customer support, incidentally, is the overlooked knowledge gold mine in most companies.  They know why customers are unhappy, cancelling, or singing your praises, but they rarely get to share that info with other teams.

Those are the first 2 reasons – and, in my experience, the most pernicious. Next week I’ll cover the other 2 problems, and how your organization can improve upon them.

I’m going to show you how taking an extra 30 seconds to identify the type of choice and presenting the appropriate defaults can save you a ton of errors, dropoffs, and customer frustrations.

Which of these describe your choice:

There is only one right answer, and that answer is obvious to the customer

Don’t set a default. For radio buttons or checkboxes, that means nothing should be selected.  For dropdown menus, that means adding an explicit first option called “Choose one:” so that the menu doesn’t default to the first alphabetical choice.

There is only one right answer, and that answer is NOT obvious to the customer

Don’t provide options at all. This seems counterintuitive, right?  If you’re asking a hard question, it seems like you should help the customer by telling them what the possible options are.

But what happens is that customers will simply choose an option at random, and if they guessed wrong, an error will happen.  (Very bad if you are doing an emergency funds transfer to save yourself from overdraft!) It’s better to force them to type in an answer, which they will do slowly and with more care.

There are multiple acceptable answers, but you can guess which one would be preferable to the customer

Set a default and (preferably) explain why. I often hear product managers say something like “well, the customer should pick X, but I want to let it be their decision…”  Guess what?  People hate making decisions!   If you know we should pick X, throw us a bone and pre-select X for us.   Please.  We will appreciate having that 5 seconds of my life and those 5 brain cells spared!

There is one answer that is probably right unless [some situation applies]

Set a default and explain clearly what that exception situation is. Offer an email address or more info icon so the customer can feel really sure that the situation does / does not affect them.

Having worked with a lot of Fortune 500 companies with massive in-house design teams, it calls up images of enormous, image-dense PDFs specifying “6 pixels of space here” and “use 18pt Verdana bold #999 except when centered, and then use 17pt Georgia bold #D41091 but only with 4 pixels of padding” — hundreds of rules that either no one follows, or people spend hours and hours following precisely (to the detriment of actually releasing any useful features).

So today I’m going to talk about a checklist — one that you probably do not have, but should.

You need an interaction design checklist.

Why do I need this?

Because it’s difficult and expensive to fix interaction design mistakes.  Once a workflow has been designed poorly, it often involves both visual design and touching multiple functional pieces of code to get it right again.

But we already know about good design and usability.

Saying “we’re going to design a usable product” is like saying “I’m going to exercise more”.  It’s a vague New Year’s resolution that will be forgotten by February.  Unless you have specific guidelines that are written down and integrated into your process, you will make mistakes.

Our designer feels like they can’t do good work if there are a bunch of rules.

If your designer can’t work within practical constraints, they’re not much of a designer.  An interaction design checklist is like a set of rules for building a house — you need foundation beams, electrical outlets, windows need to be a certain distance from the ground.  That still leaves a ton of room for innovating on room layouts, materials, and paint colors.

But we do usability testing.

Good!  Keep it up.  But you can’t rely on a handful of user testing subjects to find all of your interaction design mistakes.  For one thing, you probably aren’t testing errors and edge cases.   Also, if you start out with a very flawed design, it’s going to be really expensive and time-consuming to keep iterating and testing.  You’re better off starting with a better first draft.

What should my interaction design checklist include?

Every application will vary, but I’ve put together an Interaction Design Checklist Template for you to download.

It includes:

• First User Experience
• Error Messages
• Confirmations
• Forms
• Optional / Advanced View
• “Money-related stuff”
• No Data / Lots of Data
• Actions and Navigation
• What’s Next
• Other Areas to Consider

Don’t think of this as a big project – use the template as a starting point, and as you develop new features, take a little bit of time to ask some of the questions and create new rules as they make sense for you.   Your checklist should develop over time, as you continue learning about your application and your customers.

“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.)