Hacker News Reader

Yes, users are fucking dumb. I use to work help desk for a number of years, and the stories I could tell...

Though, I sorta object to treating them all like their stupid. There are stupid users, and then there are users that are stupid because you treat them like they are. Let me explain.

When I worked in healthcare I was pretty stupid. It wasn't that I didn't understand the mechanics behind it, but it just didn't click with me because the training I had was deplorable. I was regularly yelled at for making mistakes, and didn't have a really supportive environment. So in my haste to ensure I did everything quickly, and didn't make any mistakes it actually caused me to either overthink or underthink certain steps due to anxiety and nervousness. So in other words, when someone started treating me like I was stupid I was more prone to acting like I was stupid...

So when I worked at help desk no matter how stupid a users was I always did my best to treat them as kindly as possible. In the end what wound up happening is that I wound up getting much better results than my coworkers who wouldn't treat them respectfully. That wasn't even my super weapon though. It was anticipation of future problems...

I always really liked Roman Mars perspective on design. Good design is effortless. When you go through a door if there is a handle on it and you pull that handle you feel stupid when you see that it says pull only. So in my own way I am always trying to view things I do in IT, whether programming or helpdesk from a user centric perspective. If I think ahead of time about what sort of potential issue someone would have, and I can change something to prevent that then I have much better results.

This is something I see being a problem all up and down the entire stack in IT. It is time to stop treating our users like idiots. But it’s also time to start returning to idiot proof design.

> Yes, users are fucking dumb. I use to work help desk for a number of years, and the stories I could tell...

That sounds like textbook selection bias; users will usually end up at helpdesk only when they're out of their depth.

Exactly. Users rarely if ever go to tech support to show off things they figured out themselves.

Tech support pros saying users are all dumb is like brain surgeons saying everybody has brain damage.

I see your point, but I dealt with users far more often than just whenever they needed tech support.

Interactions with users were more common in my position than just when they needed help. I provisioned all the computers for the company I worked for. I also upgraded any software, usually manually for whatever reason, and dealt with a lot of the day to day maintenance.

Like I said, users are not universally stupid, but when they are they can be especially stupid. A lot of it could be mitigated with better design. A lot of it could be mitigated by critical thinking on behalf of the users.

> when I worked at help desk no matter how stupid a users was I always did my best to treat them as kindly as possible.

This resonates with me because it's something I try to do all the time.

The XKCD "Ten Thousand" comic[0] really spoke to me and ever since reading it I've tried to treat people as 'temporarily inconvenienced geniuses' rather than morons when they ask me for help and it seems to work wonders.

If you enter requests for help with the mindset of "let me show you how to solve your problem" and not "let me solve your problem" you end up speaking to people as if they are an equal which always seems to provoke better responses

Of course the reward for being good at digging holes is more holes and to coin a malaphor if you teach a man to fish he'll come annoy you every time his boat won't start, but it's also pretty nice to be the person everyone assumes can fix anything.

(Also it's a great outlet for the typically annoying desire to solve everyone's problems)

[0]: https://xkcd.com/1053/

One of the things that I have discovered is that treating people in this way can be a bit of a double edged sword though. When I was working at my last company I was on a team of three, and I wound up being the guy that dealt with all of the difficult users. That was fine by me though, because I had previously also worked in a group home with individuals with developmental disabilities, and emotional problems so a difficult user to me was just whatever. But... I can see how it might negatively effect someone else. lol

But! On the other hand, if I ever needed something it wasn't that hard to get someone to help me. Kindness in my experience has always multiplied. There is, as you said, always something that someone doesn't know, including yourself. So there was always something that the users were willing to teach me in return.

PS. I love this comic. When I am finally done going to school maybe I'll hang that in my cubicle or something. I estimate with all of the programming I have done for college, and all of my personal time on side projects that when I am finally ready to get back into IT again I'll end up being stuck in help desk again, anyway...

> So there was always something that the users were willing to teach me in return.

This is very true and why I love mentoring people. Once you have shared knowledge with someone, they usually want to return the favour and you can learn a lot from that.

> I love this comic. When I am finally done going to school maybe I'll hang that in my cubicle or something.

Nice! Prior to that comic I had Hanlon's razor in a frame above my desk which uh, while a good sentiment isn't the most positive mindset.

Computers can be really frustrating to use, the biggest offender in my opinion is hidden state. So many programs don't mention something has changed, and so if you fumble a click or a shortcut you can end up in a program state you didn't want to be in and may not even realise it until something goes wrong.

You wouldn't accidentally hit a switch on your car and now you can only go left, with no indication on why that is, and no transitional information given during the switch. Yet programs and websites will happily modify the state without so much as a brief text flash asaying "Oh hey, you're in Paint Only Mode now" for example.

My absolute favorite way to deal with this is small status indicators in some kind of toolbar, that when I hover over it, it gives me a tooltip on what it is and how to toggle it.

