When designing interactive systems, it behooves you to define a conceptual model before you start thinking about the user interface. A great resource to learn to do this is Austin Henderson and Jeff Johnson’s Conceptual Models: Core to Good Design. In this book, they describe the system’s conceptual model in terms of “how the user would ideally think about the application and its use in supporting tasks.”
This requires you first understand the tasks (and “task domains”) the system is meant to accommodate. As you analyze the ways users understand tasks, you can define what (conceptual) objects the system must present to help users accomplish those tasks. These objects have certain attributes that are essential to their roles in the system, and they allow users to carry out particular operations that help them accomplish their tasks.
The book includes the following example, which defines a conceptual model for a simple office calendar application:
| Calendar | owner, current focus | examine, print, create, add event, delete event |
| Event | name, description, date, time, duration, location, repeat, type (e.g., meeting) | examine, print, edit (attributes) |
| To-Do item | name, description, deadline, priority, status | view, print, edit (attributes) |
| Person | name, job-description, office, phone | send email, view details |
It’s obvious why it’s useful to define such a structure before you design a user interface: a conceptual model gives you a high-level picture of the system’s user-facing components. Rather than adding affordances for features piecemeal, here you have the opportunity to think about them as a whole. This allows you to think holistically about the system’s interaction mechanisms and language. Having such a conceptual model before working on the UI saves a lot of headaches and leads to a much more coherent experience.
However, there’s another good reason to start by defining a conceptual model: doing so allows you to better understand opportunities for leveraging data that may go unacknowledged when you begin by sketching out screen-level artifacts. Thinking about the conceptual objects in the system, their attributes, and the actions they accommodate helps surface opportunities inherent in the data these objects, attributes, and actions require and generate.
For example, when interacting the model above, the user will generate data points. Adding an event to a calendar is an action that will be captured by the system. We know events include a “type” attribute, so over time, this system will have data about various types of events. We can use this data to spot usage patterns and predict behavior, information we can use for the benefit of users and the business.
While conceptual models focus on user-facing concepts, defining them upfront also sheds light on these “invisible” aspects of the system. Doing so allows you to spot opportunities for improvement that may otherwise become apparent only further down the line (or not at all.)