Another was that obviousness of a feature is how that thing will be used. You don't want people placing stuff on top of walls, don't make them flat.
I think this is a bit too easy. After all it depends on what problem the thing is solving. E.g. if I think of lab test equipment you failing to use it properly might have nothing to do with the design and everything to do with you not having sufficient knowledge in the given domain.
I vehemently oppose the idea that everything needs to be usable without instruction. Sure, everything where it makes sense should be usable without instructions — but it does not make sense everywhere.
That btw. does not mean the design and usability of the lab test equipment cannot be improved uppon. I think any design can be improved uppon till you at least find a local maxima.
But not every design needs to be usable without instruction, because not every tool/object should be usable without instruction.
For other objects usability is simply a function of your ability to understand basic physics. If you e.g. hold a flashlight wrong enough you might emit light at an angle that wont properly illuminate the thing you are meant to illuminate. If you hold a microphone 50cm away and point it in the wrong direction and expect your voice to be heared well, you would have done better with instructions.
You know, cups and door handles.
Knowing which thing is meant to be an everyday thing and which is meant to require some domain specific knowledge is key. Trying to make some specialized tool easier to use than it should be, can harm the usability of the specialized thing. Treating an everyday object as a specialized thing when it is clearly not and pushing the burden of reading the object onto the user is also bad. Both problems can be observed (just think about documentation that starts with "this is completely trivial to use" and then it isn't).
As Dieter Rams said: Good design is honest. That means also that it should not hide the complexity of the actual problem people try to solve with this in a bad way.
The comment might read so if you don't have the context, but the context here is everyday things, as is obvious by the title (and the book).
The book also talks (which probably you're familiar with already then) about discerning what is a everyday thing vs not.
Dieter Rams is also mentioned in the book if I remember correctly, as examples of good user experience, especially since Rams mostly created designs for everyday things.
Its about common everyday things. We have a washing machine which I totally can't use without going through the manual, reading which number and which light does what. You shouldn't need to carefully go through a manual to just wash your clothes.
There is another book "User Interface Design for Programmers" by Joel Spolsky from which my take away was that no one is going to read all your manuals and documents.
Both of these essentially boil down to making things obvious for your end users.
This is actually covered in the book. It's really worth a read. It's only ~300 pages with lots of those pages being pictures and diagrams.
The example I use, in my life, is Tokyo subway maps[1]. They look crazy complicated; and they are, because it's a complex system.
But after we learn it, using them is as natural as turning a door handle.
It should not be easy to use things wrongly, with more secret knowledge needed to use things that are more dangerous or require more skill than things that will do no harm when used wrongly.
In other words, your lab equipment should be fool-proofed so that if I walked into the lab and try to use it, I might get it loud buzzing sound a emoji of a sad face.
I am not the first to believe this. "Poka yoke" is a manufacturing term for a reason.
Think of the command line. It would drive me crazy if it didn't exist, because I'm a power user. But it's not a good interface for a novice, it fails several design guidelines, starting with lack of discoverability.
Lab equipment is even worse, since you -- a non-scientist -- are not even supposed to be touching it to begin with.
I do think that equipment with the potential to cause catastrophic failure (such as a nuclear reactor) should be designed in such a way that the critical error state cannot be entered easily. A silly human mistake shouldn't cause a reactor meltdown. (Do note modern nuclear reactors tend to "fail safe", so this is definitely a consideration!)
I didn't mean discovering the terminal app itself!
I used to see this in church settings where someone would come up front to "give a testimony" (share a personal anecdote) and be handed a typical SM58-style vocal mic. They would hold it nearly at arms length pointed straight up, so they were talking off the side of this directional mic.
It drove the sound guys and the entire congregation nuts.
After reading this book, I realized that maybe if one person can’t program their VCR, you could have argued that it’s their fault. But certainly if so many people have problems with it, it’s clearly an issue with the design.
Arguably the VCRs did as well as they could - BUT they made the critical mistake of not realizing that programming and setting the clock would be difficult (and for many uses of the machine, not necessary at all, so nobody would bother figuring it out), and so didn't set the VCR to just not display the clock until the time was set. Very few people bought VCRs to use as a clock, after all.
If you weren't going to use that feature, yeah, it was pointless and could have just stayed blank rather than blinking 12:00 or whatever.
Which means that if you can't figure out how to set the time, you can just remember to disconnect the battery just before noon, and then reconnect it.
The flashing clock on a VCR is actually an error message because if it lost power/lost time, it won't record correctly until you tell it what time it is.
But if you have no timed recording setup, there's no need to report that error.
The other big lesson I took is about discoverability but I think most people here know about that, even if they don't really notice where it's terrible (Vim, CLIs, Python, etc.)