9 Principles of GUI design (first article)

Basic principle 1: Focus on users and their tasks, not technology
Basic Principle 2: First consider the function, then the expression
Basic principle 3: Consistent with user perceptions of the task
Principle 4: Design to meet common situations
Basic 5: Don't distract users from their goals
Basic Principles 6: Promoting learning
Basic Principle 7: Passing information, not just data
Principle 8: Design should meet response needs
Basic 9: Find an error through a user trial and fix it

1) Principle 1: Focus on users and their tasks, not technology
This is the most important principle, the fundamental of all principles, and the foundation of all other user interface design principles.
What does "focus on users and their tasks" mean? It means that the following questions will be answered as a starting point for a development project:

• Who is this software designed for? Who is the target user? Who is the target customer (not necessarily the user)?
• What does the software do? What does it intend to support? What issues will it help the user solve? What value will it provide?
• What's wrong with the target user right now? For the way they work now. What do they like and dislike?
• What skills and knowledge does the target user possess? Do they have the motivation to learn? How to learn? Are there different types of users with different skills, knowledge, and motivations?
• How do users master the concept of the data that the software will manage?
• What does a target user prefer to work with? How does the software fit those ways? And how will it affect them?

2) Principle 2: First consider the function, then the expression
It should be noted that the first consideration of the function does not mean "to design and implement the function first." Then care about the user interface. Many developers use methods that have this misconception. This approach rarely develops successful software.
The user interface of a software application is more than just the look of software. It also embodies some design decisions that go deep into the architecture. For example, what are the concepts, the structure of the information, the backend functionality, and the ability to customize to the user. Therefore, it is not possible to assert the user interface success simply on the implementation side.
Principle 2 should be understood in this way: software applications embody a particular concept and the relationship between concepts. Designers should completely define concepts and their relationships before designing how to present concepts to users.
More specifically: Don't jump to the GUI layout in the first place. Developers draw screen sketches, select and layout controls, crop foam prototypes, or write code. You should first carefully answer the task-related questions given in principle 1, and then answer the following questions:

• What are the concepts that the software will present to the user that they are aware of from the task domain? Or a new concept? If they are new concepts, can they be represented as extensions of common concepts? Or are they a foreign concept introduced from computer science?
• What data will users create, view, or manipulate with this software? What information does the user extract from the data? How to refine? What steps will they use? Where does the data that the user enters into the software come from, and where is the data generated from the software used?
• What options, choices, settings, and controls are available for this application? This is not a question of how controls (such as radio buttons, menus, scroll bars) are represented, but about their capabilities, goals, and roles in the software (for example, week days, number of dollars, e-mail addresses, volume). This is a question about what options are available for this software.

3) Principle 3: Consistent with user perceptions of the task
The user interface of the software should be designed from the user's perspective. Developers can't design if they don't know what the user's opinion is. The best way to find the user's point of view is to follow the basic principle 1 approach: Talk to a representative user, watch their work, and collaborate with them. Thus complete the task analysis. There are several guidelines for designing according to the user's point of view.
3.1 Exclusion of unnatural
Unnatural behavior is that the actions performed by the user are not clearly linked to their goals. Software that enables users to perform unnatural operations is more arbitrary, less intuitive, and unprofessional to the user, because unnatural behavior is difficult to learn but easy to dry forget, time-consuming and annoying.
3.2 Use the user's vocabulary instead of your own
Avoid computer jargon when composing text for software or its documents. As described in basic principle 3, we should create a project dictionary. Dictionaries should be named for each concept (object, action, or property) that the user will see. The terminology in the dictionary should match the idioms used in the task area. Once a dictionary is developed. The text in the software or documentation should strictly follow the dictionary.
3.3 Let the internal content of the program be processed inside the program
Software users are not interested in how the software works, they just want to achieve their goals. Therefore, the internal details of the software should be kept in-house, so that users can not see and unexpected. This sounds unreasonable, but in fact exposing the software internally to the user is a very common user interface taboo.
So far, we have learned that conceptual models should be developed before the user interface is designed. The conceptual model indicates which concepts are exposed to the user. The application's user interface should show only those concepts that are necessary to support the target task, and hide all other concepts. Includes general computer terminology concepts and those that are only part of the implementation concept.
3.4 Finding the right function/complexity balance point
The problem for software developers is finding the best balance between functionality and complexity. To achieve this, developers have to talk to and observe representative users. You might even want to have some of these users join the design team. Otherwise, developers are just guessing.
Once the developer knows how much functionality a user needs, they can use these design techniques to reduce complexity:

• Appropriate default value: Ensure that each setting in the application has a default value. Users should be able to leave all or most of their settings as their default values and still get a reasonable result. This allows the user to ignore most of the settings most of the time.
• A template or packaged solution: instead of starting every task from scratch, users are provided with partial or complete solutions to choose from, and users can modify these scenarios to meet their specific purposes. This approach allows users to bypass the functionality of most software. Users can even get useful results without having to know how to produce results from scratch.
• Guided paths and wizards: New users often want to be able to guide them through the various steps of a complex task. An application can meet this requirement by providing a "wizard" that provides a predefined sequence of steps that guides the user through the complex process step-by-step, specifying clear instructions and choices in the process primarily through menus rather than text fields. Wizards are a great way to simplify complexity, regardless of what the user wants the wizard to help you with.
• Asymptotic display: The details and complexity are hidden until the user needs it. The control is activated or the menu of the menu bar is displayed until the menu of the control and menu bar is associated with the current transaction. Hide the rarely used settings under the panel labeled "Detail" or "advanced" or the controls that require advanced software knowledge. Named for a combination of multiple settings, allowing the user to use a named combination instead of all individual settings. For example, a paragraph style in the document editor allows a user to define a set of formatting properties. and applies to all text paragraphs at the same time.
• Generic command: Manipulate all types of data with a small set of commands. Reduce the number of commands required by a carefully selected collection of generic commands that corresponds to all types of data in the application. Most of the operations that people use on computers are represented by 9 common commands: Create, Open, Move, Copy, Save, Print, Show/edit properties, and follow Link. As described in basic principle 2, the development of a conceptual model allows you to show what operations are common between objects, and then provides these operations through generic commands.
• Task-specific design: Provides good support for a small set of tasks. Instead of providing users with programs with a complex set of functions, they provide them with a collection of small private programs. Each program is very well supported by a task.
• Customizable: Allows customization of the user interface so that customers can adjust it to highlight the features they need to use without highlighting or hiding other features. Allows the user (or as a local developer of the user) to set a default value that defines the macro. Create templates or customize the software to meet their specific needs.

If you want to hear the funeral, please listen to tell.

9 Principles of GUI design (first article)