Database Reference
In-Depth Information
and you can send it into early retirement. Just be careful about reaching this conclusion
prematurely—Users A, B, and C might sail past an issue that flummoxes User D. If there's any
doubt, keep the task and gather more data.
You've identified a problem but aren't prepared to fix it yet. Paper prototyping allows you to
make many improvements to the interface in a short time, but sometimes you uncover problems
that require more in-depth thought. If a task reveals an issue that you all agree needs to be fixed,
it's not always necessary to keep banging your head against that particular wall. (However, if you
are still trying to understand the nature of the problem, then you should probably keep the task.)
The task is too unrealistic. If users indicate they'd never do this task, it might not be not worth
keeping. But first reexamine the issues that caused you to create the task. If you had a wrong
assumption about what users needed, drop the task. On the other hand, if your underlying
questions are still valid, perhaps you can fix the task to make it more meaningful to users.
Search WWH ::




Custom Search