Somehow the other day I needed to print more than ten checks from my payment history using an ATM of one of the largest banks. I went to the payments, chose “History”, scrolled the list scroller to the desired payment, chose it, and then clicked the “Operations” button and selected the print. And so it was repeated for each check: each time there was a transition to the main menu and everything started anew. I wondered - really, despite the abundance of sources of information on UX , huge budgets are still being spent on such inconvenient interfaces? Why developers do not want to make an interface that allows the user to feel like a magician, and make users helpless in achieving their goals? Perhaps the reason is that, despite the abundance of theory, these sources provide few examples from real projects.

Since we literally completed a large Web project last week, in which the goal was to develop a user-friendly interface, I decided to highlight in the article what major points in designing an interface worth paying attention to and gave examples of our solution.

What is a magic interface?

The interface is usually called the set of ways in which you perform any tasks with the help of a product, or rather the actions you take and what you get in return.
Based on this, the magic interface is the interface that executes what you want. However, we will try to give a definition closer to real life.
Psychologists have noticed that when using different things, users have three levels of cognitive processing involved:

• visceral (produces an internal positive impression)
• behavioral (corresponds to the mental model ),
• analytical (establishes an emotional connection with the user, attracts to further study and gain experience of use).

Each level corresponds to the achievement of certain goals by users. Objectives achieved at the first and last levels of cognitive processing, lie in the field of emotions and user identity. Behavioral (end) goals correspond to the technical purpose of the thing, regardless of the user's identity. Here it is only worth noting that each person will have his own unique scenario leading to the final goal, i.e. each will tell his story on how to achieve it.
')
So, if the interface impresses every user, allows you to achieve the desired through a sequence of intuitive actions, and is also remembered or even becomes part of everyday life, then users could call such an interface magical .

Is it possible to create a magic interface in a specific subject area? When creating the DevExpress Web Dashboard , we considered it possible.

The goal of the DevExpress Web Dashboard project (hereinafter referred to as Dashboard) was to create an interactive analysis panel with a given set of visualization elements, the ability to filter and group. Unfortunately, at the development stage, due to the nature of the business, we did not have access to real users of the product, so the users were various employees of our company and fictional characters .

Below I will consider the interesting features of the interface, in our opinion, claiming to be “magical”.

For each feature, I will give examples of how we did in our project, and compare the implementation of some of them with our similar product for another platform.

The nature of a positive impression

The basis of the positive inner feeling is the attractiveness of the interface design from the side of the person's feelings (sight, hearing, taste, smell, touch). External influence stimulates the work of the corresponding sense organ, which transmits information to the brain. As a result, a person perceives this external influence, he has positive or negative sensations. In the case of software interfaces, the impact is usually the appearance of the interface, and the sensation is vision.
Are there any universal recipes, how to make this or that impact lead to the necessary perception? .. How to understand and evaluate whether you have made a good, attractive interface? Well-known industrial designer Dieter Rams, in search of an answer to these questions, formulated 10 principles of good design , suitable for any kind of interface. There are also many sources where fashion trends and typical solutions in the design of visual interfaces are described. In spite of everything, the fact that the user likes the appearance of the interface depends primarily on the personality of the designer, who, in turn, seeks inspiration anywhere. It seems that here as in painting - how to draw a portrait is described in any textbook on the basics of fine art, but only one person painted the Gioconda.

At Dashboard, we fully rely on the artistic taste, intuition and experience of our main designer.

From beginner to expert

Alan Cooper recommends creating an interface so that the beginner quickly starts working, the expert finds the functionality he needs, and the average user comfortably performs his daily tasks. The representative of each category of users should not be annoyed by the interface.

In Dashboard, we made a system of unobtrusive "bread crumbs", pointing the way at the initial stage of creating a dashboard. Consider the most typical scenario of creating a dashboard. After directly connecting to the data source, the user creates the elements. The first step in creating an item is to configure its relationship with the data source fields. For a newcomer, this will be enough to see the initial result.

Newbie

The average user will continue to work by changing simple properties, such as headings or the type of chart.

Average user

The expert will set complex filtering criteria or go to the Dashboard properties to create your own calculated fields or parameters.

Expert

