Designing applications: how to get closer to the user?
In the previous article (“ Do not tell me where to go ”) we considered the issue of structuring information in an application and pulling important blocks upward in order 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 for a place 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 dive into the details, learn the details and implement important, but still secondary actions.
Someone saw in the article the squares and informers in the pictures, but I hope that the essence of the article did not slip away from the curious reader.
In principle, the need to combine the above tasks was not born today - and they began to be discussed for a long time, respectively. Here I want to refer to the Susan Weinschenk article “ The psychologists view of UX design ”:
')
And for those interested in the details in terms of usability, I recommend the relevant article by Jacob Nielsen - “ Progressive Disclosure ”.
Today we will try to look into this area from several sides - and I will try to show how the idea of pulling important information up can change the UX and associated interface solutions, especially in the projection on Windows 8.
Any information can have many projections on which it is decomposed into user experience. For example, everything that we considered before concerned the semantic structure of information and its distribution across 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:
This is, in general, a classic method of accepting any trial restrictions that make the user to work with the application, but at some point require additional actions that benefit the authors of the application. However, we are interested in a completely different moment in this story - how the user learns about this restriction .
In the first version of the application, it looked like this: the user could work with the application at will until the number of filled 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 the message what should he do next:
This is a problem because the event that occurred is not fully predictable for the user: he has no control over the actions taking place (or the sensation of such control). Also, such a message, of course, discourages at the most inopportune moment.
There is a classic solution to this problem, which I will discuss below, but what I want to draw your attention to is a temporary projection of this information.
It is necessary to begin with the fact that the presence of such a threshold value and its quick 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 thought arises of pulling this information closer to the user, but no longer along the hierarchy of screens, but along the timeline.
The sooner I find out about it, the better. However, when this “earlier” must come, it requires careful study in each specific case. For example, you can lead the user by the handle at once, displaying some progress bar:
And you can display a warning one step at a time or several before the onset of the event by blocking further actions:
Or do both at once:
In any case, the approach remains the same: we carry important information closer to the user, while trying to remove the stimuli. The user gets additional control over the situation.
Here also the idea that instead of giving the user an error message in his actions (in our case, trying to add another apple), it’s better not to allow such an action if it is already impossible, however, informing what happens at the moment.
I do not think that the above should be a great revelation to you, however, I hope I managed to illustrate the general idea.
Separately, I’ll note that it’s important not to trash the application with a bunch of redundant information while carrying the information above (earlier in time) for the scenario of working with the application. This makes sense only for key scenarios.
Let's look at another interesting example and talk about geography, more precisely about geo-referencing. This topic is known, perhaps even a little bit annoying, 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, say, cafes / restaurants with live music or something more winter, for example, skating rinks in M.
You can start with an idea to display all objects on a city map, giving you the opportunity to scale and, for example, apply some filters:
Further, by clicking on any of the objects, you can show the accompanying information (description, address, average check size, working time, etc.), or directly transfer to the object card.
It’s like a basic idea, a starting point that may have occurred to you. Now it is necessary to get into the head to the user. For example, find out how much the target audience is really oriented around the map, imagine some areas of the city, and does the location of a particular tag tell her anything other than “it's about there”?
It may turn out that the best way to present information is not a map at all, but a very real list of objects. The list, of course, can not be displayed randomly, need sorting, filtering, etc.
Then you need to dig into the details and look at the essence of information and user scenarios, trying to achieve a very simple result: issue relevance, that is, by default most users should get a suitable object among the first few in the list, although the list itself may contain hundreds of positions.
One of the first ideas that comes to mind is to display the 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. In the list this is displayed simply by text, for example, “1.4 km”. On the map, it is enough to indicate the current location of the user and get directions to the selected point.
As a result, we get the geographical proximity of objects to the user. If we expand this concept, we can say that we are drawing closer to the user what is closer to him in the current context.
This may be not only the distance to the object, but also, for example, the 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 only routes, if by car or taxi, this is completely different situation. On the map from the current location of the user you need to show what corresponds to the user's requests.
Further, if we continue to think about geographic proximity, then it is important for us to correlate our data with the user's world view. For example, it is usually difficult for us to perceive long lists, so it makes sense to divide them into some groups that allow us to orient in making a decision. In the case of distance, these can be groups expressed in kilometers and an estimated time to reach (for example, for a car with traffic):
The breakdown also allows you to quickly go to the group that suits me the most: for example, I don’t want to go to a restaurant in the area, but I don’t want to go too far either — I moved to the group in the middle, quickly navigating through the title.
Another example of contextualism: if the institution closes soon, it would be good to prompt the user about it, or just when sorting by some relevance, pick up those into which the user can potentially get into and have a good time there.
It's 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 at all! For example, they go to the same favorite places, listen to the recommendations of friends and, in general, user reviews and restaurant ratings.
Here the situation turns over completely and our card pyramid begins to collapse. (Yes, that's why it is so important to explore user motivation and decision making.)
This does not negate, of course, completely our previous perceptions, however, makes us rethink what is important in the application for quick decision-making. For example, they may be the context of the user himself (personal preferences) and social context (friends, other users) and only in the third place are the nearest results 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 carry out the basic information to the first hub, assuming that the information in one of the selected pieces of information will be most suitable:
In such a situation, we just come to what we discussed in the previous article: what is the most important of the underlying sections is taken up in the hub, and in the hub itself the sorting takes place according to the priority of the scripts for the user - in this case the personal proximity, on the second social, on the third geographical.
Of course, this does not prevent in parallel 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, having moved completely to the search, where geography accounting turns out to be the opposite meaningful.
We return to the idea that all secondary should be removed to the background, and the important thing on the contrary 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 is, of course, the separation of functionality across the levels of the application hierarchy. Basic actions need to be able to do quickly and immediately, and secondary ones can be omitted on subsequent screens and states.
For example, in the mail application (Mail) for Windows 8, there are not so many buttons on the screen itself, but they all answer key scenarios: clear text, send and delete (or save in draft):
Secondary actions that are meaningful from time to time are displayed on the application panel, which appear at the user's request:
Here we can easily find both font management and, for example, access to attachment attachment functionality. This is all important, but secondary in relation 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 brought out, the secondary one appears at the user's request.
Let's look at another example. Imagine that on the description screen of a product in a store you give the user the opportunity to do several actions with it. For example,
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 the application panels (secondary actions):
With this screen - it is clear, there is no special magic here. Let's move up a minute for a minute: most likely it was a screen with a list of products.
Further, analyzing user scenarios, we can find out that sometimes the user is ready to perform an action without plunging to a lower level. For example, it is enough for it to have the name, description of the product and rating - it is ready to immediately add to the cart or to the bookmarks. Or one more important scenario that I remembered - to add to comparison, especially relevant in the general list.
Can we extend the actions that are at the level below to the top? Technically, yes: we could put three or four buttons next to each product:
Try not to do that. In general, a similar iconostasis very quickly turns into a dustbin with a lot of visual noise. And most importantly - all this kills content, which should be given priority, and the main (direct) way of interacting with it.
Nevertheless, the idea to make the opportunity to make quick actions a level higher remains reasonable. What to do?
Firstly, perhaps, not far away from the idea presented above, it is possible to confine ourselves to a few products for which quick actions are possible:
So, by the way, they did it in the “liters” application - the “read book” button immediately translates to the reading mode without intermediate pages of description:
Secondly, that can also be combined with the first, especially for such cases, you can use the selection of list objects, to which the contextual panel of the application is hung, which provides quick access to actions regarding the selected items:
Here, of course, it is also important to prioritize and bring only the key actions to a higher level, for example, in this case, the board is left on the Start screen.
As a result, important actions are closer to the user, but still, in the mass, are available only on request: by selecting the desired list item. And they are also available when diving to the details, which corresponds to the traditional solution.
Finally, let's take a quick look at another interesting section.
Suppose you really spread information across different screens according to the semantic hierarchy and application usage scenarios, consistently pulling the top of the most important.
It is clear that this may reduce the level of detail of information, and even dragging up the entire description of the most important object, as a rule, is meaningless. By reducing the level of detail, for example, you can successively restrict yourself to a heading and a brief description or basic parameters at the second level and only the 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, not just to narrow the amount of information provided, but to make its presentation more compact, information-rich. From the raw data at the bottom level, go on to extract the essential content of the data at the top.
Both data analysis and infographics as a way to visualize data are already starting to work here.
For example, imagine that your application in a chain of screens displays data on the transport of goods:
The higher the level, the more important is not so much the generalization of information as the extraction of the essence of the processes taking place from it. 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: do you need to do something urgently, dive into the details and study a more complete presentation of the data.
If we were talking not about transportation, but for example, about monitoring server racks, it would make sense at the first level to display, say, not so much information about how much space is left on all hard drives, but directly insight that there is little space and based on the statistics of observations, tomorrow the whole place will end and ah-ah-ah - something urgently needs to be done.
Ultimately, the question is how to make the data closer and clearer to the user, so that he can solve other important tasks more quickly and tell him when to dive into details, for example, to intervene in the process.
And, as you already, I hope, understood, all this is not about the squares and informers, but about how to make the user happier, satisfying his needs, expressed in key scenarios and projected onto the modern mobile world of various devices and applications for them.
As I wrote, in the modern mobile world it is especially critical to be able to simultaneously solve two conflicting tasks for a place 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 dive into the details, learn the details and implement important, but still secondary actions.
Someone saw in the article the squares and informers in the pictures, but I hope that the essence of the article did not slip away from the curious reader.
In principle, the need to combine the above tasks was not born today - and they began to be discussed for a long time, respectively. Here I want to refer to the Susan Weinschenk article “ The psychologists view of UX design ”:
')
Get a task done. If you want more details. Progressive disclosure .
And for those interested in the details in terms of usability, I recommend the relevant article by Jacob Nielsen - “ Progressive Disclosure ”.
Today we will try to look into this area from several sides - and I will try to show how the idea of pulling important information up can change the UX and associated interface solutions, especially in the projection on Windows 8.
Time
Any information can have many projections on which it is decomposed into user experience. For example, everything that we considered before concerned the semantic structure of information and its distribution across 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 up "apples";
- collected "apples" are stored in boxes;
- The application logic is such that a user who is 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 accepting any trial restrictions that make the user to work with the application, but at some point require additional actions that benefit the authors of the application. However, we are interested in a completely different moment in this story - how the user learns about this restriction .
In the first version of the application, it looked like this: the user could work with the application at will until the number of filled 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 the message what should he do next:
This is a problem because the event that occurred is not fully predictable for the user: he has no control over the actions taking place (or the sensation of such control). Also, such a message, of course, discourages at the most inopportune moment.
There is a classic solution to this problem, which I will discuss below, but what I want to draw your attention to is a temporary projection of this information.
It is necessary to begin with the fact that the presence of such a threshold value and its quick 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 thought arises of pulling this information closer to the user, but no longer along the hierarchy of screens, but along the timeline.
The sooner I find out about it, the better. However, when this “earlier” must come, it requires careful study in each specific case. For example, you can lead the user by the handle at once, displaying some progress bar:
And you can display a warning one step at a time or several before the onset of the event by blocking further actions:
Or do both at once:
In any case, the approach remains the same: we carry important information closer to the user, while trying to remove the stimuli. The user gets additional control over the situation.
Here also the idea that instead of giving the user an error message in his actions (in our case, trying to add another apple), it’s better not to allow such an action if it is already impossible, however, informing what happens at the moment.
I do not think that the above should be a great revelation to you, however, I hope I managed to illustrate the general idea.
Separately, I’ll note that it’s important not to trash the application with a bunch of redundant information while carrying the information above (earlier in time) for the scenario of working with the application. This makes sense only for key scenarios.
Context
Let's look at another interesting example and talk about geography, more precisely about geo-referencing. This topic is known, perhaps even a little bit annoying, 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, say, cafes / restaurants with live music or something more winter, for example, skating rinks in M.
You can start with an idea to display all objects on a city map, giving you the opportunity to scale and, for example, apply some filters:
Further, by clicking on any of the objects, you can show the accompanying information (description, address, average check size, working time, etc.), or directly transfer to the object card.
It’s like a basic idea, a starting point that may have occurred to you. Now it is necessary to get into the head to the user. For example, find out how much the target audience is really oriented around the map, imagine some areas of the city, and does the location of a particular tag tell her anything other than “it's about there”?
It may turn out that the best way to present information is not a map at all, but a very real list of objects. The list, of course, can not be displayed randomly, need sorting, filtering, etc.
Then you need to dig into the details and look at the essence of information and user scenarios, trying to achieve a very simple result: issue relevance, that is, by default most users should get a suitable object among the first few in the list, although the list itself may contain hundreds of positions.
One of the first ideas that comes to mind is to display the 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. In the list this is displayed simply by text, for example, “1.4 km”. On the map, it is enough to indicate the current location of the user and get directions to the selected point.
As a result, we get the geographical proximity of objects to the user. If we expand this concept, we can say that we are drawing closer to the user what is closer to him in the current context.
This may be not only the distance to the object, but also, for example, the 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 only routes, if by car or taxi, this is completely different situation. On the map from the current location of the user you need to show what corresponds to the user's requests.
Further, if we continue to think about geographic proximity, then it is important for us to correlate our data with the user's world view. For example, it is usually difficult for us to perceive long lists, so it makes sense to divide them into some groups that allow us to orient in making a decision. In the case of distance, these can be groups expressed in kilometers and an estimated time to reach (for example, for a car with traffic):
The breakdown also allows you to quickly go to the group that suits me the most: for example, I don’t want to go to a restaurant in the area, but I don’t want to go too far either — I moved to the group in the middle, quickly navigating through the title.
Another example of contextualism: if the institution closes soon, it would be good to prompt the user about it, or just when sorting by some relevance, pick up those into which the user can potentially get into and have a good time there.
It's 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 at all! For example, they go to the same favorite places, listen to the recommendations of friends and, in general, user reviews and restaurant ratings.
Here the situation turns over completely and our card pyramid begins to collapse. (Yes, that's why it is so important to explore user motivation and decision making.)
This does not negate, of course, completely our previous perceptions, however, makes us rethink what is important in the application for quick decision-making. For example, they may be the context of the user himself (personal preferences) and social context (friends, other users) and only in the third place are the nearest results 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 carry out the basic information to the first hub, assuming that the information in one of the selected pieces of information will be most suitable:
In such a situation, we just come to what we discussed in the previous article: what is the most important of the underlying sections is taken up in the hub, and in the hub itself the sorting takes place according to the priority of the scripts for the user - in this case the personal proximity, on the second social, on the third geographical.
Of course, this does not prevent in parallel 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, having moved completely to the search, where geography accounting turns out to be the opposite meaningful.
Actions
We return to the idea that all secondary should be removed to the background, and the important thing on the contrary 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 is, of course, the separation of functionality across the levels of the application hierarchy. Basic actions need to be able to do quickly and immediately, and secondary ones can be omitted on subsequent screens and states.
For example, in the mail application (Mail) for Windows 8, there are not so many buttons on the screen itself, but they all answer key scenarios: clear text, send and delete (or save in draft):
Secondary actions that are meaningful from time to time are displayed on the application panel, which appear at the user's request:
Here we can easily find both font management and, for example, access to attachment attachment functionality. This is all important, but secondary in relation 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 brought out, the secondary one appears at the user's request.
Let's look at another example. Imagine that on the description screen of a product in a store you give the user the opportunity to do several actions with it. For example,
- add to cart (this is the most important action!),
- bookmark,
- send information to friends (focusing on the “Shared Access” contract) and
- report on the sale, if the product is not available,
- pin on 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 the application panels (secondary actions):
With this screen - it is clear, there is no special magic here. Let's move up a minute for a minute: most likely it was a screen with a list of products.
Further, analyzing user scenarios, we can find out that sometimes the user is ready to perform an action without plunging to a lower level. For example, it is enough for it to have the name, description of the product and rating - it is ready to immediately add to the cart or to the bookmarks. Or one more important scenario that I remembered - to add to comparison, especially relevant in the general list.
Can we extend the actions that are at the level below to the top? Technically, yes: we could put three or four buttons next to each product:
Try not to do that. In general, a similar iconostasis very quickly turns into a dustbin with a lot of visual noise. And most importantly - all this kills content, which should be given priority, and the main (direct) way of interacting with it.
Nevertheless, the idea to make the opportunity to make quick actions a level higher remains reasonable. What to do?
Firstly, perhaps, not far away from the idea presented above, it is possible to confine ourselves to a few products for which quick actions are possible:
So, by the way, they did it in the “liters” application - the “read book” button immediately translates to the reading mode without intermediate pages of description:
Secondly, that can also be combined with the first, especially for such cases, you can use the selection of list objects, to which the contextual panel of the application is hung, which provides quick access to actions regarding the selected items:
Here, of course, it is also important to prioritize and bring only the key actions to a higher level, for example, in this case, the board is left on the Start screen.
As a result, important actions are closer to the user, but still, in the mass, are available only on request: by selecting the desired list item. And they are also available when diving to the details, which corresponds to the traditional solution.
Finally, let's take a quick look at another interesting section.
Essence
Suppose you really spread information across different screens according to the semantic hierarchy and application usage scenarios, consistently pulling the top of the most important.
It is clear that this may reduce the level of detail of information, and even dragging up the entire description of the most important object, as a rule, is meaningless. By reducing the level of detail, for example, you can successively restrict yourself to a heading and a brief description or basic parameters at the second level and only the 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, not just to narrow the amount of information provided, but to make its presentation more compact, information-rich. From the raw data at the bottom level, go on to extract the essential content of the data at the top.
Both data analysis and infographics as a way to visualize data are already starting to work here.
For example, imagine that your application in a chain of screens displays data on the transport of goods:
- on the lowermost screen you display all the parameters of a particular carriage,
- at the level above, you are talking about a certain direction (for example, transportation in the northwestern region), also listing briefly information on the traffic in the region;
- at the first level you derive the regions by summing up the information from the levels below.
The higher the level, the more important is not so much the generalization of information as the extraction of the essence of the processes taking place from it. 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: do you need to do something urgently, dive into the details and study a more complete presentation of the data.
If we were talking not about transportation, but for example, about monitoring server racks, it would make sense at the first level to display, say, not so much information about how much space is left on all hard drives, but directly insight that there is little space and based on the statistics of observations, tomorrow the whole place will end and ah-ah-ah - something urgently needs to be done.
Ultimately, the question is how to make the data closer and clearer to the user, so that he can solve other important tasks more quickly and tell him when to dive into details, for example, to intervene in the process.
And, as you already, I hope, understood, all this is not about the squares and informers, but about how to make the user happier, satisfying his needs, expressed in key scenarios and projected onto the modern mobile world of various devices and applications for them.
Source: https://habr.com/ru/post/164233/
All Articles