9 ms·

> ASK! ASK! ASK! Except users lie all the time. They don't know what they need or want. People are horrible at being logical about what will actually help them

> ASK! ASK! ASK! Except users lie all the time. They don't know what they need or want. People are horrible at being logical about what will actually help them. Watch them work. Watch a bunch of people work. Test and prototype changes and watch more people work. And watch them work at their desk or where ever they work.

duxup 8y ago
I probabbly didn't emphasize it enough but yeah you give them something mvp like and watch them and get feed back on it. Recently, I actually forgot to make a whole series of changes on a dashboard that were requested. They hated the old version .... but I didn't change it before the next meeting ... and then they loved it at the recent meeting. It was the same one they hated on. Sometimes you also just have to let them get used to it too ;) It's an iterative process no doubt, but as a dev... I'm no better at knowing what I'll do too. Iv'e worked something up and weeks later changed it completely after I've used it.
carlmr 8y ago
Why not both? It's not even that people lie, but they might not know what's possible, limiting the amount of information they will give you.
ThomPete 8y ago
Exactly. Asking users is only interesting if you know what you are looking for and you have to ask around the questions instead of leading them to answer. 90% of the time observing is what you want.
bachmeier 8y ago
> Except users lie all the time. That's the starting point for all the garbage enterprise apps I've ever used. Someone that has no clue what the users are doing makes a decision about how best to design an app that they don't even know how to test. Don't ask them how to design the app. Ask them what they do with the app, then find the best way to get them where they need to go. Then let them test the first and second and third versions, and listen to their feedback without an assumption that "they just don't understand my genius". It's important to distinguish between casual social media app users and power users spending hours of their day using an app to get their work done.
- vectorEQ 8y ago
  ofcourse you dont ask them how to design. you are hired as the designer. ask them for specifications / limitations / painpoints in the current system etc. etc. and base your design upon their feedback on actual relevant questions. a plumber doesnt ask his customer how to plumb. just which pipes need fixin! doesn't go fix the toilet if the shower is broken :S
  - chrismeller 8y ago
    I think the better analogy would be installing a whole new bathroom (it’s a redesign after all). In that case the plumber could and should ask where the sink is going, even if he was only told to move the toilet. Why? Because maybe the sewage line is over there and about to be covered over with concrete and they’ll have to tear up all of that to move it in two weeks, but the sink hadn’t arrived yet so no one told him that would move either. The point is not that the plumber is asking his customer how he should do his job, but that he can be more valuable if told the whole scope and impact of his job. Similarly you can’t just ask a user “how could this screen work better”, you need to watch them work so that you see that that screen isn’t even the problem - they’re clicking off of it 15 times every call - but you didn’t even know to ask about the other page.
    - erikpukinskis 8y ago
      > you can’t just ask a user “how could this screen work better” Why would you ask that anyway? You've already assumed the problem and solution at that point. You ask how it's going, very generally and let the conversation lead you to their pain points. You don't ask about the UI, which they are not an authority on. You ask about their subjective experience, which they are.
      - tabtab 8y ago
        The best approach is to watch them do their work and ask a lot of questions. For example, "Why did you have to leave this screen to go find X?"
tom_ 8y ago
You can probably find a better term for this phenomenon than "lie", which implies a degree of active intent to deceive.
- adrianhel 8y ago
  Users have ideas. These ideas are motivated by pains and pleasures. When asked what they want, they present the ideas they believe will reduce pains or increase the pleasure of using the software. It's up to you to 1. Determine if the idea reduces pain, increases pleasure or both. 2. Test whether the hypotheses are correct. Rephrased: Users come up with untested ideas
