Why is it important to focus on user needs as opposed to requests?

Question

This question is written with digital product design in mind, but is not exclusively tailored towards digital.

It is pretty accepted that in order to design the 'best' solution to a problem, you need to focus on user needs, problems, and desires instead of reacting to what they request.

So, ideally, you should not react to 'I want the app to do X' and instead you should find out why the user wants the app to do x, and if there are better ways to solve that root problem.

I am looking for solid reasoning, ideally backed up with well-written articles and possibly with relevant examples to support such opinions.

If the above is true, how do you prove it?

Answer 1

Users are bad at asking for what they need and great at asking for what they want.

Anecdotal evidence from my own recent experience:

We have a department that asked for a button that would generate a PDF report about some data. A few months later they asked for the report in the form of a spreadsheet. A few months after that they asked for additional columns to be added. And most recently they asked for a full hierarchy to be shown in this report.

At first the requests seemed reasonable and were easy for our development team to keep up with. But by the end, the report had grown so unwieldy that it took days to revise each time there was a small change, and the query we had to use was so complex there was no way to reasonably render it as a spreadsheet and have it make sense.

It turns out that they didn't need a report at all, but rather a customizable web page that allows them to adjust their queries as needed. They asked for a report because that's what all the other departments were asking for, and that's all they thought we could do.

Users will only ask for what's already inside the box, but UX sometimes has to look outside the box to see if there is a better way.

Answer 2

Here are two examples, one online and one offline

---

1. Train arrivals

• Subway passengers frustrated with waiting for trains routinely ask for more trains on the track. For metropolitan transit agencies globally, this is obviously a very expensive request.

• Analysis of passenger needs reveals that the uncertainty around the wait is as important as the duration of the wait itself. Uncertainty means that passengers find it hard to estimate the impact on their schedule, and what tasks they can do while waiting (drink coffee, buy a newspaper, etc).

• The analysis of needs suggests a different solution, which is not a substitute for more trains but can significantly help calm anxious passengers. Present passengers with a countdown to train arrival, to eliminate wait uncertainty:

  

• This article documents how significant the results are, and also points out that passengers tend to overestimate their wait times when they don't have information. Countdown signage has now been rolled out around in transit stations around the world.

---

2. Displaying product selections

• Consumers will often ask for more choices when shopping, because they believe that more choices lead to a better shopping experience.

• It is well documented that too many choices can lead to an overwhelming decision for consumers, which can result in shopping cart abandonment or a delay in purchasing. See the paradox of choice and the magic number 7, but there is a lot of research available on this effect.

• As a result, despite consumers' desire for more choice, smart commerce sites actually constrain the number of choices presented to the consumer because they recognize that what customers need is less choice and not more.

• For example, Amazon uses product grids and pagination to help avoid the feeling of overwhelming choice for customers. Here's a product result page from Amazon which shows six (close to the magic number 7) choices per screen. Note that no matter how large I resize the browser, the number of columns presented is 3:

  

• Amazon uses a number of different layouts for product results, but the default layouts often deliberately reduce on-screen choices to avoid overwhelming customers.

Answer 3

If you've seen The Simpsons episode "Oh Brother, Where Art Thou," you should remember what happened when Homer's half-brother gave him free reign over designing a car "for the average schmuck." The end result was expensive and looked ridiculous and didn't truly meet the user's needs, even though it had all the features he wanted.

If the company truly wanted to make a car for the average Joe, they would have taken suggestions from multiple users and weighed the benefits that the typical user would derive from them against the cost of implementing them. If you blindly do what your users want you to do, you'll end up with a Homer.

Answer 4

Let's start with an old one from the Ford's founder:

