This is the second part of an article series. To read the introductory notes about user experience research and design tips, click this link: READ PART I.

One of the biggest Lean UX myths is that these guiding principles will get you to a solid stand-alone UX strategy. Well, there is no such thing as a stand-alone UX strategy. As long as you work together as a collaborative team to strengthen the whole product strategy, you’re always optimizing the weakest parts of that strategy. Sometimes that’s the UX part and other times it’s not.

The user experience strategy should not have a set of features at its core. It should have something else: the reason why people use the product. If we look at Google Maps for example, a standalone product, its core user experience is to easily get from one place to another at any time. The countdown, displaying when exactly you will arrive, is a suitable feature that expands this experience.

But Google’s product works regardless of this feature. The countdown, on the other hand, cannot live without the product (the certainty to get to a specific place on the map). Here’s a simple correlation between feature and product: features don’t work without the product. This is why designers should design with the PRODUCT in mind, not its features. In effect, we can observe how design thinking applies to a start-up’s core needs as PRODUCT THINKING.

Through product thinking, UX designers should be able to answer: what problem does the team have to solve, for whom are we all doing this, why are we doing this as a business, how are we going to do this, or what does the team want to achieve? When it comes to building a product, this mindset will help the team in different stages: at the validation level, when designing the actual product, and also right before (and after) launching it.

About the validation

Many startup companies are founded based on an idea for an amazing new product. That is also the reason why many of those same startups fail: they are based on assumptions, and those assumptions are not tested before building the actual product. If the ideas that you got wrong are a vital part of the product, you’re going to be out of business.

Your product is essentially a response, a solution to somebody’s problem. This definition has three variables that should be verified and tested. You identified a group of people who might want to buy your product – that would be THE MARKET. Good!

You observe the reason why those people are likely to use your future product – THE PROBLEM. You are also thinking about the way that you’re going to solve these people’s problem – THE PRODUCT. Perfect! But what’s the order in which you should start validating these variables from your story?

You should validate the problem first. When doing the research for it, you will most likely identify a group of people with similar pain points. A designer’s job is to understand if all these different things that people complain about are actually the same problem or not.

The second variable that you should validate is the market. This can be done by doing further research on the initial group of people that confronted with the problem. A part of that group will probably be interested in purchasing a solution which would solve their problem. Their pain points are severe enough, so these people would want to spend money (or time, or other resources) on solving their problem, their need, or their desires. That’s your market.

Once you identified this particular type of person, you can validate your product idea on them. A product can become a business only if a high enough percentage of that narrow group of people offers to pay for your product, instead of looking for another solution to their problem.

Tools for early validation

The key to an effective validation process is to use the right type of research at the right time. There will be many ways to collect information about users, but some of them would be useful only in certain phases of the design process, and others will turn out to be a giant waste of money.

So what should we use? Landing pages, Guerilla User Tests, Wizard of Oz, New User Interviews, Prototype Usability, NPS (Net Promoter Score) Surveys, Unmoderated Testing, Analytics, Customer Development Interviews, Sales, Focus Groups, Product Stubs (Fake Doors), Task Based Usability, Brain Imaging, A/B Testing, Observational Usability, Click Tests, Surveys?

I’ll be describing some of the most common approaches when it comes to validating either a specific market, people’s most annoying problems, or the designed solution for those problems.

Listen to your users

This phrase has been used so many times without any description about what it really refers to. It doesn’t imply letting users dictate your product roadmap, but rather get an overview of their behavior, their current practices, their shortcuts and patterns. You can understand the problems of your potential users only if you observe them in person. Are they performing tasks in a specific way that could be made easier? Is that a specific problem encountered by most of them?

Test somebody else’s product

This is a very straightforward way to avoid most of the mistakes your competitors are already making. This approach will allow you to solve some user problems that you are actually capable of fixing.

Here are some questions for your competitor’s users: What do you like about that product? What do you hate about it? What confuses you about it? What do you find particularly annoying about it? What’s missing from it? How did you learn to use it? Where did you hear about it? Have you tried anything else like it? Why did you pick up this particular product over the other options? What other parts of your job or task do you still have to do outside the product?

Advertise it

Trying to sell your product before you build it is a great research exercise. By publicly releasing a set of teasers, you should be able to predict which version of your product has the biggest potential market. Pre-order landing pages are a cost-effective way to test the reaction to different possible versions of the same future product.

Ask what users think you do

Whether you design and prototype either the product’s homepage, an app’s dashboard, or a marketable landing page, show it for five seconds to potential customers. What does the user think this product does? Who does the user think the product is for? Can the user figure out how to get the product? This short tests will validate your messaging, your branding materials, your call-to-action buttons.

Prototype tests

Even when you do know what problem you are solving, there might be multiple ways to solve it. We should always take time to verify if the implemented solution will work for our users. But simply asking somebody if your idea solves their problem is not the right way to do it. Showing a working and interactive prototype of the product and observing their reactions would rather be a safe way to get some insights about the future success of the functionality.

This testing method will be efficient only if the prototype is interactive enough, so that people can imagine that they are using a real product. Actually, the closer you get to the real thing, the more accurately you can predict the outcome of the experiment. In the same time, you want to quickly build something that you can iterate on. My advice here is to pick a tool that lets you make updates really fast, because you probably are going to get something wrong and need to change it.

When testing a prototype:

• Shut the hell up!
• Don’t give a guided tour.
• Ask open-ended questions.
• Follow up!
• Let the user fail!

Qualitative vs. quantitative research

To maximize efficiency, you should be able to predict when is a good time to use a specific research method. Quantitative research will indicate WHAT the problem is. Qualitative methods will tell you WHY the user has that problem.

When the interaction that you want to validate has only one variable change (like the color of the Sign-up button), qualitative feedback is not going to be worth the time and money and will not be able to give you any extra information. So go with quantity. Furthermore, if you need to test a multivariable change or an entire flow (a good example would be a new feature), then you will need qualitative methods to understand the WHY behind a preference.

This was the second part of an article series. To continue reading about user experience research and design tips, click this link: READ PART III.