Designing applications: how to get closer to the user?

In the previous article (“ Do not tell me where to go ”) we examined the issue of structuring information in the application and pulling important blocks up to make them more accessible to the user.

As I wrote, in the modern mobile world it is especially critical to be able to simultaneously solve two conflicting tasks under the sun: 1) provide quick access to relevant information, the most important actions and generally high speed of key scenarios - and at the same time 2) allow users to plunge into details, find out details and implement important, but still secondary actions.

Someone saw squares and informers in the pictures in the article, but I hope that the essence of the article did not escape the curious reader.

In principle, the need to combine the tasks outlined above was not born today - and, accordingly, they began to discuss them quite a while ago. Here I want to refer to Susan Weinschenk's article “ The psychologists view of UX design ”:

People will do the least amount of work possible to get a task done. It is better to show people a little bit of information and let them choose if they want more details. The fancy term for this is progressive disclosure .

And for those who are interested in the details in terms of usability, I recommend the corresponding article by Jacob Nielsen - “ Progressive Disclosure ”.

Today we’ll try to look into this area from several points - and I’ll try to show how the idea of ​​pulling important information up can change UX and related front-end solutions, especially in Windows 8 projection.

Time

Any information can have many projections on which it is laid out in the user experience. For example, everything that we examined before this concerned the semantic structure of information and its distribution across the screens.

Another important projection of information is its temporal component: when this or that information appears in the process of interaction with the application.

In one real application, its authors faced the following task:

• there is a field for the key activity of the application, which is tied to, say, picking “apples”;
• collected "apples" are recorded in boxes;
• the application logic is such that a user interested in key activity collects “apples”, however, the number of boxes is limited - and in order to remove this restriction he must register / pay / take an additional action.

This is, in general, a classic method of any trial restrictions that make the user work with the application, but require at some point an additional action that is beneficial to the authors of the application. However, we are interested in a completely different point in this story - how the user learns about this restriction .

In the first version of the application, it looked like this: the user could freely work with the application until the number of full boxes reached a certain threshold value, for example, 15. After that, as soon as he wanted to add the sixteenth apple, he was “pleased” with a message saying what should he do next:



This is a problem because the event that has occurred is not fully predictable for the user: he does not have control over the ongoing actions (or the feeling of such control). Also, such a message, of course, discourages at the most inopportune moment.



This problem also has a classic solution, which I will discuss below, however, what I want to draw your attention to is the temporary projection of this information.

We must start with the fact that the presence of such a threshold value and its rapid approximation is important information from the point of view of application scenarios. You can even say that it is critical for both the user and the authors of the application. Therefore, the idea arises of pulling this information closer to the user, but not in the hierarchy of screens, but in the timeline.

The sooner I find out about it, the better. However, when this "earlier" should occur, it requires careful study in each case. For example, you can lead the user by the handle immediately, displaying a certain progress bar:



Or you can display a warning one step or several before the event occurs, blocking further actions:



Or do both at once:



In any case, the approach remains the same: we take out important information closer to the user, while trying to remove irritants. The user receives additional control over the situation.

The idea also works here that instead of giving the user an error message about his actions (in our case, trying to add another apple), it’s better not to allow this action if it is no longer possible, however, letting you know what exactly is happening at the moment.



I do not think that the above should be a great revelation for you, nevertheless, I hope I managed to illustrate the general idea.

Separately, I note that taking out the information above (earlier in time) according to the scenario of working with the application, it is important not to litter the application with a bunch of redundant information. This only makes sense for key scenarios.

Context

Let's look at another interesting example and talk about geography, or rather geo-referencing. This is a well-known topic, perhaps even a little boring, but I hope it will also be quite transparent.

Imagine that you decided to give the user access to a catalog of some geographical objects, for example, cafes / restaurants with live music or something more winter, for example, ice rinks in M.

You can start with the idea of ​​displaying all objects on a city map giving you the opportunity to scale and, for example, apply some filters:



Next, by clicking on any of the objects, you can show related information (description, address, average receipt size, working hours, etc.), or directly transfer to the object’s card.

