"User error"

[jducoeur]

One of the interesting lessons of working on the Querki project has been to be suspicious of the phrase "user error". It's a commonly-enough heard term in programming -- dismissing a bug report on the grounds that the user just didn't read the documentation closely enough. It's often accompanied by just the *tiniest* bit of sneer (or sometimes, not so tiny), that the user is obviously a bit dim for not *getting* it.

That's *never* a good response, but in a consumer-facing application it's downright capital-B Bad. I tend to think of this as the heart of UX, or at least a major artery: if the user isn't understanding your product, your first response should be to look for problems in the product, not problems with the user.

I've been slapped upside the head with this a bunch this week: alexx_kay has been doing some building, and logging a pile of bugs. Some of them are simple, straightforward, ordinary bugs, but several of them have been provoking an internal monologue along the lines of, "Well, that doesn't *work* that way... but of course you *expected* it to work that way... annnnnnd your expectation is perfectly fair and consistent with the rest of the system, a clear improvement... so I guess I need to tweak things to make it work that way".

There's a lesson here, for both programmers and users. I've mentioned it before, but it always bears repeating: users who send you bug reports like this are worth their weight in gold, and the correct response to bugs like this is "thank you". Down in the trenches, it is *terribly* easy to develop tunnel-vision, and your users, especially the serious ones, often spot inconsistencies that you overlook. (Folks building stuff in Querki, *please* don't be shy about sending 'em in.)

Or, to put it more simply, people sending in bug reports are usually *doing you a favor* by doing so. Treat them accordingly, and value their input...

Comments

[cellio]

Yes. Also, "RTFM" (if it's documented) shouldn't be one's first response. If you wrote documentation but the user couldn't find it, understand it, or use it (like maybe because it's incomplete or wrong), then treat that as a doc issue. Possibly also a product issue, depending on what it is; if an "intuitive" UI needs lots of documentation, that's signal too. But "we wrote some words already" doesn't mean there isn't a problem.

Relatedly, documentation generally gets way way less user testing than the product it goes with. Feedback on doc is gold.

[jducoeur]

Heh -- yeah, actually, several of Alexx' bug reports have been documentation bugs. I find it ruefully amusing that fixing doc bugs is often much harder than fixing code ones. I'm gradually coming to the depressing conclusion that much of the current documentation needs to be thrown out and replaced.

(A professional doc writer is on my list of "the first ten people I need to hire if I get to the point of having the money", maybe even higher...)

[cellio]

There's nothing like having to actually document something for shining the harsh light of reality on a development effort. :-) This is why I always push to get doc involved early, before things are set in, well, if not stone, then at least kiln-fired earthenware. While more software developers are user-aware than used to be, and while rubber-ducking an interface can fix some problems before you make them, the act of actually having to explain it, especially if that explaining is being done by a colleague and not you yourself, can uncover issues.

When you get to the point of hiring that writer, I'll be happy to chat with you about candidate-screening approaches if you like. I actually look for technical aptitude first and English second. Technical aptitude isn't just about understanding the domain enough to write doc; it's about being able to understand the domain deeply enough to explore, pose questions, anticipate edge cases, and poke holes in the design. Yes they also have to be able to write, but Pulitzer-grade writing won't help if the technical aptitude isn't there.

[jducoeur]

Thanks -- I might well take you up on that...

[mindways]

the first ten people I need to hire if I get to the point of having the money", maybe even higher

As a sometime user of Querki, I'd say s/ten/three/, keeping the "maybe even higher" clause. From my point of view, the state of Querki's documentation / examples is both the #1 problem I have with using it[1], and the #1 hesitation I have about pointing other people in its direction.

[1] = Though "the feature I would like is not implemented" may give it a run for its money. :-)

[jducoeur]

Yeah, understood. Sadly, that particular chicken-and-egg isn't likely to be resolved in the way I want, so I need to focus on figuring out how to improve this within my skills.

I have two remaining feature areas that need some attending to in the next couple of months (Apps and social network integration, both of which appear to be critical); once those are done, the next priority is an in-app tutorial system, which I believe will make Querki considerably easier to learn. (Along with contextual help.) That will not only help the beginners, it will help me distinguish better between the tutorial and reference content, I believe to the benefit of both.

At least, that's the theory -- I suspect it's going to need a lot of trial and error to figure out all of the rough edges...

[drwex]

Yes. This is rather what I've spent the last 25-30 years doing for a career :)