When it’s time to start a big project like a new product build or a UX overhaul, one of the first steps for many organizations is project approval. How much will it cost? How long will it take? Sometimes you have to answer these questions before you can spend the first penny.

Teams get a development quote, feel the sticker shock, and start whittling. What nice-to-haves can we omit?

Even organizations that use Agile processes can be fooled into an expectation of certainty. And for myriad reasons some development teams feed into it too: maybe they need the project, maybe they like to be the one you can trust to handle the problem.

As a UX team, we know one thing for certain: user input can change plans. And that’s a good thing. Sometimes, you might learn that you need to do more than you thought. But often times, you’ll learn that you can focus, and do less. By catching issues in the design phase, you can avoid the cost of rework.

But once a development team has committed to a particular cost for a particular scope, user input can become risky. Some teams will push back on it simply because changes in plans introduce uncertainty.

The lesson: be careful how and when you lock in development scope. A plan that allows you to learn from users and refine your path can help you save significantly in the long run.

User interviews prior to design and development are a great way to better understand users’ needs and pain points. Beyond interviews, there are several other valuable research methods. We discuss choosing the right research method in a previous blog post.