What are wants and needs?

UX design is a thing/process that focusses on the wants and needs of the user, their experiences with products, and how those experiences influence the user.

That is the definition I settled and agreed upon in my last blog post. That’s all fine and dandy but it doesn’t give me much to work with mentally too be frank with you. So, in this post I would like to explore this a little more. 

Specifically, I’d like to focus on what the wants and needs of the user could be and before I can look at that I need to define what a user is.

Personally, I define a user as anyone who uses the product. This means for example that someone who drinks out of a carton of milk is a user of that carton of milk. Kind of a weird example but I hope you catch my drift.

Milk drinker

This user might not only drink out of a carton of milk but might also pour milk out of the carton into a mug/glass/cup/etc. This will not stop them from being a user. It will be them using the carton differently. These different types of uses are what I call use cases. “Cases of usage”. There are hundreds of use cases for carton of milk and maybe I’ll go a bit more in depth about use cases in a different post but for now let’s move on.

A user is someone who uses the product, and they use the product for a specific reason. This specific reason, I imagine, would be their wants and needs. But what does a “want” and a “need” mean? These words mean the same thing for me with 1 little difference. A want is not a necessity, and a need is. A need must be fulfilled before a want can be considered. That’s how I look at it personally but also according to the Maslow’s hierarchy of needs theory.

In Maslow’s theory of human motivation, he talks about what drives a person and their continuous survival. He describes 5 different “basic needs”. These being 

  • Physiological (Food, water, rest)
  • Safety
  • Love/Affection
  • Esteem (Self-respect, self-esteem, esteem/respect of others)
  • Self-actualization (doing what one is meant to be doing, “what a man can be, he must be”).

These needs are often show in a pyramid like this one.

Maslow Pyramid


Now I hear you asking what is the point of knowing this really? Am I not talking about UX design anymore? I, in fact, still am. See, in Maslow’s theory he talks about how the basic needs at the top can only become motivators for a person if the needs below it have been, at least mostly, satisfied. Remember how I talked about how a need must be fulfilled before a want can be considered? This is that basically. A want can only be done after needs are (mostly) fulfilled.

Let’s go back to the milk carton example for a bit.

I’m going to take some liberties with this example but bear with me.

Let’s say someone must drink milk to survive. Let’s call this someone Jimmy. Jimmy must drink milk to survive, and he really does not want to go straight to the source (a cow udder). I don’t blame him. But this shows us 2 things already. Jimmy’s NEED is to survive he must drink milk. It also shows us a WANT. Jimmy does not want to suck on a cow udder (please bear with me).

That means he needs some way to transport that milk from the cow’s udder to his mouth somehow. He could use his hands but now comes his next want. Jimmy wants his hands to not touch any milk in the process of him drinking it.

We have a main goal now. 

  • Provide Jimmy with milk.

To reach this main goal we have some conditions attached to it. 

  • Jimmy does not want to be close to the cow’s udders.
  • Jimmy’s wants his hands to stay clean of milk.


So now we are already doing part of the UX design process because Jimmy told us and we listened to what his wants and needs are for drinking milk. He did not tell us about his experiences or how they influenced him, but we will get to that a bit later. Let’s just say that Jimmy has no prior experiences with drinking milk and is therefore not influenced by them. He just popped into existence to consume milk.

Okay so now we can just design him a cup. A regular cup. Whatever image popped into your head that is the cup or if you can’t imagine things use the image below as reference.

A cup. Sort of...

Now comes the following problem. Jimmy lives in an apartment and doesn’t have the capabilities or time to take care of cow. That’s alright since he popped into an existence where we have farmers who can do that and do that on a large scale. They can just fill this cup with milk and bring it to Jimmy. Now the next problem arises not necessarily a problem Jimmy directly experiences but a problem regardless.

This problem being that the person delivering the cup to Jimmy seems to spill a little while traveling to Jimmy resulting in Jimmy not getting the maximum amount of milk in his cup every time. So there now is a new problem that shows us a want which we are going to convert to a need by doing a little retconning. Jimmy’s cup was big enough to hold the exact amount Jimmy needs to survive another day so if the milk gets spilled a little Jimmy needs to rush to get a little more milk somehow.

To avoid this problem, we now need to make it so losing milk during transportation is basically impossible. We can do this closing up the top of the cup. But now it can’t be filled. So, it must be either closed after it has been filled or resealable.

You see where this is going? I hope you do because I’m kind of tired of going on with this example. Basically, this is the process of focusing on the users wants and needs when creating/improving a product.

Now let me show you a method of categorizing these wants and needs of users in a nice little matrix. This method is called the MoSCoW method. With this method you can put their wants and needs in 4 different categories. These categories being

  1. Must haves 
  2. Should haves 
  3. Could haves 
  4. Won’t haves/Will not have (this time)

Must haves are things that are a must (obviously). This means that the created solution will fail if it does not solve anything in this category.

Should haves are a little higher in the pyramid (like the one of Maslow) and should be solved too but Jimmy would probably still survive without them. They get a little lower priority.

Could haves are nice little things that can be added onto the solution. In this categories you would put things that are nice little additions to the end product but won’t be missed if they are left out.

Won’t haves/Will not have (this time) are things that are either completely unnecessary or that would take up too many resources for too little gain. An example of this would be a counter on the side of the cup to show Jimmy how many times he drank from his cup (StatTrak for a cup for those who know :p). It doesn’t really add that much if any value to Jimmy’s experience and would take a lot of work.

Okay, but MoSCoW can be made a bit more visual to help us categorize them easier. One way of doing that is by putting it in a matrix like this one.


MoSCoW Matrix


Nice. Let’s use this matrix to put in what we just learned about our situation. If you want to do it yourself here are all the things in a nice little list.

Main goal: 
  • Provide Jimmy with milk.

Sub goals: 

  • Jimmy does not touch the cow’s udders. 
  • Jimmy’s hands stay clean of milk.
  • Cup must not lose any of its content during transport.
  • Top of cup must be seal-able after being filled.
  • Top of cup must be able to open after being delivered.

Alright, that’s what we shall put into the matrix. You could make them a little shorter and I think I will do so too. Now I’ll just add a little more text here so it might hide the following matrix a bit more for the enthusiastic reader who fills it in themselves. Okay, here is my filled in MoSCoW matrix.


Now with the things important for Jimmy's milk!


Ta da! Now we have actionable things we can focus on in our project to make something so Jimmy can get his milk at his apartment and not die of milk-dehydration.

So, this is part of UX design basically. Slightly more explained. I think in my next post about UX design I will explore what the user’s experiences mean with hopefully no more milk carton examples.

Thank you for reading and stay tuned ^_^



Comments

Popular posts from this blog

Design Guidelines. What, Why, How

Design principles, what and how.

I'm back!