6 ms·

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 th

by sgentle 1mo ago

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.

DrewADesign 1mo ago
> 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.
- atmavatar 1mo ago
  > They’re smart enough 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.
  - Groxx 1mo ago
    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)
    - jiggawatts 1mo ago
      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.
      - Groxx 1mo ago
        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.
deleted 1mo ago
[deleted]
ChannelFence 1mo ago
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.
- 3eb7988a1663 1mo ago
  Why should I file a bug? So it can be ignored until a PM eventually declares bankruptcy and wipes the tracker clean? There are some well reported bugs in Microsoft/Google/Apple that have persisted for years. Nobody cares.
lelanthran 1mo ago
> "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". Well, Jira does that too in many of its input widgets: anything you type while the page is loading is cleared after the page is loaded. At this point users have been conditioned to accept this sort of react crap.
codeflo 1mo ago
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.
- Terr_ 1mo ago
  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".
- raincole 1mo ago
  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.
junior44660 1mo ago
> You don't need to understand the system if you abandon the assumption that the system was designed to be understood. This applies to software engineers too. Especially now there's claude to help them complete the tickets without understanding the system.
normie3000 1mo ago
> "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" GitHub also introduced this feature recently in the New Issue GUI.
eru 1mo ago
> 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.
nkrisc 1mo ago
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.
gblargg 1mo ago
> 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.

by sgentle 1mo ago

DrewADesign 1mo ago

> 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.

atmavatar 1mo ago
> They’re smart enough 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.
- Groxx 1mo ago
  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)
  - jiggawatts 1mo ago
    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.
    - Groxx 1mo ago
      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.

deleted 1mo ago

[deleted]

ChannelFence 1mo ago

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.

3eb7988a1663 1mo ago
Why should I file a bug? So it can be ignored until a PM eventually declares bankruptcy and wipes the tracker clean? There are some well reported bugs in Microsoft/Google/Apple that have persisted for years. Nobody cares.

lelanthran 1mo ago

> "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". Well, Jira does that too in many of its input widgets: anything you type while the page is loading is cleared after the page is loaded. At this point users have been conditioned to accept this sort of react crap.

codeflo 1mo ago

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.

Terr_ 1mo ago
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".
raincole 1mo ago
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.

junior44660 1mo ago

> You don't need to understand the system if you abandon the assumption that the system was designed to be understood. This applies to software engineers too. Especially now there's claude to help them complete the tickets without understanding the system.

normie3000 1mo ago

> "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" GitHub also introduced this feature recently in the New Issue GUI.

eru 1mo ago

> 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.

nkrisc 1mo ago

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.

gblargg 1mo ago

> 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.