User Analysis - Outline
With the client’s help, identify as many users of the software you are developing as possible, and schedule 15-20 minute interviews with them.
As a team, prepare for each interview. You should have a list of questions, for example, and a specific idea about what you can show them of your existing system. After each interview, you may want to revise the questions – that’s ok.
The questions should ask about things which could lead you to making decisions about the “model” they are using when they would use your system. Don’t ask them questions in the specific jargon of the model. See what the minimalist question might be, which would lead them to talking about that kind of thing generally. Maybe, “Do you think you might spend time searching for what to do next?”
The actual interviews: Interacting with the users the first time:
At least two team members need to be there. Here’s why:
a. In the interview part – before showing them your thing –
One of you asks the questions.
Another person, the observer, records what they say, and also (very importantly) their reactions to the questions. Not in a sneaky way, but things like, “Didn’t say anything when asked how much he’d pay for this, but looked uneasy.” Now, of course, the observer can’t record things that verbosely while writing down what’s happening fast, so you’ll have to make your notes more complete and more legible later.
b. In the demo part:
One of you does a “light explanation,” trying to get them to ask questions. And, asks them questions about preferences or reactions if they aren’t saying much.
The other is, once again, taking notes like crazy.
In-between interviews: After each interview, huddle before the next play, like a football team:
a. Write up that particular interview, in a way you can turn in.
b. Refine the questions, as noted above.
c. Try to get a grip on whether you got good information related to the conceptual model you think users will be using with your system. If you’re not getting anything, change the questions for that reason, too.
Then, build the mental model: Together, figure out the conceptual model and write that up! This should require some brain stretching, because you are abstracting things you heard into very general things you read in the book. I left this part of the assignment as general. I’d like you to use your imaginations. A picture is important, to go with the description.
Finally, figure out what you don’t have which you need in order to create a prototype. This goes into a list in your requirements called “Unknowns, Risks and To-Do’s.” An example might be if, as predicted in the Day 7 lecture, you forgot to ask them about any of the Quality Attributes!
What to post for this
part of the project on your webpage