chrisseaton 8y ago
> They don't know what they need or want. If they're so deluded about what they want what makes you think you can see through that and find a solution more clearly than they can?
- jfengel 8y ago
  Because you know something about UX. Good design is a cross-disciplinary activity, mixing the domain knowledge in users' heads with the design knowledge in the heads of developers/designers. This is hard to do well, with few hard-and-fast rules, but it often benefits from collaboration. There are often big a-ha! wins when you're watching a user and ask a question like "why did you do that that way?" or "what if I redesigned it like this?" Users often can't ask those questions because they're focused on doing their job rather than the meta-job of improving it. They often don't realize what's possible. That's no excuse for ignoring their suggestions, and unfortunately many users have been specifically discouraged from thinking how to improve their own experiences by developers who were lazy, incompetent, or merely bureaucracy-laden. But fostering a collaborative environment, where developers learn something about the domain and users learn something about how their tools are created, can lead to much better user experiences than either could do alone.
- jolmg 8y ago
  More to jfengel's point, it's not just UX, you have more knowledge of what is technically possible. People will often come up with very convoluted solutions to problems because they don't have a good view of what is technically possible. It also happens that people only take their own needs into account and not those of the other users they're indirectly interacting with via the app. They'll tell you that certain app objects should have certain constraints, that certain things should be impossible, and that such assumptions can be used as foundations for other features. Then you go visit another user and they'll tell you very plausible conditions under which those things should be possible and even required. Talking to users is good, but you also need to observe them as a group and sometimes weigh their needs against each other.
- deleted 8y ago
  [deleted]
Bjartr 8y ago
> Except users lie all the time. They don't know what they need or want. People are horrible at being logical about what will actually help them. Asking them to describe the problems they have and doing exactly what they say will fix those problems are two very different things. The difficult, but critical, step here is to decipher what root problem should be fixed given the feedback users have given you. Sometimes the right thing to change is something the user never would have thought of to ask for, but can be figured out from what they did ask for. Remember, your users (usually) aren't UX designers, they just know where they get frustrated.
foobarrio 8y ago
Consider their response an input signal and not necessarily instruction from them. If my little niece comes crying saying there is a monster under her bed, of course I know it's not a monster but I'll still go look. Maybe a toy is under there making a noise, or the heater pipes, or the cat is moving stuff around.
- ErikVandeWater 8y ago
  This is how you get your kid eaten by monsters. But in all seriousness, this is a good point. In addition, you have to think about the user you are listening to. Are they smart? What terminology do they know that other users don't? Maybe they figured out a workaround to some problematic UI already, and you can just make that workaround global.
- Bartweiss 8y ago
  I've heard a corresponding principle in both game design and writing expressed as "When people tell you what needs fixing, they're almost always right. When they tell you how to fix it, they're almost always wrong." Feedback is great, but feature requests and proposed changes aren't actually feedback, they're new ideas.
noir_lord 8y ago
I've found its not that they lie (all the time) it's that often they don't have the time or mental energy to figure out what they want and even if they do they lack the tools to communicate it. That is fundamentally a human problem and I'm not sure what technology can really do to significantly improve the solution which is to slog through it and listen to feedback.
- cmiles74 8y ago
  I think many people don't really understand how they perform the functions of their job. Some things they enjoy doing, some things feel like busy work: all the things are mixed together over the course of the day. Picking and teasing the separate pieces apart and dealing with them individually is always hard for people and for some more than others.
potta_coffee 8y ago
It's true, but you still need to ask, and watch them work. But what it often comes down to is that the company underestimates the effort involved, they push you to rush the process, and communication is the first thing to suffer.
manyxcxi 8y ago
> Watch them work. This x1000! I took on a freelance project for a heavy machinery hauling company. They were a year into transitioning away from some customized off the shelf Enterprise scheduling and dispatch system into some custom built software by an “Enterprise” consulting company. They were originally bringing me in to audit what the team that was building it but that pretty much changed on the day I submitted my proposal... In the proposal I wrote to my then prospective client I allocated a couple of days of onsite interviews with “lower than management” people that would be using the system or it’s outputs, and a week of shadowing people in all roles that would be directly using the system. The project sponsor (to his credit) didn’t ask me why I would need to do that, he started laughing and exclaimed that I was the only person to ever even recommend this approach. We ended up re-writing the proposal into multiple phases where I just interviewed and assessed, documented their current processes, provided business process workflows and suggested ways their current workflow could be optimized, irrespective of any one technological solution. A crappy process, then automated, is still crappy. I wound up spending 6 weeks before even proposing anything that had to do with technology. My implementation proposal was set in phases that would bring related functions to light in a way that their teams could begin using them right away and we could collect feedback and iterate while producing the next set of features as well. It was their first ‘agile’ project or contract and the fear was quelled when after the first month I had put more useful software in their dispatchers hands than the “Enterprise” team had in a year. From day one interviews to “finished” project we spent about 6 months and that system still lives 9 years later- though it has been modernized and upgraded every so often in the intervening time, it is still one of my proudest projects even though it was one of the least “sexy” I’ve ever done.
- ljoshua 8y ago
  Great war story with enough specifics to be learnable, thanks for sharing! Reflects my experience as well.