This is a basic idea, a starting point, which may have come to your mind. Now we need to get into the head to the user. For example, to find out how much the target audience in reality is guided by a map, imagines certain areas of the city, and does anything tell the location of a particular label, other than “it's about there”?

It may turn out that the optimal way to present information will not be a map at all, but a real list of objects. The list, of course, cannot be displayed randomly, you need sorting, filtering, etc.



Next, you need to delve into the details and look at the nature of the information and user scenarios, trying to achieve a very simple result: relevancy of the issue, that is, by default, most users should get a suitable object among the first few in the list, although the list itself can contain hundreds of positions.

One of the first ideas that comes to mind is to display a list taking into account the geolocation of the user's device, that is, sort by the distance from the device to the object and show the distance itself accordingly. In the list, this is displayed simply in text, for example, “1.4 km”. On the map, it’s enough to indicate the current location of the user and get directions to the selected point.

As a result, we get geographical proximityobjects to the user. If we expand this concept, we can say that we are getting closer to the user that is closer to him in the current context.

It can be not only the distance to the object, but also, for example, a way to get to the object: if we understand from some conditions that the user is traveling by public transport, this is one situation and one route, if by car or taxi, this is completely another situation. On the map from the current location of the user you need to show what meets the user's needs.

Further, if we continue to think about geographical proximity, it is important for us to correlate our data with the user's worldview. For example, it is usually difficult for us to perceive long lists, so it makes sense to divide them into some groups that allow you to navigate when making a decision. In the case of distance, these can be groups expressed in kilometers and estimated time of achievement (for example, for a car taking into account traffic jams):



Breakdown also allows you to quickly go to the group that suits me the most: for example, I do not want to go to a restaurant in district, but I don’t want too far either - I moved to the group in the middle, quickly finding the headline.

Another example of context: if the institution closes soon, it would be nice to tell the user about it, or just sort them by some relevance to pick up those that the user could potentially get into and have a good time there.

This is all good, but the flight of thought does not end. It may turn out this way: as a result of user research, it turns out that the distance for a significant group of restaurant lovers with live music does not play any role whatsoever! For example, they go to the same selected establishments, listen to the recommendations of friends and generally user reviews and restaurant ratings.

