4 ms·

For me one lesson was that when we fail to properly use a thing we should blame that thing for its bad design instead of ourselves. Another was that obviousnes

For me one lesson was that when we fail to properly use a thing we should blame that thing for its bad design instead of ourselves. 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.

IshKebab 4y ago
Yeah that's easily the biggest lesson of the book, especially because almost everyone gets it wrong. It's especially noticeable here, so if you haven't read this book yet please do! 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.)
atoav 4y ago
> For me one lesson was that when we fail to properly use a thing we should blame that thing for its bad design instead of ourselves. 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.
- Stratoscope 4y ago
  > If you hold a microphone 50cm away and point it in the wrong direction and expect your voice to be [heard] well, you would have done better with instructions. 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.
  - h2odragon 4y ago
    Tape paper around it in a little cone shape. people will speak into the cone.
- capableweb 4y ago
  The book is not talking about every single thing, but everyday things, objects people without any domain knowledge should be able to use, like radios, teapots, doors and so on.
- smilespray 4y ago
  I agree. But the context here is a book called The Design of Everyday Things. You know, cups and door handles.
  - atoav 4y ago
    Yeah I know the book. Yet: your comment made it sound like this idea is universally applicable (which as I demonstrated it isn't). 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.
    - capableweb 4y ago
      > Yeah I know the book. Yet: your comment made it sound like this idea is universally applicable (which as I demonstrated it isn't). 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.
- smusamashah 4y ago
  I didn't mean 'everything'. Things that do require specialized knowledge are already used by a very specific subset of people. 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.
- hyperpallium2 4y ago
  By the principle of only taking responsibility where you can do something about it: designer blames design; user blames user.
- thundergolfer 4y ago
  > But not every design needs to be usable without instruction, because not every tool/object should be usable without instruction. 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.
- ChrisMarshallNY 4y ago
  Tufte[0] is a good person to demonstrate that kind of UX. His stuff can be pretty crazy, and often needs training, but, once someone knows how to do something he champions, it's amazing. 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. [0] https://www.edwardtufte.com/tufte/ https://www.edwardtufte.com/tufte/ [1] https://www.tokyometro.jp/en/subwaymap/ https://www.tokyometro.jp/en/subwaymap/
  - slowhand09 4y ago
    I took Tufte's course. London Metro maps is good also. He points out the map is significantly different than reality, but makes the complex seem simple.
    - ChrisMarshallNY 4y ago
      Did he have the Euclid's Geometry books?
- readthenotes1 4y ago
  I feel you are re-emphasizing the validity of the point. 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.
  - the_af 4y ago
    I think a problem with designing specialized equipment (such as lab equipment) in such a way that it is "obvious" to people without specialized knowledge is that it becomes annoying to use for power users, i.e. the lab workers who do have the specialized knowledge. 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!)
    - borroka 4y ago
      I don't think that the command line (take Macs) is difficult to discover, since you have just to digit "terminal" in spotlight. I think it is within easy reach of anyone, then if the word "terminal" doesn't mean anything to the user, there is no point in looking for the command line.
      - the_af 4y ago
        Sorry, I mean using the command line. You can't easily discover which terminal commands are available, which is why the command line has terrible affordances -- in Don Norman's parlance -- for novices. I didn't mean discovering the terminal app itself!
pacificmint 4y ago
Back in the day, when VCRs were a thing, everybody used to joke about how no one new how to program theirs. Heck, half of them had the blinking clock forever cause people couldn’t figure out how to reset it. 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.
- bombcar 4y ago
  It can also indicate a process that is (currently) beyond the capabilities of the interface available (thinking the difficulty of programming a VCR when you have four buttons and one LED that can display 88:88 and that's it vs a full touchscreen interface on a phone). 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.
  - corrral 4y ago
    The clock was crucial to timed recordings, which were how people recorded TV programs when they weren't around for them before things like TIVO existed. Set a it to record when your program's supposed to start and for X duration, put a blank tape in, go to work, come home and find it's recorded that daytime program you didn't want to miss. 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.
    - bombcar 4y ago
      Interestingly car radios have the same "how do you set the time" problem, and arguably a clock is more useful in a car anyway - but almost all of them set the time to 12:00 when they get power back. They don't blink. 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.

IshKebab 4y ago

Yeah that's easily the biggest lesson of the book, especially because almost everyone gets it wrong. It's especially noticeable here, so if you haven't read this book yet please do! 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.)

atoav 4y ago

> For me one lesson was that when we fail to properly use a thing we should blame that thing for its bad design instead of ourselves. 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.

Stratoscope 4y ago
> If you hold a microphone 50cm away and point it in the wrong direction and expect your voice to be [heard] well, you would have done better with instructions. 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.
- h2odragon 4y ago
  Tape paper around it in a little cone shape. people will speak into the cone.
capableweb 4y ago
The book is not talking about every single thing, but everyday things, objects people without any domain knowledge should be able to use, like radios, teapots, doors and so on.
smilespray 4y ago
I agree. But the context here is a book called The Design of Everyday Things. You know, cups and door handles.
- atoav 4y ago
  Yeah I know the book. Yet: your comment made it sound like this idea is universally applicable (which as I demonstrated it isn't). 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.
  - capableweb 4y ago
    > Yeah I know the book. Yet: your comment made it sound like this idea is universally applicable (which as I demonstrated it isn't). 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.
smusamashah 4y ago
I didn't mean 'everything'. Things that do require specialized knowledge are already used by a very specific subset of people. 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.
hyperpallium2 4y ago
By the principle of only taking responsibility where you can do something about it: designer blames design; user blames user.
thundergolfer 4y ago
> But not every design needs to be usable without instruction, because not every tool/object should be usable without instruction. 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.
ChrisMarshallNY 4y ago
Tufte[0] is a good person to demonstrate that kind of UX. His stuff can be pretty crazy, and often needs training, but, once someone knows how to do something he champions, it's amazing. 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. [0] https://www.edwardtufte.com/tufte/ https://www.edwardtufte.com/tufte/ [1] https://www.tokyometro.jp/en/subwaymap/ https://www.tokyometro.jp/en/subwaymap/
- slowhand09 4y ago
  I took Tufte's course. London Metro maps is good also. He points out the map is significantly different than reality, but makes the complex seem simple.
  - ChrisMarshallNY 4y ago
    Did he have the Euclid's Geometry books?
readthenotes1 4y ago
I feel you are re-emphasizing the validity of the point. 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.
- the_af 4y ago
  I think a problem with designing specialized equipment (such as lab equipment) in such a way that it is "obvious" to people without specialized knowledge is that it becomes annoying to use for power users, i.e. the lab workers who do have the specialized knowledge. 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!)
  - borroka 4y ago
    I don't think that the command line (take Macs) is difficult to discover, since you have just to digit "terminal" in spotlight. I think it is within easy reach of anyone, then if the word "terminal" doesn't mean anything to the user, there is no point in looking for the command line.
    - the_af 4y ago
      Sorry, I mean using the command line. You can't easily discover which terminal commands are available, which is why the command line has terrible affordances -- in Don Norman's parlance -- for novices. I didn't mean discovering the terminal app itself!

pacificmint 4y ago

Back in the day, when VCRs were a thing, everybody used to joke about how no one new how to program theirs. Heck, half of them had the blinking clock forever cause people couldn’t figure out how to reset it. 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.

bombcar 4y ago
It can also indicate a process that is (currently) beyond the capabilities of the interface available (thinking the difficulty of programming a VCR when you have four buttons and one LED that can display 88:88 and that's it vs a full touchscreen interface on a phone). 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.
- corrral 4y ago
  The clock was crucial to timed recordings, which were how people recorded TV programs when they weren't around for them before things like TIVO existed. Set a it to record when your program's supposed to start and for X duration, put a blank tape in, go to work, come home and find it's recorded that daytime program you didn't want to miss. 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.
  - bombcar 4y ago
    Interestingly car radios have the same "how do you set the time" problem, and arguably a clock is more useful in a car anyway - but almost all of them set the time to 12:00 when they get power back. They don't blink. 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.