When Talking to Customers Isn't Enough

A few weeks ago, I was talking to the head of a small company about next steps. His company had a product with many happy, paying customers, and he wanted to know what to do next to make his current customers happier and attract some new ones.

The company had already made a good start. They had done surveys of current users asking the standard questions like, "How disappointed would you be if you could no longer use this product." They'd even surveyed current users about what new features they would like to see. The problem was, the happy customers couldn't think of anything else they wanted, and while the slightly less happy customers wanted some new features, there was no general consensus on one big, missing piece or fantastic new idea. So, the CEO wanted to know what to do next.

I believe this can be a problem with the "go out and talk to your customers" solution to product development. We can get so focused on talking to customers that we forget that it's not always the best way to figure out what to do next.

Observe Your Customers

Customers lie. They don't always mean to lie, but it often ends up that way. It's especially problematic when you ask people to explain how they currently use your product. Sometimes they forget parts of their process, or they don't even realize that they're doing certain things because it's all become so routine. Also, they tend to explain their process of using your product from start to finish, as if they weren't doing seven other things while trying to use your product. This can give you a totally skewed vision of what people are actually doing with your product.

What's the solution? Go out and watch them. Sit with them in their offices or homes and observe their real behavior. Most importantly, watch what they do immediately before and after they use your product.

I was talking with somebody who used to work for a marketplace that allows people to buy and sell products directly to each other. While observing users, her team noticed that, while people had very little trouble using the marketplace itself, the sellers spent a huge amount of time arranging shipping of the items. In fact, the shipping process took so much time that it limited the number of items they could list. By integrating with a shipping company to help customers print labels and schedule pickups, the company increased the number of items that could be listed which increased revenue.

Why didn't users ask for that? Well, the customers had a particular way of doing things. They thought of the marketplace as a place where they could buy and sell things, not as a product that helped them mail things. They had another solution that helped them mail things, and they didn't know that there was a better way to do that until they were presented with it.

How Many Features Does it Take to Destroy Your Product?

I work with a lot of startup founders who are extremely excited about their products. This is unsurprising, since nobody in their right mind would launch a startup without being totally convinced that their product is going to be awesome. It’s just too much work and risk for something that you aren’t passionate about.

Passion in startups is a great thing. It can also be incredibly dangerous.

The story is the same with pretty much every group of founders I work with: they have hundreds of great feature ideas for their product. Let me be clear: HUNDREDS of great feature ideas. Don’t get me wrong, many of these are genuinely great ideas. Almost every time I hear one, I think, “Wow, that would be really nice to have in this product and would add a lot of value.”

Unfortunately, starting a product with all of those features causes a lot of problems.

More Features = More Time to Build

Imagine building a house that includes a single room vs. one that has twenty rooms on three floors. There’s a lot more work, design, and planning that needs to go into the bigger design to make sure that people don’t get lost and that the house won't collapse.

This may seem obvious, but building one feature takes a lot less time than building ten. And the more time you spend building your initial product, the longer it takes to start getting metrics from actual users. Sure, you can and should start getting feedback from people using mockups and prototypes, but nothing beats actual data from your real product in the hands of users.

More Features = More UX Complexity

Remember that 20 room house? It has a lot more windows, doors, staircases, and electrical outlets than the one room place. It can be hard to find a reasonable place for everything. The more complex your product is, the more challenging it can be to present all of your features to your users in a usable way.

It’s hard to design a product that has a lot of different features. Everything needs to have an obvious, findable place in the product structure. All the features need to fit together in such a way that a user never gets lost or confused. Starting with a couple of key features keeps the overall UX much simpler and vastly reduces both your design time and the chances that your product will look like a giant mess.

More Features = Less Clear Value Proposition

Ever come to a web site or opened a product and thought, “What on earth does it DO?” Generally, the culprit is a confusing jumble of features, menus, buttons, and calls to action that prevent you from understanding the main value proposition of the product. Sure, companies try to combat the problem with wordy feature descriptions, video tutorials, and on-rails first time user experiences, but those often make things worse.

