User Research - Needs/Wants and solving a problem

If you are going to start a new project from scratch and are going to do user interviews, how do you go about balancing the wants/needs from a user as well as solving a problem? From what I understand you interview users to learn what their needs/wants are so you can design for them. But you always have to solve a problem as well too right? Or are their cases where it might be learning what needs/wants is enough and there isn’t a problem to solve? Also I am talking as someone who wants to create a personal project for my portfolio and not a “real life” scenario if that helps.

I think it differs on what kind of project you are working. But in my experience mostly You begin open and slowly narrow it down. This gives the opportunity to learn about things you haven’t thought about before. Also it gives people time to feel comfortable and tell what is on their mind first.

So the interview starts with an intro of who you are, you set expectations, no answers are wrong, etc. Then you ask them to tell a bit about themself. Perhaps you have some specifics you care about you can ask…

Then a super broad overview of the problem/topic you care about. Ask open questions, not 'Do you want X to solve Y, but more “How do you deal with X?”.

Then after a couple of those questions, you present your solutions, still rather broad, ask feedback on that, and only then you might go into a specific moodboard/wireframe/design/whatever to ask specific questions.

Also I like to end with them rating your solution on a scale of 1 to 10. Sometimes people sound negative, and end up giving an 8. Follow up question then is, “How can we make it a 10?”.

Than you thank them for your time. Bye!

1 Like

There’s always a service you’re providing at the core of every project, otherwise known as your Value Proposition. It might not always be solving a specific problem for a specific type of person: generally speaking most products solve different problems for different people, but you’re always aiming to deliver some kind of core value for your user, something that gives you an edge over other options.
How you should conduct your user interview depends on whether or not you’ve decided on what that edge should be. If you’re making, say, a theoretical food ordering app, your edge might be how fast it is to place an order, or how much customization you have over your food, or speed of delivery, or accessibility for visually impaired users.
If you don’t know what you want to do to set yourself apart yet, I’d focus on making interview questions that find Key Features. Key Features are the make-or-break topics of user wants: for example if you’re getting a new computer on a budget and you commute to work often, your key features might be affordability, durability, and portability. Look for How, When, and Where users want to use your product, and more importantly look for when similar products they use fail them: for example, food ordering apps being hard to use while walking back home from work.
You don’t want to try and fill every user want and need you discover from the interviews, some of those wants are likely going to contradict each other. Look at the results and find some user frustrations, otherwise known as pain points, that you have an idea on how to address. From that point, you can decide on the edge, the big selling point your idea has over others for your target audience.

I find that it’s best to hold a back-and-forth conversation for user interviews to get started. Walking through their experiences and taking thorough notes helps to ensure that you get insightful, in-depth stories and information to work with.

I hope this helps!