5 tips on how [não] do user validation

It is very common to hear the term “validation” as it has been incorporated into startups’ daily life and designer talk cycles. However, I think you are doing it wrong. Doubt?

Academically speaking, everything needs to be proved. When we go to the business world, the thing needs to be validated. In the frying egg, the logic is the same because it is necessary to gather evidence that your product will really meet the goal and solve the “pains” of users.

There are several methods for validating an idea or proving a hypothesis. They range from observation and registration to quiz and immersion. What you can’t do is create things, buttons, and artifacts without going through the validation process. But unfortunately, things turn out to be misunderstood and the “validation” is just like a “guesswork” from the team.

Here are the tips on how not to validate your product/service or idea.

1 – Ask colleagues or relatives

I am not saying here that colleagues and relatives are not valid, but if they are not really the target audience of your product, then it is no use presenting to your 10,000 Facebook friends and posting to the family group. Feedbacks will be diverse and invalid.

This idea of ​​asking friends is good and encouraged by a number of startup bestsellers, but it has a line here: present / test your product/service only to the specific audience. Use personas to help you build an average profile of who this audience is.

2 – Only test with someone if the product is ready (or the system/site is working)

At this point, you will have spent a lot of effort, time, money and patience to develop all the features of your wonderful product. Then when the user will touch it, two things can happen: either he will find a lot of errors, or he will not say anything.

Because? Simple… the first reaction is because you were developing without asking if it was relevant and the right way for the user. The other reaction, of saying nothing (or almost nothing of value), is because people may be afraid to point out defects in something that took you a long time to do and it seems that it was difficult.

When in doubt, scribble on a piece of paper (or a whiteboard) and show it to a user. You can get so much information about this scribble that you can’t imagine.

3 – Do quantitative research on the interface, without precise indicators

This is harder to explain to non-locals, but I’ll try.

It is very common to find people who publish a survey for other users to give their opinion about the new site, system or application. The problem is that such a survey usually asks if the user liked the X or Y screen… that’s when they don’t do a general system NPS.

Remember that the user does not understand the interface and will give you invalid answers. By the way, if you are asking the wrong questions on any questionnaire, your answers will always be bad and it is not the interviewee’s fault.

To get rid of this, always set KPIs for your analysis before taking a quiz. Eg, I want to know if users find the “new” button and how many leave the screen without saving. Then you can show 3 or 4 button types and analyze which of these the user identifies as “Save”. Understood?

4 – Test walkthroughs step by step

User tests are done to test the system, not the user. What does that mean?

If you want to test your system you need to let the user find out (or not) the route to the task. When you say a step by step to perform a task on the system, you are invalidating the user’s mental model and the test.

Give more general instructions such as: login, make a purchase, leave only 3 items active. This will cause the user to expose their way of doing it, not to follow YOUR way of doing it.

5 – Do not test

Better known as the eXtreme Go Horse method, the easiest way to make a mistake is not to think that there is a mistake and keep developing/idealizing.

If you have a lot of time to lose and you are not aiming to produce something that is user-friendly, organized and thinking about your evolution… abstract this tip.

This post is for both designers and developers, as the digital product involves many similarities and shared methods.