The simple fact is that the fewer features your product has, the easier it is for a new user to immediately understand what your product has to offer them. When all you have is new users, making sure they don’t get confused and leave is a pretty high priority.

Visual Design is Important, But Maybe Not Just Yet

I’ve been thinking a lot lately about visual design. A few weeks ago, at the Startup Lessons Learned conference, somebody asked how important visual design is in user experience, and recently somebody asked how much time I spend on visual design early in the design process. The answers to those two questions are: “incredibly important” and “not much.”

Why Is Visual Design Important in UX?

A lot of people, even a lot of designers, write off visual design as “making something pretty.” Frankly, I’ve been guilty of this myself. Meanwhile, companies like Google and Facebook have made fortunes while keeping their visual design so spare as to be almost non-existent. So you may reasonably wonder, why is visual design important to my startup or new product, and why should I bother spending time and resources on it?
But visual design doesn’t just make things pretty. It’s instrumental in a lot of ways, including:

• Enhancing your information design
• Reinforcing desired user actions
• Setting the tone for your product

Visuals Enhance Information Design

Sure, Facebook has a very simple, blue, gray, and white look. That’s because Facebook is all about delivering an enormous amount of content and information to you quickly. A bright, distracting, or cluttered interface would make it hard to read large numbers of news items and could clash with user-posted pictures.

Same with Google. Google, at least the main search product, is about getting you to type in a search term and then giving you access to everything on the internet that matches it. That’s a lot of information to process. Sites that are about delivering large quantities of information need to keep their visual design simple. But a simple design doesn’t mean no visual design at all.

7 Ways Design Can Speed Up Your Product Development

One thing I hear a lot from startups that don't want to bother with design is, "But design will slow us down!" They're sure that the fastest way to get a good product in front of users is to just jump in and start coding and then iterate on the feature or product once it's been built and released. Guess what? They're wrong.

A good designer who is willing to work with a lean development team can remarkably speed up your progress. Let's look at some different ways that design can help you quickly get your product into the hands of your customers.

I Can Design Faster Than You Can Code

So, you think you're a pretty fast coder, right? I believe you. But, unless the feature is dead simple, you can't build a working version of it faster than I can build a fake version of it. Remember, my prototype doesn't have a backend or a database. It doesn't have privacy controls. It doesn't have to support multiple users. It doesn't even have to work at all. It just has to look like it works.

Getting rid of all those requirements makes my prototype really, really fast to build. That means I can build several versions of it in the time it might take you to get the backend set up. If I make those versions seem like they work, I can get the prototype in front of users, get their feedback on it, and iterate much faster than you can.

That means, by the time you build the real version, it's already been through two or three versions and validated with customers. Many of the major usability problems will already have been found and eliminated. Complicated things will have been simplified. You'll already know how it integrates with the rest of the user interface. If you assume that you'd need to do all of these things anyway, this will save you time.

I Don't Need to Design it All Upfront

Maybe you've only worked with waterfall-style designers in the past, but there are some of us who don't need two months and a full set of specifications to get a product designed. We can get started on the broad outlines just a little before you begin coding and have something ready for you to get started with right out of the gate.

