Hot answers tagged

131

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


119

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


68

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


41

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


33

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


22

Try to distinguish between what users want and how they want it done. Taking your example above, users wanting one vs. two input boxes is all about the how. The what is being able to paste comma-separated coordinate pairs vs. not having to press comma. (Or, for some users, being able to simply press comma rather than having to click a second input box.) In ...


16

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


15

UX isn't just about doing what the user wants, or even what the user needs. Good UX requires taking many elements into consideration. For example: Business Requirements - Does this requirement help achieve any measurable business benefit? Does giving every customer a free cup of coffee directly increase the number of actual sales you make? Technical ...


15

You can't please everyone Most changes or additions will leave some people behind. They may catch up later, they may hate you forever. Shoot for net gain in the experience. If you avoid negative feedback, you avoid progress. It helps to keep a destination in your sights. Focus on an established list of goals for the long term vision of the product and the ...


10

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


8

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


7

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


7

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


6

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


6

Because the image and text are differently in each case I would do the following. 1st grouping I would only use that in an aligned left scenario 2nd grouping I would have to use this in a centered design 3rd grouping I would use this only when floating like elements next to each other.


5

I believe this solution gives equal prominence to each option and is seen on many iOS interfaces:


4

Is any data connected to the login account? Then yes. People want to keep their stuff when they change email just like when they move houses. Is there no data connected to the login account? Then why have a login at all?


4

I haven’t heard of any study about your question. But I can only base my opinions on readability issues, for this specific case. (See image) For the big paragraph text, is easier to read when aligned to left . It makes it a clear paragraph. Your 3rd option shows the typical “teeth” that annoys the readability. Also not applied in print design for such big ...


3

Accommodate both! In this case, your users told you exactly what they were missing in the old version (in this example, easy copy/paste). So create a new way that meets both sets of requirements. Generally speaking, say the old way offered Features A and B, and the new way still supported Feature B, lost feature A, but added feature C. Users said they ...


3

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


2

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


2

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.


2

The e-mail address is a way for you to notify/warn/inform users outside their account. If users prefer to use a different address for that kind of communication, let them change it. So from UX perspective I would call it essential. For accounts that use an email address as login name you can give the option to add antoher e-mail address for notifications ...


2

The principle you want to leverage, here, is called social proof. I noticed that the experts at user-experience consultancy NN/g discuss this in their article, Social proof in the user experience. This article gives a quick overview and, in the last few paragraphs, provides links to other authors and research for in-depth reading. You might like to read ...


1

You apparently need 50 rep to comment, so I would just like to add to @riotgear's beautiful "context dependent" answer. You also asked about an "Acceptable amount of lines" I would say this is again dependent on context. Only this time, instead of it being around placement/surrounding, based on you user's viewing context: On the go, quickly scanning a ...


1

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


1

For your specific scenario, there are many benefits and really can't see why NOT to use them. Basically, you want to have user's reviews, so while users are not the focal point, they're an important aspect of your site, if not THE MOST IMPORTANT. and this is NOT an exageration. I assume your app is oriented to sell. Now, with apps like yours, I can find 100 ...


1

Any user will never sign up if he does not know what is there in the website for him. In case you think your site is too complex that a user will not be able to identify the complete potential; you can use an optional tutorial after the user signs up.


1

Assumptions are assumptions You are making an assumption, and while it could well be a valid one, it is still an assumption. It is perfectly fine to make assumptions in UX and we do this often as you can't gather, analyse and validate data on every single aspect of a system. But for anything other that minor, you hope some data will emerge or be collected ...


1

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



Only top voted, non community-wiki answers of a minimum length are eligible