Digital Product Development with Mental Models

Hello, Habr! We found a very cool article in Designing Digital Products with Mental Models on a blog by colleagues from the USA, translated it and published it here. The author of the article is designer Tim Scheiner . We recommend reading it to everyone involved in the development of digital products.

The best way to achieve mutual understanding in the project team.

Translation is difficult

Once, traveling in India, I bought an inexpensive book - Crime and Punishment by Dostoevsky in English. I was looking forward to reading this masterpiece with pleasure, but in the end I defeated it with great difficulty. Instead of delight, I was perplexed: why is it so admired? As it turned out later, the text that I read was far from the original source. I only found out about this when I got to Bangkok, where I tried to sell the book I had read to a second-hand book dealer. He said that he did not need it, because the translation was terrible.

This case suggests that translation is not an easy task. It is not only difficult to do well, it can only be determined by an expert to determine that it is done poorly. When developing digital products that automate human operations, you have to deal with translation in the most complex way. Firstly, you must translate the analogous results of observations of a person’s work into a digital form that a computer can interpret. Secondly, you need to describe analog-to-digital conversions in words that mean the same thing to engineers, designers, and product managers in your team, and they all use different terminology to formulate ideas. The story with Dostoevsky shows that it’s not so easy to keep the meaning even when moving to one level, but there are two when developing digital products of such levels.

The solution is to build models together

My approach to translation difficulties when 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.

1. User Model: Who is it for?
2. Value Model: Why is it Useful?
3. Interaction model: how to use it?
4. Object model: how is it arranged?
5. Data Model: How to manage the state of this?

I call this scheme “Digital Machine” and present it like this:



These five models always exist as unconscious assumptions in the heads of the project participants. Such assumptions are the main source of confusion, so the proposed scheme helps people find a common language and effectively exchange information, discussing the ideas that have developed in their head.

My approach works because software is really a digital machine.
Although it consists of bits, not bolts, and is embodied in code rather than made of steel, the sensations of using it (i.e. usability) - in any case, when everything is thought out as it should - come from the same source as any machine: the operator’s relationship with the device, where simple introductory information is converted into useful results for solving significant problems.

Drawing an analogy with a machine in 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 a machine during its development, we can rely on the same visual and spatial logic that applies to physical objects. And since spatial and figurative thinking are nonverbal abilities, such models, built together, are easily perceived by participants with different views.

Now that we have figured out what the Digital Machine scheme is for, let's dwell on each model in more detail.

User model

The user model describes who is using the digital machine. This is a model of human behavior - it defines goals, actions and emotions. For any project, this is a fictional character with certain characteristics:



Thomas is like a real person, but he is not. You perceive the heroes of the popular television show as living people, but in reality they are just actors who play their roles. For a development team, a fictional user is a specific person: everyone knows him by face and by name, unless he participates in meetings. The trick is that when you use a photo and a name, the model comes to life and does its job thanks to the natural tendency of people to empathy.

It is empathy that helps us accurately predict the behavior of other people in order to communicate and work with our own kind. For example, if today we agreed 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 he likes, but also what he expects from the digital machine that we develop for him. This common understanding becomes the criterion that we use - often unconsciously - to determine the value of adding or removing 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:

1. What is this product?
2. How will it make my life easier (more interesting, more efficient, etc.)?
3. Why should I buy / prefer / use this particular product, what is special about it?

The first question is what kind of product is this? - serves as a filter for the user at the highest level. Thomas is a busy man, so he will very quickly and for the most part intuitively classify your car in a certain category. After that, all other impressions of your product depend on their expectations in relation to this category. First of all, he will determine if you created a recording tool, an image editing program, a toy to pass the time at the bus stop, a messenger for communicating with friends or a data analysis system. If Thomas is interested in the appropriate category, he will study the rest of your value model; if not, he will not waste time.

The value model can be represented as the following statement:

[Product Name] is a category of user experience
that brings me such and such benefits (and is better than alternative solutions for such and such reasons).

