,
13 tweets,
3 min read
Read on Twitter
1) A friend had trouble connecting her computer to a Bluetooth speaker. I investigated and got it fixed. Yet every step along the way, I was confronted with obstacles, obscurities, and obstructions that resulted in obscenities; a mix of arrogance and incompetence in UX design.
2) Whether this stuff had been checked, it had apparently not been designed, tested, or fixed from this perspective: "The user is confused because aspects of her new computer are in an unfamiliar state, and she wants to restore them to what she's used to." /
3) I've got 35 years of more or less daily experience with this stuff, and it was still opaque and impenetrable to me. Here's an example: you know those extra features on the F keys that require pressing Fn most of the time? On this unit, Fn was pressed and locked by default. /
4) Now, you'd think that changing this setting to one's preference would be a straightforward matter, accessible from either the OS or one of those stupid machine-specific configuration programs. Nuh-uh. In order to change it, you have to go to BIOS settings for the machine. /
5) How do you get to the BIOS settings? Machines *from the same manufacturer* vary on this. At very least, how to get to the BIOS could appear somewhere in the stupid machine-specific configuration program, or even in its help file. /
6) But of course, we don't ship help files any more, do we? You need a working network connection for that, because Help is all on the Web now. There can be literally gigabytes of crap software on the machine, but a few hundred K for its documentation is unacceptable somehow. /
7) Experiential user testing (often derided as "manual testing") wherein the tester is given an unfamiliar but plausible task to perform, would expose lots of problems that frustrate and annoy users, and that defeat the purposes for which the product was built. It happens rarely.
8) Why does it happen rarely? My theory is that too many testers are consumed with (for instance) trying to locate elements on Web pages so that machines can press virtual buttons and read virtual output fields, instead of getting interactive experience with the product. /
9) When the field of software development is fixated on coding and programming, the goal of creating and testing products for non-coders and non-programmers becomes displaced. But based similar problems I see with open source software, there may be something darker at work. /
10) When people make stuff, they tend to make it for themselves. Everyone is always, to some degree, unaware of and unconcerned with the needs or desires of other people. We could say this: builders build for themselves first, for other builders second, for non-builders third.
11) The builder's mindset — especially in software — demands a high volume of tolerance for tinkering to work around problems. Builders are used to confusion, to hiccups here and there, to poor or non-existent explanations for how things work. Software is designed by builders.
12) The software builder's mindset seems to have spread to technological products in general. Stuff that doesn't quite connect properly or consistently is a manifestation of that. All this is why we need some systems thinkers and non-builders to test software, not only coders. /
13) Those of us who have been programming for years, or have been working with a certain product (line) for years tend to become inured to things that would annoy or confuse us on first encounter. It's hard to preserve beginner's mind. The testing mindset requires us to try.
