I think there are two opposite causes here: either an overly-aligned or completely unaligned mental model.
For developers, bug-blindness tends to be because their mental model is so close to the system's model that both have the same blind spots, and the developer can't effectively think outside the system (the classic "QA walks into a bar, orders 0 beers, orders -1 beers, orders 0.999 beers" vs "customer walks into a bar, asks where the bathroom is, bar immediately bursts into flames").
On the other hand, a common way for regular people to interact with a system is they just... don't have a model. None at all. Like, they click a thing and see what it does, and if it doesn't do what they expect they shrug and click something else. The horror of seeing a non-software person using a software system is realising that they usually cannot tell the difference between expected and unexpected behaviour, because they don't really form expectations in the first place. The computer is more genie than machine.
You can see this in the article: "Google Docs added some kind of delay such that the typing you do into the title box right after you open the doc gets overwritten". That's a developer forming a model of the system. The lay alternative is to simply learn that sometimes when you type in a box, the text appears. Other times, it doesn't. If it doesn't, you try again.
You don't need to understand the system if you abandon the assumption that the system was designed to be understood. And, in practice, the widespread plagues of shitty engineering, anti-features, and lack of respect for the user often combine to make that model the more information-theoretically optimal one.
In that sense, the very thing that makes us miserable is our perverse need to treat Google Docs as an engineered product rather than a cross between a djinn and a symbiotic fungus.
> a common way for regular people to interact with a system is they just... don't have a model. None at all. Like, they click a thing and see what it does, and if it doesn't do what they expect they shrug and click something else. The horror of seeing a non-software person using a software system is realising that they usually cannot tell the difference between expected and unexpected behaviour, because they don't really form expectations in the first place. The computer is more genie than machine.
This is completely lost on most developers, which is why interface and UX designers exist. Developers, especially in FOSS projects, often love to condescendingly assert that users are just not reading the docs, or are not smart enough to understand the software. They’re smart enough— they just don’t want to have to learn about technical implementation details for the same reason most developers are perfectly content to use personal bookkeeping apps instead of learning the best ways to organize that data and making the spreadsheets manually. Most non-technologists get no dopamine hit from solving technical problems, have no need for the requisite knowledge needed to confidently do that, and are often just trying to make the computer do what it must so they can get back to doing what they’re actually passionate and knowledgeable about. When a competing product has an interface built for people without that mental model, it would have to be pretty fucking expensive to not be a no-brainier for most nontechnical users.
I worked at a small company that had a policy of putting devs on front-line support in a rotation, both because it was too small to have dedicated support staff and because the owners wanted devs to understand how users interacted with the system better.
I can assure you that while some users merely think differently than devs, there is cohort of users who are absolutely not smart enough. It's impossible to do any amount of front-line support without collecting some horror stories.
One of my favorites is spending nearly 10 minutes trying to get someone to read a single word on their screen correctly, in a dialog box that was blocking them, containing fewer than 10 words, so I could find the cause of their problem. After nearly 30 minutes to figure out that they had a popup blocking them, and not "the computer doesn't work".
What eventually worked was getting them to spell it to me backwards. That strategy has worked out quite well in other cases too - I suspect because it avoids some of people's built-in autocorrect and dyslexia (autoincorrect).
(I honestly mostly enjoy tech support, and I've done it for many years, sometimes professionally. But some people do seem like lost causes, and are not just having a bad day)
The flip side of this is the pleasant surprise of working with a near-retirement age grandma who assures you that she "isn't technical" and "doesn't know how to use a computer", but will studiously write down every keyboard shortcut on little post-it notes and add it to their collection like they're porcelain cats she found at the Sunday markets. I've watched some of these people operate a computer in a manner reminiscent of watching an F1 driver at work, the screen just a blur as their fingers dance over the keyboard.
Absolutely, the ones that are clearly trying more than make up for the rest imo, and some are stunning. There are a lot of them. And many of the rest are just having a bad brain day and need help rubber-ducking to see the thing right in front of them - we've all been there, many times.
This sounds like "Smart person who has little technical experience and might have cognitive decline from age". The world is fully of people who's intelligence is legitimately lower than you might expect.
I'm not the same person, but probably. There are at least two errors in the quoted fragment, though personally I don't think either is especially indicative of a lack of intelligence.
There were 2 typos in that sentence (the one I didn’t mention is “fully” instead of “full”). Talking about intelligence in such a sloppy manner sounded like a joke to me.
I have experienced this in person with a developer who was failing to debug something. An error message was popping up on screen and he was reflexively clicking it away faster than anybody could read it. Even after being told “an error message is popping up, don’t dismiss it”, even after being told “[do the thing that triggers the bug] and then completely stop without doing anything else”, and a whole bunch of other ways of phrasing it, he was unable to understand that the error message contained useful information that we needed to see. I’m not even sure he was consciously aware it existed or that he was doing it. After many failed attempts at getting him to stop I literally had to take the mouse away from him and do it myself. I was shocked that apparently nothing anybody could say would stop him from dismissing the error message without even looking at it.
Developers should adapt to human behavior not laugh at users for using their precious thing wrong. It's not precious to the user. A probably misremembered quote from Joel Spolsky is users don't love your software, they tolerate your software because it's the least annoying obstacle in the way of doing what they want to do.
The person I replied to described their frustration with a colleague dismissing an error message without reading, not a user. I'm not shaming users not providing clear actionable feedback with stack traces and reproduction steps. I've known fellow software engineers throw their hands up and ask for help because they're 'getting an error', that's what's annoying (because they should know better, ok what have you done before asking me, etc.) not users.
I think this comes from the same problem as notifications on iPhones: if you dismiss them accidentally then it is very difficult to find out what it was.
It is missing the equivalent of the "history" in e.g. browsers and YouTube.
If a user dismisses an alertbox on desktop, why isn't there an history menu item that shows the previous 100 alert messages?
It's so weird to me that this kind of thing wasn't a day-1 kind of thing. Android's has loads of issues too[1], not least of which is that you need to manually enable it.
1: you can't get access to actions or details in the history (e.g. no long-press to change settings), nor does it show you ones you didn't dismiss by hand afaict (I've been having Discord notifications disappearing almost immediately after making a noise, but there's nothing in history even though I saw it for its whole half-second existence because it popped over my screen).
That may be an issue for messages from people but almost anything that pops up because the computer wants to tell you is useless and certainly doesn't need to be findable later. If you want to work on the problem, you can do that when you're ready, at your own initiative, not in the middle of what you're actually trying to do. Programmers wouldn't stand for a language that pops up a modal dialog when you type incorrect code but we think users are somehow less deserving of respect and ready to drop everything to deal with some stupid notification telling them they did it wrong or the software is broken like a crying child demanding his mother knows that he hurt his finger.
Reflexively dismissing error message popups is reasonable behavior because they're almost always unhelpful. It is often easier to mindlessly trial-and-error your way around obstacles than waste your attention on them.
> Programmers wouldn't stand for a language that pops up a modal dialog when you type incorrect code
I have no idea why you think this. The only reason I wouldn't like it is because I might be doing something that requires incorrect code as a placeholder, but if the modal didn't come back after being dismissed (and just sat in a history) I'd be pleased as punch. It's why I moved to rust - I wanted the compiler to stop me.
Not only do you think this, but you think it's somehow a sign of being egotistical and disrespectful that anyone would like to know when they're screwing up. Weird.
> If you want to work on the problem, you can do that when you're ready, at your own initiative, not in the middle of what you're actually trying to do.
As I explained earlier, what we were actually trying to do was debug the problem, and reading the error message was a necessary part of that.
It’s weird you’ve cooked up this little fantasy that the error message was getting in the way when it was the most important thing in the whole process and that was the entire point of the anecdote.
> Reflexively dismissing error message popups is reasonable behavior because they're almost always unhelpful.
Not when you’re trying to debug the problem the error message is telling you about!
There's a selection effect here in that smart-enough users won't bother contacting support if they work around an issue on their own, or if something is actually a non-issue for 99%+ of the user base. The ratio of usage and support contacts can be monitored. I fear a lot of devs develop unproductive mental models of the user purely from a minority sample.
Sure, but whenever you can make life easier for those who have are having hard time without making life harder for those who aren't, you should do it.
For example, no power user benefits from having to use work arounds to make a product function. It's an annoyance to them, and it's an insurmountable obstacle to others.
> I worked at a small company that had a policy of putting devs on front-line support in a rotation, both because it was too small to have dedicated support staff and because the owners wanted devs to understand how users interacted with the system better.
In the 2010s Mathworks, the company that makes Matlab, had a policy that everyone started in frontline support. Including developers. (They probably still have this policy, I don't know.)
The shaping isn't necessarily productive, though. My company has a policy wherein a the dev team are on a rota to assist the support team (and by extension clients) with technical queries. The net effect has been to make me hate customers with a passion usually reserved for opposing political regimes and childhood bullies.
I wish it was just users. I once had to explain to a PM on client's side for 10 minutes that no, the software can't split $1.00 into three exactly equal invoices and we need to put that remaining $0.01 somewhere. In the end it seemed like he's given up without understanding the nature of the problem and escalated to have someone higher up to tell us to add it to the last invoice.
Well, software doesn’t exist for its own sake, the sake of the people that made it, or the sake of some kind of exclusive smartypants club. The purpose is to solve problems or accomplish tasks for people— some of whom are not cognitively gifted. A good interface will take everybody that needs it into account, including people that need less handholding if the usage is different enough.
> there is cohort of users who are absolutely not smart enough
The average IQ is 100, half of people are below that.
Being surprised that customers may be of different intelligence is the kind of thing that comes out of people who have never had to work a retail/restaurant job in high school growing up. If someone has made it that far in life before finding this out, they've lived in a bubble.
People of varying intelligence levels can operate a motor vehicle and yet software can't be designed well enough for them? The failure may be on the SWEs.
Steve Krug's other book, Rocket Surgery Made Easy, got me into usability tests with real users, and how to get it in place in a corporate environment. It's shocking to watch real users use software.
There's an idea in this book, that when using a mouse, smaller buttons are harder to click because you need to stop the cursor inside its hitbox, but moving the cursor to the edge of the screen is easy because it's effectively a huge button whose height is infinite (or infinite width for lateral edges). And hitting a corner is even easier because it effectively has both infinite width and height!
This means that if there is an actual, finite button on a corner, the easiest way to click it is to position the cursor on the very corner, rather than attempting to position the cursor in the middle. But this is ruined if this button has padding. So for example, the start button on windows at the bottom left corner had padding in earlier versions of windows like windows 98, but the actual hitbox of the button shouldn't have padding, so that it's easier to click.
This is all to say that I use Firefox maximized, without a titlebar or menubar, so that the "back" button is at the top left corner of the screen, and the hamburguer button is at the top right corner. But those buttons have padding! If I actually move the mouse to the very corner before clicking, I miss the button
Padding is typically part of the hitbox, margin is not. What you are describing sounds like margin to me. Especially for Firefox since their UI is made with web tech.
But besides being overly pedantic I agree with your general point. If their is a small gap between hitbox and edge of the screen it is very annoying.
But the worst thing IMO is Windows 11 windows which you can grab by the titlebar but not the content area. However often there is no visual indication of where the titlebar starts/stops.
Also, more than 90% of the title bar are active UI elements like menus and close buttons, and you have to guess which few pixels are actually inert enough to allow dragging.
>so that the "back" button is at the top left corner of the screen
"Back" is used so frequently that I consider any mouse lacking a side button for "back" to be incomplete. You don't need to put a high value on your time for upgrading your mouse to pay for itself within its service life.
I think I can see where you're coming from - and it is true that there are cases of dogmatism as a defense for just sucking at UX - but I violently disagree here.
Good UX I believe doesn't mean that the implementation details are hidden, but conveyed in a way that is human-readable.
You do not hide the machine from the man, but translate between them in a way that makes neither of them invisible.
This makes for better experiences, as reality gets bound by.. well.. reality. So you don't get these weird failure modes that live in the gap between the narrative (e.g. "everything just works") and reality (e.g. "networks are always black magic").
This is also important for the user, because by having _a_ mental model (even if it is very low-res), they gain the ability to diagnose issues themselves and not be completely helpless once the magic box breaks down. They might not know exactly what to do, but the direction is very clear.
Agency is important. A lot more important than convenience. And fake convenience through frontloading short-term rewards for long-term systemic instability.
> Good UX I believe doesn't mean that the implementation details are hidden, but conveyed in a way that is human-readable. You do not hide the machine from the man, but translate between them in a way that makes neither of them invisible.
This is where skeuomorphism used to be king before computers ate the world. In the 90s everybody knew how a paper book worked, so document readers presented as books. Everyone knew how a tape deck worked, so audio apps presented as tape decks. Floppy disk as save icon, etc
Unfortunately, the passage of time is inexorable, and by the late 2000s we had a lot of users who had never actually seen a tape deck/floppy disk. And the whole skeuomorphic project came crashing down.
Did it though? Most people young today probably never pressed a physical play/pause/stop button in their lives. Still, they get it. Some icons outlive their era, some don’t.
> In the 90s everybody knew how a paper book worked
> Did it though? Most people young today probably never pressed a physical play/pause/stop button in their lives.
It's hard to call this an example of "skeuomorphism". Those icons were introduced on physical buttons with a certain meaning that everybody had to learn. They have exactly the same meaning on software buttons; the interaction that people have with them now is the same interaction that everybody has always had with them.
This isn't a case of the software appealing to a visual metaphor that made non-metaphorical sense before the software. It was just as much of a metaphor originally as it is now. You might as well call the word "edit" a skeuomorphism in modern software because past software also had "edit" menus.
> the interaction that people have with them now is the same interaction that everybody has always had with them
Right, that was my point. What does it matter what a diskette used to be? Unless something more obvious to convey storage/saving comes along, it’s hardly “crashing down” anytime soon.
The disk icon is skeuomorphic because it's a picture of storage media. That has now gone obsolete and, instead of being skeuomorphic, it's vestigial.
Play and pause icons aren't skeuomorphic. They're symbolic. There is no point at which they were a reference to some phenomenon earlier than or other than themselves.
I guess even without the physical buttons you had to just learn that "play" means "engage the appropriate technical machinery".
> "[play] The meaning "to cause (a recording) to reproduce what is on it" is by 1903, probably from the "make music" sense." - https://www.etymonline.com/word/play
Skeuomorphism didn't fail. It feel out of fashion with designers.
We should distinguish between skeuomorphic interaction design and skeuomorphic iconography. Attempts at skeuomorphic interaction design did fail badly, I'll give you that. Document readers that expect you to turn the page by pulling at the edge of the page, mimicking a page turn in a physical book, they're terrible.
But skeuomorphic iconography works: The more detail you add to an icon, the easier it is to form mental associations with what it does - and that goes even if you don't know the original object that it's based on. Sure, a lot of people have never seen the floppy disk that the traditional Save icon is based on, making the icon less intuitive now than when it was designed. But what would you replace it with? Any alternative you might suggest is just going to be less recognisable.
> Sure, a lot of people have never seen the floppy disk that the traditional Save icon is based on, making the icon less intuitive now than when it was designed. But what would you replace it with? Any alternative you might suggest is just going to be less recognisable.
Obviously you replace it with the three stacked cylinders that symbolize a hard drive. ;D
I've seen an SD card icon used for a save icon before. I think conveniently the shape is similar enough to a floppy that you find it while scanning for it as well
That's one of the things that surprised me (in a positive way) about Mac OS X when I first got to use it -- it actually does indeed do lots of things in an _understandable_ and genuinely simple way. It's also clear how much work went into making the system behave in this way, it certainly wasn't an accident.
In the era of web apps and Electronification of anything I believe most of this is sadly gone, but in the older Mac OS X models you could clearly understand and see the logic behind the software and I believe it worked well for non-technical people from what I observed.
A developer sees an application as a toolkit to help them solve a problem. The more flexibility and power, the better it is. They’ve become comfortable with complex tools on the computer, over the years, because they enjoy learning about and using computers.
A nontechnical end user generally isn’t interested in operating a toolkit— they want to solve their problem, and the application claims to do that. The easier it is for them to get from problem to solution, the better.
When a developer sees a software interface, they see a palette of commands and parameters to pass to a software back end. Understanding that, and it’s implications, took years of learning and intensive usage that has blended into an imperceptible base layer of technological understanding.
To a nontechnical end user, the interface is the software. The button might as well mechanically do something. For whatever reason, often because they didn’t find it interesting, or their cognitive skillset didn’t easily adapt to it, or they just didn’t have the exposure, they didn’t learn about the basic structure of applications, and they’d be years away from understanding it enough to make decisions based on that.
Flexibility and power yields agency for technical users. It blurs obvious pathways and dampens signals for nontechnical users that just want a problem solved.
It’s difficult for experts to see things with novice eyes. That’s one of the most important things a designer can do for the software building process.
Fundamentally, interface design is a communication discipline. There’s a reason it’s a field unto itself, with its own degrees and professional organizations, and there’s a reason it’s often taught in art schools. There’s also a reason that every significant user-facing interface in your life, from your text messaging apps to the ordering kiosks in restaurants— none of which need documentation— were created by designers and not developers. Looking nice is not the point — it’s often a side effect of clear and deliberate communication, which is both difficult and important.
Nobody reads the docs. This will be even more true soon as LLM generated docs become more popular. I once read a user report "would be nice if I could move large Xs to uncover Y", filed a bug report myself to add the feature, and then realized that feature was already added and documented months ago, by me! I just updated it with an unobtrusive prompt/instruction to the UI when relevant. I definitely get lazy sometimes, but if you don't take the extra step to make sure a feature is easily discoverable and understandable in the UI, you're wasting almost all of its potential benefit.
> often love to condescendingly assert that users are just not reading the docs, or are not smart enough to understand the software.
The older I get, the more annoying I find this habit in the SWE community. It's not even a well earned condescension. Software is often horrible! Physical hardware products are not put out into the world with the kind of defects that software so regularly is.
We get away with it because we say we can patch it later, though often all we do is move defects around.
It's amazing picking up pre-internet connected era electronics from 30/40/50 years ago and they just.. work.
Meanwhile software decays at a faster and faster rate each year. I am coming around to the idea of keeping air gapped old-OS machines around just to maintain pieces of software that otherwise auto-update themselves into oblivion.
It's still a wild logical leap to me that we went from this observation, that maybe the bottom half of users never learn how the software works, to the idea that we should build software that is actively learning-hostile. In the old era, we established consistent UI patterns: this kind of button does X, this kind of button behaves like Y, here are the tools to solve your problem. Maybe not everyone learned the patterns, but those that did became wildly productive. Now: who cares if buttons are recognizable as such, your bottom half of users tap all over the place anyway, so design for them exclusively. It's good to enable more people, but we also lost something in the process.
I cynically ascribe that to a change in the market/ecosystem, from "personal computer as democratized means of production" to the (more profitable) "device we control to sell content and subscriptions to you".
The root problem is so-called startup/growth hacker culture: you start from zero user. There are a lot of potential users out there. Far more than your current users. So, the best way to grow your business is not to retain your current users, but to grab new users.
In this scenario, you only need to cater to the most clueless users. There is no need to make an app learnable as you don't even intent to keep the users long enough for them to actually learn how your app works.
In my UX jobs where we did actual UX research with participants in the office the UX research team would go around before each session and find any available developers to come with and sit behind the one way mirror to watch.
You could always tell when it was someone’s first time watching a real user attempt to use our website.
> On the other hand, a common way for regular people to interact with a system is they just... don't have a model. None at all. Like, they click a thing and see what it does, and if it doesn't do what they expect they shrug and click something else.
I suspect that's part of why fuzzing is so powerful.
> You can see this in the article: "Google Docs added some kind of delay such that the typing you do into the title box right after you open the doc gets overwritten". That's a developer forming a model of the system. The lay alternative is to simply learn that sometimes when you type in a box, the text appears. Other times, it doesn't. If it doesn't, you try again.
Things like this just infuriate me. The user just learns that things are unreliable. To me that's unacceptable for something to be presenting a text box to type text, let you type it, then wipe it out. Sometimes you have to wait a second after typing something before clicking search, or it searches for your incomplete query a half second before. I don't blame users for just concluding that typing is unreliable.
the people without a model are also the easiest users to lose, they won't file a bug or explain what broke. they'll just click twice, decide the product is unreliable and use something else. then the team sees no bug report and assumes everything is fine.
For developers, bug-blindness tends to be because their mental model is so close to the system's model that both have the same blind spots, and the developer can't effectively think outside the system (the classic "QA walks into a bar, orders 0 beers, orders -1 beers, orders 0.999 beers" vs "customer walks into a bar, asks where the bathroom is, bar immediately bursts into flames").
On the other hand, a common way for regular people to interact with a system is they just... don't have a model. None at all. Like, they click a thing and see what it does, and if it doesn't do what they expect they shrug and click something else. The horror of seeing a non-software person using a software system is realising that they usually cannot tell the difference between expected and unexpected behaviour, because they don't really form expectations in the first place. The computer is more genie than machine.
You can see this in the article: "Google Docs added some kind of delay such that the typing you do into the title box right after you open the doc gets overwritten". That's a developer forming a model of the system. The lay alternative is to simply learn that sometimes when you type in a box, the text appears. Other times, it doesn't. If it doesn't, you try again.
You don't need to understand the system if you abandon the assumption that the system was designed to be understood. And, in practice, the widespread plagues of shitty engineering, anti-features, and lack of respect for the user often combine to make that model the more information-theoretically optimal one.
In that sense, the very thing that makes us miserable is our perverse need to treat Google Docs as an engineered product rather than a cross between a djinn and a symbiotic fungus.