The last part is enclosed in brackets, because 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 the interaction model.

The paradox is that the value model is the easiest to understand and the most difficult to describe. The hardest part is finding a language that defines value for the individual, not for the organization creating the user experience. It is important for a person that the fulfillment of some task or organization is simplified — that it earns income or achieves a strategic goal. Value for a person is primary, and value for an organization is derived: the organization receives value as a reward for creating value for a person.

The hardest part is finding a language that defines value for the individual, 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 broader 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, you need to build it together by 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 represented as a dialogue of two components of the Digital Machine circuit - human and algorithmic. In this dialog:

• operator action to change the state of the machine -
• this is the input to the algorithm,
• which in response produces a result,
• perceived by the operator as a feedback signal about
• that the car changed its state.

Since the user interacts with the digital machine to perform a specific task, and this interaction changes the state of the digital machine, we can say 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 the 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 book information.
4. Put the book in the basket.
5. Place your order.

At each stage, I interact with the system, entering text, selecting an item from the list, or pressing a button to perform an action. The system responds by issuing visual feedback signals that confirm that it received input from me. At each stage of history, the state of the system changes. In the final, a global change is taking place: I bought a book - the system completed its task!

Another name for a story that describes how a person achieves a goal is workflow. The idea that a workflow is history works like a heuristic: if the interaction model cannot be described as a simple plausible story, you have not finished designing.

Another important thought is that the interaction model is always a complex hierarchical structure. You can illustrate this by expanding the example above.

1. Go to amazon.com.
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 the text.
2.1.3. View options in the partial matches drop-down list.
2.1.3.1. Choose one of the options available.
2.1.3.2. Browse 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 the list of search results.
2.3. Click on the title of the book.
3. View detailed book information.
4. Put the book in the basket.
5. Place your order.

We see that when additional details are added, the interaction model more and more clearly describes how the finished software should behave.

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 are useful, but not required.

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 focuses too early and recklessly on the interaction model without properly describing the other models on which it depends.

Object Model

So far, we have talked about the components of a digital machine that are associated with 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 illustrate this with an example. Let's say we decided to create a simulation game for riding bicycles. When designing a model of an object, we first need to imagine a bicycle. It is clear that although we could display all the details of the bicycle, we only need 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 in the form of a story and identify significant nouns:

Whenthe cyclist rides a bicycle , he sits on the seat , placing his feet on the pedals , and holds the steering wheel with his hands . He controls the bike by controlling the angle of rotation and steering angle 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, to make a trip .
This can be represented as follows:



Or in a more compact form:

Ride
> Vehicle
> Cyclist
> Bicycle
> Handlebar
> Turn
> Tilt
> Position
> Home
> Destination

This representation reveals both the objects in the model and their interaction. The hierarchical structure that we have already discovered in the interaction model naturally appears here, since the two models are interconnected. The more detailed the story in the interaction model, the higher the granularity and accuracy of the description of objects entering into relationships. The converse is also true: if you divide objects into subobjects, the history of their interaction becomes more detailed.

Schematically depicting an object model is extremely useful, but our digital machine lacks the final touch: a state data collection mechanism. This problem is solved by the data model.

Data model

The data model is built on the basis of a simple principle - a name / value pair. It means that when presenting data, each parameter is given a name and a specific value is assigned. More often the value is expressed by a number, but it can also be text.

It is customary to write the name first, and then the value, for example:

x = 3
π = 3.14
color = green
city ​​= San Francisco

Name / value pairs give us the ability to capture status data. Applying this principle in our example with a bicycle, we can write:

position: {
latitude: '37: 78 ',
longitude:' -122: 42 '
}

Pairs that describe the state of an object are often called properties of the object. Continuing in the same vein, you can write:

ride = {
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 '
}
}
}

This is the data model for our game. By fixing the state of all objects in our machine separately, it thereby fixes the state of the machine as a whole.

