Designers design. It’s right there in the job title. The problem is that we can overdesign. We can spend a lot of time focusing on the details and the vision and a lot of other things that don’t directly relate to solving a problem.

Look, I just explained that you need to figure out how you’re going to test to see whether your design change actually made a measurable difference to your business. Now let’s talk about making sure you’re only making design changes that make a measurable difference to your business.

Those two things are different. Seriously.

Whether you’re a trained designer or somebody who just needs to know enough design to get your product in front of users, you’re going to have to stop thinking about design primarily as a way to make things beautiful or cool or interesting. Your goal for this type of design is to make things easy, obvious, and useful.

The way to do that is to strip out everything that isn’t necessary to validate your hypothesis or to move your key metric.

This is a tough concept to get, so let’s look at some examples, both good and bad. Have you bought anything at Amazon recently? Oh wait. You’re human, so probably.

Have you noticed all the stuff it has on its product pages? There’s a lot of it. It has recommendations and reviews and other places to buy and descriptions and ratings and...about a million other things. It also sells a couple of versions of virtually every product known to mankind.

Figure 6-1. I’ve been looking for this everywhere!

Because of the way Amazon creates its product, I have a fairly high certainty that each of those things helps it sell more products. I also know, because I was around at the time, that it didn’t have most of that stuff when it started selling books back in the prehistoric era of the Internet.

That’s the thing. Each of those elements it’s imagined and designed and built and tested took a really long time to imagine, design, build, and test. If you decide to build a product page with all that stuff on it, you’d better be independently wealthy, because that shit’s going to take awhile.

I talked with some people from a company that had a fairly successful product. They wanted to add a new feature to their product. They spent a lot of time discussing how the feature would work, what it would do for users, how users would interact with it, and all the other sorts of conversations you tend to see around exciting new features.

Then they got to a key question: How would users access the feature?

They decided that the feature was important enough to include in their main navigation. Unfortunately, there wasn’t any place that their new feature fit nicely.

They decided they would need to redesign their entire main navigation for the product. This, of course, meant that all the other small changes they’d been saving for the main navigation had to go into this redesign. Also, they’d have to do a full visual redesign of the main navigation. Oh, and if they were doing a full visual redesign of the navigation, obviously they’d have to update the visual design on the rest of the application to match.

Did I mention that, when they finally launched the new feature, users didn’t care about it? It failed to move a single metric, and the company eventually pulled it entirely.

OK, that last example depressed me. Let’s look at a nice example of the right amount of design. This is probably the most commonly used trick in the Lean UX arsenal. It’s wonderful, because it allows you to test a feature without building anything at all! What could be faster than that?

I often consult with companies that are considering selling a particular item or package or feature. For example, I was talking to a company that wanted to start charging for certain features on its free product.

When we spoke, they immediately started talking about things like whether they should charge a one-time fee or a subscription, whether they should allow a free trial, and what payments they should accept. They told me that they wanted me to design the payment flow so that users would be more likely to buy the upgrade.

I stopped and asked what I think is a reasonably important question: Do you have any evidence that anybody will buy this thing at all?

The reason I asked was that all of the questions they were trying to answer are hard to solve, design, and build. Despite the sheer number of things being bought and sold on the Internet, great payment flows can still be tricky. Also, did you know that integrating with payment systems is the leading cause of Developer Rage Syndrome, which is a syndrome I just totally made up? True story.

The first step was to validate whether anybody wanted to pay for any part of the company’s free system. Here is the design that you need to start testing that assumption: a button that says Upgrade and a static page with a price and a couple of features you might offer when the user upgrades.

You also need a way on the backend to calculate the number of people who click on that button and a way to A/B test how changing the price and benefit statements affect conversion. These are far easier to build than an entire payment system and flow. Besides, you should really have the ability to A/B test this kind of stuff anyway.

When I was consulting, I worked with a company called Food on the Table. Now, Food on the Table has a product that helps people plan their meals around whatever is on sale at their local grocery store. At the time I write this, they have the daily sale information from literally thousands of grocery stores all over the United States.