- freedomben 8y ago
  My first paid gig I did this with wild success also. After that I tried to do this several times and was always met with incredulity. Management never seemed to grok the importance of this, to the point where I started thinking maybe my first experience had been a fluke (gaslighting). While I no longer think this is practical (unless you are the one in charge), I do recommend it whenever possible. The product will be orders of magnitude better, but expect management to strain at the gnat of paying a software developer to watch a non-technical person do their job.
ams6110 8y ago
And only change what are real problems. Maybe something like a user needs to navigate to three different pages to get the information they need. That's something you can improve. But resist the urge to do a general facelift or reorganization just for cosmetics. Users can fly through the ugliest interfaces, even text-mode terminal interfaces, once they get used to them. Change that at all, and they will be stumbling around and complaining. That can be worth in the end if their usual workflows are now shorter and faster, but tread carefully. Users of enterprise apps really don't care too much about how they look.
pwthornton 8y ago
Some of this comes down to phrasing. We should both ask and observe (but it has to be the right kind of asking). The asking should be user interviews and contextual inquiry to understand their problems. What are they trying to solve? We shouldn't be asking them to design our products for us, because users often don't know what they want or what they even do. This should typically come very early in the process as foundational work. Observing people both working and in a usability testing setting will help us learn what is and isn't working. As we get into the prototyping stage, it should be a lot more observing and testing. I think what you are responding to is this idea that all we need to do is just talk to our users, and you are correct, that is very wrong. Just asking users what they want is a good way to give them something they won't use. When we do ask people questions, they need to be done in a methodical and probing way.
jrochkind1 8y ago
This is why user/usability/UX research is actually a _thing_. Like a discipline, a thing to learn, a thing where experience and skill matter. Yes, you can't just "ask". But there are certainly ways to learn. Doing a major UX redesign without doing any UX research seems like asking for trouble -- and I don't trust the conclusions drawn from the outcome, still without being based on UX research, either.
phkahler 8y ago
>> Except users lie all the time. They don't know what they need or want. People are horrible at being logical about what will actually help them. That's a bit harsh. IMHO people don't know what's even possible, so they can't tell you what the solution is. Sometimes they can tell you what bothers them about what they've got even if they don't know what would be better. The rest of your comment it good though. Watch them. Look for things that look hard or redundant. Ask if they ever get tired of X, what gets in the way, etc... But don't necessarily expect them to tell you how to make it better. I like to say users don't have requirements. They have problems.
- NeedMoreTea 8y ago
  They often gloss over how they might use an app, or use it differently to described when doing real, live work with real data instead of test scenarios. Just as I would likely gloss over much of what I do when I drive a car, as I no longer think about it. Sometimes they use something differently to how their supervisors think they do. Maybe they found a handy shortcut or unintended timesaver, maybe relying on a side effect or unused field. Best to watch a few at all levels of seniority, if at all possible, to fully understand how to deliver what they might need. Then dig into the issues, shortcuts and timesavers or bottlenecks they currently have.