Comparing with our similar solution for another platform, we notice that it is quite difficult for a beginner to understand where to start. The drag area does not seem to be more important than the properties in the ribbon (Ribbon) and if you start with the properties in the ribbon, the new user will not see the changes in the element.

Newbie (other platform)

The average user and expert will be annoyed by the need to switch the ribbon tabs to switch from the element properties to the general properties of the dashboard.

Average user (other platform)

Expert (other platform)

Users of any category will always have some time to think about which tab of the tape to go to in order to find the necessary property. It will be very difficult for them to remember which properties should be searched for in the ribbon, and which in the dialog boxes of the dragging field.

User performance

User efficiency when working with the interface should be maximized (the useful effect of the interface should be maximized). This means, first of all, that the necessary tools for this functionality are easily located, located close and accessible without “targeting”, i.e. at least the Fitts law is satisfied. From this law, in particular, it follows that the frequently used menus and toolbars are optimally located on four sides of the screen (recall the Mac with its top menu).

Sadly, for applications running in the browser environment and when you need to show lists of lists and properties that take up too much space, you have to compromise. In our analysis panel, the main toolbar for creating elements is fixed on the left — this is the optimal place for a browser application and users reading from left to right. The properties of the entire analysis panel are set up level by level through the main menu, which also pops up on the left. Setting properties of elements is in their context. When you click on an item, a menu appears in which you can select the type of custom properties (data relations, interactivity, general properties) and customize them using special controls, which I will discuss below. The menus are large enough so that the choice of their elements is not accompanied by “targeting”, and the controls appear on top of the elements without taking up a separate place, which is so valuable for the dashboard space.

Menus and toolbars

Efficiency is directly related to short-term memory, the amount of which is limited. Miller’s wallet of 7 ± 2 elements has long served as a kind of law here, but if you try to summarize, everything that overloads short-term memory will reduce the user’s efficiency in the process of working with the interface.

In Dashboard, we tried to do no more than 7 items in menus, property editors, and other items at the same hierarchy level; the points were given concise short names.

It is proved that complex hierarchies in the interface reduce the efficiency of the user, so they are reduced or divided into modules.

It was quite difficult for us to reduce the number of hierarchies in the editor of properties of the elements of the analytical panel (grids, diagrams, etc.). Here we were helped by the principle of “divide and rule” or, as they say now, the principle of modularity . We divided the property settings into different types: BindingArea allows you to visually represent an element from the point of view of data relations, and contextual PropertyAccords - from the point of view of properties (and the properties of objects of the BindingArea itself are also edited in a pop-up window with PropertyAccordion). PropertyAccordion displays properties grouped into a flat list as editors and allows you to edit only one such expanded group (slide).

BindingArea and PropertyAccordion

The classic property editor was too cluttered and complexly hierarchical, and the tape took an unacceptably large (for 16: 9 monitor) space at the top of the screen and, like the field dragging fields, required the creation of many different types of dialog boxes specific to the settings of a particular element.

Classic property editor (another platform)

Ribbon and field dragging area (another platform)

Good habits

If the interface forms useful habits , it becomes its additional big plus. To understand what will go into the user's subconscious is quite difficult. However, it is obvious that if similar procedures are done in a similar way, if an element with its appearance or location says what needs to be done with it (click, drag, svapnut, etc.), then such things once realized, no longer leave the user's brain. You also need to exclude the possibility of achieving the same goal in different ways.

In Dashboard, we made the setting of different types of elements uniform through BindingArea and PropertyAccordion. Suppose a user sets up a data link for a chart. In BindingArea, he sees the series, arguments, and values, selects the data source fields, and sets properties in PropertyAccordion. Then, for example, when setting up a grid, he sees the grid columns in the BindingArea, which are similar to the series of diagrams in setting up data connections, as well as in setting properties in PropertyAccordion.

Chart and grid setup

Modes

