Well as developer I come across this the other way around. Users often say things in a general way like "Make it easier to use". But how can you know how to do that?
There are many easy to use programs out there. But though their interface looks simple, it's the result of probably years of work by dozens of programmers - or at least building on prior experience of dozens of programmers on previous programs. In case of a big company like Microsoft probably hundreds of programmers have worked on it. And made many mistakes along the way, things they thought would work but didn't. And with feedback from users to find out how they interacted with it.
Or they may tell you how to set out the user interface, e.g.: "Put all the controls into a single page so I don't need to go around from one page to another or one window to another to accomplish the task".
But that may be self contradictory. They have too many controls to fit onto a computer screen, and want them all to be present at once without navigating between them. Or suggest some way of dealing with it that you know from experience is totally unfeasible and would be hugely frustrating to the user such as for instance making the window scrollable and many times the size of the available monitor display - so you have to keep scrolling up and down, and maybe sideways and diagonally to find the extra controls and have to remember the position of hundreds of controls that are outside the display area of the screen. That just can't be made to work.
So what we know about as programmers are - quite a lot about what does and doesn't work in a user interface, often learnt the hard way by trying to program ideas and finding they don't work. Things you may think are the next big idea in user interfaces, such as making everything a big scrollable window to take that simple example - may be things the programmer already knows just won't work at all. Because that's their speciality and area of technical expertise.
It's like asking someone to design a bridge and they suggest a suspension bridge or a cable stay bridge, or a truss arch bridge, or a bow bridge. And you then say that you want to go with a different type of design of bridge.
That's fine, you may have e.g. aesthetic reasons for preferring another type of bridge for instance. But if your bridge designer comes back to you and says "A cable stay bridge just doesn't make sense for this type of bridge" or "It's almost impossible and would be hugely expensive to build this as a truss arch bridge" or whatever - then you listen to the bridge designer.
It's a bit like that with user interface designs.
As well as that - the users often have very little idea of how to implement what they want. They know or think they know what it is they want or need. But their idea of how to make it easy to achieve this with the program may not match the thing they want to be able to do.
They may for instance, often they say they want me to add some feature to a program. But when you look at it closely, you find out, that actually the reason they wanted to add this was to fix some other issue in the program which they haven't yet talked about. There was something they couldn't see how to do, and they suggested this new feature as a way to do it. I used to just program these features for users - but then found that often after programming it just as they asked for - that (maybe sometimes after some weeks of fulltime work :) ), you then find it is not what they needed at all and doesn't solve their problem. And nowadays often after talking to them, I find a much simpler solution that solves the original problem that was their reason for asking for the feature in the first place.
Sort of like - to use an analogy - someone wants to be able to walk over soft snow. But instead of asking you to design a snowshoe, they say - "Please can you make me a pair of tennis rackets to attach to my feet? I'm sure that it will make a huge difference to users if only they can attach tennis rackets to their feet". And they ask that beecause they've come to the conclusion that this is the right way to cross soft snow.
So then you get in a long complex discussion asking them to explain how they want the tennis rackets attached to their feet, and you assume they want to play tennis using their feet, and put in all sorts of tweaks and features based on that assumption, and never in any of that discussion is soft snow mentioned. And the end result is something that is no good either for playing tennis or walking on snow. And maybe all along you had a snowshoe already built into the program but there was some little thing that got in the way of them using it as intended, which lead them to the conclusion that it "just doesn't work" which is why they came up with this request for tennis rackets. And after you've spent weeks trying to program in this tennis racket attached to their feet, you find out that a few hours of work fixing the built in snowshoe would have solved all their problems.
It can be very frustrating as a developer when this happens. It just takes a few hours of thought to come up with the ideas, but the developer will spend working days, weeks, or more to try to program them - and then find that they don't work - a very inefficient way of proceeding.
So that's why developers may ask rather strange questions, which users may find hard to understand the motive for them. And may be able to say straight out, cutting through a long explanation "Sorry that won't work, or is far too hard to do - but what about ...". They come to it with another perspective. See things from a somewhat different angle and in a different light from the user. In my case I'm not employed by anyone else, I write my own programs and ask users for feedback and often get requests for new features from them, but the situation is similar I think.
There are many easy to use programs out there. But though their interface looks simple, it's the result of probably years of work by dozens of programmers - or at least building on prior experience of dozens of programmers on previous programs. In case of a big company like Microsoft probably hundreds of programmers have worked on it. And made many mistakes along the way, things they thought would work but didn't. And with feedback from users to find out how they interacted with it.
Or they may tell you how to set out the user interface, e.g.: "Put all the controls into a single page so I don't need to go around from one page to another or one window to another to accomplish the task".
But that may be self contradictory. They have too many controls to fit onto a computer screen, and want them all to be present at once without navigating between them. Or suggest some way of dealing with it that you know from experience is totally unfeasible and would be hugely frustrating to the user such as for instance making the window scrollable and many times the size of the available monitor display - so you have to keep scrolling up and down, and maybe sideways and diagonally to find the extra controls and have to remember the position of hundreds of controls that are outside the display area of the screen. That just can't be made to work.
So what we know about as programmers are - quite a lot about what does and doesn't work in a user interface, often learnt the hard way by trying to program ideas and finding they don't work. Things you may think are the next big idea in user interfaces, such as making everything a big scrollable window to take that simple example - may be things the programmer already knows just won't work at all. Because that's their speciality and area of technical expertise.
It's like asking someone to design a bridge and they suggest a suspension bridge or a cable stay bridge, or a truss arch bridge, or a bow bridge. And you then say that you want to go with a different type of design of bridge.
That's fine, you may have e.g. aesthetic reasons for preferring another type of bridge for instance. But if your bridge designer comes back to you and says "A cable stay bridge just doesn't make sense for this type of bridge" or "It's almost impossible and would be hugely expensive to build this as a truss arch bridge" or whatever - then you listen to the bridge designer.
It's a bit like that with user interface designs.
As well as that - the users often have very little idea of how to implement what they want. They know or think they know what it is they want or need. But their idea of how to make it easy to achieve this with the program may not match the thing they want to be able to do.
They may for instance, often they say they want me to add some feature to a program. But when you look at it closely, you find out, that actually the reason they wanted to add this was to fix some other issue in the program which they haven't yet talked about. There was something they couldn't see how to do, and they suggested this new feature as a way to do it. I used to just program these features for users - but then found that often after programming it just as they asked for - that (maybe sometimes after some weeks of fulltime work :) ), you then find it is not what they needed at all and doesn't solve their problem. And nowadays often after talking to them, I find a much simpler solution that solves the original problem that was their reason for asking for the feature in the first place.
Sort of like - to use an analogy - someone wants to be able to walk over soft snow. But instead of asking you to design a snowshoe, they say - "Please can you make me a pair of tennis rackets to attach to my feet? I'm sure that it will make a huge difference to users if only they can attach tennis rackets to their feet". And they ask that beecause they've come to the conclusion that this is the right way to cross soft snow.
So then you get in a long complex discussion asking them to explain how they want the tennis rackets attached to their feet, and you assume they want to play tennis using their feet, and put in all sorts of tweaks and features based on that assumption, and never in any of that discussion is soft snow mentioned. And the end result is something that is no good either for playing tennis or walking on snow. And maybe all along you had a snowshoe already built into the program but there was some little thing that got in the way of them using it as intended, which lead them to the conclusion that it "just doesn't work" which is why they came up with this request for tennis rackets. And after you've spent weeks trying to program in this tennis racket attached to their feet, you find out that a few hours of work fixing the built in snowshoe would have solved all their problems.
It can be very frustrating as a developer when this happens. It just takes a few hours of thought to come up with the ideas, but the developer will spend working days, weeks, or more to try to program them - and then find that they don't work - a very inefficient way of proceeding.
So that's why developers may ask rather strange questions, which users may find hard to understand the motive for them. And may be able to say straight out, cutting through a long explanation "Sorry that won't work, or is far too hard to do - but what about ...". They come to it with another perspective. See things from a somewhat different angle and in a different light from the user. In my case I'm not employed by anyone else, I write my own programs and ask users for feedback and often get requests for new features from them, but the situation is similar I think.
About the Author
Robert Walker
Writer of articles on Mars and Space issues - Software Developer of Tune Smithy, Bounce Metronome etc.Studied at Wolfson College, Oxford
Lives in Isle of Mull
4.8m answer views110.4k this month
Top Writer2017, 2016, and 2015
Published WriterHuffPost, Slate, and 4 moreHuffPost, Slate, Forbes, Newsweek, Business Insider, and Science 2.0