Wants, Needs, Requirements: Asking the Right Questions in User Research

If a new product needs to be useful, if your customers may use it with joy or even get inspired by your product, you have to know your users’ needs and address them by your product. The company Apple, for example, recognized it some years ago: Thus, it advertised not simply its new MP3 player but an outstanding experience with the immersion into the world of music.

Of course, it is possible in principle, that also some products without user-centered requirement analysis meet the heart of their target group. But such effects can’t be planed and remain randomly. Identifying user needs early in the development process and taking resulting requirements as a starting point for the product development is more promising.

The direct way to capture users’ needs is to speak with users.

But what are the right questions? In our workshops we heard the best questions would be: “How should the product look like?” or “What do you wish?”

But such questions are quite inappropriate to understand users’ needs and to generate real insights for the development process. Why not? Isn’t the user asked about his or her preferences?

Yes, he is, but in a very direct and solution-oriented way. If asked such direct questions about a possible new system the user will name very concrete ideas like “tabs for navigation through the software” or “red buttons”. The problem is, that this kind of requirements aren’t real needs, they only describe possible solutions. Such concrete ideas often arise on the base of already known solutions. They can also be only situational inspirations or reflect an individual taste. If the interviewer shows him satisfied with these answers, the development team will not have any other possibility than to implement all the suggestions. It becomes hard to surprise users with the new product, not to mention that other users may prefer green buttons to red ones.

Obviously, only individual wishes and no real needs are collected by solution-oriented questions. The words “wishes” and “needs” are often used synonymously. But there is a big difference which should be considered during asking questions in user research.

What are wishes?

A wish is, according to Duden, “a desire that someone feels or expresses. Its fulfillment is more hoped for, than tried to achieve by own efforts”. This desire is normally conscious. Wishes focus on concrete material objects, i.e. smart phones, or on abilities, i.e. creativity. That’s why users can express an amount of wishes for a special product like special features or colors. But in contrast to needs wishes are easier to influence. They can be changed, i.e. by advertising, or they fade after better products become known. If a new product reflects only users’ wishes it should not necessarily support them by doing a task or help them to solve a problem. Customers may want to have a product only because of its beauty.

And what are needs?

Needs are settled behind the wishes. They do not focus on objects or abilities but on emotional factors like appreciation as a human, trust or competence.

A need is a desire based on lack. If a person experiences a lack of something, it creates a desire deeply in the subconscious. This desire motivates acting which should eliminate the lack. Different lacks induce varying degrees of acting. According to the famous Maslow’s need pyramid, a physiological need for sleeping or hunger is, for example, much stronger than a need for social communication. In contrast to wishes, needs are unspecific. The same need can be satisfied by a various amount of actions or objects.

How can the difference between wishes and needs help doing a better user research?

If a user is asked about his preferences regarding a special product, he would i.e. name a red confirmation button. If the interviewer does not try to get to the bottom and does not ask about the reasons of that preference, the solution will probably pass the real problem. Open questions about the work flow with the software and the circumstances of the button’s use can reveal the need for safety behind it. Thus, it could be, that the user can’t distinguish the confirmation button between others and clicks often next to it, which once even led to a loss of data. User’s real requirement for the new software is, therefore, not the red button itself, but the design of the confirmation in a way which retains him in control of the system. If this problem isn’t understood the button can be turned into red but located next to other buttons remaining difficult to use. But if a button is designed in a way which excludes the confusion to other buttons it also can stay grey without any problems for the user.

Thus, it is important for the user-centered requirement analysis to focus on the real users’ needs rather than writing a wish list. The user and his environment should be priority in any user research endeavor. You should talk to users about the following topics:

User as a human:

How technophile are users? Which kind of (previous) knowledge do they have in the related area?

Tasks:

Which tasks should the new product support? How are these tasks performed today? What works well and where do problems exist?

Application context:

What does the daily work flow of users or the context, where the new product should be used, look like? When, where, what special events happen?

Important is to gain a deep understanding of your users and their environment with all positive and negative experiences. If necessary, concrete users’ ideas for the new product should be addressed only at the end of the interview. Ask users about their opinion on chances and threats in relation with the new product.

Beside the qualitative interviews, different other methods can be helpful to identify real users’ needs. A really nice approach for the context of interactive systems was developed by Sarah Diefenbach, Eva Lenz and Marc Hassenzahl at the University Volkwang. They differentiated seven groups of needs and designed a card set with need describing terms and sentences from everyday life. Using these cards D-LABS could, for example, support users by naming and describing their most important needs whose satisfaction they expected by a new digital system.

Despite of the importance of verbal methods like qualitative interviews or need cards, they are not sufficient to gain the users’ needs exhaustively. Because of their anchoring in the subconscious, needs are difficult to recognize and to name. That’s why we recommend interviewing users on their working places or in the context of product use. Doing so, it is possible to observe users when solving relevant tasks and to gain deeper insights.

Only if the right questions are asked, and what is heard and what is seen is questioned, true requirements for the new product can be derived. On this base innovative and user-centered products can be developed.