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