Why
One of the easiest and highest payoff things I do to save money on a design project is user test it before investing time and money on polished designs or development. Completely separate from QA, from functionality testing, user tests should help drive a design that makes sense to a stranger who has some distance from the project. Even the simplest user test will give you surprising and valuable feedback that you can react to before you’ve spent any money on development.

The great thing about using actual test data is that it saves you, your team, your client, from having debates around educated guesses. Teams full of sincere people with good intentions can sink a lot of time into controversy over the right answer, and there’s an easier, more effective way. The good news is, we don’t have to guess, we don’t have to be in the minds of our users (and as hard as we try, we never truly can be), and we don’t have to bet the project budget on our ability to predict the response. Test paper, test click-throughs, A/B test alternatives you actually build out. Think about the Tropicana redesign debacle. When you’re taking a risk, make it a calculated one, match it to your risk tolerance (test in a limited market?), measure the results, and make informed decisions.

How
It depends on where you are with a project. It can come in at any stage. Sketches of new screen ideas, or an existing completed site that’s under review. Whatever stage you’re at, don’t set up barriers that prevent you from just doing it. I sometimes set a paper prototype in front of someone and ask things like:

What are you looking at right now? What is this telling you?
What can you do? What’s clickable? What’s a field?
What would happen if you clicked that?
What if you wanted to go back?
What else might you want to know right now for this to be useful?
If you wanted to x, how would you try to do that?
What would this be worth to you? You’d be pissed if you paid money for this? Great! Why?

Yes, you can go deeper. You can be more targeted. You can professionally recruit people to test on, and those people can be representative of your audience and in the best headspace to evaluate your work. Those are all good things. But if you’re not able to do all that, don’t let it stop you from taking a simpler approach, and let the process snowball into more and better testing once people get a taste and want more.

What if there’s no money?
For some reason, people tend to worry that they don’t have the budget to test. At the risk of sounding like an infomercial, you can’t afford NOT to test. I’m shameless about it. I’ve been known to bribe friends with a round of beers to look at a paper prototype and give me some feedback. It helps me because I’m armed with better information, but the downside to testing on the sly is that clients don’t get to be part of the process, and therefore they don’t value it. I like clients to at least observe one real user test–more if they haven’t had an Aha moment with it yet–with someone they respect, so they internalize the benefit. It’s not just some abstract thing that has nothing to do with them and their goals.

A lot depends on a relationship starting out right. I would make sure to be clear about your intent to test things at the beginning of a project, and remove obstacles. If they’re worried it takes too long and is too expensive, focus on getting them to experience quick cheap user testing early on, so they learn to love it and come to rely on it. If they value their metrics, connect your test plans to the metrics they care about testing. Design qualitative tests around quantitative metrics that have them concerned. One thing will lead to another, and everyone will have learned something valuable. *steps off soapbox*