Besides, all of the products I've ever worked on had at least some non-customer facing code that needed to be written, so maybe you could write that part first. If you have some idea what you're coding based on things like customer stories (you did write customer stories, didn't you?), you can get started on anything the user doesn't see, and I can get started on everything the user does see. By the time you're done making sure the feature isn't going to bring down the servers, I can have built and tested a few mockups.

6 Questions To Ask Before Launching a New Feature

There are a lot of things to pay attention to when you’re launching a new feature. This post is going to cover a few of the questions that you really ought to ask before launch, but may not have in the past. Now, to be clear, these are not the obvious questions like:

• Is this addressing a user need or pain point?
• Has this been through and passed some form of QA testing?
• Do I have a marketing plan for letting users know this exists?
• What is the expected ROI for this feature?
• Will this feature scale to a reasonable number of users?
• Is this feature usable, and is the UX reasonably consistent with the rest of my product?

If you have not asked the above questions about the feature you’re about to release, then you should stop reading this blog post and answer them right now.

The questions we’re asking today are more advanced, but your launch will go a lot more smoothly if you ask (and answer!) them ahead of time.

How Am I Going to Get Feedback on this Feature?

It’s not enough to just launch a feature and see if your revenue increases. You need to have some sort of plan for testing to see how it’s affecting key metrics, whether those are revenue, retention, registration, user happiness, or some other number you care about. You need to have a strategy for finding how users feel about the new feature, whether they’re using it, and how it’s affecting your bottom line.

A good answer to this question might include some or all of the following:

• I am initially releasing this feature to a small cohort of random users and A/B testing key metrics of the sample group vs. the control.
• I have embedded a short survey or feedback link into the page and will gather qualitative data from my users that way.
• I have contacted my customer service/community management team and prepped them with information about the new feature and asked them to get back to me if we start to see any significant new support requests.
• I have already released the feature to a small, select group of beta customers or my customer advisory board, and I am meeting with them to discuss their feedback.

Your Users Are Doing Something Surprising

This post is for all of you lucky enough to have a product with real users. Way back before you had users, or even a product, you probably went through a process to figure out what you should build. During that process you may have written user stories and work flows that described, in various levels of detail, how your users would perform each expected task. But you know who didn’t read your user stories? That’s right: your users.

The result? Somewhere out there, a whole lot of your users are doing something totally unexpected with your product.

Ok, maybe it’s obvious that sometimes users do the unexpected. Maybe you expected your SMS-based social network to help people find out where their friends are in real time, but instead celebrities started using it to market directly to their fans. Maybe you created a product designed to help bands promote themselves, but instead ended up with a social network where people hook up with their high school sweethearts. Or, although this seems extremely unlikely, maybe you had an MMO but people just used it to share photos.

Whatever they’re doing, it’s something you didn’t expect, but it’s very important that you learn what it is as soon as possible!

Why Should You Care?

There are three excellent reasons for you to know what your customers are actually doing with your product:

• So you know if you are missing an opportunity to pivot your product or marketing
• So you know if you are missing an important feature
• So you don’t accidentally destroy a commonly used workaround or "unplanned feature"

Pain Driven Design

I have a problem with both User Centered Design and Customer Driven Development. This may come as something of a shock to people who read my blog, since I’m constantly giving advice on better ways to talk to users, analyze data, and improve customer development efforts.

The problem I have with UCD and CDD is not the methods. The problem is that people so often misunderstand them. People hear “user centered” and think, for some insane reason, that we are encouraging them to turn their entire design process over to the user. They hear “listen to your customer” and think that we want them to blindly accept every ridiculous feature request made by somebody with a credit card and an opinion.

Guess what? I rarely speak for entire communities of people, but I think I can safely say that nobody in the user centered design or customer driven development business are asking that of anybody. If they are, they’re idiots and shouldn’t be listened to anyway.

Unfortunately, a lot of us have debunked this myth by explaining that we don’t actually think that customers can predict future behavior (even their own) or that they’re going to have some grand design vision for your product. We just think that customers are great at talking about their problems and pain points, and that those are good things for you and your designers to know when you create a new feature or product.

I’m suggesting that we come up with a new name that will be harder (or at least more fun) to misinterpret: Pain Driven Design.

What Is Pain Driven Design (PDD)?

The PDD methodology requires that, before you start design for a product or feature, you need to figure out what is causing pain for your users and potential users. The desired outcome of PDD is to make that pain go away by some brilliant method of your devising. You then check to make sure you made their pain go away without causing them any more pain.