Now we see: for the user to feel that he controls the speed and direction of the bicycle, we need to translate 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 that he can receive a feedback signal.



Thus, all the work on development and implementation that I carry out with my team comes down to giving the user the opportunity to change several numerical parameters. Understanding this clarifies the situation and at the same time confuses arrogance.

To summarize

A “digital machine" is a diagram that describes a digital product as a collection of five models.

1. User Model: Who is it for?
2. Value Model: Why is it Useful?
3. Interaction model: how to use it?
4. Object model: how is it arranged?
5. Data Model: How to manage the state of this?

This scheme helps project participants cope with the complex process of translating human needs into a useful product in three aspects.

1. The rules of communication set by the models of the digital machine reveal unconscious assumptions and assumptions and allow us to evaluate the degree of agreement of the project participants.
2. The design process becomes more flexible, as it allows for some time to work on each model individually, and then re-assemble them together and evaluate them as an integrated system.
3. Together, building models of a digital machine, 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 get to these lines, you have learned a serious piece of design theory. However, for me the application of such an approach is by no means a theory - I successfully use this scheme in my work every day. 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 easier for each project participant to discuss the models. Although this initially causes some awkwardness in the new team, the communication efficiency increases dramatically, and I was very pleased when one of the former bosses told me: “Probably, sooner or later, we would come to a consensus on our mental models, but thanks to that that you talked about them all the time, it happened much faster. "

Thanks to Ian Shen and Raymond Sutejo for helping to make my ideas about models readable. Thanks also to my former students from the California College of the Arts who asked difficult questions. In search of answers, I developed the Digital Machine scheme.

Literature

It was not me who invented 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 an article and provided illustrations. For those who want to get acquainted with the digital machine and its components in more detail, I will name several sources.

Digital car

The development of digital machines - like any other technology - began with the search for more sophisticated methods of killing during World War II, when it was necessary to break into enemy codes and improve the guidance systems of anti-aircraft guns. In 1945, The Atlantic magazine published an essay, As We May Think . Its author, American engineer Vannevar Bush, first spoke to a wide readership about cars that can think. In 1948 he published a paper by Claude Shannon's " Mathematical Theory of Communication » (The Mathematical Theory of Communication) , where the first scientific description of the information has been given, which was seen as a measurable mechanical quantities. In addition, I recommend that you read the book Introduction to Cybernetics"(Introduction to Cybernetics) by William Ross Ashby - although this is not the easiest reading, here is given the best - rigorous and at the same time affordable - 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 the absolutely correct approach, but I decided that for the purposes of training, information exchange and implementation it is easier to operate with a modular system of models.

Models, general information

The first models that served to simplify the understanding of the world appeared when an ancient man 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 of Hugh Dubberly Model of Models , published in 2009.

User model

The user model has long been successfully used in the practice of designing interactive digital products, environments, systems and services. The best book on the topic - “ Alan Cooper about the interface. Interaction Design Fundamentals ”(About Face 3: The Essentials of Interface Design). Frank Long's article Using Personas in Product Design describes an ingenious experiment that shows the conditions under which collective portraits of users enhance empathy and thereby increase design efficiency.

Value model

The described value model is directly related to the concept of the value proposition outlined in the book by Alexander Osterwalder and Yves Pine " Building Business Models » (Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers), which was published in 2010.

In 2011, IDEO released the Human-Centered Design Toolkit: An Open-Source Toolkit To Inspire New Solutions in the Developing World , which explains how to choose a target user to build a value model.

Interaction model

To describe interaction in the form of a convincing story together with other participants in the project is a very difficult task. A great help in this work will be the book of Jeff Patton's “ User Stories. The art of agile software development ”(User Story Mapping: Discover the Whole Story, Build the Right Product), released in 2014.
It’s useful to get acquainted with the article by Hugh Dubberly What is Interaction , which discusses different options for the interaction model.

Object Model

The construction of such models is best covered in the article by Sofia Wojciechowski Object-Oriented UX .

July 25, 2017

Original article