To me, Idiot Proofing just means making sure the user can't break a piece of software even if he tried. For instance, if a value is read from a text box, and is converted to a double, if the underlying software is idiot proof, it won't break if the user types in a non-double value.

I recently wrote up a development schedule and one of the items was named "Idiot proof UI". The people I am building this software jokingly feigned offense to the term, but I can see where this term would actually make people upset.

What's a nicer way to say this?

  • 23
    Call it, ID-10T Proofing – Jarrod Nettles Jul 11 '11 at 20:10
  • 2
    Lol, I realized the 1337 as I googled ID-10T. me fail... – sooprise Jul 11 '11 at 20:11
  • 13
    This question reminds me of one of my favorite quotes: "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." ~ Rich Cook – KallDrexx Jul 11 '11 at 20:18
  • 3
    hows about basic engineering? – jk. Jul 11 '11 at 20:45
  • 4
    "Nothing can be made foolproof, because fools are so damn ingenious." – M.Sameer Jul 12 '11 at 1:57

16 Answers 16


If you are including "Idiot proof UI" as a schedule item then you are just trying to add quality afterwards to your software. Any well designed system will validate its inputs and give clear guidance to users as a matter of course, it's not something that gets put on the schedule as a discrete item (which is then subject to removal when the inevitable crunch hits).

Alternatively, if it has to be a discrete item (I know how some organizations think about scheduling), "Idiot proof UI" should be changed to "Input Validation Library" and moved to the front of the schedule.

  • 2
    +1. If you're trying to add any sort of input validation after the fact, you have already pretty much lost. Better to have as a standing point in the spec, "the software must gracefully handle invalid inputs anywhere". Exactly how to "gracefully" handle invalid input depends very much on what the software is doing at that particular point. For very simple UIs (think perhaps an ATM), it might even be possible to make invalid inputs impossible. – a CVn Jul 11 '11 at 20:40
  • 14
    +1. Idiot-proofing isn't a task. Idiot-proof is a consequence of good design. – S.Lott Jul 11 '11 at 20:48
  • 4
    Idiot-proofing is an ongoing process - because the universe keeps manufacturing ever-more-ingenious idiots – Steven A. Lowe Jul 12 '11 at 2:22
  • While it may sound as wrong and redundant, take into account that both the interface designers and the beta testers knew the blueprints and general design of the software, and may just not realize (overlook) that something that seems perfectly obvious to them is in fact completely baffling to a common user. "Testing and debugging UI design decisions" is what it could be called. Input validation is one thing, having the user understand what should be entered where is another. – SF. Jul 12 '11 at 13:50
  • To all upvoters: ...whatever you do, you'll always forget something. Software is so complex that having a team making everything "perfect" in a first shot is almost unattainable. That's why testing is necessary. To detect flaws and omissions, or even things nobody thought about. Such an "idiot proof UI" is exactly what is required. – dagnelies Aug 29 '11 at 10:16

User input validation I'd have thought would be a professional term. I don't see anything wrong with idiot proofing if used in internal documents though.

  • 3
    You had me at "user input validation." Idiot proofing is an unprofessional term regardless of where it is used. – Robert Harvey Jul 11 '11 at 20:17
  • 2
    Whatever you do, don't put it in writing. – JeffO Jul 11 '11 at 21:27

Hardening is a good word. If anybody asks, tell them the first pass on software is usually written for ideal scenarios, and like steel tools, software needs to be "hardened" toward rough day-to-day usage by real customers.

Robustification is another good word for this - you're making the code robust toward the kinds of challenges real customers will throw at it.

Both words sound cool and industrial, don't blame the users or the programmers, and get the point across.

BTW, here's Metrowerks' old mascot Arnold, the guy who used to help us Mac programmers harden and robustify our code with a heat treat furnace, a forge, and an anvil and small sledge hammer:

  • hardening generally refers to fault tolerance of the underlying hardware - or resistance to gamma rays ;-) robustness can mean a lot of things – Steven A. Lowe Jul 12 '11 at 0:48
  • @Steven: Well, yes. But this is for communication to what is presumably a non-technical audience, and the question is really about how to "spin" the task so it's palatable to those folks. – Bob Murphy Jul 12 '11 at 0:58
  • that makes sense; the non-technical audience has probably seen TV ads for 'hardened' laptops. So they'll think it's ok to drop your software 3 feet onto concrete ;-) – Steven A. Lowe Jul 12 '11 at 1:08
  • @Steven: Yup, and if they've seen the latest Toshiba laptop commercial, they'll also realize that if they don't give you the time and resources to harden the software, it will bring about the Zombie Apocalypse. B^) – Bob Murphy Jul 12 '11 at 1:31

Defensive Programming

Is what I was taught. Back when we had to whittle our own bits out of wood.

If you want to be PC, call it "anticipatory" programming.


When I was learning, we called it bullet proofing.

Most of the other euphemisms I've read apply too, though.


How about "Fault tolerant" system or UI?


"Idiot proofing" should consist of both

  • designing the UI so that it is user friendly and leads the user to enter data in the way that the programmers expect, and

  • testing the UI to determine whether the interface can be broken by entering unexpected data values.