Accidentally hit debug mode? No worries, a little debug symbol just flashed briefly, I can go look for it in the toolbar and hover over it to figure it out.

> Computers can be really frustrating to use, the biggest offender in my opinion is hidden state. So many programs don't mention something has changed, and so if you fumble a click or a shortcut you can end up in a program state you didn't want to be in and may not even realise it until something goes wrong.

There is a high degree of irony to this when you think about the extremely popular Unix philosophy, which is kind of the antithesis to what you're saying.

I know that it's meant for power users, but even for those in many cases it's still bad UX.

Isn't Unix philosophy the one about small, focused tools that compose well? It fits the GP's view, since the composition is meant to be user-driven, explicit and visible.

(Also composability usually implies lack of hidden state - in Unix-land, state issue may just come from the baggage of C language.)

Yeah, but all those tools by default don't print anything if they run successfully, which is indistinguishable from silent failure.

If you look at all modern tools, this approach has been abandoned, especially for long running operations, since it's obviously bad UX.

Right. That I agree with.

> which is indistinguishable from silent failure

What is why the same tools do not have silent failures. And OS failures aren't silent.

> If you look at all modern tools, this approach has been abandoned

Gladly, you are wrong. Modern tools have indeed add optional noisy modes, nearly all opt-in.

> What is why the same tools do not have silent failures. And OS failures aren't silent.

Thankfully, there are no bugs in our software :-)

> Gladly, you are wrong. Modern tools have indeed add optional noisy modes, nearly all opt-in.

Almost everything network facing (which is almost everything, these days), is verbose by default. Git, curl, etc.

> Thankfully, there are no bugs in our software :-)

Yep. Bugs are why OS failures are not silent.

But you've got a point. Network facing software need some progress confirmation.

You mean like grep not returning anything when it searched for something and didn't find it?

It is more about a lack of feedback than a hidden state. It is a problem but not the same one. Talking about Unix tools, the hidden state would be more like environment variables like the PATH or locale.

Environmental variables are essentially dynamic binding at process level. Super useful, but I wish there was a way for programs to declare what env variables they're using, in a way that can be inspected programmatically.

Related: cmdline arguments are essentially lexical binding at process level. I wish there was an idiom there like there is in Lisps (Common Lisp in particular), where a function would take an optional argument whose default value is the value of a dynamic variable. In process terms, that would be declaratively specifying that an optional cmdline parameter takes its default from an environment variable.

Or just some kind of generic way to advertise where they're reading configuration. The worst are programs that search 20 places for configuration, so you have no idea whether you've turned some feature on or off.

What I really want is a generic system of algebraic effects for processes so "read configuration" becomes something I can inspect or wrap with my own handler.

You mean the "silence is golden" rule?

If so, that's completely different. It just states that after the user change something and the thing actually changes the way the user expects it to do, you should not interrupt the UI flow. It has no realtion at all with hidden state.

State on a classical Unix system is pretty much entirely explicit.

I agree with a lot of things you say, but I think that “lack domain knowledge” is a better description than “stupid”.

There are many people who have little interest in the underlying “how” and “why” of computers work. They haven’t been educated, more importantly they don’t want to be educated. They want to focus their time and energies on (What they regard as) more important things.

I have two bright teenage girls who need to use computers every day to get school work done. But their focus is art and reading, and writing. Their eyes gaze over whenever I try to explain why their computer is behaving the way it is.

My eldest did an amazing project in just a couple hours the first time she ever used Photoshop, removed a person imperceptibly from a old scanned image, realigned it to be upright from a mislaid scan, recolored it to make it look present day without oversaturating it.

Most of this she learned from in app tutorials. But I had to show her how to save the file and explain file formats and the difference between cloud and local storage. She just didn’t care about that part any more than she needed to turn the assignment on.

But how to use Photoshop is like another form of sketching or painting, so she ate those tutorials up like chiclets.

True.

Yet how often do you ask a waiter about the challenges of scheduling the maintenance of a commercial refrigerator?

Author here. I actually agree.

Cheesy (but true) anecdote: As I was writing my article this morning, there were two distractions. First, I tabbed to Facebook where I saw one of my "friends" had posted something political that was both factually incorrect and also very offensive. It reminded me of All the Bad Things, and made me doubt my argument, to the point of almost just scrapping the article. Not just because that FB post was an example of someone being stupid and lazy, but because I had mindlessly interrupted myself and tabbed to Facebook and was about to engage with that post.

My second distraction was my 2-year toddler, who had just woken up and was tugging at my sleeve. And I thought about the world I want him to grow up in and the view I want him to have of it.