Getting rid of the modes in the interface is sometimes quite difficult. Leading experts on UX and HCI have long been actively campaigning for getting rid of regimes. A well-known employee of PARC and Apple, Larry Tesler, even on his car had a license plate with the inscription “NOMODES” (by the way, on Twitter, Larry Tesler can be found by the name @nomodes).
Despite everything, many modern interfaces have modes, and if the interface doesn't change properly when switching between modes, this can be confusing to the user. For example, my Microsoft Natural Ergonomic keyboard allows you to disable the F-mode (F Lock is next to the F12 I often use) and I occasionally find that when I press F5, I don’t understand for some time why what I’ve been expecting . Also, in many modern development environments, it is not possible to add / delete / edit modules, etc. in the application execution mode.

In the Dashboard, we were able to exclude elements that have different behavior depending on any mode. We also did not begin to do the preview mode (you immediately work with live data), did not separate the settings mode of the elements and the analysis panel layout. However, we made a mode that changes the accessibility of editing elements primarily because editing should be available to a limited number of users. In addition, the direct analysis of the data is not necessary in many windows settings.

Modes: viewer (for business analyst to work) and editor (for administrator-creator of dashboards)

Load indicators

Often we hear the expression "How does it slow down!". Programmers are sure: in this case, it is necessary to optimize and accelerate the core of computations, queries to the database, etc. Yes, they could, for example, recommend parallelizing operations or caching frequently used data ... but what about the interface? In the interface, it is necessary to make an unobtrusive system of “load indicators” , where it is possible to do double buffering, show the old “picture” until a new one is received, and to apply smooth animations with complex interface changes.

Dashboard displays all panels with smooth animation. With interactive actions (filtering, etc.), the loading indicator appears in the corner of the element, the loading indicator has a small size and is shown in place of the menu icon, which additionally avoids unnecessary blinking. I bet that the systems where the huge spinning loading panel in the center of each element is shown are far from magic.

Loading indicator

Omnipresent scrolling

In any interface, and especially in a multi-widget interface similar to dashboards, I would like to avoid any scrolling . Of course, this is generally not possible. But, as you know, there are a number of important things that are being done to improve the situation, for example, where it is possible to get rid of horizontal scrolling. In addition, we consider the place occupied by the scrollbars to be contrary to the principle of Edward Taffy to maximize the “ payload / ink” ratio.

Therefore, in Dashboard, we implemented our scrolling, which appears on top of the content when you hover the mouse (that is, the behavior is similar to what we see in the latest MacOS).

Normal scrolling

Hiding (contextual) scrolling

“Cancel action?”

People love to experiment, so the interface must be able to undo and return the action. Currently, systems with undo / redo have already become standard, but not all of them are deprived of a heap of dialogs with confirmations about entering something. “Are you sure?” They ask. Why bother the user once again if there is one simple “Cancel” button?

Dashboard allows you to undo and return any action without any questions.

Undo / Redo

The first usability rule (with reservation)

Any interface needs to be run-in on live users, watch them, ask what they were guided by when they did that. At the same time, in no case should they not listen to what they ask for , except when the user can identify the so-called “desire lines” while working with the interface , and tell the interface developers about them so that there is no known situation:

For example, I constantly tried to roll up to this non-folding PropertyAccordion slide. A number of users expected to hide the property bar of the BindingPanel element when they click it again (previously, a second click did not hide the panel, but had to press the “<” button in the upper right corner of this panel). Initially, the menu item appeared on mouseover, and many users still made an additional mouse click, because expected selection just by click.

Examples of “desire lines”

While filming the video for this article, I constantly felt the lack of the ability to press Esc to close the panels. In the usability testing document, only 10% of users mentioned the hot keys, and it was primarily about Delete.

It is obvious that in practice the creation of such a magic interface will be iterative and usually begins with a minimally viable product .

We started that way and made at least 5 prototypes, which were based on different user scenarios. Despite this, we are still a CTP version and are waiting for your feedback.

In conclusion, I would like to note that many of the principles discussed can and should be applied in the development of any product that has an interface, be it a hand dryer or an ATM. The success of companies (Apple, Dyson, etc.) that take these principles into account when developing the interfaces of various devices has already spurred many to take the nuances of human perception and usability more seriously. Let's try to make life easier together.

In our project, we tried to adhere to the principles described in the above sources, some of which I covered in this article. Many principles have been implemented intuitively, based on our development experience. In this case, due to the timing of the project and the human factor, we still need to finalize some interface elements in the beta version. It is also possible that we have missed something and will reconsider some fundamental points.