Usability testing is the gristle and fat of software development. The steak - juicy, sizzling, meaty - comes from the interface design, the programming and development, and the build. But when those things are finished and the project seems done, it really ain't done.

If you're into itterative user-centered design, agile development, or any other process that shortens the distance between the those who build software, and those for whom software is built, you're intimately familiar with this problem: formal requirements documentation processes are generally eschewed, and in their purest form agile development methodologies skip over the "design" portion of the software development process. There is problem - there is solution. It isn't always a one-to-one relationship, though. Sometimes there are many possible solutions to the same problem. And so, when the development team wants to "get agile", their process involves picking a solution - whichever one seems right and feasible - and building it. No user testing, no contextual inquiry, no design. Just build the thing, and see if it solves the problem.

How then to determine if the problem is, indeed solved? Emprically, I've always felt that the answer is to test the solution with actual end-users. But typically, in agile development, a representative of the customer is asked to review the solution, and approve it. In the development environment in which I work, however, this doesn't seem to be quite the right answer. Clients hire me to figure out what works and to get it built. They don't hire me to ask them to decide whether or not the solution fits.

And really, why ask someone to sit in and pretend that they are the end user, when the real deal is so easy to find? (Don't know where to look? Look at your customers. Look at your employees. If you don't have any of those, chances are good that the usability of your website is only part of the problem.)

The difficulty I've faced is getting usability testing, with real end-users, integrated into an agile development environment. It's a reasonable problem to have: the timelines are short, the cycles are fast, and in our agency model there aren't an unlimited number of cycles in which to deal with the usability testing results. But I've found a more pertinent and disturbing trend: developers/programmers who don't want to test because the sense - fear, perhaps - that the results will undo their hard work. Agile development is supposed to be big on "tearing down" past work if it turns out to solve the problem. But when budgets are constrained, people tend to look for the easiest validation they can get that the problem is solved - that the feature is done, built, finished.

But if the testing ain't done, it ain't done.

Usability testing validates whether or not the feature built addresses the problem it's meant to address. Structured as a "fit criteria" (which, in requirements development, defines the criteria by which a piece of software will be judged in determining whether or not it fits the requirements), usability testing provides the best kind of validation: Does it work, in the environment in which it's intended to work, being used by the people who will have to use it?

Absent usability testing, I think any product delivered to its audience is being delivered poorly, lacking in empathy for the user's needs and respect for their rights. So much software is so oppressive in it's lumbering, clumsy implementation. Software that technically works, in that it is possible - however difficult - to achieve what it's meant to achieve. The question is whether or not it works well.

When it's done right, everyone is happier: clients are delighted, developers are proud of their work, the UX guys feel good about the process, and the final product actually helps people in their daily lives.

And only then is it done.