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 turn and I want to give you some rules for how to code the raw data into neat 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 needs 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 cart 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's 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 over-generalization that loses the essence of what the user is trying to say. It abstracts too much. You've lost information when you've expressed it that way. A better 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 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, needs statements are as specific as the raw data. Coding rule two is to express needs without implying a particular design concept. So let's just take that same statement, which was 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. Well, you could write that you could cleverly devices a solution for that and say the cart has a strap for retaining long objects. The problem with that is that you're now focused on the solution to the design problem not to the definition of the design problem. We're going to get to solving the design problem next. But for now, what you're trying to do is accurately characterize the problem. And leave open for the designer, for you or the other designers, as much latitude as possible for finding a solution that will close the gap. As soon as you write that it has straps on it, you've overly constrained the problem. So it's much better to express that need as the cart can transport a longish object like a collapsible chair. So that expresses the need in terms of what the artifact has to do, not in terms of how an artifact might do it. So coding rule two is always express the needs without implying a design concept. That is in terms that are neutral or independent of a solution that you might eventually device. Those are the two main rules, but there are some other conventions that I think make it easier to work with the statements of need. So here are two conventions that I think are useful. One is that you can express the needs as an attribute of the artifact to be designed. And this is kind of a strange convention, as it sounds a little weird. So, instead of saying bags of groceries are stowed securely, you're going to say, the cart stows bags of groceries securely. So, the only difference is that in one case it's expressed passively as a passive property of what happens to the bags. And in the other case, in this case the preferred case, the statement is an attribute of the cart. That is, the card has the property or the quality that it stows bags of groceries securely. This just makes manipulating, editing, and interpreting the statements easier, because they're all expressed in a similar way. And it also adheres to this definition that customer needs or user needs are qualities or characteristics of the artifact that if addressed will close the gap in the user experience. The second coding convention is a little bit picky, but I think it's valuable. And it is that you want to avoid the words must and should. So it's very tempting to write statements like, the cart must navigate big curbs or the cart should navigate big curbs. That often reflects what you heard your users tell you. But when you do that you are prematurely establishing the relative importance of different needs and you probably are doing that without careful deliberation. That is, without very carefully considering which needs really are more important than the others. So as a general rule it's better just to write the needs in very neutral language, the cart navigates big curbs. It's also valuable to arrange needs hierarchically. I talked about this when I talked about some general characteristics of needs. But as a general rule, you're going to end up with somewhere between 30 and 400 user needs. It makes it much easier to digest and use the needs if they're clustered by similarity. So if you cluster a group of needs by the similarity of the need that they express, it will often be the case that one of those needs in your cluster is already a good general statement that generalizes the meaning of the other needs. So for instance, this set of needs here are all related to how easy the cart can be used to transport things. And what these more detailed needs here do is they articulate in detailed terms what we mean, or what our users might mean, by what it means for it to be easy to transport stuff. But if you just want to capture the essence of that collection of needs, you can work with this statement in bold that the cart makes transporting stuff a lot easier than just carrying it. As just a definitional matter, we call this need in bold the primary need and we call these needs in regular Roman typeface, the secondary needs. This is simply a way to arrange the needs into clusters with a generalization of the cluster that will now allow you to abstract the higher level or the primary needs that characterize what your artifact needs to do. Now sometimes there isn't a statement of need in the cluster that will serve as a generalization. In which case you can write a new statement that reflects the generalization of the more detailed statements in your cluster. Lastly, it's valuable to flag the latent needs. I talked in some depth about this kind of diagram. And just to remind you I had said that the latent needs were those needs which if addressed would result in delighting the customer, delighting the user, but which if unaddressed would go unnoticed. And I gave the example of a cart providing a temporary tabletop when used in the outdoors. That's an example of a need that for some customers would delight them, but that if missing, they wouldn't notice. And maybe there's a few others that I've noted here that would also qualify as latent needs. In general, latent needs are determined by a subjective judgment of the designer. They're often the result of non-verbal cues that are made by observing passively the user in the use environment. Sometimes you see these latent needs implemented or articulated by so-called lead users. That is, some of your users who are really advanced in their thinking and maybe have already innovated in order to address their own problems. Sometimes they'll actually tell you what the latent needs are that they've addressed in their own innovation. And just as a little convention, I like to use an exclamation point in advance of this statement of need that flags that need as being a latent need. So your end result of those steps is going to be a list of need. These are 50 shown here, although as I indicated in the book you can find a list of all 66. They're organized into clusters, with the primary needs shown in bold, the secondary needs in roman typeface. And then the latent needs, or some of the latent needs are identified with exclamation points. Once you've done this, you have efficiently and concisely created a statement of your understanding of what problem it is you're trying to solve. At this point you'll have a top level statement of the problem. And you'll have a collection of typically between 30 and 400 needs that capture those qualities or characteristics of the artifact that if you can deliver them will result in the closing of the gap for the user. And that's really a goal in defining the designed problem.
