Why
One of the easiest and highest payoff things I do is usability testing before investing time and money on polished designs or development. Completely separate from QA, from functionality testing, usability tests should help drive a design that makes sense to a stranger who has some distance from the project. Even the simplest usability 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 about 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-through prototypes, 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 (what if tropicana had tested in a limited market?), measure the results, and make informed decisions.

How
It depends on where you are with a project. Usability testing can come in at any stage. I might test sketches of new screen ideas, or an existing completed site that’s under review. Whatever stage the project is in, don’t set up barriers that prevent you from 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?
If you are trying to accomplish x, how do you think you can do that here?
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?
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 live recruit people that are 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. If you start small, prove the value of testing to your team, and step it up when you see where and how more investment in usability testing can pay off.

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–more if they haven’t had an aha moment yet, 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 usability 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*