In this course, I use the term user needs to refer to those characteristics or qualities, which if present in an artifact, will result in user satisfaction or the closing of the gap in the user experience. In other words, these are the things that the user wants the artifact to have in order to be satisfied. I cited the example from the car rental experience of the user need that the car rental service provides a vehicle that's consistent with the customer's preferred brand associations. That's an example of a user need. User needs in design are usually captured as verbal statements, and usually in a list. For almost any artifact you as the designer can identify at least 30 distinct user needs and there may be as many as 400 user needs. Here is a list of 66 user needs for an urban cart. And I want to use this example to illustrate a few key points about user needs. The first point I want to make is that not all users will value every user need. For instance, there's a user need here at the current work with, with the user's bicycle. Those who don't use bicycles are not going to care at all about that user need. The, the list of user needs is merely meant to capture all of the relevant issues or variables that relate to the satisfaction of the user with the artifact. The second point I wanted to make about the user needs is that two user needs can, in fact, be contradictory. So, for instance, there's a need on, on the list of cart needs that says the user wants the device to be able to transfort, transport all of his or her stuff in one trip. On the other hand, there's also a need that says that the cart can be easily lifted, moved while loaded. Depending on the solution that's devised, those two needs could be contradictory. The list of needs don't resolve the design challenges. Rather, that list is the designer's attempt to capture everything that might be important. The resolution of the contradictions, the establishment of the relative importance. Those will be, that will be done later. Third. Not all needs are equally important. So, for instance, one of the needs articulated on this list is that the cart be able to handle rough, rough urban terrain. But there's another need that says. The cart should be able to or that the user wants the cart to be able to handle, or store and transport a cooler, a picnic cooler. Well, for most users, it would be more important that the cart handle rough urban terrain than that it handle a picnic cooler. A cart that handled a picnic cooler well but didn't navigate rough urban terrain would likely be less preferred to one that handled rough urban terrain but that couldn't handle a picnic cooler. Lastly, I want to point out that not all needs are of the same type. And it's useful in thinking about customer needs, to divide them into different categories. There's a, a nice framework that was pioneered by the Japanese quality guru, Kano, that helps to think about different types of user needs. The Kano framework divides user needs into four categories based on the way the user responds in terms of the user's satisfaction, to either the presence or the absence of, of the satisfaction of the needs in the product. So. In the Kano framework, the horizontal dimension is the extent to which the need is addressed in the product, from addressed completely to addressed not at all. And the vertical dimension in the Kano Framework is the user's satisfaction, from the user completely satisfied, that is, the user, user delighted, to down bel, down at the bottom. User completely dissatisfied, that is having intense dissatisfaction. And within the Kano framework you could think about how the user's satisfaction varies with respect to the extent to which you deliver on the need. So for instance, in the first category are needs that are in the don't, are don't care needs. And I cited earlier the example of a user who doesn't have a bicycle. That user doesn't care whether the cart can be used with a bicycle. Similarly, a, a user who never expects to transport a baby with the cart will, will not care at all whether the cart can be used as a baby jogger. So those are don't care needs. The second category of need within the Kano framework are the linear needs. Linear needs are those for which a little bit better addressing of the need will result in a little more satisfaction., and vice versa. So for instance. Cost or affordability is a standard kind of linear need meaning if the device costs $twenty I'm, I'm half as happy as if it costs $ten There's very linear response within certain ranges for, to price and affordability. Similarly you might imagine that the time required to deploy the cart might be a linear need meaning if it takes a little longer I'm a little less happy, if it goes a little faster I'm a little happier. Those are linear needs. The third category are the must-haves, And these are the needs, which if, if not addressed in the product invoke intense dissatisfaction. Whereas if you do them extremely well in the product, your user basically doesn't notice, that is you don't get any real credit for delighting the user, when you really satisfy the need. So for instance, At the, whether or not the cart rests stable, I.e., rest in a stable configuration when parked, That's kind of a must have. If you don't do it the user is going to be really unhappy if the cart either falls over or rolls away, the user is going to be really unhappy. On the other hand if you do a fantastic job of enhancing the stability of the cart when it's in it's resting position, it's not clear that the user going to care much or notice much. So that's at category three the must have. The fourth category is maybe the most important and these are called the latent needs. These are the needs which if unaddressed will not be noticed by the user, in effect the user won't notice what he or she was missing. On the other hand, if you recognize the need, are able to articulate the need and are able to deliver a solution concept that addresses that need, the user is delighted. So for instance, Maybe your user, maybe your cart could be designed in a way that it could serve as a portable tabletop so that when it's parked, there's a horizontal surface that you could use to place a beverage on or to write a note or maybe even to, to sit down and, and drink a cup of coffee next to a chair. Having a cart that becomes a portable tabletop is probably not a need that most users would articulate. But it's possible that as a designer, if you understand that need, if you observe that need, if you believe that need is latent in the user population and you are able to deliver on it, it can result in a great deal of satisfaction. Let me also say that most user needs as lists of user needs can be usefully organized in a hierarchy. When you go out and gather your user needs through observation, interviews, and other techniques, you'll end up with needs that are often expressed at varying levels of detail. So for instance. You might express a need that the cart makes transporting stuff easier than just carrying it. That's a very general kind of need, it basically says the cart makes it easy to transport your stuff, makes it more worth, makes it worthwhile using the cart instead of just carrying it in the first place. But there's lots of nuance to that need. And your customers are likely to also talk about things like, the cart can be conveniently lifted and moved when loaded. Or. The cart can be unloaded quickly or the cart, cart can be deployed in seconds. Those are all aspects of the user experience, which would contribute to the overarching need that the cart makes transporting your stuff easier than just carrying it. So when you organize your needs, It's useful to sort them into clusters with one of the user needs often emerging as more general than the others. And the others subordinate or secondary to that primary more abstract need. Finally, let me note that there are analytical techniques and empirical methods for assessing the importance of user needs. For arranging those needs into hierarchies. For discerning which ones of the needs are latent versus must-haves versus linear versus don't-cares. But by and large in design, These, these frameworks are implied subjectively through the judgement of, of the designer. And so, in most cases, the designer will be the one, based on observations of users, discussions with users and maybe some informal surveying. Who will identify which of those user needs are most important. Which are less important, which are latent. Which are must-haves and so forth.
