A common misconception about user research is that it begins after something has been built. But to build something only for it to fail or underperform can be expensive and demoralising.
Modern product and service development has research start before a line of code is written. Understanding the end-users’ needs and constraints, and the wider ecosystem at the start helps to make things useful and appropriate. Regular research also helps to keep a product or service’s development connected to its purpose, and development teams connected with their end users.
As development progresses the focus and outputs of research moves from understanding requirements, context and constraints (formative research) to testing what’s being built. That can be done using a prototype or the live output of a development sprint (summative research), testing with just 5 people can identify up to 80% of a website’s usability issues. The kind of research that’s done also changes.
These are good reasons for starting early and doing ongoing research. But perhaps the less obvious reason is that it’s a really good way to address the questions teams have and informing the decisions they take: should this or that screen come next to keep the flow, will a user “get it” or know what to do next. The alternative can be a bit hit and miss.