Digital Product Development with Mental Models
Hi, Habr! We found a very cool article Designing Digital Products with Mental Models in a blog of colleagues from the USA, translated it and publish it here. The author of the article is designer Tim Sheiner . We recommend reading it to anyone who is related to the development of digital products.
Translation is hard
While traveling around India, I bought Dostoevsky's inexpensive book, Crime and Punishment, in English. I was looking forward to reading this masterpiece with pleasure, but in the end I overcame it with great difficulty. Instead of delight, I was perplexed: why is he so admired? As it turned out later, the text I was reading was far from the original source. I found out about it only when I reached Bangkok, where I tried to sell the book to a bookseller. He said that he did not need it, because the translation is terrible.
This case suggests that translation is not an easy task. It is not only difficult to do it well - only an expert can determine that it is done poorly. When developing digital products that automate human operations, you have to translate in the most complex form. First, you must convert the analog results of human observations to digital form that a computer can interpret. Secondly, you need to describe analog-to-digital transformations with words that mean the same thing to the engineers, designers, and product managers in your team, and they all use different terminology to formulate ideas. The story of Dostoevsky shows that it is not so easy to keep the meaning even when translating to one level, and there are two levels when developing digital products.
My approach to translation difficulties in developing digital products is to first minimize the amount of information that needs to be translated. To do this, at the very beginning, team members must construct five mental models together.
')
I call this scheme "Digital Machine" and imagine it this way:
These five models always exist as unconscious assumptions in the heads of the project participants. Such assumptions are the main source of confusion; therefore, the proposed scheme helps people to find a common language and effectively exchange information by discussing the ideas that have formed in their heads.
My approach works because software is truly a digital machine.
Although it consists of bits, not bolts, and is embodied in code, and not made of steel, the sensation of using it (that is, usability) — in any case, when everything is thought out properly — comes from the same source as in any machine: the operator’s relationship with the device, where simple introductory data are converted into useful results for solving meaningful tasks.
Drawing an analogy with the machine when developing a digital product, we can rely on the same visual and spatial logic that applies to physical objects.
This means that although it is impossible to see or touch the internal structure of a digital product, drawing an analogy with the machine during its development, we can rely on the same visual and spatial logic that applies to physical objects. And since spatial and imaginative thinking is non-verbal abilities, such models, built together, are easily perceived by participants with different views.
Now that we have understood what the “Digital Machine” scheme is for, let's look at each model in more detail.
A user model describes one who uses a digital machine. This is a model of human behavior - it defines goals, actions and emotions. For any project it is a fictional character with certain characteristics:
Thomas is like a real person, but he is not. You perceive the heroes of the popular TV show as living people, but in reality these are just actors who play their roles. For the development team, a fictional user is a specific person: everyone knows him by sight and by name, except that he does not participate in meetings. The trick is that when you use a photo and a name, the model comes to life and does its job due to people's natural inclination to empathy.
It is empathy that helps us to accurately predict the behavior of other people in order to communicate and work with our own kind. For example, if today we agreed with you that Thomas’s favorite color is orange, of course, tomorrow it will also be orange. Continuing to discuss Thomas, we will come to a common understanding of his preferences and needs: not only what color does he like, but what does he expect from the digital machine we are developing for him. This common understanding becomes the criterion we use - often unconsciously - to determine the value of adding or removing certain functions.
A digital product - like a person - has only one chance to make a good first impression. The value model determines how this impression should be from your point of view.
She tells the user:
The first question is what kind of product is it? - serves for the user the filter of the highest level. Thomas is a busy man, so he will very quickly and mostly intuitively assign your car to a certain category. After that, all other impressions of your product depend on its expectations regarding this category. First, it will determine whether you have created a recording tool, an image editing program, a toy to pass the time at the bus stop, an instant messenger for communicating with friends, or a system for analyzing data. If the relevant category is of interest to Thomas, he will study the rest of your value model; if not, he won't waste time.
The value model can be represented as the following statement:
The paradox is that the value model is the easiest to understand and the most difficult to describe. The most difficult thing is to find a wording that defines value for the person, not for the organization creating the user experience. It is important for a person that it is easier to accomplish a task, an organization - that it receives income or reaches a strategic goal. Value for a person is primary, and value for an organization is derivative: an organization receives value as a reward for creating value for a person.
The most difficult thing is to find a wording that defines value for the person, not for the organization creating the user experience.
To solve this problem, you need to take two important steps. First, mentally place a digital machine inside a more extensive business model, where our product is only one component of the organization’s overall value proposition for the consumer. Secondly, to create a convincing model of value, one needs to build it by common efforts, applying human-oriented development methods - and directly attracting people who are similar to the target user.
The interaction model determines how a person changes the state of a digital machine. This model can be presented in the form of a dialogue between two components of the “Digital Machine” scheme - human and algorithmic. In this dialogue:
Since the user interacts with a digital machine to perform a specific task, and this interaction changes the state of the digital machine, it can be said that the purpose of the interaction model is to change the state of the digital machine.
Such a theoretical understanding of the interaction model is necessary in order to link it with the object model and data model, which will be discussed below, but this is not the best approach to its design. In this case, it is much better to present the interaction model as a story.
Here is an example of such a story for buying a book on Amazon.
At each stage, I interact with the system by entering text, choosing a product from the list, or pressing a button to perform an action. The system responds by giving visual feedback signals that confirm that it received input from me. At each stage of history, the state of the system changes. At the end there is a global change: I bought a book - the system has completed its task!
Another name for a story that describes how a person achieves a goal is the work process. The idea that a workflow is a story works like heuristics: if the interaction model cannot be described as a simple plausible story, you have not finished designing.
Another important point is that the interaction model is always a complex hierarchical structure. You can illustrate this by extending the example above.
By presenting this model as a set of hierarchically related stories, we can rank these stories and determine which ones are necessary for the workflow and which ones are useful but not necessary.
Since the interaction model tells the story of what the user does with software, it is easiest for project participants to discuss this particular model, which helps them come to an understanding. The danger is - and this is the problem of most software development projects - that the team too early and recklessly focuses on the interaction model, without properly describing other models on which it depends.
So far, we have been talking about the components of a digital machine that are related to the user and his experience with the product. The object model and data model allow us to discuss the technical side of things.
Although all models in a digital machine are important, the object model is the most important because it defines the “details” of the machine and their relationship. Let us explain this with an example. Suppose we decided to create a simulator game for cycling. When designing an object model, we first need to imagine a bicycle. It is clear that, although we could display all the details of the bike, we need only those that interact with the cyclist and the road.
A convenient way to perform such an analysis of an object is to present the interaction model as a story and identify significant nouns:
When a cyclist rides a bicycle , he sits on the seat , putting his feet on the pedals , and holding the steering wheel with his hands. He controls the bike, controlling the angle of inclination and steering in a certain range , so as not to fall under the influence of gravity and get from the starting point to the destination , that is, make a trip .
This can be represented as:
Or in a more compact form:
To schematically depict an object model is extremely useful, but our digital machine lacks a final touch: a state data collection mechanism. This problem is solved by the data model.
The data model is based on a simple principle - a name / value pair. It means that when presenting the data, each parameter is given a name and a certain value is assigned. More often the value is expressed by a number, but it can be text.
It is accepted to first write the name, and then the value, for example:
Now we see that in order for the user to feel that he controls the speed and direction of movement of the bike, we need to transfer the data that he enters into the game controller into numerical values ​​and use them to update the data model, and then translate these state changes into visual information, so he can get a feedback signal.
Thus, all the development and implementation work that I do with my team comes down to allowing the user to change several numeric parameters. Understanding this clarifies the situation and simultaneously brings down arrogance.
A “digital machine” is a circuit that describes a digital product as a combination of five models.
This scheme helps project participants cope with the complex process of converting a person’s needs into a useful product in three aspects.
If you have come to these lines, you have learned a serious piece of design theory. However, for me, the use of such an approach is by no means a theory — I daily successfully use this scheme in my work. I constantly tell my team about the models, I draw them on the board, include them in the presentations, and do my best to make it easy for each project participant to discuss the models. Although in the new team this at first causes some awkwardness, the effectiveness of communication increases dramatically, and I was very pleased when one of the former bosses told me: “Probably, sooner or later we would come to a common opinion about our mental models, but due to that you talked about them all the time, it happened much faster. "
Thanks to Ian Shen and Raymond Sutadjo for helping to bring my ideas about the models into a readable form. Thanks to my former students at California College of the Arts who asked difficult questions. In search of answers, I developed the “Digital Machine” scheme.
I did not invent the digital machine and the models of which it consists. My merit (or fault) lies only in the fact that I outlined this concept in the article and provided it with illustrations. For those who want to get acquainted with the digital machine and its components in more detail, I will mention several sources.
The development of digital machines - like any other technology - began with the search for more sophisticated methods of killing during the Second World War, when it was necessary to crack enemy ciphers and improve the guidance system of anti-aircraft guns. In 1945, The Atlantic magazine published an essay, “ As We May Think ” ( As We May Think ). Its author, American engineer Vannevar Bush, for the first time told a wide readership about cars that can think. In 1948, Claude Shannon's article The Mathematical Theory of Communication (The Mathematical Theory of Communication) was published, where the first scientific characteristic of information was given, which was considered as a measurable mechanical quantity. In addition, I recommend to get acquainted with the book Introduction to Cybernetics by William Ross Ashby - although this is not the easiest reading, here the best is given - a strict and at the same time accessible definition of a digital machine.
I advise you to pay special attention to the book Conceptual Models: Core to Good Design by Jeff Johnson and Austin Henderson, which was published in 2011 - it was she who inspired me to create the “Digital Machine” scheme. The authors describe an absolutely correct approach, but I decided that it was easier to operate a modular system of models for the purposes of learning, information sharing and implementation.
The first models that served to simplify the comprehension of the world appeared when the ancient people painted a picture on the wall of the cave. A more modern interpretation of this concept, primarily in relation to design, is contained in the book Hugh Dubberley Model of Models , published in 2009.
The user model has been successfully used for a long time in the practice of designing interactive digital products, environments, systems and services. The best book on the topic is “ Alan Cooper on the interface. Basics of interaction design "(About Face 3: The Essentials of Interface Design). The article by Frank Long on Using Personas in Product Design describes an ingenious experiment that shows under what conditions collective user portraits enhance empathy and thereby increase design efficiency.
The value model described in the article is directly related to the concept of value proposition set forth in the Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers, published in 2010 by Alexander Ostervalder and Yves Pigne.
In 2011, IDEO released the Human-Centered Design Toolkit: An Open-Source Toolkit To Inspire New Solutions for Developing World , which describes how to choose a target user to build a value model.
To describe the interaction in the form of a convincing story together with other project participants is a very difficult task. A great help in this work will be Jeff Patton's book “ User Stories. The Art of Agile Software Development (User Story Mapping: Discover the Whole Story, Build the Right Product), released in 2014.
It is useful to get acquainted with the article by Hugh Dubberley What is Interaction , which discusses various options for interaction models.
The best way to build such models is highlighted in the article by Sofia Wojciechowski Object-Oriented UX .
July 25, 2017
Original article
The best way to achieve mutual understanding in the project team.
Translation is hard
While traveling around India, I bought Dostoevsky's inexpensive book, Crime and Punishment, in English. I was looking forward to reading this masterpiece with pleasure, but in the end I overcame it with great difficulty. Instead of delight, I was perplexed: why is he so admired? As it turned out later, the text I was reading was far from the original source. I found out about it only when I reached Bangkok, where I tried to sell the book to a bookseller. He said that he did not need it, because the translation is terrible.
This case suggests that translation is not an easy task. It is not only difficult to do it well - only an expert can determine that it is done poorly. When developing digital products that automate human operations, you have to translate in the most complex form. First, you must convert the analog results of human observations to digital form that a computer can interpret. Secondly, you need to describe analog-to-digital transformations with words that mean the same thing to the engineers, designers, and product managers in your team, and they all use different terminology to formulate ideas. The story of Dostoevsky shows that it is not so easy to keep the meaning even when translating to one level, and there are two levels when developing digital products.
Solution - we build models together
My approach to translation difficulties in developing digital products is to first minimize the amount of information that needs to be translated. To do this, at the very beginning, team members must construct five mental models together.
')
- User Model: Who is it for?
- Value model: why is it useful?
- Interaction model: how to use it?
- Object Model: how does it work?
- Data model: how to manage the state of it?
I call this scheme "Digital Machine" and imagine it this way:
These five models always exist as unconscious assumptions in the heads of the project participants. Such assumptions are the main source of confusion; therefore, the proposed scheme helps people to find a common language and effectively exchange information by discussing the ideas that have formed in their heads.
My approach works because software is truly a digital machine.
Although it consists of bits, not bolts, and is embodied in code, and not made of steel, the sensation of using it (that is, usability) — in any case, when everything is thought out properly — comes from the same source as in any machine: the operator’s relationship with the device, where simple introductory data are converted into useful results for solving meaningful tasks.
Drawing an analogy with the machine when developing a digital product, we can rely on the same visual and spatial logic that applies to physical objects.
This means that although it is impossible to see or touch the internal structure of a digital product, drawing an analogy with the machine during its development, we can rely on the same visual and spatial logic that applies to physical objects. And since spatial and imaginative thinking is non-verbal abilities, such models, built together, are easily perceived by participants with different views.
Now that we have understood what the “Digital Machine” scheme is for, let's look at each model in more detail.
User Model
A user model describes one who uses a digital machine. This is a model of human behavior - it defines goals, actions and emotions. For any project it is a fictional character with certain characteristics:
Thomas is like a real person, but he is not. You perceive the heroes of the popular TV show as living people, but in reality these are just actors who play their roles. For the development team, a fictional user is a specific person: everyone knows him by sight and by name, except that he does not participate in meetings. The trick is that when you use a photo and a name, the model comes to life and does its job due to people's natural inclination to empathy.
It is empathy that helps us to accurately predict the behavior of other people in order to communicate and work with our own kind. For example, if today we agreed with you that Thomas’s favorite color is orange, of course, tomorrow it will also be orange. Continuing to discuss Thomas, we will come to a common understanding of his preferences and needs: not only what color does he like, but what does he expect from the digital machine we are developing for him. This common understanding becomes the criterion we use - often unconsciously - to determine the value of adding or removing certain functions.
Value Model
A digital product - like a person - has only one chance to make a good first impression. The value model determines how this impression should be from your point of view.
She tells the user:
- What is this product?
- What makes my life easier (more interesting, more efficient, etc.)?
- Why should I buy / prefer / use this particular product, what is special about it?
The first question is what kind of product is it? - serves for the user the filter of the highest level. Thomas is a busy man, so he will very quickly and mostly intuitively assign your car to a certain category. After that, all other impressions of your product depend on its expectations regarding this category. First, it will determine whether you have created a recording tool, an image editing program, a toy to pass the time at the bus stop, an instant messenger for communicating with friends, or a system for analyzing data. If the relevant category is of interest to Thomas, he will study the rest of your value model; if not, he won't waste time.
The value model can be represented as the following statement:
[Product Name] is a user experience category,The last part is enclosed in brackets, since it is not always possible to describe the reasons with a simple sentence. Defining these distinctive features is very important, but often the best way to convey them to the user is implicitly through an interaction model.
which brings me such and such benefits (and better alternative solutions for such and such reasons).
The paradox is that the value model is the easiest to understand and the most difficult to describe. The most difficult thing is to find a wording that defines value for the person, not for the organization creating the user experience. It is important for a person that it is easier to accomplish a task, an organization - that it receives income or reaches a strategic goal. Value for a person is primary, and value for an organization is derivative: an organization receives value as a reward for creating value for a person.
The most difficult thing is to find a wording that defines value for the person, not for the organization creating the user experience.
To solve this problem, you need to take two important steps. First, mentally place a digital machine inside a more extensive business model, where our product is only one component of the organization’s overall value proposition for the consumer. Secondly, to create a convincing model of value, one needs to build it by common efforts, applying human-oriented development methods - and directly attracting people who are similar to the target user.
Interaction model
The interaction model determines how a person changes the state of a digital machine. This model can be presented in the form of a dialogue between two components of the “Digital Machine” scheme - human and algorithmic. In this dialogue:
- operator action to change the state of the machine -
- this is the input to the algorithm,
- which returns the result,
- perceived by the operator as a feedback signal stating
- that the car has changed its state.
Since the user interacts with a digital machine to perform a specific task, and this interaction changes the state of the digital machine, it can be said that the purpose of the interaction model is to change the state of the digital machine.
Such a theoretical understanding of the interaction model is necessary in order to link it with the object model and data model, which will be discussed below, but this is not the best approach to its design. In this case, it is much better to present the interaction model as a story.
Here is an example of such a story for buying a book on Amazon.
1. Go to amazon.com.
2. Find a book.
3. View detailed information about the book.
4. Put the book in the basket.
5. Place an order.
At each stage, I interact with the system by entering text, choosing a product from the list, or pressing a button to perform an action. The system responds by giving visual feedback signals that confirm that it received input from me. At each stage of history, the state of the system changes. At the end there is a global change: I bought a book - the system has completed its task!
Another name for a story that describes how a person achieves a goal is the work process. The idea that a workflow is a story works like heuristics: if the interaction model cannot be described as a simple plausible story, you have not finished designing.
Another important point is that the interaction model is always a complex hierarchical structure. You can illustrate this by extending the example above.
1. Go to amazon.com.We see that when additional details are added, the interaction model more and more clearly describes how ready-made software should behave.
2. Find a book.
2.1. Use the Search dialog box.
2.1.1. Place the cursor in the Search dialog box.
2.1.2. Type text.
2.1.3. Look at the options in the drop-down list of partial matches.
2.1.3.1. Choose one of the options.
2.1.3.2. Browse through the list of search results.
2.1.4. Ignore the options in the drop-down list of partial matches, click the Return button.
2.2. Browse through the list of search results.
2.3. Click on the book title.
3. View detailed information about the book.
4. Put the book in the basket.
5. Place an order.
By presenting this model as a set of hierarchically related stories, we can rank these stories and determine which ones are necessary for the workflow and which ones are useful but not necessary.
Since the interaction model tells the story of what the user does with software, it is easiest for project participants to discuss this particular model, which helps them come to an understanding. The danger is - and this is the problem of most software development projects - that the team too early and recklessly focuses on the interaction model, without properly describing other models on which it depends.
Object model
So far, we have been talking about the components of a digital machine that are related to the user and his experience with the product. The object model and data model allow us to discuss the technical side of things.
Although all models in a digital machine are important, the object model is the most important because it defines the “details” of the machine and their relationship. Let us explain this with an example. Suppose we decided to create a simulator game for cycling. When designing an object model, we first need to imagine a bicycle. It is clear that, although we could display all the details of the bike, we need only those that interact with the cyclist and the road.
A convenient way to perform such an analysis of an object is to present the interaction model as a story and identify significant nouns:
When a cyclist rides a bicycle , he sits on the seat , putting his feet on the pedals , and holding the steering wheel with his hands. He controls the bike, controlling the angle of inclination and steering in a certain range , so as not to fall under the influence of gravity and get from the starting point to the destination , that is, make a trip .
This can be represented as:
Or in a more compact form:
TripThis view reveals both objects in the model and their interaction. The hierarchical structure, which we have already found in the interaction model, naturally appears here, since these two models are interconnected. The more detailed the history in the interaction model, the higher the detail and accuracy of the description of the objects entering into the relationship. The reverse is also true: if you break objects into sub-objects, the history of their interaction becomes more detailed.
> vehicle
> cyclist
> bicycle
> steering wheel
> turn
> tilt angle
> position
> starting point
> destination
To schematically depict an object model is extremely useful, but our digital machine lacks a final touch: a state data collection mechanism. This problem is solved by the data model.
Data model
The data model is based on a simple principle - a name / value pair. It means that when presenting the data, each parameter is given a name and a certain value is assigned. More often the value is expressed by a number, but it can be text.
It is accepted to first write the name, and then the value, for example:
x = 3Name / value pairs enable us to capture state data. Applying this principle in our example with a bicycle, you can write:
Ď€ = 3.14
color = green
city ​​= San Francisco
position: {Couples that describe the state of an object are often called object properties. Continuing in the same vein, you can write:
latitude: '37: 78 ',
longitude: '–122: 42'
}
trip = {This is the data model for our game. Fixing the state of all objects in our car separately, it thereby fixes the state of the machine as a whole.
vehicle: {
cyclist: {
Name: 'Thomas'
},
bicycle: {
steering wheel: {
turn: '12',
tilt angle: '3'
}
},
current position: {
Latitude: '37 .78 ',
longitude: '-122.42'
},
},
starting point: {
Name: 'San Francisco',
position: {
Latitude: '37 .78 ',
longitude: '-122.42'
},
destination: {
Name: 'Los Angeles',
position: {
Latitude: '34 .05 ',
longitude: '-118.42'
}
}
}
Now we see that in order for the user to feel that he controls the speed and direction of movement of the bike, we need to transfer the data that he enters into the game controller into numerical values ​​and use them to update the data model, and then translate these state changes into visual information, so he can get a feedback signal.
Thus, all the development and implementation work that I do with my team comes down to allowing the user to change several numeric parameters. Understanding this clarifies the situation and simultaneously brings down arrogance.
Let's sum up
A “digital machine” is a circuit that describes a digital product as a combination of five models.
- User Model: Who is it for?
- Value model: why is it useful?
- Interaction model: how to use it?
- Object Model: how does it work?
- Data model: how to manage the state of it?
This scheme helps project participants cope with the complex process of converting a person’s needs into a useful product in three aspects.
- The rules of communication, set by digital machine models, reveal the unconscious assumptions and assumptions and allow us to assess the degree of agreement of the project participants.
- The design process becomes more flexible, as it allows for some time to work on each model separately, and then reassemble them together and evaluate them as a complete system.
- By building models of a digital machine together, the project participants use their abilities for imaginative and spatial thinking, which helps them come to a common understanding of how the product works.
If you have come to these lines, you have learned a serious piece of design theory. However, for me, the use of such an approach is by no means a theory — I daily successfully use this scheme in my work. I constantly tell my team about the models, I draw them on the board, include them in the presentations, and do my best to make it easy for each project participant to discuss the models. Although in the new team this at first causes some awkwardness, the effectiveness of communication increases dramatically, and I was very pleased when one of the former bosses told me: “Probably, sooner or later we would come to a common opinion about our mental models, but due to that you talked about them all the time, it happened much faster. "
Thanks to Ian Shen and Raymond Sutadjo for helping to bring my ideas about the models into a readable form. Thanks to my former students at California College of the Arts who asked difficult questions. In search of answers, I developed the “Digital Machine” scheme.
Literature
I did not invent the digital machine and the models of which it consists. My merit (or fault) lies only in the fact that I outlined this concept in the article and provided it with illustrations. For those who want to get acquainted with the digital machine and its components in more detail, I will mention several sources.
Digital machine
The development of digital machines - like any other technology - began with the search for more sophisticated methods of killing during the Second World War, when it was necessary to crack enemy ciphers and improve the guidance system of anti-aircraft guns. In 1945, The Atlantic magazine published an essay, “ As We May Think ” ( As We May Think ). Its author, American engineer Vannevar Bush, for the first time told a wide readership about cars that can think. In 1948, Claude Shannon's article The Mathematical Theory of Communication (The Mathematical Theory of Communication) was published, where the first scientific characteristic of information was given, which was considered as a measurable mechanical quantity. In addition, I recommend to get acquainted with the book Introduction to Cybernetics by William Ross Ashby - although this is not the easiest reading, here the best is given - a strict and at the same time accessible definition of a digital machine.
I advise you to pay special attention to the book Conceptual Models: Core to Good Design by Jeff Johnson and Austin Henderson, which was published in 2011 - it was she who inspired me to create the “Digital Machine” scheme. The authors describe an absolutely correct approach, but I decided that it was easier to operate a modular system of models for the purposes of learning, information sharing and implementation.
Models, general information
The first models that served to simplify the comprehension of the world appeared when the ancient people painted a picture on the wall of the cave. A more modern interpretation of this concept, primarily in relation to design, is contained in the book Hugh Dubberley Model of Models , published in 2009.
User Model
The user model has been successfully used for a long time in the practice of designing interactive digital products, environments, systems and services. The best book on the topic is “ Alan Cooper on the interface. Basics of interaction design "(About Face 3: The Essentials of Interface Design). The article by Frank Long on Using Personas in Product Design describes an ingenious experiment that shows under what conditions collective user portraits enhance empathy and thereby increase design efficiency.
Value Model
The value model described in the article is directly related to the concept of value proposition set forth in the Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers, published in 2010 by Alexander Ostervalder and Yves Pigne.
In 2011, IDEO released the Human-Centered Design Toolkit: An Open-Source Toolkit To Inspire New Solutions for Developing World , which describes how to choose a target user to build a value model.
Interaction model
To describe the interaction in the form of a convincing story together with other project participants is a very difficult task. A great help in this work will be Jeff Patton's book “ User Stories. The Art of Agile Software Development (User Story Mapping: Discover the Whole Story, Build the Right Product), released in 2014.
It is useful to get acquainted with the article by Hugh Dubberley What is Interaction , which discusses various options for interaction models.
Object model
The best way to build such models is highlighted in the article by Sofia Wojciechowski Object-Oriented UX .
July 25, 2017
Original article
Source: https://habr.com/ru/post/444564/
All Articles