Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I have been thinking a lot about my favorite quote from Henry Ford:

If I asked people what they wanted, they would have said 'Faster Horses'. -Henry Ford

The trouble I have been having is that I know how to make something usable, but I am an innovator at heart, I have to be trying something new.

So what is the way to discover what users NEED and not what they just WANT?

If I do a user test the way I do now, I get their reactions, wants, and desires, which are rather predictable 9 times out of 10. But what I am having trouble with is digging out their needs.

share|improve this question
11  
@zzzzBov: No thanks, not any more... I'd like to stay around a little while longer –  Marjan Venema Nov 9 '11 at 7:44
6  
Aside: It's a pithy quote, but Henry Ford didn't invent the car, so it sounded unlikely that he said that. He didn't: blogs.hbr.org/cs/2011/08/henry_ford_never_said_the_fast.html –  Plutor Nov 9 '11 at 13:24
    
@zzzzBov: I'd say he knew what people want, at least lately. –  bigstones Nov 9 '11 at 14:24
15  
When told that the people want "Faster Horses", the right question to ask would have been "What do you want to use those faster horses for?". ("To get places faster/more efficiently") –  Sverre Rabbelier Nov 9 '11 at 14:24
    
The answers naturally focus on avoiding all the obvious ways of asking what users need. It's possible, if you're lucky, that after doing a lot of that, and starting to get solid ideas about what the users need, that you might be able to go back and find the one user who was aware enough to be suggesting those things, and give more consideration to their other ideas. –  Jefromi Nov 9 '11 at 15:18
show 5 more comments

16 Answers 16

up vote 108 down vote accepted

Make sure that you focus on goals.

Don't ask what your users want or need in terms of functionality or form. Find out what they need (or want) to achieve .. that way the parameters you use to define and solve the problem will be much clearer and focused.

Questions to ask your users might run along the lines of;

  • what they need to achieve.
  • how they currently achieve 'x'

then

  • moving on to find out what makes current methods difficult.

Don't carry out user research for solutions - research problems

share|improve this answer
10  
That's an excellent way to sum things up, and I think it counts for all sorts of requirements gathering. Don't research solutions - discover problems. –  Jimmy Breck-McKye Nov 8 '11 at 22:29
    
A wholehearted +1 on the question and @JimmyBreck-McKye 's comment –  Marjan Venema Nov 9 '11 at 7:45
1  
The problem with ASKING users what they need to achieve - is that, in the words of Henry Ford, they'll tell you they want "faster horses" - The users will still see it as 'horse problem'... I'd aim to research their lifestyles instead. –  PhillipW Nov 9 '11 at 9:57
2  
+1 for pointing out: "research problems" –  aitchnyu Nov 9 '11 at 10:51
1  
@PhilipW: it's true that it's not easy to get to what user's need to achieve, but that doesn't mean it's impossible. If your conclusion is "faster horses", you didn't get to the bottom of their real needs. Instead, if users say "I need a faster horse", you can ask "why do you need a faster horse?". An answer might be, "because I need to get to my destination faster". Digging deeper – "why do do you need to get there faster?" might reveal "because time spent traveling is wasted". This is also called 'Laddering' or 'Ladder interview'. Maybe Ford could have invented the phone! –  Michel Jansen Feb 15 '13 at 15:29
show 1 more comment

I had a customer a few years back who had gone through several stages of improvements to the way their system worked.

Initially they managed everything in Excel and it kind of worked, but it started getting a bit bloated and rather out of hand - well you can imagine the problems!

Then they got a team of developers in-house to improve the situation. How? Well - still with Excel but now with a swathe of Visual Basic which automated all sorts of stuff and did calculations for them and - oh it was marvelous how much more productive the staff were. Did I say it was still using Excel?

Then management wanted something more professional, because it was going to be sold as a product - not just used in-house. And no, they didn't see that coming apparently!

So when I got involved, I spent almost a week on site to see what some of the issues were, I watched them go about their tasks, I made lots of notes, I asked lots of questions. I spoke to potential customers and I spoke to existing users. I had lunch with them. I immersed myself in their world.

But when I actually tried to ask what users wanted - that was when I found that actually the people who used the new Excel setup were so happy with the improvements over the previous Excel version that they couldn't imagine how life could be even better. Some didn't even really want me to get involved because they felt that I might make things worse again.

Needless to say, the new solution had nothing to do with Excel and everything to do with what people were actually trying to achieve - it just needed someone from outside to get a grip on the roles and goals involved, and you can't do that in a complex environment until you really immerse yourself in their world.

Immerse yourself in their world and question everything. But there's no point in trying to get direction from the users themselves, because they have pretty much no idea.


