Theory of restrictions in interfaces (who killed the old graph?)
Hi, my name is Alexander Volkov, I design interfaces at Docsvision. The purpose of this article is to help developers with complex software products. Keyword - complex. Today, even a fifth-grader can design a business card site right on your smartphone, and if you wish, you can download a zip-archive with a ready-made template for a blog or a corporate website. However, if your application is more complicated than a regular online store, then it is quite likely that you will have to build the structure and define the principles of navigation yourself, stepping on the rakes scattered everywhere. Here our experience can be useful. I will describe one of the possible ways to design interfaces, which was successfully tested in our company. This is done easily and simply (almost in semi-automatic mode) using the FlyingLogic program.
The program uses the theory of constraints Goldratt (Theory of Constrains), is used to build diagrams, competitive analysis and is such an excel, not only for numbers, but for cause and effect. Quite briefly, if you have problems causing problems like: “Not all people are Japanese. Are all Japanese people? ”, Then you will love FlyingLogic. Here I am obliged to notice that it was not we who wrote it, but quite different talented programmers, for which I thank them very much, since She proved to be very useful in our difficult task.
Honestly, although the theory is mentioned in the title, you will not find it in the text. Okeigugl obviously knows more than me about this and any other theory. I will talk about the practice - building a graph of goals, as well as how we make decisions in the design.
It was a spoiler - such a cinematic reception to save time.
Let's start! Summary:
1. What is the problem
2. Product is not a website for you.
3. Scripts, scripts ...
4. What to do?
5. Decision
6. Example
7. Conclusions
')
I will try to stick with this plan if I don’t get carried away with details.
If you read this far and did not run away, waving a bundle of paper prototypes ridiculously, it means that you are interested in, what is the problem?
A couple of words can be expressed in the following way - non-linearity and variety of scenarios In modern electronic document management systems that our company develops, unfortunately, there is no simple, clear, straight, like a billiard cue, the user's path from the main page or landing page to the registration page or pay for the purchase.
On the contrary: the movement of a document, like its life cycle, is often tortuous, entangled, and depends on many external and internal parameters. Among such parameters there may be, for example, the contract amount (if a certain threshold is exceeded, it may be necessary to coordinate not only with the financial department, but also with the legal department). The process of agreeing the document depends on the role model of the coordinator, the presence of deputies, and (you won’t believe it!) Even the time taken to leave the secretary at the reception desk.
Our expert AndreevVS (Vladimir Andreev) knows most about this, so I refer you to him and his series of articles .
In a word, there can be a lot of business process scenarios, in each organization they have their own and it is rather difficult to keep them in my head. And the designer should not just keep them in his head, but choose the main ones and build a navigation system that meets the needs of the majority of users.
Hanging up is not necessary. If the application is small, then there is a radical way out: we divide it into small, logically consistent pieces, and access the pieces to the menu on the main page. Voila! This is how most of the web applications and sites in beautiful zero were arranged, when rutracker was called quite differently.
However, the place on the main page is not rubber, and with the increase in the number of pieces to which links are needed, monstrous multi-level menus began to appear. If I were a jury, I would justify the user who killed the developer of such a menu. I think you understand what I'm talking about. In addition, this approach does not take into account the work scenarios at all, and if for the site this is all the way, for a serious business application this is the path to “nowhere”.
A small digression. How to consider scenarios in the design? In the most general case, it looks like this:
Therefore, a logical idea naturally arose: to rank the scenarios. Or at least have some selection criteria. It is better if this is done automatically. Need a program!
As you may have guessed, the program is called FlyingLogic, and it does an excellent job with our task. And not only with her! Download a free 30-day trial here . You can read about it here . For those who like not to read, but look over their shoulders, this is a 13-minute video about the principles of operation (I usually turn on the double speed, this way it only takes 6 minutes).
In his article on Medium, Vlad Golovach considered the main drawback of the program to be the inability to sort the elements, move them on the screen. Paradoxically, but this is for us its main advantage, since allows you to organize automatic ranking. And not only!
As a short example, let's develop the structure of an abstract tudushki application. This is a task manager, in it you can create tasks (to do) yourself or subordinates and control the process of their implementation. The development will be conducted in a fashionable way, based on the goals of users.
Let me explain that a structure means a basic skeleton of an application and movement on it, that is, principles of navigation. But only. If you are interested in the appearance and location of the controls, then Dribbble and Behance are at your service.
Couple of definitions
Actors are roles or any other systems that interact with an application.
A scenario is a sequence of elementary interactions between an application and an actor in order to achieve its goals by the latter.
Fig.1. How scenarios, actors and goals are related
To begin with we make lists of actors and their goals. Immediately, I stress that these lists are incomplete, but for us it does not matter, we need to illustrate the approach. In actual development, of course, the lists should be as complete as possible (see Figure 5) in order not to miss a possible scenario.
Actors for our application are:
The objectives of the actors:
As already mentioned, the actors achieve the goal by combining elementary actions into a script. Make a list of such possible elementary actions:
To prioritize, we construct a graph of achieving goals. Further work takes place inside FlyingLogic.
We create 3 types of objects: actors, actions and goals.
We begin to connect actors with actions, seeking to achieve the chosen goal. It is quite possible to add actions on the fly. For example, we ask ourselves: how can a performer achieve the goal of “unloading the head”? Obviously, having remembered some task, he must immediately add it to the application (or add and schedule a date). This will free his mind for current work and the goal will be achieved, right? Connect the nodes "Artist" -> "Add" -> "Unload head".
Right when the nodes are connected, magic happens - they are automatically lined up in a kind of hierarchy, similar to the one shown in the picture. Below are the actors, at the top of their goal. Movement on the graph is bottom-up.
Fig. 2 This is how the target graph looks in the FlyingLogic window.
The beauty is that it is necessary to add a link or node, as the graph is rebuilt, in accordance with the new configuration.
Looking at this scheme, it soon becomes clear that:
Further. We see that the most notifications have “Notifications” and “Add” (6). This suggests that these actions are very common, that is, should always be available. It looks like the truth, right? In addition, through these actions are the shortest paths to achieving the goals of “unload the head”, “Do not miss deadlines”, etc. And this is already important! Why?
Because, knowing this, we decide to place the counter of notifications and the button for adding new tasks right on the top bar to always see them. Of course, this is obvious to an experienced designer, but now we have a rationale!
On the other hand, “Schedule”, “Complete”, “Approve”, “Delegate”, “Split”, “Comment” have entries only from the “Find” and “Filter” actions. What does this mean, you guessed it? Until a specific task is selected, these actions are not needed (and the controls, which cause them, will litter the interface and the user's head). Therefore, there will be no ribbons in our application. Action buttons will appear only after selecting a task.
Strictly speaking, this method does not insure against errors. For example, in our graph the elementary action “Find task” has the greatest weight (12). On this basis, it is necessary to provide a search form in each type / screen of the application. It would seem that. However, it is not. Experience shows that people do not search for tasks by searching, but browse lists. If you know what to look for, then obviously you remember the task. And if you remember the task, then why look for it? Therefore, our screens should contain lists, and the search form can be hidden behind the icon. Of course, the search is still needed if you need to search by attributes (find all tasks from Vasi Pupkin with a deadline in a week, for example).
The catch is this: inaccurate wording. If you replace “Find task” with “Select task for execution”, then everything falls into place and the lists come to the fore in our application. Just because the choice implies a certain set list.
We are almost done. Next - the scope for creativity.
First, you can immediately easily break the application into levels or types. For example, as I did:
Fig. 3 Grouping nodes
Since movement goes from the bottom up, it turns out that the main screen will be a dashboard with a list of tasks and a quick way to filter them. Next you need the opportunity to see the detailed information on the task and decide on it (second level) - this can be done by opening the pop-up, opening the accordion or showing the details in a separate panel. This panel should contain buttons for “Completion” and other actions. So it turns out from our graph! The notification counter and the add tasks button, as we have said, will be on each screen (Extra Level).
Secondly, to determine what exactly each level / view should contain, it is necessary to decompose it into its components. Take for example the first level, and try to decompose it.
You can find (select) a task:
You can add a task:
Filter:
Thus, the first level should contain all the listed elements + Extra elements.
Thirdly, using the graph is very easy to isolate individual scenarios, evaluate their priority and group. You can experiment! If you decide that your tudushka should work using the GTD methodology, then you can build a graph for such scenarios just by looking at the GTD workflow:
Fig.4 GTD workflow
And then, based on the graph, determine the order and composition of the screens.
Well, where is the automation, you ask? Automation is that we get all the scripts on one sheet. We get a breakdown on the screens, which is suitable for all scenarios. And after the decomposition and the composition of these screens. In addition, the program is great for experimenting in the style of "if, then ...". Actually, it is intended for this. For example, if you add, remove or group nodes, they miraculously rebuild into a new structure. This is a fascinating and very addictive process when you tie knots, spontaneously insert new ones and invent things on the go, without boring planning and meetings.
Try it and you will appreciate the time savings in writing and reading scripts. Have a picture in front of my eyes is worth it, believe me. In addition, the method allows you to cut off false scenarios that lead, for example, to the goal of the organization, and not at all to the goal of the user. The theory states that these are completely different goals. Okeigugl.
The next step may be the replacement of elementary actions on the graph with quarks of buttons, controls, and controls. Thus, the designer will get the elements of which the screen should consist and can simulate their interaction. You can try to optimize the screens by analyzing the coincidence of controls in different scenarios.
And you can go the other way and assign weights to connections, add conditions for performing elementary actions, complex logic and side effects.
To be honest, we have not gone so far yet; this uncharted territory is still waiting for its Columbian people. Share your experience and we will surely give you a friend. Or maybe we will offer money and a difficult, interesting job. Especially if you think that Git support for Word is much more important than spell checking, and for prototyping you need SublimeText and Gulp (and not Axure at all, or God bless you, Photoshop).
In general, that's all. In the end, the method is quite working and tested by us in combat conditions, on real, live interfaces. His presentation was deliberately extremely simplified - it is easier to understand the concept. Keep in mind, we didn’t use a whole range of FlyingLogic cool features, such as built-in fuzzy logic, preconditions, branching, conditional transitions, grouping, link weights, side desirable and unwanted effects, and more. They are of great practical interest for the further development of this approach. The main power is manifested, of course, precisely in complex, confusing scenarios, when you have to have everything before your eyes, laid out in shelves. When it is important not to miss any little thing: the principle “Nonsense, a cancer tumor is very small ...” does not work either in medicine or in design.
For example, it is possible to estimate the likelihood of achieving an actor’s goals, to compare the contribution of different scenarios to the overall result, (which means user satisfaction) depending on different conditions. It is a great pleasure to play with confidence confidence sliders, when changing the value in one corner of the diagram you see how the values ​​are calculated in the dependent nodes in the opposite corner.
The picture below shows Chuck Norris’s shopping list at the Wallmart supermarket on Thanksgiving Day. It has nothing to do with our topic, except that the lists with which analysts and developers work with Docsvision work exactly the same way. It hurts - this is our profession, we just know that stubbornness from stubbornness is distinguished only by one thing - the presence of success in the end.
Pic.5 Chuck Norris Shopping List
I hope this post motivates you not to be afraid to experiment and invent new interfaces for EDS, ERP systems, mobile banks and other SAPs. Just in case, once again I will insert links to FlyingLogic and a couple of videos: “ So you think? "And" Decision Models with Flying Logic "for types like me who love efficient ways and always read from the end.
Oh yeah, I almost forgot. Count killer - butler!
The program uses the theory of constraints Goldratt (Theory of Constrains), is used to build diagrams, competitive analysis and is such an excel, not only for numbers, but for cause and effect. Quite briefly, if you have problems causing problems like: “Not all people are Japanese. Are all Japanese people? ”, Then you will love FlyingLogic. Here I am obliged to notice that it was not we who wrote it, but quite different talented programmers, for which I thank them very much, since She proved to be very useful in our difficult task.
Honestly, although the theory is mentioned in the title, you will not find it in the text. Okeigugl obviously knows more than me about this and any other theory. I will talk about the practice - building a graph of goals, as well as how we make decisions in the design.
It was a spoiler - such a cinematic reception to save time.
Let's start! Summary:
1. What is the problem
2. Product is not a website for you.
3. Scripts, scripts ...
4. What to do?
5. Decision
6. Example
7. Conclusions
')
I will try to stick with this plan if I don’t get carried away with details.
What is the problem
If you read this far and did not run away, waving a bundle of paper prototypes ridiculously, it means that you are interested in, what is the problem?
A couple of words can be expressed in the following way - non-linearity and variety of scenarios In modern electronic document management systems that our company develops, unfortunately, there is no simple, clear, straight, like a billiard cue, the user's path from the main page or landing page to the registration page or pay for the purchase.
On the contrary: the movement of a document, like its life cycle, is often tortuous, entangled, and depends on many external and internal parameters. Among such parameters there may be, for example, the contract amount (if a certain threshold is exceeded, it may be necessary to coordinate not only with the financial department, but also with the legal department). The process of agreeing the document depends on the role model of the coordinator, the presence of deputies, and (you won’t believe it!) Even the time taken to leave the secretary at the reception desk.
Our expert AndreevVS (Vladimir Andreev) knows most about this, so I refer you to him and his series of articles .
In a word, there can be a lot of business process scenarios, in each organization they have their own and it is rather difficult to keep them in my head. And the designer should not just keep them in his head, but choose the main ones and build a navigation system that meets the needs of the majority of users.
What to do?
Hanging up is not necessary. If the application is small, then there is a radical way out: we divide it into small, logically consistent pieces, and access the pieces to the menu on the main page. Voila! This is how most of the web applications and sites in beautiful zero were arranged, when rutracker was called quite differently.
However, the place on the main page is not rubber, and with the increase in the number of pieces to which links are needed, monstrous multi-level menus began to appear. If I were a jury, I would justify the user who killed the developer of such a menu. I think you understand what I'm talking about. In addition, this approach does not take into account the work scenarios at all, and if for the site this is all the way, for a serious business application this is the path to “nowhere”.
Scenarios
A small digression. How to consider scenarios in the design? In the most general case, it looks like this:
- Get a list of these scenarios from business analysts. And the description, if lucky.
- Looking at this list, draw a set of screens, trying to repeat a specific scenario with the minimum number of transitions and mouse clicks.
- Using these screens, assemble a prototype for this scenario, test it (if necessary), fix the shortcomings and repeat the process for another scenario.
- Then comes the stage of combining these atomic pieces into a single application. And here live dragons. The fact is that scripts are starting to compete with each other for screen space and user attention. Sometimes it is impossible to unite them. Chaos and entropy arise.
Therefore, a logical idea naturally arose: to rank the scenarios. Or at least have some selection criteria. It is better if this is done automatically. Need a program!
Decision
As you may have guessed, the program is called FlyingLogic, and it does an excellent job with our task. And not only with her! Download a free 30-day trial here . You can read about it here . For those who like not to read, but look over their shoulders, this is a 13-minute video about the principles of operation (I usually turn on the double speed, this way it only takes 6 minutes).
In his article on Medium, Vlad Golovach considered the main drawback of the program to be the inability to sort the elements, move them on the screen. Paradoxically, but this is for us its main advantage, since allows you to organize automatic ranking. And not only!
Example
As a short example, let's develop the structure of an abstract tudushki application. This is a task manager, in it you can create tasks (to do) yourself or subordinates and control the process of their implementation. The development will be conducted in a fashionable way, based on the goals of users.
Let me explain that a structure means a basic skeleton of an application and movement on it, that is, principles of navigation. But only. If you are interested in the appearance and location of the controls, then Dribbble and Behance are at your service.
Couple of definitions
Actors are roles or any other systems that interact with an application.
A scenario is a sequence of elementary interactions between an application and an actor in order to achieve its goals by the latter.
Fig.1. How scenarios, actors and goals are related
To begin with we make lists of actors and their goals. Immediately, I stress that these lists are incomplete, but for us it does not matter, we need to illustrate the approach. In actual development, of course, the lists should be as complete as possible (see Figure 5) in order not to miss a possible scenario.
Actors for our application are:
- Head
- Executor
- Controller
- Colleague
- outlook
The objectives of the actors:
- Organize things
- Facilitate planning
- Do not miss deadlines
- Unload head
- Give a sense of control
- Interact with colleagues
- Disclaim responsibility
As already mentioned, the actors achieve the goal by combining elementary actions into a script. Make a list of such possible elementary actions:
- Add a new task
- Add recurring task (template)
- Complete the task
- Schedule a task for a specific day.
- Reject task
- Split task (create subtask)
- Rate download per day / week
- View notifications
- Find Record
- Edit Record
- Filter the task list
- Sort the sheet
- Select a task to perform (what to do next)
- Plan a day
- Delegate a task
- Comment on the task
- Assess the status of the project
- Resolve conflicts
- Check execution
- etc.
To prioritize, we construct a graph of achieving goals. Further work takes place inside FlyingLogic.
We create 3 types of objects: actors, actions and goals.
We begin to connect actors with actions, seeking to achieve the chosen goal. It is quite possible to add actions on the fly. For example, we ask ourselves: how can a performer achieve the goal of “unloading the head”? Obviously, having remembered some task, he must immediately add it to the application (or add and schedule a date). This will free his mind for current work and the goal will be achieved, right? Connect the nodes "Artist" -> "Add" -> "Unload head".
Right when the nodes are connected, magic happens - they are automatically lined up in a kind of hierarchy, similar to the one shown in the picture. Below are the actors, at the top of their goal. Movement on the graph is bottom-up.
Fig. 2 This is how the target graph looks in the FlyingLogic window.
The beauty is that it is necessary to add a link or node, as the graph is rebuilt, in accordance with the new configuration.
Speculate
Looking at this scheme, it soon becomes clear that:
- The fewer actions between the actor and the goal - the faster and easier it is achieved! We need to find the shortest scenarios, only then the application will be successful. Such is life, water seeks a hole.
- The more inputs the action has, the more “popular” it is. It is on these actions that particular attention must be paid when developing. They will affect most of your users.
- (Note. Actually, this is not quite true. What if there is only one input, but 90% of users use this action? Answer: assign links to weights, there is such an opportunity in the program.)
- The sum of the inputs and outputs determines the weight of the action in the scenarios (This is a simplified approach. See the previous note)
Further. We see that the most notifications have “Notifications” and “Add” (6). This suggests that these actions are very common, that is, should always be available. It looks like the truth, right? In addition, through these actions are the shortest paths to achieving the goals of “unload the head”, “Do not miss deadlines”, etc. And this is already important! Why?
Because, knowing this, we decide to place the counter of notifications and the button for adding new tasks right on the top bar to always see them. Of course, this is obvious to an experienced designer, but now we have a rationale!
On the other hand, “Schedule”, “Complete”, “Approve”, “Delegate”, “Split”, “Comment” have entries only from the “Find” and “Filter” actions. What does this mean, you guessed it? Until a specific task is selected, these actions are not needed (and the controls, which cause them, will litter the interface and the user's head). Therefore, there will be no ribbons in our application. Action buttons will appear only after selecting a task.
Strictly speaking, this method does not insure against errors. For example, in our graph the elementary action “Find task” has the greatest weight (12). On this basis, it is necessary to provide a search form in each type / screen of the application. It would seem that. However, it is not. Experience shows that people do not search for tasks by searching, but browse lists. If you know what to look for, then obviously you remember the task. And if you remember the task, then why look for it? Therefore, our screens should contain lists, and the search form can be hidden behind the icon. Of course, the search is still needed if you need to search by attributes (find all tasks from Vasi Pupkin with a deadline in a week, for example).
The catch is this: inaccurate wording. If you replace “Find task” with “Select task for execution”, then everything falls into place and the lists come to the fore in our application. Just because the choice implies a certain set list.
We are almost done. Next - the scope for creativity.
First, you can immediately easily break the application into levels or types. For example, as I did:
Fig. 3 Grouping nodes
Since movement goes from the bottom up, it turns out that the main screen will be a dashboard with a list of tasks and a quick way to filter them. Next you need the opportunity to see the detailed information on the task and decide on it (second level) - this can be done by opening the pop-up, opening the accordion or showing the details in a separate panel. This panel should contain buttons for “Completion” and other actions. So it turns out from our graph! The notification counter and the add tasks button, as we have said, will be on each screen (Extra Level).
Secondly, to determine what exactly each level / view should contain, it is necessary to decompose it into its components. Take for example the first level, and try to decompose it.
You can find (select) a task:
- Just a glance from the general list.
- Applying filters
- Search
- Looking into history
- Having received notification of a new task
- The calendar
You can add a task:
- Through the input field
- Through the pattern
- Copying another job
- Drag drop letters from the mail
- By sending an email to a special address
Filter:
- Through the filter panel (create your own or apply an existing filter)
- Through contexts (importance, project, deadline, label, etc.)
Thus, the first level should contain all the listed elements + Extra elements.
Thirdly, using the graph is very easy to isolate individual scenarios, evaluate their priority and group. You can experiment! If you decide that your tudushka should work using the GTD methodology, then you can build a graph for such scenarios just by looking at the GTD workflow:
Fig.4 GTD workflow
And then, based on the graph, determine the order and composition of the screens.
Well, where is the automation, you ask? Automation is that we get all the scripts on one sheet. We get a breakdown on the screens, which is suitable for all scenarios. And after the decomposition and the composition of these screens. In addition, the program is great for experimenting in the style of "if, then ...". Actually, it is intended for this. For example, if you add, remove or group nodes, they miraculously rebuild into a new structure. This is a fascinating and very addictive process when you tie knots, spontaneously insert new ones and invent things on the go, without boring planning and meetings.
Try it and you will appreciate the time savings in writing and reading scripts. Have a picture in front of my eyes is worth it, believe me. In addition, the method allows you to cut off false scenarios that lead, for example, to the goal of the organization, and not at all to the goal of the user. The theory states that these are completely different goals. Okeigugl.
What's next?
The next step may be the replacement of elementary actions on the graph with quarks of buttons, controls, and controls. Thus, the designer will get the elements of which the screen should consist and can simulate their interaction. You can try to optimize the screens by analyzing the coincidence of controls in different scenarios.
And you can go the other way and assign weights to connections, add conditions for performing elementary actions, complex logic and side effects.
To be honest, we have not gone so far yet; this uncharted territory is still waiting for its Columbian people. Share your experience and we will surely give you a friend. Or maybe we will offer money and a difficult, interesting job. Especially if you think that Git support for Word is much more important than spell checking, and for prototyping you need SublimeText and Gulp (and not Axure at all, or God bless you, Photoshop).
findings
In general, that's all. In the end, the method is quite working and tested by us in combat conditions, on real, live interfaces. His presentation was deliberately extremely simplified - it is easier to understand the concept. Keep in mind, we didn’t use a whole range of FlyingLogic cool features, such as built-in fuzzy logic, preconditions, branching, conditional transitions, grouping, link weights, side desirable and unwanted effects, and more. They are of great practical interest for the further development of this approach. The main power is manifested, of course, precisely in complex, confusing scenarios, when you have to have everything before your eyes, laid out in shelves. When it is important not to miss any little thing: the principle “Nonsense, a cancer tumor is very small ...” does not work either in medicine or in design.
For example, it is possible to estimate the likelihood of achieving an actor’s goals, to compare the contribution of different scenarios to the overall result, (which means user satisfaction) depending on different conditions. It is a great pleasure to play with confidence confidence sliders, when changing the value in one corner of the diagram you see how the values ​​are calculated in the dependent nodes in the opposite corner.
The picture below shows Chuck Norris’s shopping list at the Wallmart supermarket on Thanksgiving Day. It has nothing to do with our topic, except that the lists with which analysts and developers work with Docsvision work exactly the same way. It hurts - this is our profession, we just know that stubbornness from stubbornness is distinguished only by one thing - the presence of success in the end.
Pic.5 Chuck Norris Shopping List
I hope this post motivates you not to be afraid to experiment and invent new interfaces for EDS, ERP systems, mobile banks and other SAPs. Just in case, once again I will insert links to FlyingLogic and a couple of videos: “ So you think? "And" Decision Models with Flying Logic "for types like me who love efficient ways and always read from the end.
Oh yeah, I almost forgot. Count killer - butler!
Source: https://habr.com/ru/post/277339/
All Articles