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.
