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?

  • 13
    How about: at the time the iPhone came out, everyone was asking for smaller phones plus netbooks. You can't request something you haven't seen yet. Commented Apr 13, 2015 at 15:32
  • 81
    There's always the apocryphal Henry Ford quote: "If I had asked people what they wanted, they would have said a faster horse."
    – Plutor
    Commented Apr 13, 2015 at 16:59
  • 12
    I think it's important to point out that this concept doesn't mean you should ignore requests completely and do whatever you think is best. What it means is that you should find out what the user's problem is that led them to that request, and then fix that problem in the best way you can think of. So you end up ignoring the actual request but you still use it to research the problem that prompted it.
    – RomanSt
    Commented Apr 13, 2015 at 20:17
  • 11
    Apple took the approach to not even bother asking what people wanted as they knew that wasn't going to lead to the best solution. "A lot of times, people don't know what they want until you show it to them." - Steve Jobs
    – DA01
    Commented Apr 13, 2015 at 21:41
  • 4
    @JonW I see your point, but shouldn't you have closed the question then? You made an edit that clearly deviated from the authors intent and invalidated a large number of answers. (Also note that it wasn't asking for lots of examples, but rather for quality examples) Commented Apr 14, 2015 at 21:58

18 Answers 18


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.

  • 11
    There's a nice story by ThoughtWorks, I heard repeated a few times: a client wanted the reports in the new system formatted in a very peculiar way, which wasn't possible to achieve easily with the new web-based system. Adding a PDF exporter with those very specific formattings would have been a lot of work. After some amount of investigation, it turned out that they were printing those reports, mailing them to another department and typing them back in, and the users had so gotten used to the specific placement of the relevant numbers, that multiple generations of IT systems had to replicate … Commented Apr 16, 2015 at 10:41
  • 8
    … them exactly. Well, the new system was offering XML feeds for all data, and it turned out that the system the other department was using was capable of importing XML feeds, so it was just a small matter of matching the data formats (probably an hour of coding), and reports never had to be typed in manually ever again. And the time to get at the data in the other department shrunk from hours/days to milliseconds. Commented Apr 16, 2015 at 10:43
  • 4
    I like this answer because it doesn't cast some kind of shadow of incompetence on the user. It simply states that end users often don't know what is possible, so they can't consider some solutions. The user does know what they need; they're probably the only ones that do. They're just not good at or not familiar with phrasing their request in those terms. So it's part of our job to help them reform the problem in those terms. As I've gotten better at doing this with other people's requests, I've gotten better about doing it with my own requests. It's just a matter of practice.
    – jpmc26
    Commented Apr 17, 2015 at 7:32

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:

    enter image description here

  • 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:

    enter image description here

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


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.

enter image description here

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.

  • 24
    +1 because there's no better argument than a Simpson's example. Commented Apr 13, 2015 at 15:58
  • 3
    I still wish headlight dimmer switches were foot-buttons on the floor. Just switching between "my" car and "my wife's" car is troublesome when hurriedly trying to manipulate the right steering column lever the correct way. Commented Apr 14, 2015 at 2:10
  • 3
    +1 funny argument with solid background of Ford's Edsel. I'm going to get a Hot Wheel Homer for my next design meeting where everyone has an design-opinion and tries to make it sound for the common user.
    – FrankL
    Commented Apr 15, 2015 at 11:37
  • 1
    @user2338816 - headlight dimmer switch was a foot button in the Holden Kingswood, last produced in 1979 in Australia.
    – Peter Wone
    Commented Apr 16, 2015 at 9:26

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

enter image description here

