A common misconception about user research is that it begins after something has been built, but who wants to build something that fails or underperforms?
Product and service development might usefully start research before a line of code is written. Understanding the end-users’ needs and constraints, and the wider ecosystem at the outset helps to make things useful and useable. Regular research also helps to connect a product or service’s development with its purpose, and teams with the end user.
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.