> 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".

Oh you must be joking. PMs are terrible. And technical people are basically the only ones who actually know how to write things in detailed and unambiguous enough way - it's something you can't really learn without trying and learning just "how dumb computers are" - which actually means, "how many things people implicitly assume to be self-explanatory or common knowledge".

> 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".

That I can totally believe. But then again, non-technical people like to do that too - often the "obvious" thing being the one that they conveniently forgot to mention at all.

> Oh you must be joking. PMs are terrible.

If companies weren't getting value from them, they wouldn't be hiring them.

> And technical people are basically the only ones who actually know how to write things in detailed and unambiguous enough way

No, that's exactly OP's point. Developers in general are terrible at writing explanatory text (if they even bother at all) because they make so many assumptions about background knowledge that others don't share.

Any group with expertise that's not widely shared will do the same. The illusion of transparency means people are shockingly bad at knowing what's obvious or easy unless they're teachers. That doesn't always help either.

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?

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.)

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.

I wonder if any of these 2/3 of developers ever had a service job? Has it gotten to the point to where they're like football players, and all they've done since the sixth grade is code?

I haven't found PM's to be particularly better "with people" than any other group, honestly.

We are not better "with people", but we are trained (at least some of us are) in understanding what people want and need, and how to translate those wants and needs in something a tech team can build.

> 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.

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.

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.

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?

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

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/.

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.

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!

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.

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.

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....

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.

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.

I also think people don't always try to write clear instructions.

Did you fix the controls to be intuitive afterwards?