- “Niche” Computer Systems
- Meaningful Use
- “Wrong Patient”
- Cognitive Friction
- Dialog-Box Rooms
- What’s in a word?
- Cost Disease
- Model T
- Signal-to-Noise Ratio
- Anti-Data Pixels
- Fitts’s Law
- Bad Apple
When doing usability testing (see Discount Usability Testing) we tend to act like anthropologists, observing people using computers as if they were savages performing quaint native rituals.
In a post in UXmatters, Jim Ross argues that we should also use the anthropological technique of participant observation: basically, going native. Or, in other words, trying to accomplish the user’s tasks on the computer ourselves.
There are arguments against this approach.
One is: Who’s doing “going native” to test the program? If it’s the coder who wrote the program in the first place, then it’s hard to argue that this is a legitimate test as the coder already knows the program inside and out.
Or is that true? A guy I know coded a program then six months later, as a user, couldn’t get it to work right without a few tries. While you might think this is a rare occurrence, my personal usability analysis of many leading medical programs suggests this might occur fairly often.
In fact, you can argue that you should take the coders or tech support people, give them tasks often performed by users, and make them use the program over and over until they can get it right each time. Time them.
Carrying the argument further, the ideal person to “go native” is someone who is naïve to the program, yet has a background in usability: an independent usability analyst. I expect that usability consultants will recommend this highly (think: job security). That doesn’t mean it’s a bad idea.