Task-centered design focuses on REAL, COMPLETE, REPRESENTATIVE tasks.  Traditional requirements analysis looks at ABSTRACT, PARTIAL task elements.

How to evaluate a design without users?  One approach is a cognitive walkthrough.

• Formalized way of imagining people's thoughts and actions when they use an interface for the first time.
• First select a task that the design is intended to support.
• Then try to tell a believable story about each action a user has to take to do the task.  To make the story believable, you have to motivate each of the user's actions, relying on the user's general knowledge and on the prompts and feedback provided by the interface.  If you can't tell a believable story about an action, then you've located a problem with the interface.
• A walkthrough can uncover several kinds of problems.  It can question assumptions about what the users will be thinking.  It can identify controls that may be missing or hard to find.  It can suggest difficulties with labels and prompts.  It can note inadequate feedback.
• Walkthroughs focus most clearly on problems that users will have when they first use an interface, without training.
• The most successful walkthroughs will be done by designers who can create a mental picture of the system users in their actual environments.
• To do a walkthrough, you need four things:
1. You need a description of a prototype of the interface. It doesn't have to be complete, but it should be fairly detailed.  Things like exactly what words are in a menu can make a big difference.
2. You need a task description (for a representative task).
3. You need a complete, written list of the actions needed to complete the task.
4. You need an idea of who the users will be and what kind of experience they'll bring to the job.
• Two common mistakes:
1. Don't merge step 3 into the evaluation process.  The walkthrough should look at the exact sequence, to identify problems users might encounter when following it.
2. The walkthrough does not test real users on the system.  With a walkthrough you can potentially evaluate the interface by imagining the behavior of entire classes of users, not use one unique user.

• The basic idea is to ask users to perform a test task, but also ask them to talk to you while they are working on it.  Ask them to tell you what they are thinking: what they are trying to do, questions that arise as they work, things they read.
• You can make a recording of their comments or just take notes. You should collect the data in such a way that you can tell what they were doing and where their comments fit into the sequence.
• A potential problem area that can be uncovered is a vocabulary problem, in which a word that has a clear, specific meaning to the designers, such as parameter, might not be meaningful at all to the users.
• The thinking-aloud method can be used with a prototype or a rough mock-up or with a working demo, for a single task or a suite of tasks.
• Some tips:
• Tell the user that you are not interested in their secret thoughts, but only what they are thinking about their task.
• Make clear that it is the system, not the user, that is being tested, so if they have trouble it's the system's problem, not theirs.
• Since you will be making a recording (of some type) of the session, you should make clear to the user that their privacy will be protected.
• You should prompt the user to keep up the flow of comments, and provide help when necessary (but work out a policy for this that avoids distorting your results).  Your prompts should be general, such as "Tell me what you are thinking" or "Keep talking."  Bad choices might be "What do you think these prompts about xxx mean?" or "Why did you do that?"
• You are better off collecting the comments that people offer spontaneously than in prodding them to tell you about things you are interested in (avoids bias, research shows that people will make up an answer to any question you ask, whether or not they have any basis for the answer),.
• You may also want to tell users that you want them to tell you the questions that arise as they work, but that you won't answer them (at least not at that point in time).
• You should summarize your information by creating a list of all the difficulties users encountered.  For each error and difficulty you saw, you'll need to make a judgment of how important it is and how difficult it would be to fix.  Consider the cost of the problem to users (in time) and what proportion of users you can expect to have similar trouble.