Then the situation turns upside down and our card pyramid begins to collapse. (Yes, that's why it is so important to study user motivation and decision-making methods.)

This does not, of course, completely cancel our previous mind-sets, however, it makes us rethink what is the main thing in the application for quick decision-making. For example, it may turn out to be the context of the user (personal preferences) and the social context (friends, other users), and only in third place are the results that are closest in any other sense.

In such a situation, these applications are stratified by filtering and sorting methods, but for each of them we can still take out the basic information on the first hub, assuming that the information in one of the selected pieces of information will be the most suitable: In this situation, we just come to what was discussed in the previous article: what is the most important of the sections below is brought up to the hub, and in the hub itself, sorting takes place according to the priority of the scenarios for the user - in this case, in the first place personal proximity is imposed, on the second social, on the third geographical. Of course, this does not prevent us from simultaneously realizing the possibility of switching from a list view to a map view, from which we actually started.







By the way, in some other application, where, based on the importance of the scenarios, the geographic list will be given a low priority, the latter may disappear altogether from the hub, moving completely to a search where accounting for geography will turn out to be significant.

Actions

We return to the idea that everything secondary should be put in the background, and the important thing, on the contrary, is brought to the surface. If an idea is applicable to content, how can it be applied to management?

The first thing that comes to mind, of course, is the separation of functionality across the hierarchy of the application. The main actions need to be able to be done quickly and immediately, and the secondary can be omitted on subsequent screens and conditions.

For example, in the mail application (Mail) for Windows 8, there are not many buttons on the screen itself, but all of them meet key scenarios: clear text, send and delete (or save in draft):



Secondary actions that make sense from time to time, are taken out on the application panel that appear at the request of the user:



Here we can easily find both font control and, for example, access to attachment attachment functionality. This is all important, but secondary to the main scenario: writing a letter and sending it.

At the first level, or the main state of the screen, the main functionality is taken out, the secondary - appears at the request of the user.

Let's look at another example. Imagine that on the description screen of some product in the store you provide the user with the opportunity to do several actions with him. For instance,

• add to cart (this is the most important action!),
• Bookmark
• send information to friends (we focus on the “Sharing” contract) and
• inform about the sale, if the product is not in stock,
• pin to the Start screen.

About friends, everything is simple - this is a system contract that is called by the system button, the rest is placed on the screen (basket) and application panel (secondary actions):



With this screen, it’s clear that there isn’t much magic here. Let’s go up one minute: it was most likely a screen with a list of products.



Further, by analyzing user scenarios, we can find out that sometimes the user is ready to perform one or another action without diving to a lower level. For example, he needs only a name, description of the product and rating - he is ready to immediately add to the basket or bookmark. Or another important scenario that I remembered - to add to the comparison, especially relevant in the general list.

Can we extend the actions that are at a lower level up? Technically, yes: we could put three or four buttons next to each product:



Try not to do this. In general, such an iconostasis very quickly turns into a garbage can with a lot of visual noise. And most importantly - all this kills content, which should be given priority, and the main (direct) way to interact with it.

Nevertheless, the idea of ​​taking the ability to do quick actions to a level higher remains reasonable. What to do?

Firstly, it is possible, not far departing from the idea presented above, to limit yourself to a few products for which quick action is possible:



So, by the way, we did it in the “LitRes” application - the “read book” button immediately translates the description to the reading mode without intermediate pages:



Secondly, you can also combine it with the first one, especially for such cases, you can use the selection of list objects to which it is suspended contextual application panel that provides quick access to actions regarding selected elements:



Here, of course, it is also important to prioritize and take up only key actions to a higher level, for example, in this case, left behind Fastening to the Start screen.

As a result, important actions are closer to the user, but are still largely available only on request: by selecting the desired list item. And also they are available when immersed in the details, which corresponds to the traditional solution.

Finally, let's briefly look at another interesting section.

Essence

Suppose you really spread the information on different screens according to the semantic hierarchy and application usage scenarios, while consistently pulling the most important up.

It is clear that at the same time, the level of detail of information can be reduced, and even if you drag up the entire description of the most important object, it is usually pointless. Reducing the level of detail, for example, you can sequentially confine yourself to a heading and a brief description or the main parameters at the second level and only a heading at the first:



In many cases, this solution is suitable for the task and is generally very good.

However, in some cases, especially when it comes to some processes, it makes sense to think about a qualitative transition: going up the hierarchy does not just narrow the amount of information provided, but makes its presentation more compact, information rich. From raw data at the lower level, proceed to extracting the essential content of the data at the upper level.

Here, as a whole, data analysis and infographics as a way to visualize data are already beginning to work.

For example, imagine that your application displays data on the transportation of goods in a chain of screens:

• on the bottom screen you display all the parameters of a particular transportation,
• at the level above, you are talking about some direction (for example, transportation in the north-western region), also displaying briefly information on what is happening in the region;
• at the first level, you display regions by summing up information from the levels below.

The higher the level, the more important it is not so much a generalization of information as extracting from it the essence of the processes. In the example above, we can talk not only about the amount of traffic, but also about the dynamics or alerts, allowing you to make a decision: whether you need to urgently do something, dive into the details and study a more complete representation of the data.

If we were not talking about transportation, but, for example, about monitoring server racks, on the first level it would make sense to display, say, not so much information about how much space was left on all the hard drives, but the insight itself that there was not enough space and based on the statistics of observations tomorrow the whole place will end and ah-ah-ah - you need to urgently do something.

Ultimately, the question is how to make the data closer and more understandable to the user, so that he can quickly solve other important tasks and tell him when to dive into the details, for example, to intervene in the process.

And, as you already hopefully understood, all this is not about squares and informers, but about how to make the user happier by satisfying his needs expressed in key scenarios and projected on the modern mobile world of various devices and applications for them.