UX Research: Why is it important?

The UX process can be split into four phases of Discover, Define, Develop and Deliver. UX research is part of the Discover phase that precedes all others. It is fair to say that the rest of the process is built upon what is discovered from this research, therefore deeming it to be incredibly important. However, in practise this phase is often overlooked due to budget, time constraints and misunderstanding. UX research learns us about two crucial parties in our project. They are the user of our product and our competition.

Learning about the competition and the user lets us know why the product is needed and how it will be used, ultimately telling us what the product should be. Without knowing this information we stand to waste time, resource and money and may end up with a product that has no use. Although a business may invest less time in the Discover phase due to their own financial and time constraints, it is the duty of a UX designer to illustrate how scrapping research can result in exactly what they hope to avoid.

Ultimately UX research is justified because it allows us to:

• Solve a problem that we know exists.
• Create a product that is needed.
• Know where best to spend time and resource on the project.
• Build a product that is different to our competitors’.

It is important to research both our competition and our users because it gives us a complete picture of the product. Researching competition allows us to know if our problem is already solved, or whether ours would fulfil a different need, could fit a different niche or incorporate more advanced features that would make it superior. Researching our users allows us to know how and why the product would be used, and what concerns the people who will ultimately be the key to a successful product.

So what can happen when UX research is not carried out? A business approaches an agency with a product already in mind. This product however is not based on any research. The agency begins working on the product with clear requirements from the business. However someway through the project the developers have a question about one of the features. The business decides that the best way to answer the question will be to have users interacting with the feature. Alarmingly the intended users do not interact with the product as the business imagined. The requirements are changed. Work is redone or corrected retrospectively. The project drags on, more money is spent and milestones over time are not met. Scope creeps, and users and business become impatient.

These are all project hurdles that I have come across in my career of being a Software Developer that really show me the usefulness of UX research and following the process explicitly. Needing to retrofit is exponentially more difficult as the project proceeds. Figuring details early and planning for them is always better. That is not to say that things won’t change, however it is certainly better to leave less room for error where possible.