Article summary
A successful software application needs one united conceptual model. But bringing together different mental models and turning them into a cohesive experience is a significant design challenge. Where should the application maintain divergence, and where should it unify similar concepts? Where do we (as a product team) aim to meet expectations, and where do we push for changing the expectations?
A good UX design practice will draw out divergent perspectives and enable the team to do the hard, valuable work of dealing with those different mental models. Let’s take a look at a few ways of playing with mental models that can help with these synthesis and system design activities.
Definitions
- Mental Model – How a person views the world (or a particular slice of it). A person’s mental model is based on their individual knowledge and experience, and it informs their expectations about how something should work. For example, different perceptions about how the internet works could impact the way you need to present errors or phrase instructions in a mobile application.
- Conceptual Model – The way of a piece of software presents its view of the world — the big picture that ties together the smaller features and interactions into something cohesive. The terminology, organization, and interactions within the application contribute to how users experience the system’s conceptual model.
Too Many Mental Models
Have you heard any of these phrases?
- We don’t have the time or budget to build that many features.
- This application is getting confusing.
- This way of presenting the information is weird given how it’s presented elsewhere.
- These users have conflicting expectations; it’s impossible to have it both ways.
- Can’t users already do this via Feature X?
You may be trying to squeeze too many mental models into your application’s conceptual model. It’s time to refine and tighten the conceptual model, simplifying your set of mental models so you can create a strong, coherent application.
Ways to Morph Your Mental Models
Armed with a set of mental models, it’s time for some good, hard thinking. Here are some ways to consider changing mental models to create a better conceptual model.
1. Converge
If you can get two mental models to converge into one concept, that typically results in lower complexity and lower effort to build — both good things.
Sometimes, you can get mental models to converge by directly changing them. Can you change one or more mental models slightly in a way that makes them the same — or close enough that one set of features and one conceptual model can serve both? Maybe one just needs a little terminology tweak, clarification of an action and consequence relationship, or a small shift to make it fit. Small changes can make a big difference.
Alternatively, abstracting a model can be a powerful way to meet multiple needs with one model. A more abstract model can have exceptionally high leverage for a team, providing extended value by being applied to several similarly-shaped problems. For example, you might see mental models like this:
Steve, for Client X
- Fill out schedule
- Notify of schedule five days ahead
- Request participants two days ahead
- Receive participants ahead of time
Abe, for Client Y
- Fill out schedule
- Notify of schedule seven days ahead
- Receive participants ahead of time
Sally, for Client Z
- Fill out schedule
- Request participants two days ahead
- Receive participants on site
A more abstract model could account for all those cases:
For a Client
- Configure client notification preferences
- Fill out schedule
- Notify of schedule a selected number of days ahead
- Request participants a selected number of days ahead (optional)
- Receive participants (either ahead of time or on site)
Abstracting the model isn’t always the right solution, but it is one of my go-to methods for building more valuable software.
2. Diverge
Is a mental model asking a feature to do something it wasn’t intended to do? Are you seeing confusion or excess complexity? You might need to create separate spaces in the conceptual model for different ideas to grow and diverge.
Start by trying to change terminology, relationships, interactions, expectations, etc. until the people most familiar with each mental model feel comfortable with the result.
Sometimes making a model more concrete (less abstract) can be helpful. Abstract models are powerful but can make it difficult for users to understand how to apply them and can, therefore, require more work. Even in the simple example above, there is an extra configuration step added to the model.
The added work and complexity are worthwhile sometimes, but not always. Take command-line tools, for example. The core set are very generic (e.g., cat
to list the contents of a file, grep
to find text, the pipe operator to send the output of one command to the input of another). They can be combined to do some very powerful things, but it takes experience and time to figure out the right way to string them together.
3. Extend
What if we take the terminology and expectations from an existing mental model and add a little something extra? Adding to an existing mental model can be a great way to expand its value while remaining anchored in the familiar.
This happens all the time when new features are added to existing products. For example, when Facebook added Marketplace, they didn’t change the rest of Facebook to make it happen. Most of Facebook remained the same, but now there was an additional Marketplace space where some different activities could take place.
4. Reduce
Removing parts of a mental model can help simplify areas where there is too much going on. For example, consider a registration system where people expect to be able to:
- Register for the event
- Get a reminder for the event
- Cancel a registration
- Transfer a registration
It’s worth asking some questions. Is transferring valuable enough to warrant its place? Could the user rely on their own calendar for a reminder? If registrations are non-refundable, what’s the value of canceling?
5. Eliminate
The easiest way to reduce the complexity of the conceptual model and system is to ask, “What if we didn’t support this way of thinking?” It doesn’t have to be a permanent elimination; just defer long enough that you don’t need to take it into account right now.
6. Add
You can also add an entirely new mental model to the working set — perhaps a standard approach that your users are unfamiliar with or an imaginative new way of thinking about the problem.
Games are a good example here. They often introduce fictional concepts that don’t have any basis in reality, so it’s hard to have a preconceived mental model of how they should work. This is why games have tutorials and why they walk users through a progressive reveal of the game’s mechanics — it’s hard to learn it all at once.
In Context
Mediating between users’ mental models and the system’s conceptual model is important design work, and it shouldn’t happen as an isolated activity. It should be part of a larger practice of design, planning, communicating, and delivering software in a way that supports users. As long as work is happening on the software, the conceptual model is changing.
I hope these ways of morphing the mental models your team has gathered will help you generate creative solutions.