EDIT What happened after:

While on site, I saw people lugging equipment around to test different bits of hardware. The solution was split:

1) all calculations done on a PC attached directly to some related equipment.

2) a remote PC running a custom built application (using Java+Swing) to manage data and results in a context specific way that really mapped onto the tasks and processes that the users needed.

Communicating via SOAP between users PC and the hardware PC meant no more lugging around, and geographically remote testing was suddenly possible. Data transfer issues into and out of Excel disappeared - which I had identified as being a time waster and error prone weak link, but which users had accepted unquestioned.

If I hadn't been on site, I doubt I would have found out that people were regularly carrying their PCs around or moving heavy equipment around in order to connect things up. Nobody would have thought to mention it! As a result of the new changes, all this heavy, humming equipment was able to be moved out of the office and into a separate room. Result: much quieter offices.

But users didn't know they needed quieter offices!

share|improve this answer
1  
You left me hanging, you can't do that. What did you end up using? –  Matt Nov 9 '11 at 8:29
    
@Matt heheh - sorry :-) I added an edit to my answer - 'What happened after' –  Roger Attrill Nov 9 '11 at 9:33
2  
Nice, If i ever get a client that needs something similar, ill just say I know exactly what to do :p I'm just always curious on how people solve problems, because you never know when you will be in that situation yourself and what's better than taking advice from someone who has already been there? –  Matt Nov 10 '11 at 5:49
add comment

I've come across this before and the following image illustrates just part of the problem:

enter image description here

I've found that one way to find out what a user actually needs is to really understand the user's requirements, to the point where you can put yourself in their shoes and ask yourself "What would I need in this position?"*

The other thing I've found that helps is being honest with the user. If they provide you with requirements that sound flaky, don't just assume they know what they're talking about - point out areas you think could be improved. I've found that in my line of work (databases and web design), users often don't realise what's possible and what's not possible - Only you know the true potential for the new design, so don't be afraid to suggest some ideas of your own. After all; innovations don't come from users, as you rightly point out from Ford's quote.

*A term for this might be Grokking. Grok the user's requirements (empathise with them) and you find their true needs above and beyond what they're asking for.

(By the way, I got that image from here: A blog, but I've seen it many times before and have no idea where it originates from, or I'd credit the artist)

share|improve this answer
add comment

You aren't as likely to discover their needs by analyzing their reactions to something that you've built. I agree with codeinthehole - research that independently of your ideas.

Some questions that might be helpful:

  • What's a random day in their life like? When / where do they use tools similar to yours?

  • What do they need to know beforehand in order to achieve their goal?

  • How might their needs or behavior change depending on the situation?

  • How do they currently think about the activities they do with the tools they use now?

(Exa. Do they understand the underlying concepts or have some bizarre idea about how the technology works? If they don't understand how it works, is there a way you can design it so that it's closer to their imagined idea than reality?)

  • What do they know about the tools they already use?

People got all excited about Google+ circles. They wrote long blog posts about the innovative new circles feature. However, Facebook had the lists feature for years. Few people used it, partly because they didn't know it existed, partly because they thought it was too much effort or didn't understand it, partly because of its design.

  • What do they like / dislike about the tools they already use?
share|improve this answer
    
Also, look for the shortcuts they use. Pay attention to the post-its and printouts around their desks. Those things tell you right out where they have troubles. –  Ken Mohnkern Feb 3 at 20:18
add comment

The only way that you will ever understand what people need it to first understand them and their problem. There isn't any magic formula or set of steps to go through to do this, but any steps that you can take which help you see their problems from different perspectives will help.

That is the reason that most successful software is written by people solving their own problems. When you are solving your own problem it's a lot easier to focus on what you need.

One thing that I have found useful (but is by no means exhaustive) is to take things away from your solution until it no longer solves the problem. Very often the things that we want are just accessories whereas but our needs are the core.

share|improve this answer
    