(Although there isn't actually any evidence Ford ever said it. Thanks to user Evil Closet Monkey for the disclaimer.)

The UX Designer View

Why is it important to know why they want what they think they want?:
Simply because as a UX designer you should be the one designing the best solution and in order to do that you should evaluate all the UX variables (affordance, usability, scannability, studies on the subject, etc) and the balance between them. The most of the time the user is unable to do this because they don't know what they want and often neither what they need.

Then your job is to ask them and test them so you can get enough information about those variables to be able to propose one or more solutions which you consider the best.
When a user/client ask for something, that's just the entry door for a process of getting to know those variables.

From Jakob Nielsen: First Rule of Usability? Don't Listen to Users article:

But ultimately, the way to get user data boils down to the basic rules of usability:

• Watch what people actually do.
• Do not believe what people say they do.
• Definitely don't believe what people predict they may do in the future.

Answer 5

There are two issues that make focusing on user requests at face value problematic.

The first is known as

The Einstellung Effect

This is a negative effect of pattern-following on finding optimal solutions:

Einstellung is the development of a mechanized state of mind. Often called a problem solving set, Einstellung refers to a person's predisposition to solve a given problem in a specific manner even though "better" or more appropriate methods of solving the problem exist. The Einstellung effect is the negative effect of previous experience when solving new problems.

If users request a solution to a problem, the chances are it will similar to existing solutions they have experienced, rather than the optimal solution for their particular use-case.

A similar issue can occur when a user encounters a problem, and (by definition) not being an expert in the problem space comes up with a sub-optimal solution/kluge/workaround and asks for this kluge instead of defining the real issue.

This is commonly known as the XY Problem.

The X-Y Problem, as it is sometimes called, is a mental block which leads to enormous amounts of wasted time and energy, both on the part of people asking for help, and on the part of those providing help. It often goes something like this:

• User wants to do X.
• User doesn't know how to do X, but thinks they can fumble their way to a solution if they can just manage to do Y.
• User doesn't know how to do Y either.
• User asks for help with Y.
• Others try to help user with Y, but are confused because Y seems like a strange problem to want to solve.
• After much interaction and wasted time, it finally becomes clear that the user really wants help with X, and that Y wasn't even a suitable solution for X.

The problem occurs when people get their train of thought stuck on one approach and become unable to take a step back. Remaining open to having a new look at the bigger picture, these people might find their way back to X and continue searching for alternative solutions.

this Meta Stackexchange question also discusses the XY Problem.

The way to avoid generating sub-optimal solutions that follow from either the Einstellung Effect or XY Problem is ferret out the root problem or cause behind the prima facie request.

Answer 6

My anecdote: We were bulding a new version of a computerized machine. One requirement was to boot it in 30 seconds. We failed it by orders of magnitude. It created a big outcry. We asked why and heard that they had lost a lot of production time with the last version, because it crashed so often and needed to be rebooted quite frequently. Our new version was a lot more stable, thus eliminating the down time.

Answer 7

As engineers we were given the example of the newly-opened office tower block. It was fitted with 3 lifts. As the tenants filled the building complaints arrived that the office workers were having to wait too long for the lift. Cue expensive consultants to revise the lifts' queuing algorithm. No reduction in complaints. Cue assessment of building an additional lift. No deal. Complaints about waiting too long continue. Eventually a guy offers to cure the problem for a few hundred quid. Cynical, but prepared to take a punt, they give him a go. He fits full length mirrors on 3 sides of the lobby. Complaints drop to zero. The point? - the others were trying to 'get office workers to their desks quicker' as the Users requested. This guy was solving the problem - how to stop people complaining about not getting to their desks quicker. Fitting mirrors let the girls stand about in the lobby admiring themselves in the mirrors, and the guys could stand about in the lobby admiring the girls. No-one complained of having to stand a few minutes longer. It's a cousin of the question you were asking, but an example of solving the real problem, not the problem that the user says they want solved.

Answer 8

User requests are usually formed based on what the user perceives to be a solution to their problem. The thing is, their solution may not be the best solution, and in fact, it may not even solve their problem at all. Many questions on StackExchange are asking how to fix a partial solution, rather than asking for a better solution to the actual problem they are trying to solve (it's called the "XY Problem"). Users do this all the time, and it applies to professionals as well.

The basic examples would be:

• The user's proposed solution doesn't actually solve the problem they have. This is disturbingly common. You can usually find that afterward by observing whether the user is actually using what they "wanted" or not, but sometimes they will just force themselves.
• There's a simpler solution that covers the whole problem. You can bring in your domain knowledge to the mix - you probably know something the user doesn't. Maybe the user thinks their solution is the cheapest, but you can actually find a cheaper solution because you understand something about the underlying system. This is very common as well.
• The user doesn't actually need to solve what they think is their problem - they can do with solving a part of the problem. There's quite a few cases where you can make the customer more happy by solving part of their problem cheap, rather than solving the whole problem with huge resources. Ask yourself, why are humans still working, rather than heaping all their work on robots? At some point, it doesn't make economic sense to keep on piling solutions.

The result of all of these is that you're doing work you don't have to be doing, which of course means you're wasting the customer's resources (be it money, time or both).

Note that the famous Henry Ford (mis-)quote is basically a variant of number two. The problem people actually had was that they needed to get to places faster. The solution they figured out was "just make faster horses". This worked for a long time, mind you - we've been selectively breeding horses for different traits for a long time, so it's not stupid. The reason people like Benz and Ford were able to show a better solution was that they added a few points:

• It's getting harder and harder to make faster, stronger horses. This means that we've hit a limit where it gets absurdly expensive to get any further.
• It's easier and cheaper to acquire steel and coal then ever before. Those could be used to make artificial horses, which will be cheaper and faster.
• Horses are awfully complicated. The simplest thing we can have is a wagon which applies motive force directly to the axles. We already know wheels are pretty neat, so let's move those. Oh, and we know about trains! They basically do the same thing. Let's make smaller trains!
• If I can get trains to work without rails, and cheap enough for people to afford (the second part being what made Ford so famous), people are going to buy those mini-trains instead of horses, and everyone will be happy (except for horse breeders, of course :P). Oh, and we also have oil - oil engines are a lot more practical than coal engines for that!

But this whole time, the purpose was still to make travel easier, cheaper, faster, more comfortable, whatever. That's what the users wanted in the first place, no matter what they actually requested.

Do not think your users are stupid. They're not. It's just that most of the time, you can bring in some extra knowledge to the mix, and just as importantly, you can ignore some cached thoughts ("It's always been done this way"). People cache a lot.

Answer 9

My anecdote: Maybe 25 years ago, I was doing contract work for a municipal Utilities Billing group. The existing package was good, but primary inquiry into customer accounts required too many screens to get many customer questions answered quickly.

Since I did almost all troubleshooting over a couple years and I regularly needed some kind of overview into individual accounts, I soon created my personal version of the initial main inquiry screen. All I changed was placing a series of maybe a dozen '0'/'1' values in an empty portion of a line near the bottom.

These visual "switches" quickly told me if I was viewing an "owner" or "occupant" account, whether "business" or "residential", whether... etc. It took very little time for me to get used to it and to avoid a lot of extra clicking through multiple screens for many user questions.

But one day an application user was at my desk, watching as I researched a problem she had. When that screen came up in the sequence I was doing, she immediately jumped on those little "indicators".

"Wait! What's that?"

Well, who knew? Nowadays, it'd probably be an overview 'dashboard' or something like that. But back then it was a trivial item that the users in that group couldn't live without once it became known.

TL;DR -- I never would've known if I didn't have my own experience actually working with that app trying to figure things out. Every indicator was already expressed in the UI; it just took multiple user actions to navigate to them. No one thought to ask for info that was in fact already presented.

Answer 10

I am a software designer and run into this problem all the time.

The problem with many non technical people is they don't get abstraction. They truly cannot step back and articulate the functional requirement. Their perception is I have a problem I need this button. When they are asked to describe the problem they either can't or won't. The people least capable of design are inserting themselves in the design role.

A button and an output are design decisions. A very specific output my be very expensive to produce. If the software designer has the functional requirement they can often get to the need at a lower cost. This is especially true with large data and high number of concurrent users.

I can give you a very real example on need versus request.

Recently I got a BUG report that an export had to use a friendly long name with spaces. I replied 3 times what do you need that for as that is done with a SQL XML and I cannot use the long name and it is not a bug - that is as designed. We have utilities that parse that XML. So they decided to escalate. I pointed out to that they are getting 100,000 line exports in 40 minutes - really need to throw that out because the name on line 1 has to be the display name? Marketing said but users don't know what the names mean. I told them but users are in control of the those export names - they just have to be 20 characters or less no spaces and start with a letter. What users are doing are doing is taking prior configurations and just editing the display name for the next project and leaving the old export name. Marketing held strong with but they don't edit export name. Really 100,000 line export in 40 minutes and you would have us totally redesign export because users don't want to edit export name. That is over a man-month of work. Marketing held firm and said if you cannot use display name in your XML then maybe we need to find someone that knows XML better. I said that is is how XML works - there are restrictions. We used to have restrictions on the display name and 3 years ago you said user did not want any restrictions so take them away. The compromise there was separate export name with restrictions. Really all this because a user does not want to edit the export name?

Another hard request we got was go to page X. Users would run a search be on page X and then want to come in the next day and pick up where they left off. But it is not the same page X - there are 100 other users editing data and that search is not going to return the same results. I told marketing if we let them go to X they will think it is broken if they don't get the same Page X. Worse yet someone will have a task to review documents and what was on page 40 is now on 20 and they are on page 30 and that document does not get reviewed. We have a feature to save the results to a static list - that is what they need use. User did not want to take the extra step to save the results and had a false perception that Page X was a replacement. Marketing said that what they asked for. Sure enough a document was released that should not have been release because a user did not understand Page X and the customer went ballistic. What they want and what they need are not always the same.

Answer 11

I think this classic software engineering image is worth adding in. It's not just a problem with the customer - you get confusion everywhere.

Plus it's not even really a UX job to figure it out.

My experience has been that it is where decent project managers are worth huge amounts from the time saved by clearing out the confusion and being able to talk through, in language that customers understand, exactly what they are trying to get at.

Answer 12

Many answers here describe the problems with user/customer requests so I think i shouldn't repeat why you should do finding out what users realy need. I just want to give a hint how to do it:

What users realy need is called requirements.

And its the job of every engineer (or - should be) to find out what these requirements are, because users can't communicate their requirements for the previously described reasons. That part of the development/design process is called requirements engineering.

For more information about that topic you should read either the SWEBOK (by IEEE) or any other book or wiki article about requirements engineering.

My favorite book is Requirements-Engineering und -Management (by Chris Rupp e.a.) - which is only available in german language (or at least i couldn't find an english version).

Answer 13

Simply because that's your job to create a solution that answers user needs, and it's expected you know better than they do, otherwise they would get your job.

I guess I should begin by saying that listening to their requests can be a good thing. Because users aren't complete idiots, they're well aware of their problems and needs seeing how they've been facing them every day for years, and are perfectly able to find a solution to it, no matter how bad it can be. So when you ask them what they need, they'll tell you they want a solution, and begin presenting what they think is the solution and tell you to make it. And honestly, I've sometimes done just that, precisely because they aren't complete idiots. Their propositions deserve to be analyzed in depth, for they know and understand their job better than you do. Their proposed solutions can be very relevant, and I sometimes couldn't find better myself after looking at their real needs. Most importantly, because of the different thought process they go through, their solutions can reveal additional things about their needs that they wouldn't express otherwise.

But you know things they don't. Hopefully. Their knowledge is shaped by what they've experienced, by the structures, the architectures, the software they've encountered, and when they think of a solution, they assemble those pieces they've seen work into something they think would work. But they're not designers. You know more of those pieces than they do, and can assemble them much more efficiently, doing things they couldn't even think of. People with many varied experiences can be as good at this as you are and are definitely worth listening to, but others will tend to make bad, inefficient, limited solutions.

Then, users rarely look at the big picture. They mostly focus on their desk jobs, and while fully aware they're just a cog in the machine, they usually see no further than the neighboring cogs. Because their vision is limited, so are their solutions, because all they want is you to improve their job. Because they like their job, and they don't like change. And they want to keep that job. They would hardly suggest you something that would make their own job obsolete, even though that would greatly improve the company's operations, because they're afraid they might lose their job in the process. Some of them may see you as a potential enemy, and will try to manipulate you into doing things that would suit them, and you'd better not listen to these shifty people. Thus their requests may very well be detrimental to the overall process, and might be counterproductive.

Finally, users mostly think about the functional aspect of things. Actually, I've never seen a user think about anything else than that. They don't realize the technical considerations, nor time and money constraints behind their requests, because that's an aspect they're never confronted with.

While those are to me the main reasons why you're better at your job than they are, we could certainly find more, but I guess you see the point. While listening to requests can certainly be useful, you're simply a better designer than they are. After all, product design is within the reach of anyone, it's just that some are better than others.

Answer 14

To be brief as possible:

Not all users know exactly what they need because most of their requests are made for the sake of convenience.

Answer 15

Why is important to focus on user needs as opposed to requests? Here's an example of what we faced.

The Product Team came to the Development Team and asked for a survey form to be built in order to collect data.

The Development Team specifically asked if the Product Team planned on making any future surveys. They said no.

The Development Team decided to build a dynamic survey tool (just in case).

Shortly thereafter the Product Team and asked for another survey, then another. They have now asked for 12 additional surveys.

The Dev team is spending 10 minutes on each new survey request as a result of building the dynamic survey tool at the outset.

Imagine the problems if the dev team had listened to product.

Answer 16

Customer: I want to print a report with X. Then I want a web form so that Mike can upload this data.

Analyst: It is the same data? Could we just present Mike's group with a screen with X data?

Customer: You can do that? Really! That would save a lot of work

Analyst: And it will save us to code a new report and a form with all the data validation, errors, incoherence and delays..

Customer: You mean that it would be cheaper, faster and better? Great!

Answer 17

I'd like to extend on Digital Chris' answer, which referenced the XY problem. It actually extends even further into a linguistic issue.

The user and developer come from different points of view. They naturally develop different languages to describe what they need. In an ideal world, everyone would use objective terms for quantifying wants and needs, but realistically that's hard. It's especially hard in software, where developers often speak a radically different language.

Accordingly, everyone attempts to project their needs onto a common language. In doing so, they lose much of the flavor of what they wanted from the request.

This flavorless request is very useful for getting a connection going between the developer and customer. However, from there, it needs to expand outwards to find a common way of describing what actually should be done. This often has the form of finding out "why" a user wants something.

Answer 18

Very often, users will request what they believe to be possible, unaware of the real costs and economics involved. I've had the same people ask for things that would tax the state of the art in artificial intelligence, then express astonishment that it was possible to produce output sorted in various orders.

The question of how often something will be required is one that it is important to get answered correctly. The prudent thing is to design for generality and re-use, but that does impose a cost. On a couple of occasions I've been wrong, (didn't dig deep enough), and delivered a grossly over-engineered (hence expensive and delayed) product that literally was required to run only once. My bad.