Back in the 1980s, when I was a developer at a software company, I was walking a user through a feature that did not work intuitively at all. After a particularly frustrating session, with me struggling to explain and the user struggling to understand, the user finally asked:
“Why does it work that way?”
The answer to that question is the same today as it was then: it works that way because some developer somewhere decided that’s the way it should work.
Users are often surprised to hear that there is no higher authority, guild, union, or standards organization that determines how software should be designed. There is no Software Council that hands down rulings about what user interface elements must be present or how a program should behave. There are guidelines, best practices, and conventions, and sometimes developers even follow them. But for all software, it comes down to somebody making a decision.
And that person, being human, may be tired from months or years of development, frustrated by changing technology that forces rewrites, or even scared by some tech article that predicts no one will want their product anymore (which usually turns out to be not true, but they won’t find that out until three months later). They might have been distracted by some pretty, shiny thing that the industry says everyone wants, but in practice, users hate it.
That’s why the software works that way.
Nowadays we have UX (User Experience) designers, but that role didn’t become a thing until the 1990s. Before that, any user interface was pretty much built by developers. And even today, for some companies, the ‘UX team’ is a dev with a Figma license who draws pastels of fruit baskets on the weekend.
But if that’s the case, why don’t developers make more of an effort to understand users, and make the software more useful and easier to use?
Reason #1: Developers and users are two different species
A developer comes at a software problem from a completely different perspective than a user. The developer looks at the logic of the data being passed around, where and how it’s going to get stored and retrieved. The user looks at it from the viewpoint of how to put in real-life data, such as a customer invoice or sales transactions, and later extract some kind of useful compilation or report.
In other words, the user is interested in the beginning and end — putting in the data, and getting it out in another way — while the developer is interested in the middle part: the storage, retrieval, and manipulation of the data.
Reason #2: Users are ‘stupid’
My first job as a developer was at a small startup, where every member of the development team was required to spend time doing phone support for the software we had written.
Some devs, like myself, came away with a deeper understanding of how software design needs to meet the user where they are. Menu options needed to make sense, and things on the screen needed to resemble, as much as possible, where they sit on real-world items like pieces of paper. This was especially important in the 1980s, when them new-fangled computers were still a bit scary, but it still holds now.
For me, the customer support experience even sparked an interest in documentation, which is eventually where I took my career. I found it far more rewarding to explain how software works and help people get the results they wanted than I ever found writing the software itself.
But others forced to endure customer support came away with a different attitude — they were convinced their knowledge made them superior, and that users complain and have problems with software because they’re stupid.
Yes, there are developers, some of them writing software right this moment that you will end up using someday, who genuinely think you are stupid.
Reason #3: Users should ‘learn programming’
When I first started writing documentation, I needed to understand how a particular piece of accounting software worked. Usually I could figure things out on my own — if the interface didn’t make it obvious, I could poke around the screen, even read the source code in a pinch.
But this one entry screen completely baffled me, so I went to talk to the developer. (I should add that at some software companies, the documentation team has next to zero access to developers, which can be super annoying. At this place, however, I was able to get a few minutes with them when needed.)
It turned out that the entry screen had been designed to make data storage and access easy and quick, with no regard for how hard it would be for a normal user to actually use it. The structure made perfect sense from the developer’s perspective, but was pretty useless from the user’s perspective.
When I asked the developer how a user was supposed to understand all this, he replied that if users understood how it worked under the hood, they wouldn’t need documentation. How dare they not understand data structures, arrays, and do/while loops!
I had to pinch the bridge of my nose for a second to keep from spitting out a rather rude reply.
As a simple parallel, it would be like setting up an SQL database with employee information, and then telling the user, an accountant by trade, they could go ahead and figure out tax withholding themselves with some clever JOINs. Then having disdain for them when they can’t figure it out.
When I asked this dev how I was supposed to explain database structure and query language in the documentation, he shrugged, conveniently forgetting that these subjects are ordinarily taught at university level, as part of the second or third year of a programming degree. Yeah, sure, I’ll just slip in these advanced topics on page 34 of the User Manual, right after we explain what the up and down arrows do.
So no, Mr. Disdainful Dev, the disdain should be aimed at you, for not making the ‘user experience’ something that a user could actually experience, or even want to experience.
It’s a rough world out there
There isn’t much you, as a user, can do about disdainful devs except demand better software and refuse to buy products that provide a poor user experience. Market pressure works, eventually.
But perhaps it helps to know that when software behaves in a baffling, frustrating, or seemingly irrational way, there usually isn’t some deep reason behind it.
A developer somewhere, sitting in a dark room, listening to a heavy metal playlist, sipping a ginger ale, and munching on a bag of Cheetos, decided that’s how the software should work.
So if you’re frustrated, your frustration is valid. Just know it’s not you — it’s the software.
And if you need some decent documentation, I’ve written dozens of excellent user manuals, without ever so much as hinting that the user is the problem. Because they never are.
