If too many users are wrong, it's probably your fault (2011) | Hacker News Reader

If too many users are wrong, it's probably your fault (2011)

rachelbythebay.com

165 pointsjcolman112 comments

I have a nice anecdote to share. Years ago I was in the dev team for the website of a new major mobile operator in Italy. When the first version went to production, there was a wave of sign ups from customers, but in the following days we received a lot of support calls from customers who had signed up but couldn't access their accounts. We started analyzing the problem and noticed two things:

1) the customers who couldn't sign up had used illegal characters in their usernames - there was no validation in place to prevent this: bad mistake;

2) most of these customers, literally hundreds of them, had signed up with usernames containing lots of asterisks. Many usernames looked like lillo* * * * * or bobby* * * * *.

I didn't give much weight to this, assuming (wrongly) that it was just a coincidence. Only a guy in my team kept thinking there had to be an explanation, until he nailed it: it was the signup form that said "fill in the fields with asterisk". So we added the damn validation and clarified the copy.

I've always wanted to scream answers at the self-checkout kiosks that verbally ask if you are bringing your own bags and then make you push on the screen to select Yes or No.

Out of impatience for text-to-speech systems (easy) to catch up with reliable speech recognition systems (hard)? Or because the system should be more difficult for blind people (or those with speech impediments) to use? ;-)

Reminds me of when I was teaching and we were discussing test design. If 90% of your students fail your exam what have you learned?

I would argue that barring a conspiracy of some kind that the designer has made a mistake in either in the preparation of the exam or the preparation of the students. Others might argue that students may be lazy or aren't maximizing the use of their time. I hear similar arguments about users now that I'm in IT but I've always felt that it is the designer's problem if "no one can use it right."

This was very frustrating to me in school.

> If 90% of your students fail your exam what have you learned?

It depends if I have corroborating information.

Normally, it means that they are lacking some very fundamental piece to their learning. The last class I taught that this happened in had a particularly poor Data Structures teacher and so didn't understand Hashes/Dicts/Associative Lists and how to use them.

Yeah, that assignment didn't go well for about 30% of the class. I had to back up and teach that piece.

However, my first assignment ALWAYS has 40+% failure rate. And my assignment is: "Here are the directions to: set up Eclipse, set up Mercurial, type in this program, compile it, run it, and check it in so I can run the automated tester on it."

I literally give people a document with every single step documented. I'm not joking. We're talking a single print statement that prints "Hello, World!".

40%+ always fail. It's almost invariant. Nothing I do can budge that number. I want to bang my head off the desk at the office hours just before and after that assignment.

How do this students do by the end of the term? Are they failing because they can't do it, or are they failing because the assignment is due the day after their last keg party?

Since the projects are supposed to take two or three weeks to complete the Keg party shouldn't be a major factor. Yet it is.

Students always leave assignments to the last night and then panic.

Best classes usually have multitude of manageable last nights at regular intervals.

*Best as in most learning happens to the majority of students.

I agree. I actually made an series of online quizes that just required the student to read through the lecture notes to find the answer before the lecture (the notes were posted before the class). Even though these quizes were only worth 5% of the overall mark, the average mark of the class was 10% points higher after introducing this change. Just encouraging the students to read through their lecture notes before class made an amazing difference to how the students performed overall.

The distribution gets far more reasonable after most of the initial bunch of people who can't follow simple directions all drop after that first assignment.

I always make sure that my first assignment is due before the drop deadline. I don't make that first assignment worth a lot of points, but it sets the tone for the rest of the class--"If you can't do this, you're in for a rough time in my class." Anyone who stays even if they bomb that first assignment knows what they are getting into.

If you have the freedom to be able to do this then this is great. When I was an academic I was under enormous pressure by the university to never let a student drop out of a course because of the financial consequences. Still had the same problems as you, but I had to figure out a way to get the students through the course. Lots of fun!

At my University I would say the Numbers are about the same, CS Student in Programming, had C/C++ classes, still don't know what the heap/stack is.