funkaster 8y ago
> They don't know what they need or want Of course they don't always know. That's why you have to do proper user research. You should not just build what they are asking: you should try to figure out why they are asking for a particular solution, try to find patterns among all the users, find the actual source of the problem and then propose a solution that could work for them. This is, of course, an over-simplification. Like I said in another reply, work with a PM that's really good at user research (like scientifically-good).
time0ut 8y ago
Don't just watch. Measure. Observers have biases. Figure out what you want to improve, figure out how to tell if you have, test changes against that.
magicalhippo 8y ago
I often find that it's not that they lie, it's that they're often trying to come up with solutions and present those, rather than explaining the root problem. But yes, watching them work is invaluable. First time I visited one of our clients, I noticed two issues that I had no idea of: 1. All users had dual-monitors, and maximized our application across both. Our application is MDI still. This was a very bad fit for dialogs that were (for historical reasons) had the default position set to center-of-application, rather than center-of-screen. Try reading a dialog split right across two monitors. So when I got back I immediately did a pass to make them all center-of-screen. 2. When doing the main data entry, they didn't look a the window they were entering data into, but rather the source material. Thus any additional controls or dialog would mess up their workflow big-time. That's when it really hit me why the user interface for that window was rather clunky...
glun 8y ago
While they might not know what they need, they definitely know what won't help them.
tomc1985 8y ago
I think that this attitude a great example of the arrogance that permeates a lot of the redesigns that get dropped on people today. Yes one needs to sometimes throw out suggestions (because they aren't aware of techniques) but when users complain or praise something that needs to be listened to because they are literally telling you their workflow and describing potential optimizations. Nothing is more obnoxious than designers telling me I won't want something! It's like, 'fuck you, you don't know me, stop discounting what sounds like a good idea!' Ask things to your users, and then listen to them! Watch them when they show you things, watch them when they work, watch their emotions to see what they like and don't.
beamatronic 8y ago
A/B testing can help. Show them 2 or 3 different ways and watch them as they work with each.
maxxxxx 8y ago
You have to do both. Watch and ask.
dagoat 8y ago
I think you need both. You need to ask/provide a way for users to tell you what they want (fixing or features). And you also need to observe users using the product.
rodolphoarruda 8y ago
A friend's company actually films users using software/websites, analyse their reactions and build a thorough report on UX. All their science is based on the concepts from IA -- information architecture -- from a decade or so ago.
toss1 8y ago
Yes, users do lie all the time. So ASK, but do not ask direct questions (e.g., what do you want?). Instead, ask what are their problems, their pain points, and what items they rely on most. And OBSERVE -- watch what they actually do. What items they most rely upon (i.e., do NOT change that stuff if you can avoid it). These answers & observations can then form the basis of your solution, which should relentlessly focus on their needs (and not your own design conceits). Story from a friend who wrote & sold software into IT shops: When he asked "Do you like these features and would you buy this software?", he got all kinds of "Yes" answers, would write the package, and find few buyers. When he switched to asking (basically) "What are your pain points, what is aggravating, time consuming, etc?", then writing software to address those issues, he got plenty of sales and happy customers. It's the indirect question that matters.
crispyambulance 8y ago
> Except users lie all the time... OK, observation is certainly important, but if they tell you something LISTEN. Users who have "skin the game", who actually have to use the application usually have valuable observations and suggestions. Does it mean that you should uncritically implement what they ask for verbatim? No, but sometimes the insight is right in front of you if you're receptive to it.
andrepd 8y ago
>Watch them work Exactly. It's your job to see that, for example, people spend lots of time manually doing X in Excel, and design a tool to do it for them.
fpig 8y ago
Another thing is that suggestions from users often suffer from the "XY problem" issue. So even when a user has a ridiculous suggestion or request, there might be a legitimate issue behind it.
megy 8y ago
You don't ask them how do they want it redesigned. You ask them what they like, what they don't like. And preferably, you get a chance to see them use it.
holografix 8y ago
Couldn’t agree more! Often the users look at you as “the expert” as if you could tell them how to do their job and show up basically with a ready app.
ben-schaaf 8y ago
Its not always an option, but another alternative to asking and observing is becoming. If you yourself (or someone on your team) have previously been or are currently a user then you can usually answer a lot of the questions yourself with much less of a bias and maybe find solutions you wouldn't be able to by just asking and observing.
- jrochkind1 8y ago
  While this can give you insight, I think there's a huge danger of thinking you are a _typical_ user when you are not at all representative. I have seen this happen with disastrous consequences. I think "becoming" can supplement, but never ever substitute for observation.

duxup 8y ago

I probabbly didn't emphasize it enough but yeah you give them something mvp like and watch them and get feed back on it. Recently, I actually forgot to make a whole series of changes on a dashboard that were requested. They hated the old version .... but I didn't change it before the next meeting ... and then they loved it at the recent meeting. It was the same one they hated on. Sometimes you also just have to let them get used to it too ;) It's an iterative process no doubt, but as a dev... I'm no better at knowing what I'll do too. Iv'e worked something up and weeks later changed it completely after I've used it.

