Show me your settings and I will tell you who you are
Good afternoon, dear habravchane! I continue to delight you with unique articles on user interfaces with live examples in Russian. Today we will discuss the silver bullet of software development - application settings.
What is the setting, all imagine more or less represent. Any computer user sooner or later faces them. Only not always the winner from this collision comes the user. There are three main problems that have to be dealt with: the desired setting is difficult to find, the desired setting is not there, and it is not clear what this or that setting does.
To understand, let's think about where the settings come from? Theoretically, settings are a way for a developer to tailor a program for different usage scenarios. Users are different, one needs one, the other is different, and if the differences in scenarios are minor, the choice between them is given to the user. It follows that in order to make the settings screen correct, one needs to know the goals and objectives of the users. This is in theory. What happens in practice?
The main problem - lack of understanding of the goals and objectives of the user - leads to the fact that the developer (in a broad sense - the company producing the software) makes the wrong decision about this or that setting: it adds an unnecessary and does not add the necessary one. The lack of settings is bad, but at least not fatal, after the release, users will correct it - they will begin to demand customization. And with the addition of unnecessary settings already interesting. Having called the settings silver bullet software at the beginning of the article, I had in mind the following common misconception: it is believed that if there are several ways to implement some functionality, and it is not clear which one to choose, then the choice should be given to the user using the setting. It seems that this option is safe, because whatever the user needs, he himself will be able to choose the right way, and the bribes are smooth from us. Let's understand this error in detail.
')
First, from several options it is not clear which one to choose. Here you need to do one simple thing - think about the users. “What option will they use? Will it be enough for them only the first option? Only the second? ”- these are simple and obvious questions, but I am horrified that even when they can be answered (quite often), in reality, the people responsible for the product interface are simply not asked, because it is easier to add a setting, it’s removes responsibility and for this it is not necessary to think. According to the mind, if the options are equivalent from the point of view of use, then you need to choose one, implement it only and not soar the users (this is well discussed in [1]), and do the setting if the options are different in terms of use and users will need both. By the way, answering this question for yourself, you can dispel an idealistic dream of making one program for all users - different users and different tasks often require mutually exclusive solutions, and then the settings will not save - they need products so different.
Reflecting on this problem, I realized that there is an interesting self-regulating mechanism in life: if there is a person in the company who understands interface design, or a good user study was conducted, then only the necessary settings will naturally be added. Otherwise, the developer is insured and adds as many settings as he can think of, and, oddly enough, this is what makes it possible for people who really need the product to use this product (choosing the right combination of settings), despite the absence of any interface design.
Illustration of the problem (familiar situation, isn't it?):
Secondly, about the win-win. Each setting has its price. Picking in the settings in the user's tasks is not included, therefore the time spent on working with the settings, the user rightly records how wasted, and the responsibility for the fact that the user spends this time lies with the product developer. Therefore, we must strive to minimize this time - and from psychology we know that the response time when choosing from a number of alternative signals increases in proportion to the logarithm of their number ( Hick's Law ). That is, the more settings, the harder it is to select the desired one. Well, the person’s reading speed is very limited (approximately 5 words per second).
Illustration:
Thirdly, it would seem that the developer himself should strive to reduce the number of settings, because for each of them you need to develop and maintain an alternative branch of code, which means additional labor costs and ultimately results in money. However, this consideration is often ignored in favor of simplifying decision-making — I will call this phenomenon the Great Paradox of Settings.
The myth of the silver pool is easy to meet. Almost at any discussion of the interface, sooner or later the sentence “let's make this a setting” pops up (I did not go far, google “add site option: habrahabr.ru” and found, for example: one , two , three , etc. ) . I think you yourself have come across many times both with this myth and with the result of its use in software products.
Illustration:
Also an illustration (seemingly just a computer shutdown program):
There is one more problem related to the settings. At the beginning of the article I designated it as “it is not clear what this or that setting does”. This refers to the problem of inconsistency between the implementation model and the user's mental model, unfortunately, there is no Russian translation at hand [2], so the translation of the terms is mine). The person using the program has an idea of ​​how it works. This is called the user's mental model. The point is that this view does not have to correspond (and does not correspond) to how the program actually works (implementation model). The rule is that the interface (including the settings) must be built on the basis of the user's mental model, and not on the implementation model, otherwise users will begin to have difficulties. For example, when I drag a picture from Safari to Mail, a letter with a picture is created. In my mental model, the picture was transferred from one program to another. If Safari had the “folder for temporary files when dragging” setting, then I would not understand its meaning, because these are details from the implementation model, which are not in my mental model.
Illustration (fictional):
Illustration (real):
The problem of bloating mail.ru settings is obvious, but we will look at them from the point of view of user / implementation models. They have three (!) Different places where you can specify a city / time zone. As far as I understand, the reason is that they have three modules that need this information (implementation model). However, in my mental model, mail.ru is the interface of my personal mailbox, but I still live in the same city and do not understand why I should indicate this information three times. Well, to the heap, even if you specify the city in all three places, then the time of receiving the letter will still show Moscow - the case when there is no necessary setting.
Let's sum up. The settings screen is part of the interface of your program, therefore, it must obey all the laws of the interface. It must be designed to meet the goals and objectives of users. Remember that communication with the settings is not part of the user's tasks, and try to minimize the time of this communication, leaving only the settings that your users need. Finally, when designing settings, do it in terms of user tasks, their mental model.
PS If someone has examples of incredibly poorly designed settings, I will be glad to see them in the comments (screenshots are doubly welcome).
References:
What is the setting, all imagine more or less represent. Any computer user sooner or later faces them. Only not always the winner from this collision comes the user. There are three main problems that have to be dealt with: the desired setting is difficult to find, the desired setting is not there, and it is not clear what this or that setting does.
To understand, let's think about where the settings come from? Theoretically, settings are a way for a developer to tailor a program for different usage scenarios. Users are different, one needs one, the other is different, and if the differences in scenarios are minor, the choice between them is given to the user. It follows that in order to make the settings screen correct, one needs to know the goals and objectives of the users. This is in theory. What happens in practice?
The main problem - lack of understanding of the goals and objectives of the user - leads to the fact that the developer (in a broad sense - the company producing the software) makes the wrong decision about this or that setting: it adds an unnecessary and does not add the necessary one. The lack of settings is bad, but at least not fatal, after the release, users will correct it - they will begin to demand customization. And with the addition of unnecessary settings already interesting. Having called the settings silver bullet software at the beginning of the article, I had in mind the following common misconception: it is believed that if there are several ways to implement some functionality, and it is not clear which one to choose, then the choice should be given to the user using the setting. It seems that this option is safe, because whatever the user needs, he himself will be able to choose the right way, and the bribes are smooth from us. Let's understand this error in detail.
')
First, from several options it is not clear which one to choose. Here you need to do one simple thing - think about the users. “What option will they use? Will it be enough for them only the first option? Only the second? ”- these are simple and obvious questions, but I am horrified that even when they can be answered (quite often), in reality, the people responsible for the product interface are simply not asked, because it is easier to add a setting, it’s removes responsibility and for this it is not necessary to think. According to the mind, if the options are equivalent from the point of view of use, then you need to choose one, implement it only and not soar the users (this is well discussed in [1]), and do the setting if the options are different in terms of use and users will need both. By the way, answering this question for yourself, you can dispel an idealistic dream of making one program for all users - different users and different tasks often require mutually exclusive solutions, and then the settings will not save - they need products so different.
Reflecting on this problem, I realized that there is an interesting self-regulating mechanism in life: if there is a person in the company who understands interface design, or a good user study was conducted, then only the necessary settings will naturally be added. Otherwise, the developer is insured and adds as many settings as he can think of, and, oddly enough, this is what makes it possible for people who really need the product to use this product (choosing the right combination of settings), despite the absence of any interface design.
Illustration of the problem (familiar situation, isn't it?):
Secondly, about the win-win. Each setting has its price. Picking in the settings in the user's tasks is not included, therefore the time spent on working with the settings, the user rightly records how wasted, and the responsibility for the fact that the user spends this time lies with the product developer. Therefore, we must strive to minimize this time - and from psychology we know that the response time when choosing from a number of alternative signals increases in proportion to the logarithm of their number ( Hick's Law ). That is, the more settings, the harder it is to select the desired one. Well, the person’s reading speed is very limited (approximately 5 words per second).
Illustration:
Thirdly, it would seem that the developer himself should strive to reduce the number of settings, because for each of them you need to develop and maintain an alternative branch of code, which means additional labor costs and ultimately results in money. However, this consideration is often ignored in favor of simplifying decision-making — I will call this phenomenon the Great Paradox of Settings.
The myth of the silver pool is easy to meet. Almost at any discussion of the interface, sooner or later the sentence “let's make this a setting” pops up (I did not go far, google “add site option: habrahabr.ru” and found, for example: one , two , three , etc. ) . I think you yourself have come across many times both with this myth and with the result of its use in software products.
Illustration:
Also an illustration (seemingly just a computer shutdown program):
There is one more problem related to the settings. At the beginning of the article I designated it as “it is not clear what this or that setting does”. This refers to the problem of inconsistency between the implementation model and the user's mental model, unfortunately, there is no Russian translation at hand [2], so the translation of the terms is mine). The person using the program has an idea of ​​how it works. This is called the user's mental model. The point is that this view does not have to correspond (and does not correspond) to how the program actually works (implementation model). The rule is that the interface (including the settings) must be built on the basis of the user's mental model, and not on the implementation model, otherwise users will begin to have difficulties. For example, when I drag a picture from Safari to Mail, a letter with a picture is created. In my mental model, the picture was transferred from one program to another. If Safari had the “folder for temporary files when dragging” setting, then I would not understand its meaning, because these are details from the implementation model, which are not in my mental model.
Illustration (fictional):
Illustration (real):
The problem of bloating mail.ru settings is obvious, but we will look at them from the point of view of user / implementation models. They have three (!) Different places where you can specify a city / time zone. As far as I understand, the reason is that they have three modules that need this information (implementation model). However, in my mental model, mail.ru is the interface of my personal mailbox, but I still live in the same city and do not understand why I should indicate this information three times. Well, to the heap, even if you specify the city in all three places, then the time of receiving the letter will still show Moscow - the case when there is no necessary setting.
Let's sum up. The settings screen is part of the interface of your program, therefore, it must obey all the laws of the interface. It must be designed to meet the goals and objectives of users. Remember that communication with the settings is not part of the user's tasks, and try to minimize the time of this communication, leaving only the settings that your users need. Finally, when designing settings, do it in terms of user tasks, their mental model.
PS If someone has examples of incredibly poorly designed settings, I will be glad to see them in the comments (screenshots are doubly welcome).
References:
- Getting Real by 37signals
- Alan Cooper on the interface. Basics of interaction design. Symbol Plus, 2009
- Comic OK / Cancel from here
- Some examples from stackoverflow.com topic WI UI You've Ever Used
Source: https://habr.com/ru/post/93178/
All Articles