4 ms·

> shown that some technical types just don't understand other people. And other people are better? Writing clear instructions that random people can follow is

by dmm 11y ago

> shown that some technical types just don't understand other people. And other people are better? Writing clear instructions that random people can follow is _hard_.

speeder 11y ago
I once made a arcade cabinet + game, I wrote on the side of the screen exactly what each button do. when I showed it in public in an event, I saw the same loop many, many times: 1> user press buttons confused, see I am standing nearby, ask me what they do. 2> I do nothing if they have a SO near. 3> SO points user, that there are descriptions of the button right there in front of them. 4> User slaps his forehead. In case there was no SO near, then I would point it myself, the reaction of people was still the same... I concluded that ins't just that people don't follow instructions, is that they don't even try.
- pbreit 11y ago
  I also think people don't always try to write clear instructions.
- delish 11y ago
  This is funny and interesting. SO stands for significant other in this case, right? This is happening because the game-player wants to play the game, but the SO is, in a leisurely way, taking it all in?
  - TeMPOraL 11y ago
    I actually read a post today that had a similar story about IKEA-like furniture. http://dirtsimple.org/2009/05/how-we-get-stuck.html http://dirtsimple.org/2009/05/how-we-get-stuck.html TL;DR: The author's SO got stuck trying to assemble a kitchen cabinet, and couldn't figure it out. The author looked at the problem, checked with the manual, discovered the solution immediately, and got called smart. The SO didn't even bother. And the author realizes that if their positions were swapped, he wouldn't bother either. There's something wrong with the whole class of people - that mostly seems to coincide with the "non-tech" group, though maybe it's more about problem-solvers/not problem-solvers. What's wrong is that they get stuck on the first obstacle and give up. Instead of assuming that there must be a simple solution and searching for it, they assume it's broken and quit. Also, related, the famous XKCD chart: https://xkcd.com/627/ https://xkcd.com/627/.
    - jandrese 11y ago
      People always look at me like I'm some kind of code wizard when they are stuck on an intractable problem and I figure out it by just reading the compiler's message. To be fair, compiler messages can be needlessly cryptic, but if you copy and paste the error into Google you'll almost always find someone who did the exact same thing and had it answered quickly.
- tsunamifury 11y ago
  If you're writing paragraph long instructions (as seen in the picture of your machine), you've probably designed your game wrong. In fact these days if you have instructions at all, you're probably doing it wrong. Its not about how obvious you think it is, its about how hard it seems to the user. And the harder you make it the fewer users you'll have. Secondarily, you put your instructions in printed form next to the screen -- when all the user cares about is the screen itself.
- JeffreyKaine 11y ago
  How you instruct, Why you instruct, Where you instruct, and When you instruct are all equally as important as What you instruct the user to do.
- emeraldd 11y ago
  My first thought on reading this is that the cabinet decorations are almost always subconsiously ignored as noise. The fact that SOs spotted the directions while the players didn't seems to confirm it as well. I say subconcious because most people wouldn't realize the heuristic they were following until it's pointed out to them and probably wouldn't see their mistake even then.
- deleted 11y ago
  [deleted]
- mrspeaker 11y ago
  First rule of game design: players don't read things. Not on the screen, and certainly not on a cabinet - it's not the user's fault you put instructions in text format in a place that wasn't even the screen!
  - TeMPOraL 11y ago
    This is bullshit. Somehow, the games made 20 years ago didn't know this rule and were totally fine. We're training people to be stupid. You can't reasonably expect that a complex program will be perfectly usable for the newbie from the get-go, and trying to assume that only makes the problem worse for the future.
    - teddyh 11y ago
      I’d like to agree with you that games 20-30 years ago were unashamedly complex and were the better for it, but maybe they were made for a different audience, i.e. the small percentage of people who had invested in a home computer in the first place. Also: “In fact, users don't read anything.” http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html http://www.joelonsoftware.com/uibook/chapters/fog0000000062....
  - ygra 11y ago
    Not only of game design. People never read things that they don't expect or want to read. Message boxes are wonderful in this regard. Users trained themselves to dismiss those without ever reading them. Usually Cancel or No will close the message box and destroy nothing. Heck, I frequently even see people getting annoyed at message boxes that have a little □ Don't show this message again checkbox without ever noticing that they could get rid of them forever. Simply because they won't read.
