These are some of my ideas and lessons I've learned. This stuff can only be learned by sitting down with somebody else who uses your software.

Usability

Sometimes, theoretical niceness is less important than practicality. Make a prototype of your application, then get somebody else to use it. If you try to use it yourself, you won't find things that are wrong with your UI.

Sit in the user's seat for a while and do their job. I mean this literally: sit in their office, use their computer, enter their data. You'll soon find things that are wrong with your user interface.

• Use as few dialogs as possible. If possible, cater for 80% of tasks without popping up any dialogs.
• Keep dialog sentences as short as possible. I prefer a dialog with a Big Short Message and lots of little detail underneath that the user can read if they need to. This way, the user will instantly recognise a particular dialog and know what it's about.
• Use their terminology. This might include working with them for a while to work out what their terminology is.
• Make the screen flow from top-to-bottom, left-to-right, like a written article. Put commands on the right or bottom.
• Dialog boxes: don't use "Okay" and "Cancel"; instead, rename the buttons to what they actually do. Put the most used and sensible option on the bottom right (i.e. the last thing they look at on the dialog), and the "exception" case(s) to the left of that.
• Include "visual space" so that items on the page are nicely laid out. This needs another article's worth of explanation.
• Don't get fancy with colours. Just use the system defaults.

Flow is very important. Make sure a repetitive process flows nicely and that the user only rarely needs to reach for the mouse.

Lists and Tables

There should be a powerful list / table widget that has powerful support for searching, sorting, filtering, selecting and editing. Until such a beast exists:

• Put search widgets above the table.
• Put "Add" and "Remove" buttons below the table.
• Avoid the word "Delete" when the item is being removed from a table rather than actually deleted from all existence.

Jargon

The following are possible jargon words that should be avoided or explained:

• "Default setting": this usage of "default" was invented for computers.
• "ID": often people use "number", e.g. "Customer number" rather than "Customer ID".
• String, Integer, Float, Boolean. Programming terms will never be understood by non-programmers.
• True and False: most people have never done boolean logic or critical reasoning and don't know the boolean usage of these words.
• Disk, CPU, memory, signal, mount, volume, process (as in OS process or thread), exception, etc. These words are familiar to computer users, but even some sophisticated users don't know the difference between memory and disk. Some users don't realise that the computer is the box rather than the screen.
• "kill" as in "kill a process": don't use this word. The users will panic. Ditto with "dead", "panic", etc.
• "Application". Some users don't see a difference between icons on their desktop and items on their taskbar (and IMHO there shouldn't be a difference - there should be "documents" rather than "applications").
• "algorithm": this is a computer science word only.
• "Save". Personally, I hate "Save" and "Open"; they break the document-oriented metaphor.
• A "document" is text on a page. Windows has confused this and made sounds, movies and images "documents".