The Problem with ‘Gathering Requirements’

As I was reading this post by UX Legend, Jared Spool, I found myself nodding in agreement hard enough that neck injury seemed like a real possibility. Seriously, the article is a gem. You should go read it now.

The article highlights a problem I see again and again in software projects. The problem is the belief that people inside the company have the all the answers. That they know what needs to be built and requirements gathering is a simply matter of collecting that information.

Spool puts it this way:

“When we’re gathering requirements, we’re saying the team is comprised of two types of people: those who know what we need and those who need to discover it.”

The activity in question is called Research & Development. And we are skipping the “research” part. At least we have gotten more realistic in one way: this department is usually called just Development now.

Sometimes the cause for this rush to requirements is the project sponsor. The person with the idea for the project has “deep knowledge” of the industry and clear idea of what “the market” needs. Sometimes the cause is project management trying to fill out a gant chart. Either way it’s a missed opportunity.

The remedy is to test your hypothesis. “We have a theory about what people want, let’s see what they think.” Find a simple way, using a prototype, screen designs or wireframes to test your theory with actual people who will use it. Any honest attempt at this will teach you something. The design and product will improve.

Think of it this way: You can wait and test your hypothesis in the market with the release of your first version. Or you can accelerate the process, learn more about what your user’s want and incorporate this into your 1.0.

Originally published on the moonsault blog