+1 for the idea in the third paragraph (even though the idea in the second paragraph is unsubstantiated and exactly the opposite of the OP's Ford quote) –  3nafish Dec 12 '12 at 1:06
add comment

Go and sit with them. There is no way of understanding user needs without actually sitting with them for several weeks and listening in to their work, watching them, engaging with what they are actually doing as part of their job. You can get on with your own work at the same time, workign on other stuff, but being there and observing over a period that lets them be relaxed with you.

share|improve this answer
    
Some part of this may be to help with problems and assist with suggestions for ways to achieve what they are trying to do. This helps you understand what their problems are and the areas that they have problems with. You should, out of this, get a grasp of their business environment, not just the problems that they want you to fix. –  Schroedingers Cat Nov 8 '11 at 22:06
    
Agreed. The users probably don't even realise they have 'needs' . The 'needs' will have just melted into the background of normal life as far as they are concerned. –  PhillipW Nov 9 '11 at 10:08
add comment

In my own opinion, you need to do a few things to really determine the user's needs.

  1. Ask the all-important, super obvious question: "Why would a user use my application?"
  2. Once you've determined that, determine: "How does a user use my application?" (For example, how does a user use Twitter? I personally use it for jotting down notes to self and for venting about terrible UX, etc. Someone else might use it for keeping in touch with friends.)
  3. Finally, "How can I make that/those features used by the user ridiculously easy to use?" (In the Twitter example, this means making it as easy and quick as possible to tweet. Show a character count box; put a tweet box on every page in multiple locations, etc.)

Remember, Google got where they are today by being almost single-minded about search. Search existed before Google and it exists in other forms even today, but the crazy focus on usability really paid off. Find the purpose of your application and make whatever that purpose is extremely easy for the user to accomplish.

share|improve this answer
add comment

You are right: usability studies often only reveal the deficiencies, only indirectly the improvements to be made. If you want to design something, you run into a wicked problem:

  • The requirements are ambigue and often contradictory
  • Every sub-problem can again be recognized as a symptom of another problem
  • You can't understand the problem before you found its solution
  • Ultimately, there is no "right" solution, only a "better" solution
  • You cannot find the solution to problem by logic; however, once you found the solution, this seems obvious/understandable

So what can you do? Instead of trying to improve an existent design, you first explore all possible directions, try to come up with a solution, redefine your problem, and so on. Design thinking is an example of such a process.

Does this mean you need to create the ideas yourself, independently from your user? Not necessarily! Once the user understood the spirit of brainstorming, they can come up with their own ideas, maybe not the complete solution. A future workshop, for example, explicitly includes the stakeholders into this process of design.

share|improve this answer
add comment

Don't really have the time to write about innovation right now, however I recommend that you read Technology First, Needs Last column by Don Norman. It is a compelling opinion piece on how innovation happens. Hint: doing ethnographic studies is not the way. Just fling the poo on the wall and see what sticks (or what other people modify to stick).

share|improve this answer
add comment

I am always amazed when I silently watch someone use an application or website. Don't give them a task or tell them what its for Just watch. You will see things you never expected and get a lot of insight.

share|improve this answer
add comment

Don't ask them. Just watch them use the product they are already using and observe where they are facing problem. Where they are hitting dead end. What would make their life easier.

share|improve this answer
add comment

Keep Digging until you reveal the root.

If I asked people what they wanted, they would have said 'Faster Horses'. -Henry Ford

People don't NEED slow horses. People don't NEED faster horses. People don't NEED cars. People NEED trains or planes. People NEED the ability to travel from one place to another. They NEED to get to their job, or visit their family or transport goods.

The Medium they use hardly matters.

They will make an economic decision which is best for them. Whether it is the price, or reliability or comfort.

Sure, you can make the car more usable, redesign the interior controls, the aerodynamics, but in the end it's still a car.

Your heart wants to solve the root issue, a better way to transport. Perhaps a teleportation device!

share|improve this answer
add comment

One mentor of mine had a great way of explaining agile development methods and getting users to adopt what you build:

[Paraphrasing] Whatever you build for the first version, no matter the timeline, users will think it is crap. No one knows what it should look like and the chance of you making whatever is in their heads is nil. Therefore, keep you timelines as short as possible for this first version to minimize the loss on ROI. (You don't want to spend a lot of time on something someone will think is crap anyways, right?) When they tell you it is crap, ask them how it would be made better. They tell you. You implement it. Iterate.

Seems simple, but this approach has two major psychological benefits and one major business benefit: A) if you go in knowing your product will not be loved, you won't be upset when they tell you and you can immediately focus on solutions, B) each iteration involves direct feedback from the customer allowing him/her to take ownership of the solution which increases adoption, and C) the financial benefit of investing as little as possible in each iteration maximizes ROI.

Each iteration should be kept very small. We used to say: 2days, 2weeks, or 2months.

share|improve this answer
add comment

Ask people what they want and then ask yourself why they want that.

share|improve this answer
add comment

Lordshree gave a best example. It always misunderstood or misguided for a project but actually the need is different. So spending time to get users requirement into picture is necessary.

share|improve this answer
add comment

I think it is good to watch the user using the system, and then interview the user on what he/she sees as new ways of working of his/her system. I hope as a developer you will quick understand by telling him/her what is possible and impossible.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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