carlmr 8y ago

Why not both? It's not even that people lie, but they might not know what's possible, limiting the amount of information they will give you.

ThomPete 8y ago

Exactly. Asking users is only interesting if you know what you are looking for and you have to ask around the questions instead of leading them to answer. 90% of the time observing is what you want.

bachmeier 8y ago

> Except users lie all the time. That's the starting point for all the garbage enterprise apps I've ever used. Someone that has no clue what the users are doing makes a decision about how best to design an app that they don't even know how to test. Don't ask them how to design the app. Ask them what they do with the app, then find the best way to get them where they need to go. Then let them test the first and second and third versions, and listen to their feedback without an assumption that "they just don't understand my genius". It's important to distinguish between casual social media app users and power users spending hours of their day using an app to get their work done.

vectorEQ 8y ago
ofcourse you dont ask them how to design. you are hired as the designer. ask them for specifications / limitations / painpoints in the current system etc. etc. and base your design upon their feedback on actual relevant questions. a plumber doesnt ask his customer how to plumb. just which pipes need fixin! doesn't go fix the toilet if the shower is broken :S
- chrismeller 8y ago
  I think the better analogy would be installing a whole new bathroom (it’s a redesign after all). In that case the plumber could and should ask where the sink is going, even if he was only told to move the toilet. Why? Because maybe the sewage line is over there and about to be covered over with concrete and they’ll have to tear up all of that to move it in two weeks, but the sink hadn’t arrived yet so no one told him that would move either. The point is not that the plumber is asking his customer how he should do his job, but that he can be more valuable if told the whole scope and impact of his job. Similarly you can’t just ask a user “how could this screen work better”, you need to watch them work so that you see that that screen isn’t even the problem - they’re clicking off of it 15 times every call - but you didn’t even know to ask about the other page.
  - erikpukinskis 8y ago
    > you can’t just ask a user “how could this screen work better” Why would you ask that anyway? You've already assumed the problem and solution at that point. You ask how it's going, very generally and let the conversation lead you to their pain points. You don't ask about the UI, which they are not an authority on. You ask about their subjective experience, which they are.
    - tabtab 8y ago
      The best approach is to watch them do their work and ask a lot of questions. For example, "Why did you have to leave this screen to go find X?"

tom_ 8y ago

You can probably find a better term for this phenomenon than "lie", which implies a degree of active intent to deceive.

adrianhel 8y ago
Users have ideas. These ideas are motivated by pains and pleasures. When asked what they want, they present the ideas they believe will reduce pains or increase the pleasure of using the software. It's up to you to 1. Determine if the idea reduces pain, increases pleasure or both. 2. Test whether the hypotheses are correct. Rephrased: Users come up with untested ideas

chrisseaton 8y ago

> They don't know what they need or want. If they're so deluded about what they want what makes you think you can see through that and find a solution more clearly than they can?

