When not to do your research

Dan Saffer at Adaptive Path has a (somewhat repetitive but) cogent take on research as part of the product development process. In his article Research Is a Method, Not a Methodology he argues against doing research for its own sake.

stop thinking of it as a necessary approach to design and start thinking of it as just a helpful tool. Saying that research is required for every project would be like saying that all projects need wireframes or content analyses, which just isn't the case.

He argues that a good designer ought to be able to get 80% of the way to a good design in many cases and provides a list of situations in which research is necessary. That list basically comes down to times when it's difficult for the designer to put him or herself into the metaphorical shoes of the user, usually because they don't know the subject area, culture, users, product or industry, or because they "need inspiration."

I frankly think that it's a stretch to expect a designer to be able to put him or herself 80% into the shoes of any and all users. (Joel Spolsky warns against the dangers of overconfidence in design here.) But I will agree with the essence of Dan's argument. What many advocates (for anything, really) forget, is that every situation is different. Sometimes people get so religious about a particular method or technique that they lose sight of the real goals of a project. That's what I think Dan was saying and I agree.

As a product manager, I like writing a full product requirements document (PRD), for example, that explains the market, the business model, the target users, various use cases, the goals of the release, and of course the detailed requirements. I like following that discipline because forcing myself to provide all of that context ensures that I've thought through everything before I ask others to start work on the project. And if I am handing the PRD off to a good business analyst and designer, I know that's the kind of perspective they need.

I worked on one project, though, where there was a highly compressed time schedule and no business analyst at all. To move quickly, I hired a designer I'd worked with for many years. I knew he had background in designing products for this market and that we had a good rapport. For that project, I was able to jump straight to writing a functional spec and get the engineers working right away, accelerating our time to market.

Whatever your usual process, it needs to flexibly respond to the needs of the project. Your research or your requirements document (or even your methods for involving users) are means to an end, tools for getting you to the best resulting product, but they are not ends in themselves. Use them as such.