It’s a great idea. It’s also a giant pain in the ass to implement. After all, you have to have some way to collect all that information from all those grocery stores in order to share with users. You also have to have an easy-to-use onboarding flow to gather information from people about where they shop and what food they like.

So they didn’t do that. At least, they didn’t do it at first. Instead, they decided they needed to learn more about how people shop and whether people would be interested in the product they wanted to build.

Instead of doing all the design and engineering work to build the product for everybody all at once, they got a few potential customers and did the work manually. That’s right. Instead of spending the first few weeks getting sale data and building a user interface, they went to the store, got the sale circulars, and sat down with some potential users to help them plan a meal. There was no design or engineering involved at all.

Now, it turned out that people loved the idea, so that’s when they decided to go ahead and start designing and building. But if people had hated the idea, even when they had somebody literally sitting down with them and helping them plan their meals for free, would there really have been any point to building the rest of the product? Probably not.

We call this the Wizard of Oz feature or sometimes a concierge service, and tons of companies use it all the time. Here are some other examples of great Wizard of Oz features:

First, let me tell you a story about a very small bug we encountered at Food on the Table, one that was having a pretty big effect on metrics.

As I mentioned before, Food on the Table lets users create meal plans based on what’s for sale at their local grocery stores. There was a call-to-action button that allowed a user to add a meal to her meal plan.

When the company tested the button locally, it all worked perfectly. Users pushed the button and the meal was added. Worked every time.

The problem came when users with slower connections or slower computers pushed the button. In many of those cases, when users pushed the button, there was a delay of up to a few seconds. What this meant was the user would push the button, but nothing would appear to be happening. She would then push the button several more times, hoping to make something happen. When the button clicks registered in the UI, the user would have added the meal to the meal plan several times, which was clearly not her intention.

We discovered this bug quickly in observational testing. It was happening to enough people that we were fairly certain it was negatively affecting key metrics, especially for new users.

Then we needed to figure out how to fix it. This is where the concept of “as little design as possible” came in.

Now, as you can imagine, there are lots of ways to fix this problem. The immediate engineering response might be to reduce the latency on the button so that the button clicks were recorded faster. Anybody who’s ever written any code will recognize this as potentially a Very Hard Problem.

A different approach might be to simply have the user interface reflect the change the user made without waiting for a response from the server. This is fraught with dangers, of course, because it can allow what the user sees to get out of sync with what’s in the database.

I could give you five or six other possible solutions, but the very simple one that we came up with was simply to show a working state spinner on the disabled button until the process finished. Since the wait was never more than a few seconds, people were perfectly content to wait while their choice was recorded.

Why do I bother to tell this story? Well, it’s important to realize that this solution worked in this particular case for a lot of reasons. For example, users were typically adding only three to five meals to their meal plans at a time. Waiting a few seconds for each one to be added did not significantly affect their total time performing the task. If it was a task they had to repeat hundreds of times, the three-second pause would have become a problem.

That’s the important thing to remember here. If all goes well, over the course of your product’s life, you will make far more of these small, iterative changes than you will big, sweeping changes. It’s important to have a process for figuring out the smallest possible change you can make that is appropriate to your situation.

Every startup I’ve ever talked to has too few resources. Programmers, money, marketing...you name it, startups don’t have enough of it.

When you don’t have enough resources, prioritization becomes even more important. You don’t have the luxury to execute every single great idea you have. You need to pick and choose, and the life of your company depends on choosing wisely.

Why is it that so many startups work so hard on the wrong stuff?

By “the wrong stuff” I mean, of course, stuff that doesn’t move a key metric—projects that don’t convert people into new users or increase revenue or drive retention. And it’s especially problematic for new startups, since they are often missing really important features that would drive all those key metrics.

It’s as if they had a car without any brakes, and they’re worried about building the perfect cup holder.

For some reason, when you’re in the middle of choosing features for your product, it can be really hard to distinguish between brakes and cup holders. How do you do it?

You need to start by asking (and answering) two simple questions:

To accurately answer these questions, it helps to be able to identify some things that frequently get worked on that just don’t have that big of a return. So what does a cup-holder project look like? It often looks like the following things.