Accommodation for every possible user interaction is impossible.

Let's use your example, but switch the USB to a whole computer. A user can pull the power cord and expect the computer to safely turn off with every data saved in the drive magically. Just like a USB. How should a UX designer prepare for this?

1. 
   Lock the cord in place so that the user can't yank it out. Hard to maintain and replace, more money required for a feature hardly anyone would want to use when they can just press the power button. Also a lot slower if you need to move multiple computers at once, say, when your company changes its location.


2. 
   Remove computer caches. Data is never delayed, and you don't even have to press save when updating a component. Computer speed now slows to a crawl. A myriad of security concerns will have to be accommodated as well.


3. 
   Use a mandatory emergency power source. The user is now forced to buy the manufacturer's UPS/battery and have to pay to get it changed even if they already have a spare at home.

All solutions above are worse than a simple manual warning users about the danger of unplugging a running computer.

If you don't expect an electric saw to magically stop running right when it touches your finger, then don't expect computers to do all the work for you. That's why designers and programmers have the acronym RTFM.

Yes, there is a term for this ("the user can't do anything wrong"):

foolproof

But as other answers point out, making something completely foolproof isn't feasible. On wikipedia I found a quote from Douglas Adams' Mostly Harmless:

a common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools

There is also a term for minimizing what a user can do wrong:

Defensive Design

In Defensive Design you try to design in such a way that users can do least harm, while not expecting to make it completely foolproof. Some techniques include:

• Automatic random testing: Letting a script give random inputs to your application, hoping to make it crash


• Monkey testing: User testing, but instructing the users to either try to break the system, or try to act as oblivious to the systems workings as possible.

User-Centered Design

What you’re describing is a consequence of User-Centered Design (coined by Don Norman himself). I’ve heard this principle expressed as “the user is always right” and “it’s not the user’s fault”.

As has been pointed out, this type of thinking is not common enough, even among UX professionals. The issue is that we’re trying to “fix” user behavior, rather than matching the user’s mental model.

In your example, the user’s mental model is that the flash drive is ready and can be removed if no files are being copied to or from it. Therefore, we should design our software and hardware to match this and to prevent any errors that might occur as a result. Here are a few suggestions to accomplish this:

1. Never keep an external drive in a dirty state longer than necessary. When writing to the drive is complete, get the filesystem into a state where it can be unplugged safely.


2. Always show an indication or notification when a drive in use, such as when a file is being saved (which should also be done automatically!). The system should inform users as to exactly what is happening, so that they know that the drive should not be unplugged yet.


3. Ideally, USB ports should be redesigned so that it’s possible for the computer to physically hold the device in place; the operating system would then release the drive when it’s safe to be unplugged. This would make these problems impossible. (This is how CD/DVD-RW drives work when a disc is being burned.) I don’t know if this is feasible from an engineering standpoint, but I think it should have been considered during the design process for USB-C.


4. 
   Undo. In case a drive has been unplugged while in use, make it possible to fix the issue by plugging it back in so that the system can resume exactly where it left off.

