Designer’s Field Guide
Co-Designing the Digital Machine
Use these models to get your entire team on the same page about what you are building
The Problem is Translation
Years ago while traveling in India I bought an inexpensive English translation of Dostoevsky’s Crime and Punishment. I was excited to read this famous piece of Russian literature but after slogging my way through it, I was not impressed and couldn’t understand why it was so revered. The answer, it turned out, was that the words I had read did not convey Dostoevsky’s original meaning. I discovered this only when I got to Bangkok and tried to sell the book to a used book dealer who refused to buy it because, as he told me, that translation was awful!
This anecdote highlights the challenge of translation: not only is it hard to do well, only an expert can tell when it is done badly. Developing digital products that automate tasks for people involves solving a very difficult version of this challenge. First there is the fundamental issue of translating an analog, observational understanding of human work into a digital representation that a computer can interpret. Second, there is the equally difficult problem of coming up with words to describe the analog-digital mapping that mean the same things to the engineers, designers, product managers on your team who each use different vocabularies to describe ideas. As the story above illustrates, preserving meaning through one layer of translation is hard enough, and digital product development requires getting past two!
The Solution is Building Models Together
My approach to the translation problem in digital product development is to minimize the stuff that needs to be translated in the first place. I do this by getting my team working together to create a set of 5 shared mental models right from the start:
- Persona Model: who is this for?
- Value Model: why is it useful?
- Interaction Model: how do I use it?
- Object Model: how is it organized?
- Data Model: how is state managed?
I call this framework the Digital Machine and visualize it like this:
I believe that these 5 models always exist as unconscious assumptions in the minds of software project stakeholders. Because unconscious, unshared assumptions are the major source of project confusion, the Digital Machine framework brings clarity and efficiency to stakeholder communication by driving an explicit conversation about the models in people’s minds.
The reason the approach works is because software actually is a machine.
Although built of bits, not bolts, and crafted in code, not cut from steel, software experiences — at least well designed ones — derive their usability from the same source as all machines: a relationship between the operator and the machine where simple inputs are transformed to useful outputs for solving meaningful tasks.
This insight means that while we can’t see or touch the inner workings of digital products, if we imagine them as physical machines we can use the same visual and spatial reasoning skills to design them that we would if they were truly physical. And because spatial reasoning and visual thinking are non-verbal human abilities, models built collaboratively in this way translate easily across different stakeholder points of view!
If we imagine digital product as physical machines we can use the same visual and spatial reasoning methods to design them that we would if they were truly physical.
Now that we’ve established the justification for the Digital Machine, let’s break down the 5 models it contains.
The Persona Model
The persona model describes the person who will use the Digital Machine. The persona is a model of human behavior — it identifies goals, behaviors and emotions. For any given project, this model is best captured as a fictional, but specific, character:
Thomas could be a real person but isn’t, just as a character on a favorite show feels like a real person, even though it is really an actor pretending to be that person. As far as the product team is concerned, a persona is an individual, with a picture, who is referred to by name and treated as a respected member of the project who just happens to miss meetings. The key to making this work is using a picture combined with a name because the models’s power comes from the natural human instinct for empathy.
This empathy instinct is what allows us humans to predict pretty accurately how other human’s will behave so that we can communicate and work with them. For example, if you and I agree today that Thomas’s favorite color is orange, we will both expect, without saying, that tomorrow it will also be orange. Over time, as we continue to discuss Thomas, we will develop a shared understanding about his preferences and expectations, not only for his favorite color, but also with respect to his needs from the digital machine we are building for him. This shared understanding then becomes the test we use, often unconsciously, to measure the value of adding or removing functionality.
The Value Model
With digital products, as with people, you get one chance to make a first impression and the value model captures what you want that impression to be.
It tells the persona:
- What kind of machine is this?
- What will it do to make my life easier (more exciting/more efficient/etc) ?
- Why should I buy/pay attention to/use this particular machine, what is special about it?
The first question — what type of machine is this? — is the highest level filter the persona will use to evaluate your product. Because Thomas is busy, he will very rapidly, and largely by instinct, put your machine in a category and once he does so, every other impression of your product will be made relative to his expectations for this category. First he will decide if you have created a tool for writing, something for editing bitmaps, a game for entertaining oneself at the bus stop, an experience to catch up with friends, or something to analyze data. Once he has decided the category, if that category is interesting to him, Thomas will consider the rest of your value model, otherwise he won’t.
A value model should be expressible as a sentence like this:
This [your machine here] is a category of experiencethat provides me with these benefits(and is better than alternatives for these reasons).
The last clause is rendered inside parenthesis because it may not always be possible to describe the reasons in a way that forms a simple sentence. It is critical, of course, to define these differentiators but often the best way to communicate them to the persona is implicitly through the interaction model (see below).
The paradox of the value model is that it is conceptually the simplest to understand and also the most difficult to define correctly. The challenge comes in creating and maintaining a definition of the value model in terms of value for the persona rather than value for the organization creating the experience for the persona. For the persona, the value has to do with making some task easier, whereas for the organization, the value is to do with something like generating revenue, or addressing a particular mission. The organization’s value is meta while the persona’s value is direct: the organization receives value by being rewarded for producing value for the persona.
The challenge of the value model comes in creating and maintaining a definition in terms of value for the persona rather than value for the organization creating the experience for the persona.
There are two critical steps to resolving the paradox of the value model. The first is to visualize the entire Digital Machine framework as fittings inside a larger business model framework where the value model for a given Digital Machine is just one part of the overall value proposition the organization provides to the customer. The second step for creating a compelling value model is to co-create it using human centered design methods that directly engage individuals who are like the target persona.
The Interaction Model
The interaction model defines how the persona changes the state of the digital machine. One way to think about the interaction model is as a conversation between the human part of the Digital Machine and the algorithmic part. In this conversation,
- an action by the operator to change the machine
- is an input to an algorithm
- which responds by producing output
- that is perceived by the operator as feedback
- that the machine has, in fact, changed.
Because the persona is interacting with the digital machine to accomplish a task, and because interacting with the machine changes its state, then we can say that the purpose of the interaction model is to change the state of the digital machine.
This theoretical way understanding of the interaction model is critical for relating it to the object and data models that we will discuss below, however, it is not the best approach to actually design the interaction model. A far, far better design approach is to think of the interaction model as a story.
Here is an example of the story for buying a book on Amazon:
1. Go to amazon.com
2. Find a book
3. View the details for a book
4. Add the book to my shopping cart
5. Checkout
In each step I interact with the system by inputting text or selecting an item from a list or pressing an action button. In turn the system responds with output in the form of visual feedback confirming it has gotten my input. After each step of the story, the state of the system changes. And at the end of the story, the overall change is that I’ve bought a book — the purpose of the system!
Another name for stories that describe how a person achieves a goal is workflows. This critical insight — that the interaction model for a workflow is a story — works as a powerful design heuristic: if your interaction model can’t be described in a simple, believable story, then you aren’t finished designing it!
Another crucial insight regarding interaction models is that they are actually always nested. We can demonstrate that by expanding our example above:
1. Go to amazon.com
2. Find a book
2.1 Use the search box
2.1.1 Click into the search box
2.1.2 Type some text
2.1.3 See partial matches in the Search Suggestions menu
2.1.3.1 Click on one of the selections offered
2.1.3.2 See a list of search results
2.1.4 Ignore Search Suggestions, press return key
2.2 See a list of search results
2.3 Click on the title of a book
3. View the details for a book
4. Add the book to my shopping cart
5. CheckoutWe see that adding additional detail to the interaction model provides more and more clarity regarding how, exactly, we want the final software to behave. Understanding the interaction model as a set of nested stories enables us to prioritize the stories in terms of the ones that must be in place for a workflow to be complete versus the ones that are useful but not essential.
Because the interaction model tells a story about what the persona does with the software, it is by far the easiest model within the Digital Machine framework for stakeholders to connect with and talk about. The risk — and the place most software projects run into trouble — is focusing too soon and too completely on the interaction model and moving into development without explicitly defining the other models in the Digital Machine upon which the interaction model depends.
The Object Model
So far we’ve talked about the parts of the digital machine that are to do with the user and his experience of the product. The object & data models give us a way to talk about the technical side of the digital machine.
While all the models in the digital machine are important, the object model is most important because it names the “parts” of the machine and how they are related to each other. Let’s clarify this with an example. Imagine that we wanted to build a software game that involved a rider making a bicycle trip. We can begin to design our object model by thinking about the bicycle. Our first insight is that while we could represent all of its parts in software, we only need to include the objects that interact with the rider and the road.
A nice way to do this object analysis is by thinking about the interaction model in story form and identifying the important nouns:
The rider rides the bicycle by sitting on the seat, putting his feet on the pedals and holding the grips. He steers by controlling the inclination and rotation of the grips within a limited range so that gravity does not cause him to fall as he peddles from an origin point to a destination to complete a trip.
Visually, this:
Or, much more compactly, this:
trip
> vehicle
> rider
> bicycle
> grip
> rotation
> inclination
> position
> origin
> destinationThis representation identifies both the objects in the model and their relationships. The idea of nesting that we first identified as characteristic of the interaction model repeats here naturally because the two models are linked. Telling higher resolution interaction model stories involves naming and describing the relationships between more and more precisely defined objects. The opposite is also true: breaking objects down into sub-objects involves telling more detailed stories about how they interact.
The outline representation of the object model is extremely useful but is missing one last piece that we need: a mechanism for capturing state. Addressing this concern brings us to the final model in the Digital Machine framework: the Data Model.
The Data Model
The data model is based on the simple idea — called a name:value pair — that we represent data in terms of the name of a quantity and a value assigned to it. The value is often a number but can be any text. By convention, the name is given first as in the following examples:
x = 3
𝝅 = 3.14
color = green
city = san franciscoThe beauty of name value pairs is that they provide us a way to capture state. Beginning to apply this concept to our bicycle example we can write:
position: {
latitude: ‘37:78’,
longitude: ‘-122.42’
}When used in this way, to define object state, name-value pairs are often referred to as object properties. We can extend this method:
trip = {
vehicle : {
rider : {
name : ‘Thomas’
},
bicycle : {
grip : {
rotation : ‘12’,
inclination : ‘3’
}
},
current_position : {
latitude : ‘37.78’,
longitude : ‘-122.42’
},
},
origin : {
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. It captures individual state for all of the objects in our machine and in so doing, captures state for the entire machine.
Now, we can finally see that all we need to do in order to let the user of our game feel like he is controlling the direction and speed of the bicycle is to translate his input to the game controller into numerical values we can use to update the data model and then translate that state change back into visual updates to the display to provide him feedback.
I find it both humbling and clarifying to realize that all of the design and implementation work I do with my teams really just comes down to enabling a persona to change a few numbers!
Wrapping it up
The Digital Machine is a framework for describing digital products in terms of five models:
- Persona Model: who is this for?
- Value Model: why is it useful?
- Interaction Model: how do I use it?
- Object Model: how is it organized?
- Data Model: how is state managed?
This framework helps project stakeholders through the complicated process of translating human needs into useful products in three ways:
- The communication norms established by the Digital Machine models surface assumptions and provide a way to gauge consensus among the project stakeholders.
- The design process is made more tractable because it can be pursued in a parallel fashion by working on any of the models independently for some of the time and then bringing them all back together to evaluate them holistically as a system.
- Building the models of the Digital Machine together engages the visual and spatial reasoning abilities of the software project stakeholders into developing a shared understanding of how the product works.
If you’ve read this far, you’ve just absorbed quite a bit of design theory. I assure you, however, that for me the application of this approach is not at all theoretical — I use the Digital Machine to great success in my work every day. I speak with my team about models all the time, I draw them on whiteboards, include them in presentations and generally do whatever it takes to make everyone on the project comfortable having conversations about models. While this can feel awkward with a new team the payoff in communication efficiency is nicely expressed by a former boss who said to me “we probably would have gotten our mental models straightened out eventually, but you talking about them all the time got us there a whole lot faster.”
Thanks to Ian Schoen & Raymon Sutedjo-The for their help turning my ideas about models into something folks might enjoy reading. Thanks also to my former students in the Interaction Program at California College of Art who asked the hard questions that caused me to develop the Digital Machine framework as an answer.
References
I did not invent the idea of a digital machine, nor any of the models it contains, though I will take credit (or blame) for the packaging and visualization of the concept found in this essay. For those who want a more complete treatment of the digital machine and its components written by some of the actual inventors, I provide these references.
The Digital Machine
Like most technology, the development of digital machines began in the pursuit of better ways to kill when really smart people were given really hard problems like breaking enemy codes or improving targeting mechanisms for anti-aircraft guns during World War II. An essay in the Atlantic, “As We May Think” (Vannevar Bush, 1945), introduced the idea of machines that think to popular culture. The first scientific description of information as a measurable, mechanical quantity came with The Mathematical Theory of Communication (Shannon, 1948). That is a tough read, though, so despite its intimidating title, I suggest Introduction to Cybernetics (Ross Ashby, 1957) as the best rigorous but at the same time accessible explanation of the Digital Machine.
I want to draw special attention to the Conceptual Models: Core to Good Design (Johnson & Henderson, 2011) because that book directly inspired me to create the Digital Machine framework. I thought the approach in that book was absolutely right on, but would be easier to teach, share and implement as a modular system of models.
Models, Generally
Models as useful simplifications of the world were invented the first time a human drew a picture on a cave wall, but for a much more contemporary explanation of the idea, and particularly how it relates to design, I like Model of Models (Hugh Dubberly, 2009).
Persona Model
The persona model is well established in interaction design practice with a large body of associated case studies, construction methods, and best practices, however, the definitive text on the subject is Cooper, et al, About Face 3: The Essentials of Interface Design.
For a clever experiment demonstrating the connection between personas and empathy read Using Personas in Product Design (Frank Long, 2009).
Value Model
The value model I describe in this essay is meant to be a direct connection to the Value Proposition component of the visual business model framework introduced by Alexander Osterwalder and Yves Pigneur in Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers, 2010.
For instructions on how to get your target persona to help you define the value model, try IDEO’s Human-Centered Design Toolkit: An Open-Source Toolkit To Inspire New Solutions in the Developing World, 2011.
Interaction Model
Creating a compelling interaction narrative collaboratively with a bunch of stakeholders is very hard. An excellent description of a thorough method for attacking this problem is User Story Mapping: Discover the Whole Story, Build the Right Product (Jeff Patton, 2014).
For the general argument around the idea of interaction as a conversation, look at “What is Interaction” (Hugh Dubberly, 2009).
Object Model
The best explanation I’ve seen for the object model and how to build one is “Object-Oriented UX,” by Sophia Voychehovski, 2015.
