What should we do when our designs can’t validate our assumptions?
Imagine this, you have done various kinds of researches: conducting interviews, spreading surveys, or doing field research. From the results of the research, you managed to get a variety of initial assumptions, after that you started to create a design to answer the assumptions. After the design is complete, you begin to validate the design, and you use a variety of methods (usability testing, napkin tests, etc.).
Suddenly, you realized something,
Your design didn’t answer the assumptions
What went wrong?
When you run a company with user-oriented products, research and validation is very important. Research is important to find out what the user wants (user needs), so we can design the UI to overcome the issues faced by the user. After designing, we can’t directly apply the design to the product. There needs to be more validation from the user, to prove that the design that has been created answers all of their problems.
Sometimes the design that was created didn’t answers the previous assumptions, because of inaccurate research methods or the user targets / persona that didn’t represent the purpose of the product. These can be several factors that cause these problems.
What you can do?
1. Review the research that has been done
Before the PRD (Product Requirements Document) is created, the product team and the research team must do a research to find out the user’s needs. You can repeat the research that has been done before. There is nothing wrong with that, and we know all that research methods are based on trial and error. Instead of using only one method, you can combine various methods to collect the desired data.
For example, you want to find out why user login ratings have dropped over the past month.
You can use analytics to find out how much user degradation has occurred, which locations are causing user flow to be blocked. Plus, you can interview them to find out their behavior when they log in. By combining more than one method it makes analysis easier and more direct.
2. Align the results with the goals of creating features
After receiving the data, you can make assumptions from the data. We can take an example from the login case: after analysis, the assumption is that users are having trouble finding the login button on the page.
After the assumptions are outlined, the product team creates features to resolve the issue. For example: The login button must be made directly below “input email and password”, and use a rounded shape with a striking color for the button.
The purpose of the feature created is to overcome the user’s problem when logging in, and it’s aligned with the assumptions that have been made.
3. Is the persona that was created is correct?
Sometimes the designs that have been made can answer the problems that have been previously defined. However, when validating the design we make a mistake in determining the target / person. Participants who are color blind will not see the color of the button, they only see the words “LOGIN / Enter” on the button. If the color of writing can’t be seen, then they can’t enter the application. Then validation using the Login button with a striking color can’t answer the assumptions that have been made.
For this reason, it’s important to define the persona first, so that the design created can answer the user’s problem.
4. Re-validate
After all the steps above have been done, re-validate.
Sometimes users have their own habits, and it’s difficult to predict. Maybe what they do is a habit that they do often, and according to them that is the best way to achieve goals. Always ask “Why, why, and why?”
If necessary, repeat the process to get maximum results.