jfengel 8y ago
Because you know something about UX. Good design is a cross-disciplinary activity, mixing the domain knowledge in users' heads with the design knowledge in the heads of developers/designers. This is hard to do well, with few hard-and-fast rules, but it often benefits from collaboration. There are often big a-ha! wins when you're watching a user and ask a question like "why did you do that that way?" or "what if I redesigned it like this?" Users often can't ask those questions because they're focused on doing their job rather than the meta-job of improving it. They often don't realize what's possible. That's no excuse for ignoring their suggestions, and unfortunately many users have been specifically discouraged from thinking how to improve their own experiences by developers who were lazy, incompetent, or merely bureaucracy-laden. But fostering a collaborative environment, where developers learn something about the domain and users learn something about how their tools are created, can lead to much better user experiences than either could do alone.
jolmg 8y ago
More to jfengel's point, it's not just UX, you have more knowledge of what is technically possible. People will often come up with very convoluted solutions to problems because they don't have a good view of what is technically possible. It also happens that people only take their own needs into account and not those of the other users they're indirectly interacting with via the app. They'll tell you that certain app objects should have certain constraints, that certain things should be impossible, and that such assumptions can be used as foundations for other features. Then you go visit another user and they'll tell you very plausible conditions under which those things should be possible and even required. Talking to users is good, but you also need to observe them as a group and sometimes weigh their needs against each other.
deleted 8y ago
[deleted]

Bjartr 8y ago

> Except users lie all the time. They don't know what they need or want. People are horrible at being logical about what will actually help them. Asking them to describe the problems they have and doing exactly what they say will fix those problems are two very different things. The difficult, but critical, step here is to decipher what root problem should be fixed given the feedback users have given you. Sometimes the right thing to change is something the user never would have thought of to ask for, but can be figured out from what they did ask for. Remember, your users (usually) aren't UX designers, they just know where they get frustrated.

foobarrio 8y ago

Consider their response an input signal and not necessarily instruction from them. If my little niece comes crying saying there is a monster under her bed, of course I know it's not a monster but I'll still go look. Maybe a toy is under there making a noise, or the heater pipes, or the cat is moving stuff around.

ErikVandeWater 8y ago
This is how you get your kid eaten by monsters. But in all seriousness, this is a good point. In addition, you have to think about the user you are listening to. Are they smart? What terminology do they know that other users don't? Maybe they figured out a workaround to some problematic UI already, and you can just make that workaround global.
Bartweiss 8y ago
I've heard a corresponding principle in both game design and writing expressed as "When people tell you what needs fixing, they're almost always right. When they tell you how to fix it, they're almost always wrong." Feedback is great, but feature requests and proposed changes aren't actually feedback, they're new ideas.

noir_lord 8y ago

I've found its not that they lie (all the time) it's that often they don't have the time or mental energy to figure out what they want and even if they do they lack the tools to communicate it. That is fundamentally a human problem and I'm not sure what technology can really do to significantly improve the solution which is to slog through it and listen to feedback.

cmiles74 8y ago
I think many people don't really understand how they perform the functions of their job. Some things they enjoy doing, some things feel like busy work: all the things are mixed together over the course of the day. Picking and teasing the separate pieces apart and dealing with them individually is always hard for people and for some more than others.

potta_coffee 8y ago

It's true, but you still need to ask, and watch them work. But what it often comes down to is that the company underestimates the effort involved, they push you to rush the process, and communication is the first thing to suffer.

manyxcxi 8y ago

> Watch them work. This x1000! I took on a freelance project for a heavy machinery hauling company. They were a year into transitioning away from some customized off the shelf Enterprise scheduling and dispatch system into some custom built software by an “Enterprise” consulting company. They were originally bringing me in to audit what the team that was building it but that pretty much changed on the day I submitted my proposal... In the proposal I wrote to my then prospective client I allocated a couple of days of onsite interviews with “lower than management” people that would be using the system or it’s outputs, and a week of shadowing people in all roles that would be directly using the system. The project sponsor (to his credit) didn’t ask me why I would need to do that, he started laughing and exclaimed that I was the only person to ever even recommend this approach. We ended up re-writing the proposal into multiple phases where I just interviewed and assessed, documented their current processes, provided business process workflows and suggested ways their current workflow could be optimized, irrespective of any one technological solution. A crappy process, then automated, is still crappy. I wound up spending 6 weeks before even proposing anything that had to do with technology. My implementation proposal was set in phases that would bring related functions to light in a way that their teams could begin using them right away and we could collect feedback and iterate while producing the next set of features as well. It was their first ‘agile’ project or contract and the fear was quelled when after the first month I had put more useful software in their dispatchers hands than the “Enterprise” team had in a year. From day one interviews to “finished” project we spent about 6 months and that system still lives 9 years later- though it has been modernized and upgraded every so often in the intervening time, it is still one of my proudest projects even though it was one of the least “sexy” I’ve ever done.

