How system modelling can make better software
Something we’ve been talking about quite a lot on recent projects at Auto Trader is the underlying models of parts of our product. Thinking in models is especially useful when the implementation of a system is simultaneously also being designed, but it’s also valuable to understand the ways in which an existing system can be represented to users.
I’m going to use three terms in this post. While there are similar words used in a number of ways, this is what I mean by them:
Implementation model — the actual way in which the system is implemented in code. Especially important for design are the objects, relationships between objects, status transitions, and data structures.
Representational/conceptual model — the way the concepts in the system are represented to users, generally through the UI but potentially also through other interactions people have with the system. These are the things that users can see, the things they can do (and can’t do) and processes they go through.
Mental model — the internal model that people have about how something works. This is likely formed from their previous experiences of real-world situations and other technological processes, and the conclusions they’ve drawn from those experiences.
In general, systems work best when the implementation model matches the representational model, which matches the users’ mental model. A breakdown at any one of these steps can cause problems.
Mismatches make mayhem
Implementation model doesn’t match representational model
For example, imagine an implementation model where user accounts are identified by their email address, and can’t be deleted (for auditing purposes) but can be archived.
If the representational model (the UI) provides a delete action against a user, but then trying to create a new user with the same email address results in an error message, then we’ll have a usability problem.
Representational model doesn’t match mental model
A few years ago, the dominant mental model for sending and receiving messages remained postal messages — one distinct message is sent, another distinct message is received in reply, and so on. Representational models that attempted to glue these altogether in a “conversation” were at odds with people’s mental modal of sending and receiving messages, and were initially confusing for users to understand.
Implementation model doesn’t match mental model
One of the most classic examples of a mismatch between implementation and mental models is home thermostats. A common mental model is that setting a higher temperature makes the house get hot more quickly. For example, it’s 16° in the house and you want it to be 20°. To get it there as fast as possible, you set the thermostat to 25°.
The implementation model in this case is that the heating comes on when the temperature is less than the target, and goes off when the temperature is reached: an on/off switch. So setting the temperature higher makes no difference — except that the heating will overshoot and make the house too hot.
Discovering mental models
The key to discovering what mental models users have is user research. By understanding how people view their world and make sense of it, you can uncover the models they have for how things work.
In many cases, their model will be based on other things that they perceive as similar, and the fact that people spend the vast majority of their time using things that aren’t yours is one of the main reasons why using common patterns and being consistent with other products is so effective in making your own products more usable.
Taking an object-oriented approach to design
For many products, taking an object-oriented approach to design can help enormously with:
- mapping the model you have (or want to have)
- discussing the target model with others and influencing the implementation model
- designing the representational elements you need to reflect the model, and
- extending your product over time
There are three main parts to thinking about your product in an object-oriented way:
- What are the objects (the things)?
- What are the attributes of the objects?
- What can you do with the objects?
So, for example, if we were creating a simple social media product, we might have:
Object: Post
Attributes: Text; pictures; links
Actions: Like; reply
We would also have someone who was creating the post, so there might be:
Object: User
Attributes: Name; photo
Actions: Edit; delete
We might expect that the post object links to exactly one user, with a user linked to somewhere between zero and many posts.
Even at this massively simple level we can see that this thought process lets us:
- Talk with our developer teammates about whether this is the model they intend to implement. (For example, if they were thinking that posts weren’t associated with a user, that would have a big impact on our ability to create a representational model where they were)
- Start to model out potential UI. For example:
- Create a user (with name, photo)
- View user (with name, photo, edit and delete actions)
- Create a post (as an identified user, add text, pictures, and links)
- View posts (with a linked user & photo, seeing text, pictures and links, and actions to like or reply)
3. Easily see how to extend this system. For example, if users expect to add a bio, or be able to delete posts, we can see where it fits.
There are a number of detailed articles with resources on how to approach design with an object oriented mindset, including What is object oriented UX? and Object-Oriented UX.
Make models match
An important part of making products learnable, usable, and extensible over time is understanding and being able to explain the models of the underlying system, the models being represented through interactions with the system, and the mental models that users currently have about how things work.
As a designer, you have control or influence over all three — modelling them out and minimising the differences between them will help you design, build, and maintain products that “just work”.
