This is one where I'd look for sideways solutions. Say point blank that you don't value their input and you won't get it. But (as you've reported) - spend lots of time validating the idea, but explaining why the solution won't work, and waste lots of time and get very little value.
I've had a lot of success with guiding the conversation to meet my own ends on these. My goal is to - (1) confirm and clarify the issue (2) clarify what the criteria for a solution are (3) vet an approach that leads to a final answer
So that's where I start - I don't start with whether or not the solution will work, I start with getting the full details of the problem, clarified in engineer-speak (not analyst-speak). I don't know quite how the issues come to your doorstep - phone calls can be very different from something with a time-delay like email or trouble tickets.
But in all cases, I'd make it clear that you take their input and the nature of the issue very seriously. But I usually like to have a checklist and I don't mind telling the users that I need to fill this out before we get to the solution part:
- What did you see that was wrong/bad?
- Was is the data or the way it was presented?
- What were you doing when it occured?
- What is it keeping you from doing?
- Does it happen any other time? Can you make it happen again? Can you give me steps so I can make it happen again?
- What's the priority here? (should be somewhat corrated to "what is it keeping you from doing?")
I know it sounds crazy, but also make sure the users are very much aware that you are taking notes, and getting it all down. Paraphrase what you heard back and make sure you've got it right. A bunch of rapid fire questions asked perfunctorily will generate a hostile response. A deep conversation about the problem will soothe the fear that you aren't going to do anything about it.
It needs to stay somewhat on track, but when you get to "what were you trying to do?" and "what can't you do with this problem happening?" - let it go a little into the analyst's world. While you can't solve the problem "their way", you do need to solve the problem in a way that works for them, and that means you need to know more than a little bit about what they are trying to get done. It's a mushy space - you can spend infinite time here, and smart people LOVE talking about what they do - so there's some work guiding the conversation on these.
Clarify the requirements of a solution
Unless the issue is mind-bogglingly clear, there are probably numerous available solutions. But a solution for the analyst is not necessarily feasible and a solution for the SW developer many not actually be a solution for the analyst. Side step the "I'm right/you're right" conversation and talk about the requirements for the solution.
Sometimes I can break it into two parts:
- If I was to give you something quick and dirty, what is the absolute smallest change that I could make that would satisfy you?
- If I had a magic wand and could fix it right now for no time and no effort - what would the solution look like?
From there, it usually falls on the software person to redefine these solutions as requirements. Although analysts are really smart, factual, information aware people - they are not software developers and they don't understand the very specific jargon that is used in the methods of designing a user experience. So I usually end up stating what I think is obvious about the requirements of the two solutions - "must haves" being anything in both the bare minimum and the gold plated option. "Want to haves" in the ideal solution only. I ask for two peices of data, because I often un-cover a lot of hidden "I don't need it it at all, it's just my assumption" type stuff in that "bare minimum" solution that doesn't ever show up in the "nice to have" solution.
Just like developers assume things about users, users often make assumptions about what's "easy" - usually they are decent and don't want to be a bother, so they ask for what they think is "easy" and then get stressed when you tell them their solution is not at all easy...
Usually a simple change is something that the developer and user can agree on on the phone at this point... but I'm going to bet that the degree of frustration you describe is not usually of that type.
So the developer may need some time to craft something. But this is a good time for prototypes, screen shot samples and other ideas to get vetted back to the user before any heavy lifting occurs. It's like a mini-agile project - throw something at them and get insight on whether it works before really implementing and testing anything.
Taking time here is OK. I know I always feel pressure to jot something on a whiteboard and be done with it... but this is the time where you can stop for a sec and really think it out before promising the impossible. I've found that taking a few moments to think here actually builds trust, because at this point they realize the problem isn't "easy" but you are as engaged in making a solution as they are in getting the problem fixed.
This usually builds a lot of trust. You've never said "no", "you're wrong" or "your ideas are utterly impossible", so you never built the resentment that comes from being shut out. People usually like providing the details of their problems, their dreams of a perfect product and giving opinions about something that isn't made yet - so you're not asking for anything crazy.
I've found that very rarely do people (even high level people) expect that you will do what they ask for with no questions, concerns, or alternate ideas. In fact, most smart people realize that there has to be a round of question asking before going forward.
It's just how you pace the questions and which ones you ask.