ljoshua 8y ago
Great war story with enough specifics to be learnable, thanks for sharing! Reflects my experience as well.
freedomben 8y ago
My first paid gig I did this with wild success also. After that I tried to do this several times and was always met with incredulity. Management never seemed to grok the importance of this, to the point where I started thinking maybe my first experience had been a fluke (gaslighting). While I no longer think this is practical (unless you are the one in charge), I do recommend it whenever possible. The product will be orders of magnitude better, but expect management to strain at the gnat of paying a software developer to watch a non-technical person do their job.

ams6110 8y ago

And only change what are real problems. Maybe something like a user needs to navigate to three different pages to get the information they need. That's something you can improve. But resist the urge to do a general facelift or reorganization just for cosmetics. Users can fly through the ugliest interfaces, even text-mode terminal interfaces, once they get used to them. Change that at all, and they will be stumbling around and complaining. That can be worth in the end if their usual workflows are now shorter and faster, but tread carefully. Users of enterprise apps really don't care too much about how they look.

pwthornton 8y ago

Some of this comes down to phrasing. We should both ask and observe (but it has to be the right kind of asking). The asking should be user interviews and contextual inquiry to understand their problems. What are they trying to solve? We shouldn't be asking them to design our products for us, because users often don't know what they want or what they even do. This should typically come very early in the process as foundational work. Observing people both working and in a usability testing setting will help us learn what is and isn't working. As we get into the prototyping stage, it should be a lot more observing and testing. I think what you are responding to is this idea that all we need to do is just talk to our users, and you are correct, that is very wrong. Just asking users what they want is a good way to give them something they won't use. When we do ask people questions, they need to be done in a methodical and probing way.

jrochkind1 8y ago

This is why user/usability/UX research is actually a _thing_. Like a discipline, a thing to learn, a thing where experience and skill matter. Yes, you can't just "ask". But there are certainly ways to learn. Doing a major UX redesign without doing any UX research seems like asking for trouble -- and I don't trust the conclusions drawn from the outcome, still without being based on UX research, either.

phkahler 8y ago

>> Except users lie all the time. They don't know what they need or want. People are horrible at being logical about what will actually help them. That's a bit harsh. IMHO people don't know what's even possible, so they can't tell you what the solution is. Sometimes they can tell you what bothers them about what they've got even if they don't know what would be better. The rest of your comment it good though. Watch them. Look for things that look hard or redundant. Ask if they ever get tired of X, what gets in the way, etc... But don't necessarily expect them to tell you how to make it better. I like to say users don't have requirements. They have problems.

NeedMoreTea 8y ago
They often gloss over how they might use an app, or use it differently to described when doing real, live work with real data instead of test scenarios. Just as I would likely gloss over much of what I do when I drive a car, as I no longer think about it. Sometimes they use something differently to how their supervisors think they do. Maybe they found a handy shortcut or unintended timesaver, maybe relying on a side effect or unused field. Best to watch a few at all levels of seniority, if at all possible, to fully understand how to deliver what they might need. Then dig into the issues, shortcuts and timesavers or bottlenecks they currently have.

funkaster 8y ago

> They don't know what they need or want Of course they don't always know. That's why you have to do proper user research. You should not just build what they are asking: you should try to figure out why they are asking for a particular solution, try to find patterns among all the users, find the actual source of the problem and then propose a solution that could work for them. This is, of course, an over-simplification. Like I said in another reply, work with a PM that's really good at user research (like scientifically-good).

time0ut 8y ago

Don't just watch. Measure. Observers have biases. Figure out what you want to improve, figure out how to tell if you have, test changes against that.

magicalhippo 8y ago

