Term "Requirement Gathering" in UX - A misnomer?

Question

Having spend some good time in the Interaction design domain, I have started to think that the term "Requirement Gathering" is somewhat a misnomer and conveys a incorrect image of the process. Is there some agreement? Hear me out -

1) Term "Gathering" suggests that the requirements are already existing, and one just needs to collect them through some means. In most cases, this does not hold true. Product requirements are not gathered, but are formulated based on various sources of information - which could be user interviews, stakeholder views, business goals, market/user/domain research etc.

2) A good product is not built on a document of collected requirements but is rather a hypothesis that one builds and tests. This hypothesis is much more comprehensive and could aim to plant an "USP" which no requirement may define or want explicitly.

So given this line of thought - does it make sense to think that "Requirement Gathering" does not convey the picture the process is about - or am I just the one here?

Answer 1

At an abstract high level, Requirement Gathering still works, i.e. it doesn't specify how you will gather/discover the requirements nor the process.

However, I agree with you that it does not exactly match what we do. I doubt we can come up with an alternative which will go on to become an UX industry terminology.

Answer 2

It is quite accurate description of a process of collecting the things that are needed:

requirement (n.):

"things required, a need"

gathering (n.):

"an assembly of people, act of coming together,"

gather (v.)

"unite, agree, assemble; gather, collect, store up"

I don't think hypothesis formulation comes anywhere close to convey the true purpose of this activity. UX is advocating the use of scientific method in software development (or other areas). But scientists are first formulating hypotheses and then asking for grants, whereas the UX designers have a mandate to contribute to the business case of an existing project / survival of the organization that is paying their salary.

And if you don't work for a particular project, then you don't need to use any of the names of stages of a software development process.

Wikipedia decided to call it Requirements elicitation though, if that is a better name..

Answer 3

Term "Gathering" suggests that the requirements are already existing, and one just needs to collect them through some means.

I guess user/product requirements also already exist, in that there are several possible solutions to meet what the user's expectations are, and you just need to collect them through some means.

A good product is not built on a document of collected requirements but is rather a hypothesis that one builds and tests.

You still have to document those requirements, the hypotheses, and the test results to continually improve the product. Your view that the hypotheses are comprehensive probably points to the fact that you are comparing it to business requirements analysis and not user requirements analysis.

So given this line of thought - does it make sense to think that "Requirement Gathering" does not convey the picture the process is about - or am I just the one here?

There's not that much point dwelling on the terminology, because the actual approach and thinking process is much more important. As I mentioned in my comments, user requirements still need to be gathered, much in the same way that technical and business requirements help to define and shape the product.

Answer 4

Simple answer: No.

Longer answer:

The "Requirements Gathering" stage is not about formulating a solution. It is about gathering together the requirements that any proposed solution must satisfy in order to be considered successful. It's like finding out what kinds of food your friends prefer before you look for a restaurant to book.

You can then use these requirements to build your hypothesis but the hypothesis is not a direct product of the requirements gathering.

Answer 5

TL;DR: a UX process should include both needs discovery and requirements gathering

Question is possibly a bit leading in that assumes some particular UX process and terminology. The following two questions are a razor that may help crystallise differences in activities:

Q. UX is about discovering users needs and satisfying them. Is this the same as "Requirements Gathering"?

A. No, solving these needs could be approached in different ways. The definition of the solution does not exist 'to be gathered'.

Q. during an UX exercise come across some regulatory, technical or external constraints that affect the user. Can you ignore these requirements and deliver a successful UX?

A. No, failure to meet a constraint will leave unsatisfied users.

Thus: If working through the UX process and requirements must be satified then you're obligated to make sure that they successfully handled. But solving a need can have a different hypothesis applied.