I wonder if the concept you are looking for is Poka-yoke (https://en.wikipedia.org/wiki/Poka-yoke). This is often more associated with mechanical design (e.g. zoo cage double doors which can't both be open at the same time) but you can make an analogy with UX design (e.g. don't offer a delete button when there is nothing available to delete).

This is a common UX design principle. The best error message, is to avoid an error message in the first place. There are many examples of design principles out there, but no standard set.

Jacob Neilson used the term “Error Prevention” in his 10 usability heuristics.
https://www.nngroup.com/articles/ten-usability-heuristics/

"Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action."

Apple refers to it as “User Control" in their IOS guidelines:
https://developer.apple.com/design/human-interface-guidelines/ios/overview/themes/

"The best apps find the correct balance between enabling users and avoiding unwanted outcomes."

Just approaching this question from an analytical perspective, you'll see this mentality in some UX environments and not in others. If users are heavily limited with regard to what they can do, you'll see more preference for UX that follow the principles you describe. The more freedom users are permitted, the less popular these principles are.

I wouldn't say its a real name for this effect, but I'd call it "with great power comes great responsibility."

This is the issue with the USB example which has shown up several times in this thread. A user who can physically modify hardware has a remarkable amount of freedom. They have great power over the system, and thus they have more responsibility for what happens. Sure, I can make a USB device which locks in place until files are done copying. That will work as long as you limit their power to gentle tugs on the hardware along the axis of the USB device. A user with a Sawzall can most definitely do something wrong to my USB device if they aren't responsible enough and aren't aware of what cutting a USB device in half while it is connected can do.

Let's not even talk about implementing PSU to meet this Sawzall requirement...

Any system with a compiler has to face this reality. I can and will do something wrong with my compiler. I will break something. I can delete files I wasn't supposed to delete. Heck, I have deleted such files! I even deleted them in parallel with a glorious multithreaded harbinger of doom! It was bad news, and was most definitely "my mistake."

Contrast that with designing a iPhone app. iOS severely limits what users can do and how they can interact with the applications by design. It's the purpose of a good mobile OS. Likewise, app developers often permit very few operations. That keeps your UX simple. In these situations, its very easy to capture the small range of operations a user can do and prove that the user indeed cannot do anything wrong. In such settings, it makes a lot of sense from a user experience perspective to support this mentality.

In particular, business apps are designed with this in mind. You really don't want to let a low-paid entry level worker make a catastrophic mistake with your app. Point-of-sale devices are designed to make sure you don't accidentally email a credit card number to some malicious agent in a foreign nation. You just can't do it!

So we can see both extremes. In some situations you want to make sure the user really can't do anything wrong. In other situations you can't. I think it's pretty reasonable to say there's no dividing line between the mentalities. It's a smooth spectrum from "the user can't do wrong" to "oh my god, the monkey has a knife!"

OS [and all software] developers should see this and build their software to accommodate this instead of bothering users with "you did that wrong" messages.

Yes, you're totally, completely, absolutely correct.

Engineers and companies that do what you say, make huge amounts of money.

Some of the biggest key products of our entire era are totally based on what you describe.

Is this a widely-held view among UX designers/developers?

Yes, it's one of the central ideas.

it is constantly and widely discussed as one of, or the, central issues in UX.

The BMW 7-series was a nightmare since you had to fight and search for every function among literally 100s of choices. Whereas the masterpiece Renault Espace cockpit was (see below) user-driven and the epitome of that.

Is there an official term for this philosophy?

Sure, it is

User-driven design

Not 10 minutes ago I was yelling at some people "make it user-driven". They had some switches etc. that "had to be" set by a customer before use, which is a crap idea. Instead I screamed at everyone to make it "Pascal-style". I literally said "Make this user driven, get rid of the fucking switches."

Yesterday I literally dealt the entire workday with precisely the "Pascal issue" in relation to a product and no other issue.

Two years ago I spent four months personally inventing/engineering/whatever a new sort of algorithm for an unusual graphical interface where the entire end result was eliminating two bad "anti-Pascal-style" actions. (The result made zillions.)

Note that to some extent, the everyday phrase

K.I.S.S.

amounts to, basically, a similar approach.

Note - since the "Pascal-issue" is indeed so pervasive, there are

many, many specific terms for subsets of the concept:

For example, in the literal example you gave, that is known as

plug-and-play

or

hot swappable

Note that a company we have heard of, Apple, arguably made some 10 billion dollars from being the first to market with ("more") plug and play printers and other peripherals than the competitors of the time, back before you were born.

So, "plug and play" or "hot swappable" is indeed one particular specific subset of the overall user-driven design, KISS-UX, "Pascal-issue".

We always called it user-proofing, and it's usually the most time consuming aspect of software development. It's not so much that the user can't do anything wrong, but more that whatever the user does won't crash or break the software. This term dates back to at least 1997 when I started developing professionally, and probably much earlier.

I'm shocked to see that no one has brought up the fact that everything in design and engineering has a cost. You can always engineer a better version of whatever you're making that covers more use cases and has more features that users want, but every time you do you sacrifice something else. The thing you sacrifice may be literal cost and raise the price or lower profits, or it can be a trade off in some other way.

To use your example of usb's being pulled out without ejection there are a few associated costs to different approaches.

• If you make usb's lock in place you add manufacturing cost and complexity to both the drives and the ports, and you decrease usability because it makes them more cumbersome to put in or take out. Even if someone could make such a drive I would never buy it and continue to buy normal usb's without locks.




• If instead you make sure the usb is kept in an ejectable state as much as possible then you will lose performance (since the computer will have to do constant cleanup and restrict write times to short bursts). Since one of the biggest selling points of flash drives is read/write speed, that also means no one would want to buy it.

Either way by trying to cover for this niche UX issue they have lost a lot of potential customers.

Basically what I'm saying is that you have to do a cost/benefit analysis and decide which features are worth doing and which are beyond the scope of what you're trying to accomplish. Yes, we should watch and listen to users and find out how to refine our products to be more useful in real world scenarios, but there is always a limit.

Falling Into The Pit of Success is a term used in the development community. It's more focused around language or library design, but can be applied to front end interaction also. It's definitely vocabulary I would use when discussing UX with other developers to get them on the same page.

User-centric is the broad principle and, IME, it's widely accepted among modern software product teams and many hardware product teams.

More specifically, I think Activity Centered Design deals directly with this issue. ACD addresses the user's entire workflow and how the product can fit into, augment, or alter that flow.

ACD changes the perspective from

"how does the user want this thing to perform a function" to

"how can we make the user fundamentally more successful at this job".

If you do ACD (or UCD) without accommodating user "error" then you did it wrong and you need to keep iterating.

I need to clarify what I mean by "the user can't use anything wrong". I'm not saying that the user should be prevented from using something wrong, but that there aren't any "wrong" ways to use something. If a large percentage of users use a microphone as a hammer (like the Shure SM57 genuinely is), designers should embrace this and improve the hammer capabilities in the next iteration.

This almost entirely changes the meaning of your title. It goes from being error avoidance, to "the bug is a feature".

1. The closest thing that I can think of is Agile/Lean UX. This is where you have a short feedback loop. You build your product, be it a microphone or a mobile app and get it into the hands of users. Then depending on how they use it you enhance those features.




2. Also as far as things being used not for their original purpose - I think the buzz-word "pivot" comes in. This is where the microphone folks realise they've built a better hammer by accident and start selling hammers that you sing in to.




3. There's also another similar but related area where you have mistakes that turn out to be extremely useful - serendipitous accidents appears to be a relevant term here. I believe the most famous of these is penicillin, but there's also the discovery of Blu tack in the UK:

Fleming recounted that the date of his discovery of penicillin was on the morning of Friday 28 September 1928. The traditional version of this story describes the discovery as a serendipitous accident: in his laboratory in the basement of St Mary's Hospital in London (now part of Imperial College), Fleming noticed a Petri dish containing Staphylococci that had been mistakenly left open was contaminated by blue-green mould from an open window, which formed a visible growth. There was a halo of inhibited bacterial growth around the mould. Fleming concluded that the mould released a substance that repressed the growth and caused lysing of the bacteria.