Embedded systems are integrated into devices that we may not naturally think of as computers, such as TVs, cell phones, microwave ovens, etc.

Basic principles:

• Don’t think of your product as a computer.  Users will have very specific expectations of what the product can do.  Don’t want to bring all the baggage of a desktop computer to a simple device.
• Integrate your hardware and software design.  Hardware and software elements should be designed simultaneously, because most devices offer hardware controls that must integrate smoothly with user tasks.
• Context drives the design.  The environment of use is very important.  Some considerations for handheld devices: how is it held?  Is it a one-handed or two-handed device?  Where is it kept when not in immediate use?  What other activities are users engaging in while using the device?  Is the environment loud, bright, or dark?  How does the user feel about being seen and heard using the device if he is in public?
• Use modes judiciously.  Screen real estate is limited, so it can be harder to clearly convey mode changes.  Users are often beginners and do not have time to familiarize themselves with modes and navigation between modes.  Use of modes are navigational excise when input mechanisms are constrained.  The four hardware application buttons on most Palm OS handhelds are a good example of clearly marked modes.   Most cell phones offer extremely poor navigation of too many modes.  Most users quickly get lost accessing more than basic functionality.
• Limit the scope.  Better to do a limited set of tasks effectively.
• Balance navigation with display density.  Limitations in display real estate almost always result in a tradeoff between clarity of information displayed and complexity of navigation.  Designers must carefully map out embedded system displays, developing a hierarchy of information.  Try to avoid flashing between different sets of information by blinking the screen.
• Minimize input complexity.  Input, especially textual input, is typically awkward, slow and difficult for users.  RIM’s Blackberry and Danger Hiptop make effective use of a thumbwheel as their primary selection mechanism: spinning the wheel scrolls, pressing the wheel selects a given item.  Some devices require switching between a stylus and thumboard, making input more awkward.
• Customize for your platform.  Developing interfaces across multiple platforms creates an enormous amount of programming overhead and often ends up displeasing users, who would rather use an application native to their platforms, which take advantage of its unique features, facilities and idioms.

• Think about how the device will be held and carried.
• Determine whether the device will support one-handed or two-handed operation.   OK on one-handed device for some more advanced features to require two-handed use, as long as they are needed infrequently.
• Consider whether the device will be a satellite or a standalone.
• Avoid use of pluralized and pop-up windows.
• Strive for integration of functionality to minimize navigation.  Many devices currently integrate phone and address book, but could also provide links to related documents, etc.
• On-screen controls should be larger and brighter.  Small icons and controls may be difficult to see.
• Use larger, sans-serif fonts.  Serif fonts are harder to read at low resolution.
• Don’t require dragging.  It’s difficult to perform, and may risk accidentally scratching the screen.
• Don’t require shifting input modes.
• Clearly indicate when there is more data off screen, ideally with a hint how to access it.

• Interfaces should be weighted toward transient posture, with large, colorful, engaging interfaces and clear affordances for controls, clear mappings between hardware controls and their corresponding software functions.
• May be transactional (like ATM) or explorational (e.g., at a museum).
• Explorational kiosks are typically not a main attraction, but provide additional information and a richer experience for visitors.  Users typically have few expectations.  Each screen must therefore be interesting in itself, but also encourage users to further explore the system.
• Touchable objects should be large enough to be manipulated with a finger, high contrast, colorful and well separated on the screen to avoid accidental selection.
• On-screen keyboard should be used as a last resort.
• Drag and drop should be avoided.
• Mappings of hardware buttons should remain consistent  from screen to screen.

• Examples: voice message systems, automated call centers.
• Organize and name functions according to user mental models.
• Signpost currently available functions.
• Provide a way to get back one step and to the top level.
• Provide a means to speak with a human.
• Give the user enough time to respond.