Know thy user. Know they user’s uses.
1. Design for usage.
Know the users and their usage abilities, know the functions they want to perform and the expected frequency of use of each function. Software should be design for users to use. An application is more than just a way of collecting data for a database. An application should improve business performance and knowledge. Design should be based on business usefulness not on the database entity-relationship structure.
2. Present information logically
Present Information logically from the user’s USAGE point of view.
Information presented and tasks performed should flow in a natural and logical order from the user’s point of view. Always provide users with obviously marked tools that they need to perform tasks, at the same location they would be expected to need them. Conversely, don’t deluge the user with choices when they don’t need to make them at that time. Less is more but more is more also sometimes; the art is to make complex things simple but not simplistic.
3. Do not oblige the users to remember information.
Users should not be required to memorise information from one part of the system to another in order to perform a task. Users should never be required to supply information that the system already knows. They should never be required to do the thinking for the system.
4. Presentation Format
Information should be presented in the most useful way. Consider the format that the user is expecting or would most like to see the data presented in. Data entry layouts are not as easy to read as formats where the fields do not have boxes around them.