Talking to the users, allowing them to show you what they are trying to do with your software, almost feels like cheating, because of how easy things suddenly appear to be when uncertainty fades away.

Obviously, the number of uniquely different users has an influence, and users most often do not truly know what they need, but that's our job to tease appart.

Turns out the users most often benefits from small changes that reduces friction toward achieving their goal. Any time saving will be appreciated, but only if it can be trusted to work. Nothing worse than the dread of knowing an action might or might not work randomly.

I use most software today with a constant sense of fear that the next action will break something and waste my time. Undo probably doesn't work properly anyways

▲

devmor 3 hours ago | parent [-]

"What problem are we trying to solve?" is a question I have to ask constantly in corporate development environments, and rarely does anyone presenting the task to be done actually know the answer!

It's very frustrating.

▲

hathawsh 2 hours ago | parent | next [-]

I try to remember to say something like this: "This is an interesting solution, but I'm not confident we have a shared understanding of the problem we're solving. I have a few guesses, but I don't want to bias the discussion, so please restate the problem without suggesting a solution. If it's too difficult to explain, I can suggest what problems I think you might be running into." I wish I always remembered to say that. :-)

▲

robertlagrant 2 hours ago | parent | prev | next [-]

It can be the case that people don't want to accidentally mis-state the problem, or get into a debate about the problem because they know people will chime in about nonessentials. I would recommend "Have we written down the problem we are trying to solve? I'd like to understand more." And get it written down if it isn't already.

	▲	computomatic 17 minutes ago \| parent \| next [-]
		This is likely the start to a useful approach. I suspect the crux of the challenge is that engineers who need to write code get very pedantic in their questions and picking the answers apart (because we need to be! code leaves no room for ambiguity or intuition). And you can imagine how that feels from the other side. I imagine a lot of people feel like an engineer asking about the actual problem feels like getting goaded into some sort of pedantic debate. A natural response will be to try to dictate what to build (often micromanaging) and avoid the discussion about why at all costs. Writing offers a bit of a neutralizing buffer, at least.
	▲	some_furry 2 hours ago \| parent \| prev [-]
		Trying to position the conversation as "we're on the same team, trying to figure the problem out together" also helps a lot of the intensity of these conversations melt away.

▲

natdavidson 29 minutes ago | parent | prev | next [-]

I wouldn’t ask that if you want to keep your job.

▲

win311fwg an hour ago | parent | prev [-]

Reverse engineering the problem from someone's solution is the job. If you find it to be frustrating, you might be in the wrong profession.