Designing an effective interface goes way beyond functionality. You have to be able to meet the needs and expectations of a wide range of users and you have to do it while juggling the limitations of the device for which you're designing. Some of the common interface issues you'll be facing as you design for devices include these:
Most computer-literate folks have, on their PCs, the icons reduced to next to nothing and the resolutions cranked up. Most people who are not computer-savvy have their desktop PCs set to whatever resolution, icon size, and color depth with which the computer came installed. Hence, the still lingering nastiness that is the web 216-color palette (which I hope we can soon regard as quaint, much in the same way that we regard 2400-baud modems these days).
An additional issue is that we interface designers are digitally "tuned-in," sometimes to our own detriment. A good example of this is the current trend of design-oriented web sites to use smaller fonts. Sure, it looks cool, but it is often just plain unreadable. Sometimes, the text written in that small size doesn't mean anything it's just there for design purposes. However, even then, the small size is detrimental because it's nearly impossible for a literate human being to look at text in this language and not try to read it.
This brings us to a very important point that interface designers can utilize; human beings are, for all intents and purposes, pattern-matching machines. We can pick out a single conversation from a crowded room and know instantly the face of friend we last saw 20 years ago. Our brains are wired to match patterns, so let's use that to our advantage.
A good example of this is what happened when I first started to use my Pocket PC. The interface looked and usually acted like the Windows I was used to, and because of this, I could quickly jump in and start working with it. However, years of working with Windows taught me certain patterns that at the time simply didn't exist in the Pocket PC world namely closing applications. I must have spent 30 minutes, on and off, looking for the little X to close Pocket Word when I was done writing. I knew and realized that the paradigm of using a Pocket PC was much different from a desktop one, but the continuation of my use patterns between the devices led me to look for a Close button when it just wasn't there.
Patterns are powerful things, and often, even though there might be a more efficient and usable way of creating an interface, it's best to stick with what people know. Yes, a Dvorak keyboard is better than a QWERTY one, but I sure can't come close to the 70wpm I'm currently typing on a Dvorak. You'll notice that this is the reason that the interface widgets that I talk about (and provide later in this chapter) aren't all that different from their desktop counterparts. It is important to know, though, that they are different so that they can deal with the restrictions of devices. Just plopping a regular desktop widget on a device will rarely work well; you almost always need to make some sort of modification.
Many, if not all, of the modifications that were made to the widgets were in the name of simplicity. Even if we weren't talking about devices, simplicity would be the name of the game. However, simplicity is more important than ever when you are developing for devices (if for no other reason than that people use devices much differently from PCs). Devices need to be quick and simple to use or people won't use them. A good example of simplicity in interface design is the venerable Palm Pilot. It took Windows CE devices nearly three generations to begin to become even close to being as accepted as Palm-based devices. Anyone who has owned or used a Palm Pilot knows how simple the devices are to use. There is simply little to no learning curve. The fact of the matter is, if technology is going to try to replace a pen- and paper-based solution, it has to be just as easy, if not easier, to use than pen and paper.
A lot of what has been mentioned so far might have seemed like common sense to you. In fact, that's the point; a good deal of interface design is separating the "cool" from the "makes sense." Here's where a very important problem arises, though. As the person who has designed an interface, you know the program inside out and backward. It will nearly always seem usable to you! However, what you need to do is test your usability on a group of impartial, representative users as early as possible in your application development process. If your application will be used mostly by, say, middle-age housewives, have a group of them test the application rather than a group of hardcore UNIX sys-admins.
When you are doing your testing, watch your users closely. If they get hung up on a particular element, ask them what they were expecting and why. (You'll almost always get a good answer for the "what" part, but don't expect to get too much for the "why" part.) Look for patterns in your users where they get hung up, where they whiz through, and where they just seem confused. More than likely, you will be able to extrapolate from the results of such testing what needs to be done to your application.