Voice from the next room: "Can you help me, dkarl? The computer won't save my document."

Me, comfy in my chair: "What does it say?"

"It's doing something weird."

"Weird how? What does it say?"

"I don't know, I was just saving like I always do, and now there's this window and it wants me to do something."

"What is it asking you to do?"

"It wants me to click something? I don't know, maybe it wants a password or it's not going to do it because of iCloud or something? It's been weird lately."

"Okay. What are the words in the window where it wants you to click something?"

"It says... oh, it says there's another file with this name already."

"Okay, do you want me to come over there and help you find the other file and see what's in it?"

"No, I can do it. Thank you!"

I think one of the reasons I find computers relatively easy is that I compulsively read whatever you put in front of me. I always read cereal boxes when I was a kid, even the non-kid cereal boxes that were all about colon health and fiber. But even I get this blindness sometimes, especially when I'm writing code and running builds and tests and trying to work quickly and efficiently. I'll get hung up on something for ten minutes where the answer is literally spelled out for me in front of my face.

> I think one of the reasons I find computers relatively easy is that I compulsively read whatever you put in front of me.

Telling my mom this is what eventually got her to read error messages instead of closing them. She had to learn not to close them and then, separately, learn to also read them. I'll admit there were times where I was on the verge of crying out of frustration, begging her to "please just read the screen" because she would leave the error, but then still not actually read it and go with:

Me: "What does it say?"

Mom: "I don't know."

So glad things are better, now.

This is an astute observation.

I also didn't know that other kids read cereal boxes like that... I thought it was just me!

Or even just signs when driving down the highway. I can't help but read everything.

It took me the longest time to realize that for some people reading is something that doesn't happen until they choose to do it.

Then says "hey hon, It won't let me save."

I see the error. Can't access disk. Immediately I think, well I replaced the HDD with and SSD, so that's probably not the problem. I look at the folder she's accessing, everything looks normal. It shows a bunch of other files in it. I go up a folder and back into the folder, and everything looks great, click Save - > same error again.

Finally I go to my computer -> and path my way back all the way into the same folder, click Save. It works and she says thank you!

And I'm thinking, what the fuck that shouldn't have fixed it.. walking away dumbfounded. No problem since, there's nothing wrong with the disk she's been using the computer for days since. It was literally a bug in word's specialized save dialog.

I see alot of apps using hardcoded paths since they create a "downloads" folder and save stuff to it.

Alot of bugs are exposed in a non US-eng install.

I have broken so many computers in my life and repaired them that I am not very worried about pressing the wrong thing because I am confident I can recover from a mistake. Someone who has never repaired their own computer runs an unknown (to them) risk of being wrong that would force them to take their computer to an actual store and the hard drive probably being erased without asking.

Specifically, I was once trying to help a CS professor register a new domain name. This was at some low-cost registrar and there were 6 pages of upsells on the way to checkout. For whatever reason, he was definitely taking his time reading the entire pitch, and eventually I had to step in and click 'next' several times. "No, you don't need a new virus scanner as part of your domain name purchase. No you don't need a company to submit your new domain name to search engines. No you don't need SEO services. ..."

I'm going through a contract-heavy legal process right now, and it is amazing how strongly the agents/lawyers/etc. involved in the process clearly expect me to just sign without reading. Obviously they're not pressuring me not to read it, but the implied expectations of time/effort that it should take is much less than necessary.

Edit to add: also, I've seen this in more places than just health care.

I complained and was ignored in the same way people are ignored when they complain about the wait in the ER or ask how much treatment will cost.

For people who are not comfortable with computers, they just see an error message and expect it to be something that they cannot handle.

Part of the problem is how error messages are presented. A lot of software uses tools like modal dialog boxes to present everything from "a file with that name already exists" to "the file cannot be written". The former can easily be handled. The latter may involve a call to technical support (and part of the reason for that is the ambiguity of the error message).

"Hi"

?

"I have an error"

