What does a good GUI or tool look like

We all know a good GUI. iPod has it right and a regular automobile has a slick interface. Even an application like Photoshop is very good. What prevents the Zune from being as popular? Why is Excel so great and what makes Firefox so much better than IE?

Often, engineers are required to write a GUI or tool that must suit some purpose. It could be a file copying utility, and network monitoring service, a performance monitoring tool, or whatever. How do you design the GUI? What should you include and what should you remove?
I've put together a list of the basics points that I usually consider when designing a GUI.

• Simplify. Remove everything that isn't needed from the interface and make it an option (menu or right click). Only keep things on the main interface that are part of the workflow. You can use tabs, menus, modes, and so on. Make a list of things used almost everytime the application is used and remove everything else from the interface. Think iPod or Dr. Brown's Delorian Time Machine. Forget XCode (tons of different windows) and Word (features you can never find, terrible tables).
• Placement. Think of the simplicity and usability of the automobile. Everything is in the right place. Watch people's workflow in your GUI and move related functions close to each other. Separate things into different areas so that things aren't cluttered. Do not put all of the buttons into one area. If you have an area with more than 5 buttons, consider moving some of the buttons, coloring them, and arranging them into rows or some other pattern.
• Responsiveness. The tool must respond to user input with few, if any, interruptions. That major file copy that you need to do must happen in a worker thread. That network connection that takes 3 minutes must happen without preventing the user from doing what the application was meant to do.
• Visualization. Show numbers as a slider bar. Show history as a graph. Try using dials like on a old-style TV. Remove technical jargon from the GUI unless it should be there. Watch out for terminology that is confusing and always be willing to rename a widget if people can't understand what it does by its name. Always use terminology related to what the tool is doing. e.g. if you are building an audio tool, use terms like fader, dial, MP3, etc.
  
• Muted colors. Do not choose anything bright or possibly annoying. People may have to stare at the darn thing all day.
• Contrasting colors to differentiate functionality. If you have 3 different buttons with completely different functionality, make the most important one a different color, but nothing annoying.
• Auto functionality. Do everything technical for your users. They don't want to prepare a script to make you application work correctly and they shouldn't have to know about the special network connection needed. Hide that stuff.
• Unless it's related to security, never make users enter the same information twice. This is especially true if entering the same data into two different areas like two different text fields with the same file info.
  
• All error messages should be clear and must be obvious: a popup dialog is good, a log message is bad. Pass along errors from subsystems like "the file is locked, I can't write to it" or "The network is no longer connected".
• Give users feedback that can give them a sense of what is happening. These include status bars, progress bars, popup dialogs, and so on.
  

One heuristic I use is to put almost everything in the GUI and watch how users interact with it. Certain features not being used? Remove them or put them elsewhere.

Good luck.