Interpreting User Needs (Design Course 2.6)

Okay, so now you have the raw data. You've got this mountain of notes. What do you do with them? And we're going to take that in in turn. And I want to give you some rules for how to code the the raw data into need statements. As a general rule, you're going to take a

statement that was made by the user or an observation that was made by the user and you're going to code it. and you're going to code it in accordance with a few rules. So here's the first rule. It's really important that your need statements are exactly as specific as the raw data. And let me give you an

example of what I mean by that. Let's just say if we go to the card example that an original statement by the user might be, I like to take my folding chair to the park and it would be nice if I could figure out how to carry it more easily. The problem is that it's

kind of long. Now, basically, the user is reflecting or describing a very specific issue here, which is that he wants to be able to carry his folding chair. His folding chair is a longish oblong object, and he very much wants to know how he could carry that more easily. So what you wouldn't want to do

is to generalize that statement to say the cart handles objects of different sizes as shown here. That's an overgeneralization that loses the essence of what the user was trying to say. It abstracts too much. You've lost information when you've expressed it that way. A better [snorts] way to say it would be the cart can transport a longish object

like a collapsible chair. There's really no reason not to express the need exactly as the user said it in as in as in in language as close to what the user actually said. That's the way you best most effectively communicate what it is you heard from the users to others. So that's coding rule one. Need statements