What error?

"It won't compile"

Whats the error message?

"Function lib.X not found"

Did you import the library?

"No"

Import it

"It worked"

Most everyone seems to be trained to ignore error messages, regardless of background. Expecting them to go the next step and google the error is a lost cause, regardless of background. Even 5yr devs sometimes need to be taught this... I'm still not clear why, but it feels like people are being trained to use computers this way -- i just can't figure out when, why and who's doing this mis-training

A big frustration of mine is sites/apps that bury their support info. If I need support, I'd like support. Expose your FAQ to me, point me towards some forums, but don't bury the actual contact info somewhere like the footer, or worse, omit it completely. If I type my problem into the supplied form and the chatbot that opens up asks me to type that info again (often after a redirect where the session info gets overwritten so that I can't even copy-paste my already written text) I'm much more likely to be unnecessarily rude to the support person in the other side... Assuming it's a person and not the aforementioned chatbot.

You have no idea how many times I've seen the RDP certificate warning: "Click here to never show this again."

Nope, no. Nobody but me ticks that checkbox. NOBODY. It's infuriating.

That, and the VMware vSphere first-time tab that "explains what a cluster is". Click here to close and never show again.

Nope. Every time I look over the shoulder of a dedicated, full-time, VMware-certificate ESXi cluster administrator... there it is. The certificate warning. The first-time popup. Every time.

In my mind, I know I really should manually grab a copy of the cert from work so I'm actually certain I'm not being MITM'd, but on the other hand I know the likelihood of that being the case is pretty darn low and I'm lazy so I don't. But I make sure that warning keeps popping up because I don't want to forget that I'm doing something dangerous.

The easy way is decently secure: if you tick the checkbox, it memorises the certificate serial number for you, the same as if you had manually trusted a self-signed cert. Any change to the certificate will show the warning again. This is comparable to trusting an SSH certificate the first time you connect to a host with Putty.

The best way is to issue RDP Certificates from an Enterprise PKI: They're free, you never get warning popups ever again, and they're secure.

Your method means that if the certificate changes (due to a MitM attack), you won't notice. The warning looks the same with a new certificate as an old certificate that you didn't choose to trust. You're 100% vulnerable and you've both hidden an a warning for an actual attack and also trained yourself to ignore all such warnings.

Then it should say so.

"Click here to never show this again"—never show for this certificate? For this connection? For any connection?

Be clear and specific, even if it takes three more words.

I'd put it differently. Realize that your app is not the center of the world. Your users have things to do, and using your app is a small fraction of their life. Even though it might be your baby and you might be spending all of your waking ours thinking about your app, user perspective is different.

Thereby forcing all of their users to learn the new UI immediately, not even with due warning.

One or two platforms doing is in a week or so is a pain. But when lots of platforms do this in a short period of it, it can be "throw hands up in the air and do something else". :(

but this is functionally the same thing. whether the user is an idiot giving you 100% of their mental capacity, or a genius giving you 1%, you have to make the same decisions when you're designing a product. "Users are stupid" isn't necessarily a judgemental thing meant to demean your users, just a reality that you have to accomodate the people who are going use your product in a way that's indistinguishable from a stupid person.

You can't assume that anybody will remember anything they did in a previous step, or that anybody will correctly interpret the label on a button no matter how clearly you think it is worded, or when presented with multiple options will be able to correctly choose the one they want.

Say that, unbeknownst to you, 90% of your users are non-native English speakers. Is a non-native English speaker "stupid" because they misinterpret the simple English idioms, metaphors, and symbology sprinkled throughout your product?

A group of actually-stupid-but-native English speakers might exhibit the same behavior.

You hypothesize that you have a large percentage of non-native English speakers using your app and change the design to accomodate. Behavior improves, distinguishing the bulk of your users from merely "stupid" English speakers.

The problem is that if you conceptualize your users as "stupid" the hypothesis that something else might be going on _never even enters your head_. You never do the experiment. Or, if you do, it's not faithful to an alternative model and is basically a wild stab in the dark.

Imagine your user was not able to sleep on a Trans-Pacific flight in bad weather, they have hay fever and a very sore neck.

Better yet, get user studies.

No.

An idiot giving you 100% will never learn your product.

A genius giving you 1% will eventually develop a highly optimized way to use your product.

If we assume all users are the former, we never design for the latter. That pretty much sums up the last 20 years of de facto UX.

And if you disagree, I'd recommend you go find a call center still using mainframe apps, and watch a random sample of 100 users.

It was hilarious watching some of the reactions in our team when a client gave us a screenshot that was just boxes with numbers in them arranged neatly with no more than red/yellow/green for colors. Some saw ugly... I saw enhanced productivity.

Personally I think more UI/UX designers need to spend time doing data entry with time constraints so they learn the pains of repeated useless actions and time wasting features.

perhaps, if the user is a continual user. but most users of most products are infrequent, and if your UI relies on being learned over time, it's probably not going to work for most people.

If you're working on SaaS that is meant to help someone make money or work faster, there's a good chance you'll have people using your software as a part of their dayjob - i.e. 2-8 hours a day, 5 days a week, for years. If you treat your users as idiots and don't implement space for them to grow (i.e. power user features), you'll be wasting a lot of life for a lot of people (and a lot of money of their bosses).

That's a heuristic I'd like to see being used in UX design: assume your software becomes a tool in some company, and you have full-time users spending their workday on it. Design to that group.

Which, yes, probably. But there are more goals in software development than hyper growth.

In most situations most of the time, your code is between someone and something they want. Your main importance in their life is when you fuck it up, not when you get it right. You just aren’t that important. The user is.

Which is partly why we need books championing good design. Because good design gets out of the way, and would go mostly unnoticed if not for other designers and aficionados giving them kudos.

I disagree that you have to make the same decisions. I think you need to design your product contextually. Sometimes, users might be giving you 100% of their capacity, sometimes they will only give you 1%. It depends on context and motivation. I'm working on a personal finance app. Sometimes, users are in a "I just want to make sure that latest transaction isn't fraud"-mode and you'll have seconds of attention. But sometimes (albeit much more rarely), users are in a "I want to sit down and think about my financial future mode".

> "Users are stupid" isn't necessarily a judgemental thing...

I hope not, but unfortunately, I've often found that it is.

At least in my experience, the two ways of framing users lead to different behavior of development team.

The seminal work on interaction design isn't Don't Make Me Think, it's About Face. About Face makes thee general rule that you should not design for beginners or experts but for the perpetual intermediate.

A developer might spend a huge amount of time and effort modeling a workflow or a process into something crisp enough for a machine to process. That might take months of what feels like pulling teeth from people to extract requirements - people who are supposed to be domain experts. By the time he's done, he probably understands everything better than the people whose job it is to use the tool - the tool that now enables them to ignore and forget about parts of their job and complete it with 10% of their attention.

"Stupid users - they barely understand their own job and I spent months learning the finest details about it to build them a tool so they can keep doing it without understanding it at all."

Not saying it's right, but I can see how it happens.

Right, we also need to remember that simple is not better than possible.

If your interface is too simple and feature limited that your user can not complete their task, then you have gone too far.

We want to reduce friction as much as possible while still allowing a customer to solve their problem.

Dang, that's just the most perfectly succinct phrasing of (an answer to) my pet hate in software/developer attitude/life in general.

But it also seems that the 'possible' facet is just nowhere near as financially lucrative as 'simple'.

If the underlying model is very powerful but so complicated that it's very difficult to convey it to anyone, is it of any use? "Financially lucrative" in that case is simply a proxy for "can I get anyone go understand what is even going on?"

I've built an online pub quiz, and I'm doing as much hallway usability testing (in the Zoom hallway) as I can. Early on, every single one ended up with me changing things from being more flexible and powerful to being simpler. Either the underlying model, or just what is being presented/allowed in the user interface at any given time.

There is just no point in trying to provide lots of options instead of a well thought out middle-of-the-road path of obvious next steps if no-one will be able to get around to doing what they came for. People can't become power users if they aren't users.

UX design is so hard, but luckily it's also very interesting :)

Yep. It's probably over used as an example, but I always come back to pinch-zoom. People don't care about your UI, the best you can let them do is directly manipulate their data. Anything else is a compromise. That compromise is always going to be there, but we need to minimize it.

MS Office has turned into a sort of industrial machine with a control panel. You can do anything to your data if you know what sequence of buttons to push to tell the machine what to do. Actually that peaked several years ago and they have been getting better about more direct access to features. OTOH they also have so much functionality that such UI will never go away completely.

On a related tangent, I feel like tools for programmers suffer even more from this. Because we're used to editing text files to get things done, the notion of editing a config file or writing a script to get something to do what you want doesn't seem that unreasonable to software developers. Maybe it should.

Text files aren't perfect, but they're hard to beat. It's not like the hardest part of programming is actually syntax, anyways. You can always improve on this by providing better assisted editing.

If there's anything I'd actually want it would be for software to have pluggable configuration so I can instruct it to pull its configuration from a database or something along those lines.

edit: and on that note, it’s probably the command line interface that actually would strongly benefit from some consideration. CLI arguments are currently a flat unstructured list... but almost everything at least has key value pairs.

Alternative views into those same text files would be nice. You could color-code the type of a snippet (yaml string/float issues) or nested blocks. You could offer a graph view of dependencies (context-dependent -- could be services, function calls, modules, docker base images, etc...).

Text files are nice (and I've yet to see anything that would be a good replacement for most uses), but that doesn't mean we can't offer extra tooling/views into that data when it would be more convenient.

Are they real world problems like the examples given above.

What is more important.

Someone once said the best interface is no interface.

If I do not have to think about an "interface", if the program is doing its job without requiring interaction, then that is more time I have to focus on what is important.

Not all software can be like this but a lot can. As the article indicates, there is an enormous amount of "forced interaction" in today's computers. This is in part because companies that employ interface developers rely on the online advertising business to make money.

I think about it every time I'm forced to use it. I think about how much I hate it, how constantly clicking between tabs slows me down, and how much more productive I was without it.

For mainly this reason, I still use Word 2003 and have no plans to switch until the fad passes and someone in UI at Microsoft finally stops designing for the lowest common denominator and remembers the point of toolbars wasn't to replace menus, but rather to put commonly used functions one click away.

I have the latest version of Office installed for when it's needed, I simply prefer doing my serious Word work in '03.

I don't think I'd hold up any version of Office as the paradigm of "internet safe" software.

a recipe for rote disaster

I'm a dev and I cannot cringe at a user failure to operate a piece of software.

Even those with a solid enough mind and education will have issues, french teacher told me she couldn't bear the improper use of verbs and nouns in her daily usage. It's a gigantic mess.

Though from a practical PoV those two states are often hard to distinguish. Very similar hand-holding is required in each case.

> Users have tasks to concentrate on. They don't have the attention left over to deal with your app's crappy UI.

This is very true. We provide accountability/competence/compliance management software for regulated industries (mainly savings and investment banking ATM) and for most of our users touching our software is a secondary task linked to their main roles. Even the day-to-day admins and UAT testers for new releases, are seconded from other areas or worse effectively being asked to use our software on top of their usual roles (an extra task given with no extra time assigned or other tasks paused).

Distractions include sudden popups that aren't the result of an immediately preceding interaction (looking at you, iOS). And those login forms. No one ever wants to see a login form for something they've already logged into from this browser/device.

Also, it might seem silly to point out, but use your goddamn product yourself the way your users would. That alone really helps with many UI/UX issues.

Therefore, it shouldn't distract from the task at hand.