Attend “UX Design for Growth,” a training session by Laura Klein that will give you the skills you need to design products that convert and retain users.
After many years as a designer, I’ve realized that some of the most important design decisions have nothing to do with what any of us consider design. Instead of designing the perfect version of a feature, sometimes the best thing we can do is learn that we shouldn’t build the feature in the first place.
In my all-day, online workshop on September 15, 2015, I’ll be talking about another aspect of building products: how to make them grow. Potentially fabulous products fail every day because product managers and UX designers don’t spend enough time thinking about how their product is going to be discovered by new users.
The following is an excerpt from my book, UX for Lean Startups, where I give one practical tip for learning whether or not you should build a specific feature for your product. If you’d like some practical tips on getting people to start using all those features you decide to build, please join me on September 15th for my UX Design for Growth training session.
Excerpt from Chapter 6: Just enough design
I talked with 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 nicely fit.
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 feature, users didn’t care about the new feature? It failed to move a single metric, and the company eventually pulled it entirely.
What they should have done
They should have done pretty much anything else. The whole experience was incredibly expensive and demoralizing — and I’d like to say it’s the only time I’ve ever seen it happen, but that would be a lie.
The most important thing they failed to do was to validate the feature itself before changing the entire site to accommodate it.
They could have done this in a number of ways:
- They could have done more customer validation before they created the feature to see if the feature would solve a real customer pain point.
- They could have added the feature and advertised it directly to a small percentage of their users and asked them explicitly to try it out and give feedback.
- They could have added access to the feature from someplace that wasn’t the main navigation, but that was still accessible to users, and tested it there.
- They could have just made small changes to the current main navigation in order to fit the feature in with the idea that they would go back and improve the display in the main navigation later if the feature was a hit.
- They could have used what I call a “Feature Stub.” That’s next.
Build a Feature Stub
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 their 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 their free system; here is the design that you need to test that assumption.
You also need a system 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.
What does this have to do with design?
OK, I admit it. This doesn’t seem to have a lot to do with great design. It’s more like avoiding design. But a huge component of great design is spending the time on the stuff that’s actually important and not wasting time on the things that aren’t going to work.
If you like, think of it as experiment design. Your job is to design the best possible experiment to validate or invalidate your hypothesis.
Maybe your hypothesis is that people will love your new feature or will be willing to pay for certain parts of your system. Whatever it is, do as little work as humanly possible to figure out if that’s true, because you’re going to have a whole hell of a lot of work to do once you figure out that they desperately want whatever you’re selling.
Cropped image on article and category pages by Liz Sullivan on Wikimedia Commons.