The best way to articulate what part of the problem the software needs to address is not self-evident. I think keeping seperate notions of “this is what is wrong” and “this is what we’re going to solve with the software” is valuable.

> 1. Specify that goal X is achievable in Y time.
> 2. Eliminate goal X and replace it with goal Y.
> 3. Market the product to a different user group.
> 4. Users must be trained to use the application.

(1) is most likely a requirement, (3) is a strategic decision that impacts requirements, and (4) is almost certainly a design choice. (2) depends a lot on the context.

There is ideation at each stage.

Prioritizing the right problems to solve, selecting the articulation of the requirement (sometimes the solution isn’t even in the software), and designing the software are ALL ideation activities.

To focus on “requirements design” – there are several different ways to address any particular problem. Using your example of first time users failing to use the software effectively, there are multiple ways to address the problem:

1. Specify that goal X is achievable in Y time.
2. Eliminate goal X and replace it with goal Y.
3. Market the product to a different user group.
4. Users must be trained to use the application.

Each of these “requirement designs” would drive different software design decisions.

On another point – I would be careful of using “95% of users”, as that either introduces a burdensome cost or a sense of false precision. There is significant effort in actually assuring that X% of users can do anything – and you would actually have to state “with Y% degree of confidence” for the requirement to be unambiguous. This is an expensive process, and misleading to anyone who hasn’t studied statistics. It would be better as a general rule, IMHO, to simply say “customers with skills a,b,c…” – and then evaluate subjectively based on anecdotal data. For critical usability concerns (can the guy in the silo enter the launch codes) – spend the money, but clarify the requirement first.

Thanks again for your comments – they are frequent, provoking and helpful, and very appreciated!

Just to try to bring some clarity to some of the terms: I would not portray things in terms of market need and product capability. Instead, I would go from:

problem -> requirement -> design

Example:

problem – 20% of customers quit using the product after trying it the first time, expressing frustration about how difficult it is to use.
requirement – 95% of customers with skills a, b, and c should be able to accomplish goal x in y amount of time using the product the first time.
design – present an optional wizard-based user interface for first-time users.

Ideally, the requirement does nothing more than state a pass-fail measurement expressing whether the product has solved the problem to a sufficient degree. Any specification of “product capability” beyond this measurement is, as you state, design. I don’t see any reason to call such a further specification a “requirement”.

Furthermore, I don’t see design (whether high or low level) or “product capability” as the purview of the product manager. Architects and user interface designers are by definition the experts on such matters. A single person can be well qualified to play all these roles, but the roles are distinct.