(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.

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.

  • 3
    nice stuff! and about so-called X-Y, it's only secondary whether you are "a user" or not, two people or group are able to get into this kind of time-wasting regardless being a programmer, architect, "a user", administrator or whatever, as it seems to me. The programming-related experience is probably a way to improve oneself recognizing this exact situation, however anyone with decent communication skills should be able to see when more questions need to be asked in a conversation.
    – n611x007
    Commented Apr 15, 2015 at 10:49
  • 3
    A key point of yours is that the conversation with the user is not for naught if you know how to ask effective questions. Keep asking "why" someone needs what they requested and you'll eventually discover the need that's driving the request. Then, armed with the knowledge that typical users don't have and the ability to imagine something that hasn't been invented yet, you can create a solution that exactly meets their need. Commented Apr 15, 2015 at 13:30

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.

  • 3
    This makes me wonder why ecent Windows versions advertise the feature of fast booting :) Commented Apr 19, 2015 at 21:59

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.

  • 5
    Urban legend or actually documented? Sounds weird enough to be true...
    – WernerCD
    Commented Apr 14, 2015 at 0:28
  • 1
    @WernerCD It's such a common urban legend that it's bound to have happened in one rendition or another, somewhere, sometime.
    – Etheryte
    Commented Apr 14, 2015 at 8:41
  • 1
    Urban legend or not that's actually quite believable!
    – Wander
    Commented Apr 15, 2015 at 9:51
  • 1
    @AlanG But it is not a user need to look into a mirror. The need is to be in control (of the waiting situation). This solution doesn't solve a need, but sidetrack users.
    – FrankL
    Commented Apr 15, 2015 at 12:31
  • 1
    @FrankL - agreed. This is akin to users complaining about boot times and fixing it by handing out rubiks cubes. Distracting them might stop the complaints but it doesn't fix the problem.
    – Mike
    Commented Apr 16, 2015 at 19:22

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.

  • 1
    -1 Ford didn't invent the car. Your example is misleading and wrong. It was Carl Benz en.wikipedia.org/wiki/Karl_Benz who invented the car. Ford re-organised the manufacturing of cars in terms of small dedicated montage steps. Thus he was able to reduce manufacturing costs and made cars affordable for common men.
    – FrankL
    Commented Apr 15, 2015 at 13:09
  • @FrankL I never said he daid. Maybe you need to read a bit more carefuly :)
    – Luaan
    Commented Apr 15, 2015 at 14:47
  • You wrote: "He added a few points...", "make artificial horses", "Let's make smaller trains!", "oil engines are a lot more practical than coal engines". If one adds it, it is a car, don't it? Ford didn't added this - he invented the so called fordism en.wikipedia.org/wiki/Fordism
    – FrankL
    Commented Apr 16, 2015 at 7:17
  • 1
    @FrankL You're just adding your own notion of "people mistake Ford for inventing the car", and as such, you see the example where you want to see it. Benz didn't create a car as an alternative to horses - he probably didn't even believe it was a good use of resources (originally - of course, they whipped out a bunch of cheap cars and trucks very soon after Ford). He started the switch from "horse for poor, car for rich" - today, horses are the luxury. It's like saying "Xerox gave us mouse" - yeah, they invented it; but they're not the ones who made it available for everyone.
    – Luaan
    Commented Apr 16, 2015 at 8:26
  • 1
    In this case you should rewrite your example for a better usability.
    – FrankL
    Commented Apr 20, 2015 at 11:39

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.


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.

  • 5
    When you're getting instructions direct from the marketing department you know you're in trouble
    – icc97
    Commented Apr 16, 2015 at 8:34
  • 2
    A favourite daydream: Take a water pistol to meetings and squirt every marketroid who says something asinine or attempts to achieve truth by repetition. You'll need a big reservoir.
    – Peter Wone
    Commented Apr 16, 2015 at 9:36
  • 2
    This answer sounds more like arguing with users than solving their problems... =/ The whole premise of this question is that instead of arguing about what they ask for, probe down and find out the root problem and solve that. In both of these situations, I'd ask more questions. Why don't users change the export name? Is it overly burdensome? Are they just forgetting to do it? Why does the system even allow duplicate export names if this is a problem? Why aren't users already using the static list feature? Do they know about it and what it does? Is it hard to use?
    – jpmc26
    Commented Apr 22, 2015 at 2:17
  • @jpmc26 XML does not allow duplicates. It is a simple edit box. It is right next to the display name box and they have no problems editing the display name box. We had restriction on display name to make it XML compliant and they said they did not want those restrictions so we took the restriction off display name and added an export name. If users are too lazy to change a simple setting is not a program problem.
    – paparazzo
    Commented Apr 23, 2015 at 9:46
  • 1
    XML makes no restrictions on duplication of elements, so I have no idea what you're talking about, unless you have an XML schema that prevents it. And yes, it absolutely is the program's problem if the users are having trouble doing what the program requires. This is usually an indication of a design problem. Users don't care about your program; they care about getting their work done. If something in your program isn't helping them accomplish that, it's time to step back and rethink how it's designed. That's my point: step back and start asking why the user is doing what they're doing.
    – jpmc26
    Commented Apr 23, 2015 at 13:39

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.

a swing

  • 2
    HEY! That's "what operations installed" because that's all we were given! Commented Apr 19, 2015 at 16:27
  • I'll believe that! And I'm an engineer. It's amazing how magical people think others are.
    – AaronD
    Commented Apr 22, 2015 at 1:59

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).


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.

  • +1 For the important social aspects of user requests and needs.
    – FrankL
    Commented Apr 15, 2015 at 13:13

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.


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.


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!


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.