I often find that it's not that they lie, it's that they're often trying to come up with solutions and present those, rather than explaining the root problem. But yes, watching them work is invaluable. First time I visited one of our clients, I noticed two issues that I had no idea of: 1. All users had dual-monitors, and maximized our application across both. Our application is MDI still. This was a very bad fit for dialogs that were (for historical reasons) had the default position set to center-of-application, rather than center-of-screen. Try reading a dialog split right across two monitors. So when I got back I immediately did a pass to make them all center-of-screen. 2. When doing the main data entry, they didn't look a the window they were entering data into, but rather the source material. Thus any additional controls or dialog would mess up their workflow big-time. That's when it really hit me why the user interface for that window was rather clunky...

glun 8y ago

While they might not know what they need, they definitely know what won't help them.

tomc1985 8y ago

I think that this attitude a great example of the arrogance that permeates a lot of the redesigns that get dropped on people today. Yes one needs to sometimes throw out suggestions (because they aren't aware of techniques) but when users complain or praise something that needs to be listened to because they are literally telling you their workflow and describing potential optimizations. Nothing is more obnoxious than designers telling me I won't want something! It's like, 'fuck you, you don't know me, stop discounting what sounds like a good idea!' Ask things to your users, and then listen to them! Watch them when they show you things, watch them when they work, watch their emotions to see what they like and don't.

beamatronic 8y ago

A/B testing can help. Show them 2 or 3 different ways and watch them as they work with each.

maxxxxx 8y ago

You have to do both. Watch and ask.

dagoat 8y ago

I think you need both. You need to ask/provide a way for users to tell you what they want (fixing or features). And you also need to observe users using the product.

rodolphoarruda 8y ago

A friend's company actually films users using software/websites, analyse their reactions and build a thorough report on UX. All their science is based on the concepts from IA -- information architecture -- from a decade or so ago.

toss1 8y ago

Yes, users do lie all the time. So ASK, but do not ask direct questions (e.g., what do you want?). Instead, ask what are their problems, their pain points, and what items they rely on most. And OBSERVE -- watch what they actually do. What items they most rely upon (i.e., do NOT change that stuff if you can avoid it). These answers & observations can then form the basis of your solution, which should relentlessly focus on their needs (and not your own design conceits). Story from a friend who wrote & sold software into IT shops: When he asked "Do you like these features and would you buy this software?", he got all kinds of "Yes" answers, would write the package, and find few buyers. When he switched to asking (basically) "What are your pain points, what is aggravating, time consuming, etc?", then writing software to address those issues, he got plenty of sales and happy customers. It's the indirect question that matters.

crispyambulance 8y ago

> Except users lie all the time... OK, observation is certainly important, but if they tell you something LISTEN. Users who have "skin the game", who actually have to use the application usually have valuable observations and suggestions. Does it mean that you should uncritically implement what they ask for verbatim? No, but sometimes the insight is right in front of you if you're receptive to it.

andrepd 8y ago

>Watch them work Exactly. It's your job to see that, for example, people spend lots of time manually doing X in Excel, and design a tool to do it for them.

fpig 8y ago

Another thing is that suggestions from users often suffer from the "XY problem" issue. So even when a user has a ridiculous suggestion or request, there might be a legitimate issue behind it.

megy 8y ago

You don't ask them how do they want it redesigned. You ask them what they like, what they don't like. And preferably, you get a chance to see them use it.

holografix 8y ago

Couldn’t agree more! Often the users look at you as “the expert” as if you could tell them how to do their job and show up basically with a ready app.

ben-schaaf 8y ago

Its not always an option, but another alternative to asking and observing is becoming. If you yourself (or someone on your team) have previously been or are currently a user then you can usually answer a lot of the questions yourself with much less of a bias and maybe find solutions you wouldn't be able to by just asking and observing.

jrochkind1 8y ago
While this can give you insight, I think there's a huge danger of thinking you are a _typical_ user when you are not at all representative. I have seen this happen with disastrous consequences. I think "becoming" can supplement, but never ever substitute for observation.