I got excited by the name, but the details are disappointing.
"In their opinion, iterative rapid prototyping is like trial-and-error design and may never lead to an optimal solution if too many stakeholders are involved and too many opinions influence the design process. Instead, their usage-centered design approach is based upon abstract models to describe users, tasks and content."
Yikes! Supposing that rapid prototyping fails because of too many "stakeholders" and "opinions" misses the point. The role of a designer is to manage the process which leads to a design. If a designer doesn't sufficiently manage input, ANY process will fail.
Abstracting the user, tasks, etc, is all well and good for providing a stable platform for design, but it turns the iterative design process into a waterfall process. It smacks of designer equivalent of "Why does the spec keep changing?"
It also says that this allows the designer to design for tasks, not expectation. However how can you be sure your design fits the task without trialling it?
"In their opinion, iterative rapid prototyping is like trial-and-error design and may never lead to an optimal solution if too many stakeholders are involved and too many opinions influence the design process. Instead, their usage-centered design approach is based upon abstract models to describe users, tasks and content."
Yikes! Supposing that rapid prototyping fails because of too many "stakeholders" and "opinions" misses the point. The role of a designer is to manage the process which leads to a design. If a designer doesn't sufficiently manage input, ANY process will fail.
Abstracting the user, tasks, etc, is all well and good for providing a stable platform for design, but it turns the iterative design process into a waterfall process. It smacks of designer equivalent of "Why does the spec keep changing?"
It also says that this allows the designer to design for tasks, not expectation. However how can you be sure your design fits the task without trialling it?