Both steps might reasonably appear on development schedule where the design is vetted by a user experience expert and where the delivered code is vetted by a tester to ensure that invalid data is handled correctly (for whatever "correctly" means to your application).

  • You didn't answer the question that was asked. – Robert Harvey Jul 11 '11 at 20:18
  • @Robert - I believe I did. The nicer way to say "idiot proofing" is either "review the design to improve user friendliness" or "test that the interface handles invalid data" depending on which sense of "idiot proofing" you mean. – Justin Cave Jul 11 '11 at 20:48
  • OK, that makes sense. – Robert Harvey Jul 11 '11 at 20:54

Idiot-proofing involves a lot more than simple input validation. I wouldn't even include such a thing in its definition.

Input validation is a process where you sanitize and validate user data to both eliminate illegal/nonsensical values. This should always be done with any information coming from outside of your program so as to eliminate the obvious as well as protecting yourself from attacks (e.g. sql injection attacks).

I would consider idiot-proofing to be a set of logic to keep the user from accidentally causing great damage to him/herself through otherwise legal means.

For instance, making rm reject the command rm -rf / and close variants has nothing to do with validation or correctness. It's a perfectly valid command. Unfortunately, it's a command which could and can wipe out all of your data from all of your disks in Unix/Linux. Idiot proofing this would reject this command and would suggest rm -rf --i-really-mean-this /, or if in interactive mode, have the user type in an affirmative response after a warning.

Anything which is destructive to the system should be idiot-proofed. Anything which could cause potential embarrassment might also be a candidate (e.g. "are you sure you want to send this email without an attachment even though you mentioned one in your text?", and "are you sure you want to send this email to the entire company?")

Idiot-proofing is a collaboration between QA (trying to be the best idiot) and Development (trying to anticipate all of these scenarios and designing around them).

As for a more friendly synonym, may I suggest "destructive code-path analysis" or "enable user feedback for critical operations". Whatever you may call it, you should really start it as early in the design process as possible.


"Sanity Checking" tends to work pretty well quite often...

  • 3
    To me, "sanity checking" means about the same thing as "assert": making sure that internal state is correct. Not really the same thing as external input validation. – Mason Wheeler Jul 11 '11 at 20:17
  • @Mason, I think of it as checking the state of the system, at all points, for valid input that makes sense. For example, checking that the end date is after the start date, in addition to checking for garbage input, etc. I do see your point of view too and agree with you. – Marlon Jul 11 '11 at 20:23

Call it "adding Poka-yokes to the UI". http://en.wikipedia.org/wiki/Poka_yoke


"Error handling" or "input validation" would be other terms I'd use for what you describe. Bulletproof would be another term that I could see being used in some circles as the idea here is to make the software robust enough to handle almost anything. Rock solid would be another slang phrase I could imagine someone wanting to use here too.


"Worst case scenario proofing". Because, as developers, we all know that if it can be done, then it will be done. So you just have to be prepared to handle that worst case scenario situation with your software.

Security measures aren't just a way to protect users against outside cyber invasions, but also against themselves. We live in an imperfect world with imperfect users.


Gold-plating is the polite (and very positive sounding) term I use when talking about improving end-user interface experience in any way (GUI or other).

Idiot-proofing, as you say, is the largest part of that process, along with design or workflow improvements (think end-user feedback acknowledgment).

The idea here is that you can use that term freely in the work environment and its seen as a valuable process (once completed) by both management and users, even though it may take some time (and thus generally costs some money).

many other terms related to this (often end-of-cycle) process make it sound like this process:

  • implies users (often management ;-) are dumb
  • is hard to achieve
  • has little net worth

By associating gold with the process (metal usually equated to "worth" rather than "cost"), I've seen the process become changed from expense to investment in some managers mindsets.

Its like openly stating that until this is done, that clunky piece of steel isn't jewelry yet. But once its plated... then its valuable.

  • I see how this term works for your audience. For most managers, gold-plating would be the first thing cut from the project. In other words, the not necessary parts. – Gilbert Le Blanc Jul 12 '11 at 12:41
  • Odd - I see the term "gold plating" as meaning you're wasting your time doing something that offers no functional improvement. Ensuring valid inputs etc. does offer functional improvement and is therefore (by my definition) not gold plating. – ChrisF Jul 12 '11 at 13:53
  • the detail is that gold plating doesn't improve the software internals. it only improves the external aspect of it. I use it when non-techies are involved specifically because it doesn't relate to a specific part of the end of cycle process. People understand it as, once gold plating is done, its nice, easy to use and has added value. its not just a ruff piece of software. – moliad Jul 12 '11 at 15:54
  • In my experience, gold-plating is normally used to describe software laden with unnecessary features, i.e. as a synonym for bloatware. – Mark Booth Jul 12 '11 at 16:36
  • yeah, just did a little research and found that the term is sometimes used that way in literature (thanks for the comment). Funny thing is that in many places I've worked, idiot proofing was considered gold-plating in this sense (It really depends on the type of work you do I guess). – moliad Jul 12 '11 at 18:46

Most often using in relation to manufacturing processes but I think a really good fit is Poka-Yoke:

"[poka yo-ke] is a Japanese term that means "fail-safing" or "mistake-proofing"

It was originally described as baka-yoke, but as this means "fool-proofing" (or "idiot-proofing") the name was changed to the milder poka-yoke.

More broadly, the term can refer to any behavior-shaping constraint designed into a product to prevent incorrect operation by the user."


A common term in bigger shops is also Quality Assurance (QA).

Its a general, vague on purpose term which you can mold to your own specific meaning within your release cycle.


We call it Human Proofing. We are all idiots.

Not the answer you're looking for? Browse other questions tagged or ask your own question.