High-quality interface for Microsoft
Here, translated, adapted and added for our developers and testers an article from MSDN , about the design of high-quality interfaces. It may be useful for all those involved in the development of anything, because The article lists the basic guidelines applicable to any systems.
How good is the program, according to users? How useful is it, does it satisfy the needs and aspirations of users? The easiest way to find out is to ask. But what to do when the program is not ready yet, but there is no longer any confidence that it will meet the expectations of users? The answer is very simple: you need to ask those who have already done something like this, made mistakes, corrected their mistakes and learned from them. In our case, this is Microsoft. The following are the basic guidelines for creating software that will meet the requirements of the most demanding users.
Basic usage scenarios - actually, the reason why people generally use programs - are much more important than side scenarios - operations that people can or may not do. Baseline scenarios should be implemented anyway. No options. And if everything is exactly like this, people, with a high degree of probability, will not pay attention to problems with the implementation of side scenarios.
A program is not a set of functions, but an interaction tool. Interactions - that is, the process. Often continuous. You need to create an interaction, not components. And to maintain the uniformity of the created processes throughout the program. For example: if the installation of the program is complicated, ambiguous and accompanied by errors, the user will decide that working with the program is also complicated, ambiguous and accompanied by errors. Indeed, why would he think otherwise?
')
Think about the fact that real users - not employees of the marketing or sales department - would say about your program. How would they describe it? You need to know who you are doing the program for. And we must be sure that they can say: “I love this software! She is very cool and does this and that and this and that. ” If users can't say this, then why bother? Today, “normal” is no longer normal, but bad. You yourself must love your software.
The program will be much more successful if it leads to an ecstasy target audience, rather than trying to satisfy everyone. Focusing on everything will not work at all.
Do we really need this feature, or command, or setting? If necessary - we do. If not - cut, without doubt and pity. You can not put off complex decisions making everything "customizable."
Imagine that the program interface is a conversation between you and your users. Imagine that you are looking at the user over his shoulder, and he asks: “What am I doing here?”. What will you answer him? The actions, their order, the words you use, and how you will explain. Think about what you wouldn’t say. This should be the interface - the conversation of friends. This is better than talking in riddles that the user must solve.
Most likely the program will find the order of settings that allow users to change something. But why? Select the most reliable, safe and convenient values ​​as the initial ones. And the first interaction should fully satisfy the main audience. And do not think that, in case of unsuccessful initial settings, they will reconfigure everything for themselves. They will not.
People want to use programs, not tune them, or to understand a bunch of related areas. Select the initial configuration of the program, make the execution of the main and most important tasks obvious, and let it work that way.
Avoid questions in modal windows. Better to use non-modal options. It is much better if the context can determine the user's intentions, which often allows the user to do without questions. But if you still have to ask, use custom terminology, not technical terms. Offer settings (understandable language!) And unambiguous options. Information should be sufficient for the user to make an informed decision.
You must be sure that the program performs its functions well. The fact that it consists of the correct set of functions that are arranged in the correct order. Pay attention to details and polish everything to shine. Do not count on the fact that users will not notice the little things. They will notice.
Use the standard view of programs for Windows. Standard windows, fonts, colors and controls. Modifications of the interface elements should be minimal. Use standard pictograms, graphics and animations whenever possible (and legal!). All this is a proven, reliable option.
Responsiveness, that is, the ability to respond - the key essence of the interaction, in principle. If the program is too slow or unresponsive, users will find it unusable.
Aim for functional simplicity. To create something beyond measure is necessary only in extreme cases, when it is really necessary. No need to come up with three different ways to get the same result, when one is enough. Get off this useless trash!
Diligently avoid it. Obviously, talking is easier than doing. However, the overall impression of the program, often consists of a negative experience, rather than a positive one.
Is your program good? And if you turn off the Internet? And if the user makes a mistake? Be prepared for this. Note that the connection may be slow, or it may not be at all; assume that device drivers may not be, or they may not be connected; assume that the user enters incorrect data, or skips a step altogether. At each step, ask yourself: “What is the worst thing that can happen?” And then look at how your program handles this situation. Make sure that the error messages simply and unambiguously describe the problem and offer an effective solution.
What users regularly miss is to be ruthlessly deleted. This is especially true of those elements that users regularly see: error messages, warnings, confirmations and notifications. You can not distract a user who is busy with something important for something not important. You can not cover something beautiful with something ugly. To attract attention in critical situations, it is better to use sound. Possible exceptions may be interfaces related to the security and legal field (license agreements, etc.).
None of this can not be constantly demanded from users of the program.
Follow the guidelines! To at least partially comply with the quality standards adopted for programs under Windows; to introduce generally accepted methods and practices; to simplify decision making and generally to make your work easier. Focus your creative energy on really important things, not on a routine. (Regardless of what program you do) Do not create crazy programs that no one can get to work. Follow the guidelines to make your program standard in use but outstanding in performance.
Explore the interface. You will not know how well everything went until you see how your real users work with the program. Most likely the results obtained will surprise you (unpleasantly). However, take criticism with joy - it will help to achieve the best results. Also be sure to collect feedback on the program after it sees the light.
How good is the program, according to users? How useful is it, does it satisfy the needs and aspirations of users? The easiest way to find out is to ask. But what to do when the program is not ready yet, but there is no longer any confidence that it will meet the expectations of users? The answer is very simple: you need to ask those who have already done something like this, made mistakes, corrected their mistakes and learned from them. In our case, this is Microsoft. The following are the basic guidelines for creating software that will meet the requirements of the most demanding users.
Basic scripts.
Basic usage scenarios - actually, the reason why people generally use programs - are much more important than side scenarios - operations that people can or may not do. Baseline scenarios should be implemented anyway. No options. And if everything is exactly like this, people, with a high degree of probability, will not pay attention to problems with the implementation of side scenarios.
Interaction, not function.
A program is not a set of functions, but an interaction tool. Interactions - that is, the process. Often continuous. You need to create an interaction, not components. And to maintain the uniformity of the created processes throughout the program. For example: if the installation of the program is complicated, ambiguous and accompanied by errors, the user will decide that working with the program is also complicated, ambiguous and accompanied by errors. Indeed, why would he think otherwise?
')
Stand out!
Think about the fact that real users - not employees of the marketing or sales department - would say about your program. How would they describe it? You need to know who you are doing the program for. And we must be sure that they can say: “I love this software! She is very cool and does this and that and this and that. ” If users can't say this, then why bother? Today, “normal” is no longer normal, but bad. You yourself must love your software.
No need to do everything for everyone.
The program will be much more successful if it leads to an ecstasy target audience, rather than trying to satisfy everyone. Focusing on everything will not work at all.
Make responsible decisions
Do we really need this feature, or command, or setting? If necessary - we do. If not - cut, without doubt and pity. You can not put off complex decisions making everything "customizable."
Interaction as a conversation.
Imagine that the program interface is a conversation between you and your users. Imagine that you are looking at the user over his shoulder, and he asks: “What am I doing here?”. What will you answer him? The actions, their order, the words you use, and how you will explain. Think about what you wouldn’t say. This should be the interface - the conversation of friends. This is better than talking in riddles that the user must solve.
Do the right thing.
Most likely the program will find the order of settings that allow users to change something. But why? Select the most reliable, safe and convenient values ​​as the initial ones. And the first interaction should fully satisfy the main audience. And do not think that, in case of unsuccessful initial settings, they will reconfigure everything for themselves. They will not.
Let it just work.
People want to use programs, not tune them, or to understand a bunch of related areas. Select the initial configuration of the program, make the execution of the main and most important tasks obvious, and let it work that way.
Be careful with questions.
Avoid questions in modal windows. Better to use non-modal options. It is much better if the context can determine the user's intentions, which often allows the user to do without questions. But if you still have to ask, use custom terminology, not technical terms. Offer settings (understandable language!) And unambiguous options. Information should be sufficient for the user to make an informed decision.
To work well.
You must be sure that the program performs its functions well. The fact that it consists of the correct set of functions that are arranged in the correct order. Pay attention to details and polish everything to shine. Do not count on the fact that users will not notice the little things. They will notice.
Look good.
Use the standard view of programs for Windows. Standard windows, fonts, colors and controls. Modifications of the interface elements should be minimal. Use standard pictograms, graphics and animations whenever possible (and legal!). All this is a proven, reliable option.
Responsiveness.
Responsiveness, that is, the ability to respond - the key essence of the interaction, in principle. If the program is too slow or unresponsive, users will find it unusable.
Simplicity.
Aim for functional simplicity. To create something beyond measure is necessary only in extreme cases, when it is really necessary. No need to come up with three different ways to get the same result, when one is enough. Get off this useless trash!
Bad interaction.
Diligently avoid it. Obviously, talking is easier than doing. However, the overall impression of the program, often consists of a negative experience, rather than a positive one.
Common problems.
Is your program good? And if you turn off the Internet? And if the user makes a mistake? Be prepared for this. Note that the connection may be slow, or it may not be at all; assume that device drivers may not be, or they may not be connected; assume that the user enters incorrect data, or skips a step altogether. At each step, ask yourself: “What is the worst thing that can happen?” And then look at how your program handles this situation. Make sure that the error messages simply and unambiguously describe the problem and offer an effective solution.
Molestation.
What users regularly miss is to be ruthlessly deleted. This is especially true of those elements that users regularly see: error messages, warnings, confirmations and notifications. You can not distract a user who is busy with something important for something not important. You can not cover something beautiful with something ugly. To attract attention in critical situations, it is better to use sound. Possible exceptions may be interfaces related to the security and legal field (license agreements, etc.).
Tension, erudition, thought process.
None of this can not be constantly demanded from users of the program.
- Transparency, not a hint - What the user needs should be on the screen. Therefore, it is important to carefully compile instructions for users, in windows and on pages. To clearly convey the essence and purpose of the interface.
- Automatically, not manually - Try to help users by automating processes that could be automated and which the user would like to automate. A simple test: Close the program, then reopen and perform the most basic task in it. How many manual actions could you remove?
- Briefly, not verbose - Write capaciously. Formulate for sure. Make out the text for reading, but not for attentive reading. For useful, important, but not basic information, use the links to Reference sections.
- Specially, not randomly - The Best Control - which forces you to enter the correct values.
- Enabled, not disabled — Disabled controls are confusing. Their use is permissible only in cases where the user is easy to guess why they are turned off. Otherwise, remove them or leave them on, but with some adequate response.
- Memorized, not forgotten - With the exception of situations when it comes to security or personal data, it is better to memorize previous actions of users and previously entered values ​​of form fields, and help them to repeat certain operations, rather than forcing them to start from the beginning.
- Response, not ignoring - Unambiguously show when the task is completed, and when not. Do not make users guess.
Windows standards
Follow the guidelines! To at least partially comply with the quality standards adopted for programs under Windows; to introduce generally accepted methods and practices; to simplify decision making and generally to make your work easier. Focus your creative energy on really important things, not on a routine. (Regardless of what program you do) Do not create crazy programs that no one can get to work. Follow the guidelines to make your program standard in use but outstanding in performance.
Research
Explore the interface. You will not know how well everything went until you see how your real users work with the program. Most likely the results obtained will surprise you (unpleasantly). However, take criticism with joy - it will help to achieve the best results. Also be sure to collect feedback on the program after it sees the light.
Source: https://habr.com/ru/post/137303/
All Articles