In the courses I teach about human-computer interaction, I typically open each class with an example of a usability problem. I'm putting these online, in case others find them useful.
A couple of years ago I decided to test my students' abilities to analyze a novel design, an artificial one in which I'd deliberately inserted a number of design flaws. I'd just bought a Kindle for my wife. We were talking about its usability and thinking about ways in which it could be much, much worse. (This was an early Kindle with a miniature keyboard; while it's fine for reading, some of the navigation facilities are poorly thought out.)
Here's the set-up: Imagine that you've been hired as a usability consultant by a company interested in ebook readers. You're shown the diagram below, a prototype for a new design. The physical device would be about 7 inches wide; all the keys are hardware keys; it doesn't have a touch screen; it's meant to be held in the hand or hands in use. Your job is to identify potential problems.
This exercise is interesting (to me) for a few reasons. Even today, not all the computer science students in my class have used a ebook reader, and some don't know how to interpret some design components, such as the buttons to turn pages on the left and right sides, or the use of greek text to stand in for a real book. Some students will suggest changes that are based on their own reading experience but probably wouldn't extend very well to a wider target audience. Most of the suggestions students make are good ones, though--they catch most of the problems.
Here's a list of what I expect to be flagged, in no special order. (Though I may be forgetting a few flaws at this point...)
Non-QWERTY keyboard. Obviously this will slow down experienced typists, but Don Norman and Diane Fisher [PDF] found that an alphabetical keyboard is worse for non-typists than a a QWERTY keybard--alphabetical isn't even significantly better than a keyboard with randomly arranged letters! (They also have a nice explanation why this is the case.)
Keyboard above the display. In typing, the hands tend to obscure what is being typed as it is shown on the display. (This isn't always the first thing to be noticed, surprisingly enough; I'd included it as something so ridiculous it would jump out. Imagine when I discovered that some devices are deliberately designed this way--for typing Braille.)
Keyboard/display proportion. The keyboard takes up a relatively large amount of space on the device, compared with the display.
Keyboard width. The keyboard is too wide for the thumbs to reach the keys in the center, for typing while the device is held in the hands. This is also harder to notice. It takes some practice or prompting to translate "a device 7 inches wide" to how it would feel and work as a physical object.
Key placement. The Power key can easily be pressed by accident when the Delete key is intended. The Delete key can easily be pressed by accident when the Enter key is intended.
Text. Fully justified text with hyphenated words is slower to read than left-justified text. Notice the odd spacing between words on some lines as well, to create the full justification, instead of per-character adjustments.
Negative contrast. There's some evidence that white text on a black background is harder to read than black on white; there's good reason to believe that people have preferences one way or the other.
Paging. The page forward/backward buttons are awkwardly placed; they're where you'd naturally hold the device and can be pressed by accident. The page forward/backward buttons are also the same size, but if moving forward is much more common than backward, a more efficient design would have different sizes.
Arrow keys. The arrow keys are improperly ordered, whatever their frequency of use.