This is an excerpt from a "letter to the editor" that I wrote for Embedded Systems Programming back in Jan 2002. You can see the whole letter here.

There are some general rules for good UI design that work well in both physical and graphical UIs:

1.) One control, one function. The most user-friendly designs follow the one-function-per-control rule. This is also the most expensive and impractial for most embedded designs, so this is modified into a guideline: minimize the overloading of controls. Can you imagine trying to dial a cell phone if you had to enter numbers through a menu (press SELECT, scroll through options to NUMBER, select 0-9 from the list)? The corollary to this is "fewer buttons don't mean a simpler interface".

2.) If you must overload controls (i.e. menus), generate the heirarchy from user functionality rather than the software architecture.

3.) If your menu heirarchy goes more than 3 levels deep, you need to look seriously at redesigning your menus.

4.) Often used controls should be easily accessible, and preferably limited to a single function. Don't make the user hunt for the GO button.

5.) Controls should be consistent. If buttons are used in different modes, their operation should be similar (i.e. up/down buttons shouldn't change to down/up when you enter a different mode).

6.) Follow conventions. If your device has a numeric keypad, make it look like a telephone keypad. A different layout will confuse the user and cause them to make errors. Don't be afraid to *add* a useful function: one of the best designs I ever saw for a digital clock had a 'back' button, so if you overshot your time when setting the clock, you didn't have to cycle through 24 hours to get it.

7.) Feedback is important. A click when a key is pressed or highlighing a menu selection makes all the difference in user confidence. The more *useful* information that the user has, the more comfortable they will be using the device (useless information would be something like having a voice say "a key has been pressed" every time a key is pressed). If your design will be handheld/portable, add tactile features (bumps on buttons, clicks on rotary controls, etc.) to make it easier to operate without having to look at the unit. Consider that someone will be operating your device while driving.

8.) Just because your device *can* have a feature doesn't mean it *should* have that feature.

Providing canned options for your device is a sound principle, but not at the expense of versatility. Recognize that some of the users of your device will be power users, and will want/need to fiddle with your available options. Give them a method to do this, or your competitors will.