I know I can come across as idealistic (hell, I've even gotten that as formal feedback in a performance review—but I've also gotten feedback that I'm cynical, so shrug). But honestly, one of the wonders of us as humans is that we can carry all these different capacities. We can be smart and motivated and social. We can be stupid and lazy and anti-social. All those capacities are worthy of admiration, not contempt. Technology is a great tool, we can decide where we focus it.

I agree completely. If we pander to the lowest common denominator we only serve in lowing that denominator even farther. A “race to the bottom” where the bottom is never ending.

We should instead approach issues in our lives with this “how the world should be” attitude, instead of “how do I make gains out of the world that is”. This means treating people with respect and courtesy even when we believe they are wrong. We work with them to achieve a better result, because lack of knowledge is not equal to stupidity and laziness in all cases. For instance I do not have a medical degree, but appreciate not having doctors talk down to me. Work with me, help fill in the gaps, don’t pander with hand wavy explanations. If it requires too much time in the moment then point me to were I can independently find the information and study on my own.

In other words, live by the “means” not by the “ends”.

Ah, a fellow idealist :)

I really respect this ideal.

All too often I've found people dealing with external users become calloused. We forget that questions with obvious answers (to us) may not be obvious others and that this doesn't imply that others are stupid.

I feel that it's our responsibility to design things to be as obvious to as many people as possible. I also think a default attitude of respecting the users of our products can go a long way to making this happen.

I have a bias toward designing user interfaces with simple composable mechanisms (that are easy to understand and compose), rather than single-purpose actions.

Yes, sometimes the action is really frequent or it's part of the main workflow, and having a shortcut for it is good, but I think one often ends up with a more resilient tool by allowing the user more control so they can recover from mistakes and exceptional cases you didn't think of.

A recent example is an app I'm working on that involves helping the user work through a list (they do a task for each item, then move to the next one, and so on). It's a high priority for the user to get through the whole list efficiently, so the PM wanted us to have only a "next" button because showing other buttons "might be confusing." The thinking was that it would streamline the workflow if the UI is minimal: do the task, click "next", do the task, click "next", etc.

This is the kind of situation where I really want to give the user more control — if we provide "next" and "previous" buttons, they can go back if they made a mistake, or check one of the earlier items and then return to what they were doing, look ahead to see what's coming up and plan for it, etc.

They may also be in a rush, and have more important things to do. That can appear to be lazy or stupid, but it isn't really.

I have that attitude towards things like expense filing software. It's a nuisance that I don't want to spend time learning, and it doesn't come up often enough to learn it well. So my click stream probably looks stupid or lazy.

I feel the same. An app shouldn’t be too complicated especially if you used different similar apps in the past and can sense the complication is unnecessary. Why spend energy and effort on something that is stupidly designed and which would probably be a one time use anyway?

I think you're looking at it wrong.

Have you ever taught someone to drive? They have their attention completely occupied by ... everything at once.

After a while you can see the pattern. "turn here. right here. WAIT TURN HERE!" "here?" "no, back there."

It's not that they're stupid, it's that you have the pattern ingrained in you and you don't remember what it's like to experience something for the first time.

Now yes, there are idiots - in terms of social interactions - they lack maturity or patience or speak too quickly (or are having a bad day). But don't lose compassion for 99 people for the one unenlightened person.

Yep. Not everyone comes from the same baseline. Different biases, experiences, knowledge, affinity for a topic, capacity to understand something at a certain speed, etc.

Tangentially related, I’ve noticed some online products almost purposefully make their websites less appealing to filter out certain types of users. I think landing page copy call it “speaking to your audience,” but it’s the same thing where you’re selecting for the kind of customer you want.

I recently went live with a project that does okta integration with mfa. The most common support ticket is people complaining they didn't get their mfa code. Root cause: they never clicked the "send code" button.

It's your fault because of poor naming, it should be "get code". They aren't the ones sending you something.

It's not clear whether you intend to blame the user or the tool, but my inclination, absent any other information, would be to blame the tool.

Maybe they clicked forward from a previous screen and were presented with an active text field and the "send code" button, but didn't recognize it as a button, or misunderstood its purpose, expecting the code to be delivered automatically, or thinking that it meant "send code from the user to the website" (i.e., after they have typed it in).

Whatever the details, a bunch of users have an expectation that doesn't match the tool's reality. It's the job of the designer to recognize or discover that gap and find ways to remedy it.

A user submitting a support ticket is rather like your code throwing an exception. If just one pops up in Sentry you might add a note to look at it later, but if it happens constantly you need to go fix something.

If one user submits a support ticket you can count on there being ten others that had the same problem but didn't bother.

I filled out a custom job application on a software companies site yesterday. When I finished I couldn’t figure out how to submit the form. I must have stared at it for minutes not wanting to abandon my work, until I scrolled down and the submit button popped into view. On my large screen monitor.

While I’m sure your “send code” button was visible, apparently that’s not what they expected. Maybe they expected “Send MFA code”, or “Text me my code”. Maybe the terms you are using don’t match up well with their limited understanding of the domain problem.

Sounds like a problem A/B testing or simple user interviews could help with.