And that's the problem. We're a relatively small team working to meet rapidly evolving customer expectations. We don't have the resources to take on that kind of operation (or the cash to outsource it!).

It makes more sense for us to do many small, qualitative usability tests leading to an iterative design process in which we get it 95% right in a short timespan than to do one huge quantitative test in which we end up with a product that is 99% right but obsolete

Actually, you haven't got it quite right. Because your first question "ask the users what they want ..." doesn't get you the right answer or a useful answer.

If you are going to do this the full tried and tested way that car manufacturers etc have been using for years, then you do this.

You first make a list of outcomes - these are the possible end point of what ever set of actions that the user will take. For instance let's take searching in a forum. The most obvious out come is that you get a list of results from entering a word and pressing the search button. But ...

An end result could be that they get every post that includes the phrase "fat lady sings" in it.

On the other hand, it could be that it includes every post that has the three words fat and lady and sings in it, but not necessarily as a phrase.

Added to that it could be that you want all above, but only posts that haven't been read by the poster.

So there are a lot of possible combinations and it is very quickly evident that your possible outcomes may or may not be achieved by your text field and search button.

But what outcomes do people actually want? The average geek will always demand a search box that allows every possible permutation of searching from a multitude of check boxes, drop downs etc. But is this reasonable? If you designed a car where there were a multitude of ways to start the car depending on where you wanted to go, how many people would actually want to drive it?

Product research, therefore, always starts with not just listing possible outcomes, but then putting those to research (focus groups, random members of the public, etc) to find which outcomes the user is really interested in, what will be useful to them.

Now you have your little set of outcomes, you can put together your paper proposals - normally several - and test these to see which one or more gets the thumbs up.

From these results, you then put together your first prototypes. These are possibly not actual working designs, but cheats that look like they are working, because at this stage you are not actually trying to solve the technical problems. In the case of software, you would also be creating several user manuals for each solution, and/or tutorials etc. This is because a great solutions is a bad solution if it is not easy to explain! Both elements have to be worked through and tested.

Having done that and boiled everything down to one solution, now you go and build it.

Years ago I was involved in the testing of a snack called Moments. We were making test TV commercials by basically filming story boards and putting a quick voice over on it. Believe it or not, this was at the very beginning of the design process. The company first came up with how the product would be advertised, fulfilling through advertising the end users expectation of a snack - how they would use it, what they wanted out of it, when they would use it etc. They came up with 5 possible snacks and five different advertising approaches for each snack. These then went into testing.

Two years later, with all the results analysed, Walkers gave the results to their snack boys who designed the snack that fitted the best advertising.

Gold Blend coffee was done in the same way. The famous couple falling in love etc was designed years before the coffee was even produced.

Now, I wouldn't spend that long on designing a search button, but you can see the value of such a seemingly tortuous procedure!

On a more constructive note, please also involve those with visual and agility difficulties in the early design process. User-selected large fonts can cause buttons to be off-screen making it more difficult for the user to find an important button - like "Continue>".

Will be cool to see a follow up to this afterwards to see if we can measure the difference it makes.