One of the central tasks of any UX designer is to create the interaction model. The interaction model is the overarching framework that ties the functionality together into a unified whole. Done right, the interaction model can be a major product differentiator; even if individual features are replicated, it may be difficult (although certainly not impossible) to reproduce the interaction model that ties all the features together.
Interaction models usually contain the following pieces:
- how to launch or close pieces of functionality
- how to navigate between pieces of functionality
- transitions between pieces of functionality
- how pieces of functionality interact with each other
- sort, manage, and find files or data
In short, interaction models are the means to access and move between functions. Interaction models can be overarching to include the entire device, or they can be contained within a single application or feature.
The desktop metaphor is probably the most famous interaction model. You know how to launch applications, close them, navigate through folders, etc. Over time, pieces have been added to it, like OSX’s Dock or Windows’ Task Bar, but the model has remained remarkably consistent for 30+ years now.
The purpose of an interaction model is to create a logical consistency throughout the product, so that users can determine how to do something and route around any tricky situations. “I’m going to click on this because in other places, this worked.” The device needs to make sense, to have a flow that can be understood. Interaction models create the glue that holds a device together; a box that holds all the functionality.
If we consider what interaction models really are, we begin to realize that they are nothing less than the designer’s attempt to help the user generate a mental model of the device. Mental models are the cognitive method of understanding a device that may or may not be how the device actually works, but allows the user to interact with it. For example, I don’t understand how a car engine works, but I have a mental model in my head of how it does: I steer and push various pedals to make it go forward and stop. We likely create mental models of all sorts of things in the world: everything from governments to games. We create representations of external realities and from them derive understanding. Our mental model can be wrong, of course, and that can cause confusion and worse problems.
What then, makes up an interaction model? Metaphors, for one thing. THIS works like THAT. “Your computer works like your desktop.” With products that have abstract digital behavior, applying a metaphor can make the product more physical, and thus more understandable. A folder is more physical than a directory.
Structure is also a key component in any interaction model: how the functions of a device are positioned in relation to one another. Sometimes this is a matter of information architecture: arranging pieces into a findable information structure, such as into menus and hierarchies. Other times, this is interface or industrial design: grouping controls into a panel that makes sense. It can also be an interaction design task: how do the different panels or windows in an application interact with each other? What are the device defaults, and what can users change?
On physical devices with digital behaviors, interaction models are tied to the device’s functional cartography. Functional cartography is the mapping of features and functions to a device in order to determine which functions are controlled by physical means (mechanical controls), digital means (onscreen controls, sensors), or both. Once the interaction model has been determined, the functional cartography should spring from it.
A through-line is another component of a good interaction model. A through-line is figuring out the likely pathways through the device. A user will do A, then B, then C. Any model should work really well for that A-B-C pathway. A through-line acts as the rhythm section for a rock band does: it shows where the emphasis should be placed and keeps the tasks moving forward.
An interaction model has to fit the product’s major functions, and these can be used as a type of test for any proposed model. “How would this tiling of the screens work with email?” In fact, if an interaction model doesn’t work with any of the major pieces of functionality, it simply might not be the right model. Lesser pieces of functionality can, with some work, often be conformed into fitting into the framework, but everything important should seem “native” to the device: like the device was made to perform those actions. Which, of course, it should be.
The best interaction models are either nearly invisible (that is, they do not get in the way of using the functionality), or else they are extremely pleasing in and of themselves. Transitions and navigation can be done in a manner that is not just a humdrum menu and one screen simply appearing. Think of the many transitions an iPhone or Android phone has between applications.
A device without an interaction model will likely seem disjointed and made up of pieces, instead of as a whole. Pieces of functionality will work differently and the overall concept will be hard to grasp. Many mobile phones, appliances, and consumer electronics suffer from this problem. A solid interaction model is the basis for any great product.
Originally published on Designing Devices in 2010.