Editor's Guide: Many design scenarios that look simple may hide user experience issues that are easy to overlook. The Settings scene is one of them. So, from the perspective of user use, how to design the "setting" scene to give users a perfect experience? The author of this article has summarized this, let's take a look at it together.
First, the gears that can be seen everywhere
Appearing as a small gear (or wrench), "settings" are an unavoidable module in almost all products, allowing users to customize the product within the elastic range to better adapt to actual needs.
In the eyes of some product teams, "setting" may be a very simple thing, because most of the setting modules are used infrequently and have nothing to do with the core business. So when the content seems very simple and clear, the "setting" will even be undesigned and directly started by development.
But when the results of such a simple process are put in front of the user, all kinds of bad experiences come pouring in. It is not uncommon for users who can't find the setting entrance and don't know how to set it up. So, "setup", it is not simple to say.
Let's start from the user scenario, dig deep into the design logic, and re-understand this small gear that can be seen everywhere.
Second, the user scenario of "settings"
The survey found that there are no small differences in the functional design of the "setting" module of different nature and volume of products.
ToC products generally provide settings about the user's own usage habits, such as interface language, skin theme, etc. For ToB products, in addition to some of the user personalization content that overlaps with ToC products, there are often system setting permissions that act on the entire platform and all users, of course, their visible users are not all members.
From the simple description of the function above, it can be seen that the target user of the "settings" module will not be static.
Take our daily high-frequency use of browser products, the setting is open to all users of the function module, but its use frequency is very low, such as some performance, certificate configuration, even the browser skilled users may be very unfamiliar with it.
That is, even an advanced user of the product may be a novice user of the Settings module.
Taking technology-oriented tool-based products as an example, the complicated system settings are the flexible space left in the system in order to meet the complex and changeable business specifications between different customers.
In this demand scenario, the user who talks to the product is generally a system administrator or technical support personnel, who have sufficient experience and cognition of all aspects of the system, and even the system settings are its main working modules. Therefore, for the "settings" module in such user scenarios, "efficient operation and successful results" is the most important design goal. Because advanced users often do not pursue strong interactivity, they prefer to skip processes and steps, and directly cut into the function to get the desired results.
For different target users, naturally there are different design logics, and the content that follows this article may have something in common, but it is more focused on thinking about the second situation.
Third, the design logic of "setting"
Thinking about the user scenario of "setting" makes the discussion of design logic more evidence-based. In simple terms, the design of the "settings" can be cut from three links:
- Before setting: how to show the setting content to the user;
- In settings: how to design the user's input interaction;
- After setting: How to save the handling of the error that takes effect or occurs.
Next, I will also think divergently from these three links, from the aspects of information architecture, display editing, default values, help instructions, and saving to talk about some of my views on "settings".
1. Do a good job of information architecture of the content
A mature "settings" module must have a good information architecture.
This refers not only to the navigation design within the Settings, but also to the hierarchical arrangement of the Settings throughout the product. These navigations and the determination of the hierarchy will be affected by the volume of content information and the importance of functions.
First, planning a reasonable and clear navigation within the Settings requires a balance between depth and breadth of information.
The natural enemy of balanced architecture is the headache of information overload. Whether there is too much content in a single level, or too much in the hierarchy itself, it will put users to the test of rapid positioning. Products such as Google and Salesforce have chosen to introduce global search in the complex "Settings" module to help users alleviate the pressure of finding a certain function.
The test of information overload is also the scattered and unrelated settings. Their structural arrangements are easy to cram into vague classifications such as "general" and "advanced" because they do not know how to organize, which can be described as a completely lazy design.
To get through this difficult information, designers need to have a deeper study and understanding of the setting content, figure out what it changes, what it will affect, and whether it will expand more related settings in the future, and so on.
There is also a detail worth pondering: for a rich variety of setup items, is it appropriate to scatter them in functional modules that directly affect them, or is it more appropriate to summarize them in one setup module? Perhaps the answer is not consistent in different scenarios, I think this needs to comprehensively consider the decentralization role, configuration frequency, configuration impact and other factors of the setting item, and it is difficult to finalize the tone.
2. Set up the display and editing of the content
Once you've completed the basic architecture of the Settings module, it's time to set your sights on those specific settings. As far as the common setting content is concerned, it is simple to abstract according to its suitable display form, which is mainly divided into the following two types:
- Content suitable for organizing in form form: typically a single piece of data with independent influence and the same feature label is integrated into a group for display and configuration;
- Content suitable for tabular organization: Generally, datasets with the same fixed structure need to be managed uniformly, including group-level additions and deletions.
Choosing the most appropriate display form for each content (of course, not only the above two) is not difficult most of the time, because the goal orientation of the "setting" scene is often clear and direct. Of course, the existence of some complex scenes is not excluded, which requires us to spend more effort to complete the functional expression in a display form that is more understandable to users.
In the Settings module, the presentation is very closely linked to editing. The choice of direct editing and post-unlock editing mainly depends on whether the user's general appeal to enter the page is to check the confirmation or edit the modification, and whether the changes in these settings are fault tolerant, and so on.
3. Default and user experience in the help instructions
In the Settings scenario discussed in this article, each change can have an impact on the entire platform and even on the entire user. Through research, we found that most users do not have a low inheritance of default values. Therefore, for those settings that require default values, choosing an appropriate default value is a problem worth treating with caution.
Understanding user habits and business needs is the key to solving problems. What kind of default value best fits the user's usage habits, and what kind of default value can best meet the business needs. For example, our bastion machine products generally set the default log retention time to 365 days, taking into account the delicate balance between user habits and product performance.
In addition to the design of the default values, just the right help instructions can also make the user experience of the settings better.
I often see statements such as "the goal of design should be to completely remove the caption", which seems to fit the current popular purpose of simplicity and not making users think. But, as the last of Nielsen's Ten Principles of Helping, the Humane Help Principle, also points out, help and use of documentation is necessary.
Combined with the characteristics of the "setting": this is a control module that configures the underlying configuration of the product (relative to other modules), and has a high threshold requirement for the user's cognition and learning ability. That is to say, the content of the setting is difficult for the user. We need to think more about whether the content is sufficient and don't assume that the user understands.
Therefore, it is not difficult to imagine that the probability of setting the description of the module will be much higher than the main function module of the product. Explore further into the design of the help description: in terms of form, it can be a copy, a picture, or even a video explanation; in terms of intensity, it can appear once, reside on a page, or jump directly to the help document.
Most users don't want to have fun exploring the setup module, so no matter how designed, helping it complete tasks quickly is a very important pursuit when designing the "settings".
4. Second Submission with Immediate Effect
"Saved" This is not only the question that each designer will ask himself when the computer is stuck, but also the user's doubt after completing a series of configuration operations. This raises the question of when the settings will take effect. There are two most common interaction scenarios:
So, which way is better? I continue to try to start with both business needs and user habits:
The operation of the "setting" module often involves the whole body, and the cost of trial and error is actually very large. I've heard a product manager say an example of a bank customer who suffered a huge actual loss by modifying a small configuration item. Therefore, in such a module with a control center-like position, the choice of immediate effect must carefully assess the operational risk and reduce the chance of easy error for the user.
At the same time, because both the immediate effect and the form submission are very common, users naturally have a cognitive pressure, that is, the uncertainty of "saved" mentioned above. Therefore, we need to design to let users quickly and accurately know what kind of save interaction is used on the current page.
From the research and their own experience, the following points are better ideas:
- Real-time operational feedback can help users determine whether it is effective;
- Try to control the setting content within one screen, so that whether or not the unified submission button is designed (or appears after the change), the user can easily perceive;
- The button for unified submission is clearly stationed at the bottom of the page in a floating manner, reducing the cognitive pressure when the content exceeds one screen;
- Careful handling of controls such as switches, buttons, sliders, etc. with strong "instant effect" metaphors.
Fourth, simple and not simple "settings"
For many products, "Settings" is a secondary module with a low click-through rate. Directly started by the developer, the setting item can easily become the literal translation of the machine language, the laying out under the iterative order, and whether the user can accept this simple and rough processing becomes the box of chocolates in Forrest Gump's hand.
From the discussion of "setting" to the small, even if it is a seemingly simple corner, there is not a simple design logic. If the value of design to business is to drive communication, then ideally, we should ensure that the dialogue between the product and the user is "always" smooth. So, don't rush into designs with humble edge modules or simple features.
This article was originally published by @Qizhi Design and is not reproduced without permission
The title image is from Unsplash, based on the CC0 protocol