- golergka 11y ago
  Did you fix the controls to be intuitive afterwards?
zenlikethat 11y ago
> And other people are better? Yes they are. There's a reason why product managers exist. I don't think the author's point is that technical people can't write clear instructions, it's that technical individuals sometimes mock or deride others over things that "should be obvious".
- jonesb6 11y ago
  Wait wait wait wait. You're saying project managers (which can be superimposed to middle management in general really) are innately better at understanding users then the average developer? Edit: Ok you said product managers. Which I suppose is reasonable, product managers should have a good understanding of developing products for customers. I'm going to leave the top part of my comment because in retrospect its food for thought. Are developers innately bad at understanding users? Is middle management better?
  - geofft 11y ago
    Developers are good at creating mental models of how the system probably works underneath. Non-developer users usually don't do this. If you're making a product for non-developer users, your subconscious tendency to model the system is a disadvantage, because you won't have a reliable sense for what's intuitive and what's not. If an abstraction leaks, you'll see straight through it and manipulate what's under the abstraction; a non-developer user will continue to try to manipulate the abstraction itself. This disadvantage potentially extends to managers whose job includes understanding what the abstracted-over system is, but they're probably not thinking about it as hard on a day-to-day basis as the developers. (Note that "non-developer users" probably also includes developers whose expertise does not extend to the specific system in question and therefore have no ability to guess what's leaking across the abstraction barrier, e.g., Linux users trying to use a Windows tool, new employees figuring out your in-house build system, etc. etc.)
  - funkyy 11y ago
    Totally. Most of developers I know are unable to see what people want. They are good at technical point of view, they are good at recognizing patterns and read data, but usually they are unable to connect all the dots and make something beautiful. I started developing just 3 years ago, after shifting from marketing and sales. Its amazing how most developers lack social skills needed to understand user trends. Yes, product managers are important to connect technical point of view with more abstract one. No, not all developers are like that, but I would say 2/3 at least. Developers are mostly good at creating products that they would use. Once they enter ground where they create product for others - thats when difficult part begins.
rodgerd 11y ago
> And other people are better? Other people are remarkably less prone to arrogantly declaring everyone else to be idiots, in my experience. Tech is a field full of people who fondly imagine Dilbert as a documentary about a hero.

by dmm 11y ago

> shown that some technical types just don't understand other people. And other people are better? Writing clear instructions that random people can follow is _hard_.

speeder 11y ago

I once made a arcade cabinet + game, I wrote on the side of the screen exactly what each button do. when I showed it in public in an event, I saw the same loop many, many times: 1> user press buttons confused, see I am standing nearby, ask me what they do. 2> I do nothing if they have a SO near. 3> SO points user, that there are descriptions of the button right there in front of them. 4> User slaps his forehead. In case there was no SO near, then I would point it myself, the reaction of people was still the same... I concluded that ins't just that people don't follow instructions, is that they don't even try.

pbreit 11y ago
I also think people don't always try to write clear instructions.
delish 11y ago
This is funny and interesting. SO stands for significant other in this case, right? This is happening because the game-player wants to play the game, but the SO is, in a leisurely way, taking it all in?
- TeMPOraL 11y ago
  I actually read a post today that had a similar story about IKEA-like furniture. http://dirtsimple.org/2009/05/how-we-get-stuck.html http://dirtsimple.org/2009/05/how-we-get-stuck.html TL;DR: The author's SO got stuck trying to assemble a kitchen cabinet, and couldn't figure it out. The author looked at the problem, checked with the manual, discovered the solution immediately, and got called smart. The SO didn't even bother. And the author realizes that if their positions were swapped, he wouldn't bother either. There's something wrong with the whole class of people - that mostly seems to coincide with the "non-tech" group, though maybe it's more about problem-solvers/not problem-solvers. What's wrong is that they get stuck on the first obstacle and give up. Instead of assuming that there must be a simple solution and searching for it, they assume it's broken and quit. Also, related, the famous XKCD chart: https://xkcd.com/627/ https://xkcd.com/627/.
  - jandrese 11y ago
    People always look at me like I'm some kind of code wizard when they are stuck on an intractable problem and I figure out it by just reading the compiler's message. To be fair, compiler messages can be needlessly cryptic, but if you copy and paste the error into Google you'll almost always find someone who did the exact same thing and had it answered quickly.
tsunamifury 11y ago
If you're writing paragraph long instructions (as seen in the picture of your machine), you've probably designed your game wrong. In fact these days if you have instructions at all, you're probably doing it wrong. Its not about how obvious you think it is, its about how hard it seems to the user. And the harder you make it the fewer users you'll have. Secondarily, you put your instructions in printed form next to the screen -- when all the user cares about is the screen itself.
JeffreyKaine 11y ago
How you instruct, Why you instruct, Where you instruct, and When you instruct are all equally as important as What you instruct the user to do.
emeraldd 11y ago
My first thought on reading this is that the cabinet decorations are almost always subconsiously ignored as noise. The fact that SOs spotted the directions while the players didn't seems to confirm it as well. I say subconcious because most people wouldn't realize the heuristic they were following until it's pointed out to them and probably wouldn't see their mistake even then.
deleted 11y ago
[deleted]
mrspeaker 11y ago
First rule of game design: players don't read things. Not on the screen, and certainly not on a cabinet - it's not the user's fault you put instructions in text format in a place that wasn't even the screen!
- TeMPOraL 11y ago
  This is bullshit. Somehow, the games made 20 years ago didn't know this rule and were totally fine. We're training people to be stupid. You can't reasonably expect that a complex program will be perfectly usable for the newbie from the get-go, and trying to assume that only makes the problem worse for the future.
  - teddyh 11y ago
    I’d like to agree with you that games 20-30 years ago were unashamedly complex and were the better for it, but maybe they were made for a different audience, i.e. the small percentage of people who had invested in a home computer in the first place. Also: “In fact, users don't read anything.” http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html http://www.joelonsoftware.com/uibook/chapters/fog0000000062....
- ygra 11y ago
  Not only of game design. People never read things that they don't expect or want to read. Message boxes are wonderful in this regard. Users trained themselves to dismiss those without ever reading them. Usually Cancel or No will close the message box and destroy nothing. Heck, I frequently even see people getting annoyed at message boxes that have a little □ Don't show this message again checkbox without ever noticing that they could get rid of them forever. Simply because they won't read.
golergka 11y ago
Did you fix the controls to be intuitive afterwards?

zenlikethat 11y ago

> And other people are better? Yes they are. There's a reason why product managers exist. I don't think the author's point is that technical people can't write clear instructions, it's that technical individuals sometimes mock or deride others over things that "should be obvious".

jonesb6 11y ago
Wait wait wait wait. You're saying project managers (which can be superimposed to middle management in general really) are innately better at understanding users then the average developer? Edit: Ok you said product managers. Which I suppose is reasonable, product managers should have a good understanding of developing products for customers. I'm going to leave the top part of my comment because in retrospect its food for thought. Are developers innately bad at understanding users? Is middle management better?
- geofft 11y ago
  Developers are good at creating mental models of how the system probably works underneath. Non-developer users usually don't do this. If you're making a product for non-developer users, your subconscious tendency to model the system is a disadvantage, because you won't have a reliable sense for what's intuitive and what's not. If an abstraction leaks, you'll see straight through it and manipulate what's under the abstraction; a non-developer user will continue to try to manipulate the abstraction itself. This disadvantage potentially extends to managers whose job includes understanding what the abstracted-over system is, but they're probably not thinking about it as hard on a day-to-day basis as the developers. (Note that "non-developer users" probably also includes developers whose expertise does not extend to the specific system in question and therefore have no ability to guess what's leaking across the abstraction barrier, e.g., Linux users trying to use a Windows tool, new employees figuring out your in-house build system, etc. etc.)
- funkyy 11y ago
  Totally. Most of developers I know are unable to see what people want. They are good at technical point of view, they are good at recognizing patterns and read data, but usually they are unable to connect all the dots and make something beautiful. I started developing just 3 years ago, after shifting from marketing and sales. Its amazing how most developers lack social skills needed to understand user trends. Yes, product managers are important to connect technical point of view with more abstract one. No, not all developers are like that, but I would say 2/3 at least. Developers are mostly good at creating products that they would use. Once they enter ground where they create product for others - thats when difficult part begins.

rodgerd 11y ago

> And other people are better? Other people are remarkably less prone to arrogantly declaring everyone else to be idiots, in my experience. Tech is a field full of people who fondly imagine Dilbert as a documentary about a hero.