The teachers themselves are pretty bad as well. Java is alrightish, but not in a course called 'Systems Programming' where we talk about paging! And the list goes on...

I'm always astonished by people who teach C++ to newbies in programming. I've been writing code more or less constantly for 20 years (since I was about 7), work as a lead developer now (C#/Unity), and have developed quite a while small hobby projects in C as well as in C++, read the Straustroup book on the labguage (the small "Tour" one) and even practiced about half of it, but C++ and all it can do still frightens me, and I sincerely hope that I never have to work with it in production.

Now, when I hear about students that learn what array or loop is on C++... I imagine how they start call themselves "C++ developers" after graduation, and it's even more terrifying.

I completely agree, despite having done somewhat well on that course I do not call myself a C++ Programmer and would rather not use it later on.

But it was just an example that despite needing some crucial knowledge students just don't care and do not bother to learn themselves. (Even if told)

Eclipse and dependencies handling are hard problems. It works if everything is set up perfectly, but Eclipse is super brittle, and all the plugins make bad assumptions about Eclipse and other Eclipse plugins.

Thank you. This is my main reason why giving up on eclipse shortly in. There's something to be said when your application can't handle small failures. (Looking at you, too, visual studio)

I agree, fortunately there are convenient pre-packaged Eclipse bundles like Spring Tool Suite [0] that include a curated set of plugins for common development scenarios. This may mean you end up with multiple Eclipse installations but it's easier than trying to maintain dozens and dozens of plugins within a single installation.

0: https://spring.io/tools

> Eclipse and dependencies handling are hard problems. It works if everything is set up perfectly, but Eclipse is super brittle

I agree. If that is the problem, I will happily walk the student through the setup--even at any point in the semester. If a computer craps out, I will help the student recover from the repository--I don't expect them to be able to do that. It does also happen, rarely, that I have to actually help a student set up their computer because they have some weird issue. I do not consider failing at setting up your environment to be a failure of the class. Schedule some time with me and we'll go through it together.

HOWEVER, this is generally not the problem, oddly. They get that set up pretty much fine.

The first problem is: System.out.println("Hello, World!");

I WARN people over and over. I am automated testing this. Computer output must be EXACT. The comma, space, capitalization, and exclamation point ARE NOT OPTIONAL. Debugging is about noticing details, and if you can't match this, you're not going to find the actually subtle bugs later in your own code. Really, this is the only functional line in the program--I'm not joking about this.

The second problem is: "But I didn't know I could check this before the assignment date." Um, I have a website set up for the class--did you check it for the past two weeks that it has been running? I have pointed this page out and put it on screen at both beginning and end of class for the past 4 lectures. The anonymized login ID's have a Red X for a failure and a Green + for success. I also have the intensity modulated properly so that those who are red/green color blind are able to tell as well.

I have just learned that I'm going to have to politely smile at all the excuses and whining after that first assignment and tell people repeatedly that I'm not budging on this. After the first couple of students, the rest get the message.

> The first problem is: System.out.println("Hello, World!");

Heh, you are basically battling a lifetime of built up muscle memory when it comes to that.

I wonder if your students are new enough at programming that they don't understand what exact matching means? Even if you verbally say "exact match" they may not have enough context to realize that means character by character examination.

We've done programming long enough that this is ingrained to a very deep degree, but for them, it still looks like english.

Anecdote: I had a college instructor who thought it was reasonable to write a TCP-IP program from scratch without reference using Winsock2. I'm sure he could do it, and I could probably do it now, but as a student, not so much.

I tutored CS in college and I’ve seen this effect as well.

On assignments where literally every step was documented, my students would still often not know what to do, because they had missed something small but crucial.

After reading “The Design of Everyday Things”, I’ve come to design things based on the assumption that people don’t read. Even when their sole task is to read, they just don’t.

I write compilers, and producing good error messages is a crucial part. But as it turns out, the best predictor of a programmer’s ability to notice and correct an error is not good error-message text—it’s accurate and precise source locations.

"But as it turns out, the best predictor of a programmer’s ability to notice and correct an error is not good error-message text—it’s accurate and precise source locations."

I believe a part of this is training not to read the error message text, by years of error message text not worth reading.

I certainly wouldn't go so far as to say that this accounts for all (or even most) of the effect, though.

I thought "that's silly". Then I thought what I do when I get a compiler error. Most of the time I look at the line number, go to the source, try to figure out the mistake quickly, if nothing is obvious only then go back to the error and actually read what it said.

You're right - I was taught for a long time that the compiler will usually say something like "unexpected ':'" - which is in most cases absolutely useless.

Same reason why a dialog box is useless these days, as people have seen so many that they hit yes by muscle memory.

In essence, computer logic and the monkey hind brain don't mix...

Heck, I write e-mails based on the assumption that people don't read them. It is sadly quite common for people whose sole job it is to read and reply to my e-mails (e.g. customer support) to read only the first few words of the first few paragraphs, generally stopping after the first noun and verb in each.

I find that those are the same people who tend to write content-free walls of text. No wonder they only read the upper-left-hand corner of e-mails, that's the only part of what they write that's worth reading.

Being in customer support I often experience the exact opposite. We often do not know how to explain stuff so that really nobody will misunderstand. I've recently summarized this as "everything that can be misunderstood, no matter how remotely, will be misunderstood" even little things like "click this, then click that."

We have an App (of debatable quality) where we made screenshots with big red circles so people know which button to push, as many do not read the button's label.

Sure, I also misread email. Easy enough to say "sorry, my fault" and fix the problem.

EDIT: As this might sound very negative: the whole situation is more like "collective creativity", rather than stupidity. I'm often astonished on how people think and what there reasoning is. Ways of thinking I'd never imagined. And no matter how absurd, there's always some logic reasoning.

Why i keep saying to myself and others that logic is a road, not a destination. Depending on the starting point, logic can get you wildly off the map even though it is, well, logic. We have managed to collectively fool ourselves into the thinking that if the result came from logic, it has to be right.

People don't learn basic rigor/debugging/"go over it one more time." You know that voice of performance anxiety that screams in your head when you're in it up to your neck?

They haven't learned to quiet it yet.

And some probably just gave their last full measure of devotion somewhere along the way; they just couldn't for some inscrutable reason.

I learned it less than Cary did. Every time I read this, I calculate what it'd really cost per kid and get pretty sad; it would be a pittance.

http://carymillsap.blogspot.com/2011/01/axiomatic-approach-t...

> If 90% of your students fail your exam what have you learned?

If my freshman year college professors are to be believed, this happens because undergrad is but an entrance exam for postgrad. 300 CS students come into freshman year. Only 30 can make it into postgrad 4 years later.

Do the maths.

(the stats have improved since the bologna system, now 60 people get into postgrad after 3 years)

Actually had an interesting conversation with a freshman-class oriented professor of mine. He told me that an increasing amount of people are going into undergrad CS and it is rising to levels that will only be truly seen in the graduate rates years from now.

Just in time for the next tech crash :(

As a game developer it's very easy to get jaded about user feedback. The more you read it the more you start to feel like the players are ignorant and the game would be better off without them.

It's important to remember that any time someone complains, there is a legitimate problem behind it somewhere.

The issue is that users don't come to you with problems, they come to you with bad solutions. "Make this monster easier" "Make this item drop more often", etc etc.

It's easy to start thinking that if you did what all the players wanted then the game would be entirely bland and give you so many rewards all the time that they become meaningless.

The trick is to try and reverse engineer the problems from the solutions that they are giving you, and then come up with good solutions to fix their real problems.

I'm curious about the games you're making... link?

I definitely feel you here. The feedback I see is always about letting the player be more powerful relative to enemies or even other players. This correlates well to the amount of fun a specific player has, but doesn't correlate well at all to how fun the game is for players in general.

The link is in my profile.

Path of Exile! Well, I for one thought your game was quite a worthy entrant to the genre and liked what you did with the various skill and economy systems.

That's a great point, and definitely applies to a more general case than game design. I find the same thing with our web apps. Often the suggestions are ludicrous (make all visited links bright red so I know I've seen them), but the (often unstated) underlying problem is real (on my monitor the visited and unvisited link colours are difficult to distinguish).

More importantly, those who complain on forums are never truly representative of actual userbase. Behavior analytics offers a much better picture.

I've found this very true with CLI tools. Some things just make perfect sense to me but when I try it on a Live Person I see how my assumptions were dumb.

Now I try and get in the habit of having people try out CLI tools while I watch. Especially that first run when they have no experience with it is so valuable! The grumbling is also very valuable ("that's a weird name..." "why does is this option different?")

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

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.

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

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.

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.

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.

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.

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!

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

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.

Did you fix the controls to be intuitive afterwards?

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

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?

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.

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.

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.

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

[Just following instructions...](http://thedailywtf.com/articles/just-following-instructions).

Markdown style links (like reddit uses, and like you used above) do not work on Hacker News.

There are few options for formatting. [1]

Above is an example of how HN users typically link. The "[1]" above will correspond to the first in a list of numbered links at the end of this comment.

[1] https://news.ycombinator.com/formatdoc

I think the GP might have been making a joke about text formatting on HN.

Possibly as the GP has been member here for a long time, but they have a very low karma so they probably don’t post very often and may be unaware of what works and does not work here.

HN is a really interesting UX that appears to be deliberately designed to be difficult for new users to keep the signal to noise high. At least that is my charitable interpretation.

That is exactly the design decision behind HN's bare-bones design, as said by pg somewhere (I don't remember where, but there's an explicit statement about it).

When the responsive'ish design for HN was unveiled by dang some months back, he indicated that this is not actually the case. Whether this was ever the case is a question to which I don't have an answer. At this point, I think it's just tech debt, unfortunately :-\

Support work is all about empathy.

Yep and so is programming if you want users to not hate the stuff you write.

Something that is easy to say and hard to master, I've been trying for a long time but I think just trying helps.

Is there a profession besides robbery and looting where empathy isn't helpful?

Prostitution comes to mind.

Hmm, I think prostitutes will make more money if they can more successfully attune to their client's feelings. Half of a prostitute's job is to be a therapist, after all.

They might make more money in the short term, but it is not so good for their psychological well being.

Actually any profession where you have to deal with human suffering (say child protection) you need to be able to turn off your empathy. Of course it helps if you can fake it, but if you try to stay empathic you will burn out very quickly. The turnover in these fields is very high for this reason.

Good point with child protection - it is like but not the same as looting children on behalf of the government, and so is a separate category to looting. ;)

Prostitutes can use empathy to build a good long term client relationships. I've read of one who was visited regularly by a client over a couple of years, they went on dates, he bought her flowers and she bought him birthday presents and there was a lot of give-and-take. If that's not empathy enhancing her ability to perform at her profession I don't know what that is.

I think it's empathy compartmentalization, actually.

Yup. Prostitutes, and for that matter doctors, need the ability to turn off empathy, as well as a skill in faking it. I have few medical professionals (and a one in training) in my family, so I get to hear some stories from "behind the scenes". Like, you're tired and angry, because your patient is a total moron that did something absurdly stupid and is only wasting hospital's resources, but you have to put on a compassionate face and calm down the patient's family that's freaking out. Or conversely, you're pretty much crying, knowing that the 20-year-old girl that just came in has like, few months to live, and yet you have to put on a smile and tell her that everything's ok.

I don't see myself being able to handle that kind of emotional roller coaster day in, day out, and so I'm grateful to those who can.

You can't fake empathy unless you have the skill of empathy in the first place. Otherwise your fake empathy will be seen through and won't be useful.

I agree. Judging by my personal experiences, I think "faking empathy" is really mostly about compartmentalization - and so it actually is real empathy, but only applied when you chose to. Real skill of empathy is a prerequisite here.

I am not too sure about this. I have met quite a few people in my life with zero real empathy, but boy can they fake it.

It might be useful to distinguish two concepts, which I think are being conflated here:

Cognitive empathy: I can accurately predict the feelings/experiences of another person. This can't be "faked" - if your predictions are accurate, you have it.

Affective empathy: I experience similar feelings to another party (perhaps weakened) as a result of observing them experiencing it. This can be faked, and it can also cause problems for the person who has it.

Affective empathy seems like the thing which you describe as causing problems, while cognitive empathy seems like the thing which is useful for building better products.

This is quite a good split between the rather ambitious concepts of empathy, but I rather feel that "real" empathy is more than just cognitive empathy. If the other person's hurt does not hurt you then it is being faked.

One thing that can always make me feel real empathy with a complete stranger is sunburn. I am not sure why this is (I don't feel the same way about broken bones for example despite having had them myself), but everytime I see someone badly sunburnt I really feel it as though it was me that was burnt.

Surgery.

When people click on example UI images and call support when nothing happens, IT'S THEM.

The idea that a lot of people doing the same thing can't be wrong is wrong: yes they can be wrong.

The solution which was put in reflects the view that it was them all along. Everything is exactly the same in the UI, except that the subset of the user base which does a silly thing now gets feedback that they are doing a silly thing. No design change has taken place so that fewer (or no) users actually click on the images!

If the developer believed that these are intelligent people who have a reasonable mental model of the system, but who are somehow visually fooled by the layout into clicking on inactive elements, then a true design change would have followed.

The goal of reducing support calls was achieved, of course.

The purpose of good UI is to be usable by the target user. If the target user is a blithering moron, then your UI needs to target blithering morons, or else it's bad UI in that context.

Ranting about the stupidity of your users is certainly therapeutic, but it doesn't excuse you from serving them and doing your job.

>The idea that a lot of people doing the same thing can't be wrong is wrong: yes they can be wrong.

There's a Danish entertainment that once asked: "The majority always right, or are they just the most (largest group of people)?"

I don't buy the logic that if the most people believe something, or can't work something, then they are somehow the ones that get it right.

If people are mistaking screenshots for clickable windows, though, that's easy to fix. You can give the screenshots drop shadows, and put scribbled notes on them in another color. Then they don't look like clickable windows.

(Amusingly, both of those things have appeared as user interface components, but fell out of style. Apple once had the ability to scribble notes on top of things, and Google was pushing "material design", with lots of raised squares and dropped shadows. (Whatever happened to that, anyway?))

It's not the users fault for being stupid, it's your fault for assuming they are not.

Just assume your users are illiterate, innumerate, and have a broken mouse that randomly clicks and you will be fine.

While I prefer to frame it with a bit more empathy, essentially, yes. This is correct.

Said differently, The User Is Drunk (https://www.youtube.com/watch?v=r2CbbBLVaPk)

I am not suggesting that you should think that your users are like this, but that you should design with this type of user in mind. Step back, put on your dunce cap, and fix the problems with your design.

This raises a really interesting point which is the cognitive elite are responsible for designing systems with zero empathy for the rest of the population. It is much harder to design a system that anyone can use and most system designers really don’t make the effort.

The problem you bring up is very real. Who designs software and websites? People who are very good with computers. Who uses the software and websites? Mostly people who aren't good with computers.

I work in a UX role and my yardstick is whether my mom would understand it.

Great approach - assuming of course that your mother is not a developer :)

This is the opposite of what the article is saying. The users weren't clicking randomly. They were clicking with a purpose, they just didn't understand the difference between their menu bars and the ones inside the image. They had a faulty mental model, not a faulty mouse.

I think you are missing my point − if you design a UX with this user type in mind you would have avoided the problem described in the article from the beginning.

The solution to robust user interfaces is not to just whack labels on images saying don’t click on this, but to step back and assume your user can’t (or won’t) read, can’t (or won’t) do anything mathematical, and also who loves to randomly click on things. Build for the worst possible user in mind and you will avoid a lot of problems.

For example, if the author had assumed that people like to randomly click on things then they could have created a pop-up that said don’t click on this, use the menu above.

Which the user then won't read?

Then on their second random click you drag their mouse to the menu for them. Keep thinking of solutions.

Having random thrashing return useful instructions (like making the button they SHOULD be clicking on glow or blink a few times) is not a bad design pattern. Reminds me of the annoying (to me) new mac wiggle-for-massive-cursor feature.

Exactly, but you really need to get into the mindset of the random clicker user type to even think of doing this.

This person is clearly not familiar with the militantly computer ignorant segment of the user base. Yes, there are ways to write instructions to they are better/easier to follow, and yes there are plenty of examples of software that is out there that's just absurdly and unnecessarily hard to use. BUT, there is also a large segment of the user base out there that is willfully ignorant of how computers work and do not want to learn. They want the IT people to come down and do it for them, and they will make it happen no matter how many times they need to bounce back clear and simple directions to the help desk.

I'm not saying the author is one (certainly doesn't sound like it) or that it's even a majority, I'm just saying that when I do need to call for tech support, I understand exactly why they tend to act the way they do and don't take it personally. Some people are just rock stupid and some of that group willfully remain so.

Does that mean all the elitism around IT people is warranted? Of course not, part of your job as support is working with people who you know, NEED SUPPORT. If you aren't down for that job then you really shouldn't have applied, and you shouldn't be treating everyone like an idiot even when you're pretty sure they are. That's what you're paid to do.

Obviously if people are willfully ignorant it's a lost cause. But there are many instances where clandestine technical knowledge becomes "the new normal" for people, and they refuse to have any empathy for users (or fellow developers, perhaps new to the team) that do not deal with the brain-crushing complexity of their niche on a daily basis.

Along those lines, I worked in a support position where I learned to just let go when people didn't want to learn.

Me: Here's how I fixed it, this takes only one step... User: Oh, this stuff is over my head. I don't want to know. Me: In that case, it was magic.

The user ended up finding my boss to commend me for being so easy to work with.

> This person is clearly not familiar with the militantly computer ignorant segment of the user base.

The article you're replying to directly contradicts this. He was dealing with militantly ignorant people, made a change to accommodate them, and it worked.

/r/he/she

Author is Rachel Kroll, who has also packaged up and reformated her blog posts into a book: http://www.amazon.com/Bozo-Loop-Rachel-Kroll-ebook/dp/B00878...

As a non-IT pro, I'm willfully ignorant of certain aspects of IT. I have, and like, my Mac. I love my iPad. But I don't own an iPhone, because everyone at work knows I'm the guy who can solve computer problems in a flash, and most people I work with have iPhones.

They walk up to me, they tell me their problem, and I tell them "sorry, I have a Nexus, don't know how it works on iPhone or any other Android phone. Call your manufacturer or your carrier."

> This person is clearly not familiar with the militantly computer ignorant segment of the user base.

Given the anecdote she shared relates to doing desktop support for Windows users at the dawn of web proxies, your whole premise seems like a strawman you've erected in order to launch into a non-argument.

This is not a strawman, there are dozens of people at the company where I work (Salesman mostly, also mostly over 40) who refuse to learn anything. I'm not talking about setting proxies or backing up config files or something, I'm talking about refusing to use anything but Internet Explorer, refusing to keep computers up to date, refusing to clean their own file systems and regularly infecting their road laptops with unsightly things that we need to clean off.

(I'm not a prude but seriously I do not need to see YOUR inclinations in that department.)

Sorry but this statement and this ideology is flawed. The user isn't right, the user only is good at what they know. Apple or even Ford have proved that when asked, the user wants a faster horse, cause they don't understand the concept of a car. This is the fault of the user not realizing the potential, maybe because of their lack of imagination, or intellect. Or competitors are marketing to id appeals. Users don't think, but they should.

Hypothetical Example: dating site users want an ltr with a 6, but are often seduced by the potential for a one night stand with an 8. Users have chosen 8 but the moral ethical and socally acceptable choice is the 6 with the potential for an ltr. The user is wrong but they hooked up and are happy... Is a site that caters to ltr6's wrong?

However, too often products have massive flaws that designers should have predicted.

Reply on news.ycombinator.com