Before you understand what a Conceptual Model is, you need to understand what a Mental Model is.
A Mental Model is nothing but a model that you will build into your mind about how a particular thing will look, feel and work.
Suppose I tell you that I am going to show my new web application that will let you to schedule appointments with your clients.
What picture did you draw in your head?
I am sure you would have thought about a Calendar, Contact list, creating an appointment, you getting reminders about an appointment etc.
This is the Mental Model that you have built into your mind.
When I sit down to design this web application, I will have to design it keeping in mind the model you (my user) will build in your mind.
That means, I will have to ensure that my design of the web application should have concepts like managing a Calendar, Contact List, Appointment, Reminder etc.
This design model that I will build to communicate the design of my web application with everyone is called the Conceptual Model.
The Conceptual Model will abstractly explain the function of the web application and what concepts you should be aware of to use the web application.
If my Conceptual Model is very near to your Mental Model, you will find it easy to learn and use my web application.
NOTE: I am discussing Conceptual Model from the perspective of designing a web application but all of this can also be applied to any software application like a desktop or a mobile application.
Conceptual Model is Not User Interface
I know you would be trying to correlate the Conceptual Model with the design of the User Interface.
You should be designing the Conceptual Model right at the start of the design cycle. Even before you have drawn a single of the User Interface.
Design of the User Interface should be done based on the Conceptual Model.
Conceptual Model will not talk about the User Interface of the web application. It will only talk about the concepts within the web application and the relationships between those concepts.
For example, the Appointment Scheduling web application will have concepts like maintaining Calendars, maintaining Appointments, receiving Reminders etc. and how those concepts relate to each other, an Appointment will be created on the Calendar and a Reminder will be sent for the Appointment.
The design of the actual User Interface of the Calendars, Appointments, Reminders etc. can be done later on.
Why You Should Design Conceptual Model
Here are some important reasons why you should design a Conceptual Model.
- Conceptual Model helps to give you a high level overview of the actual workings of the web application.
- Conceptual Model helps you to make your web application match the Mental Model of the user. This makes your application easy to learn and use.
- If you are designing for multiple groups of users then the Conceptual Model helps to take into account the Mental Models of each group. For example, a group of people who have never used an online Appointment Scheduling application before and another group of users who have used Apple’s Calendar application.
- Sometimes you will want the Conceptual Model to be different than the Mental Model of the user. In such cases, designing the Conceptual Model will help to understand how you need to change the Mental Model of the user to match the Conceptual Model. For example, people who have never used an online Appointment Scheduling application will not have an accurate Mental Model of receiving Reminders for the Appointments because the traditional method of organizing Appointments on paper Calendars does not send reminders.
Now that you understand why you should design the Conceptual Model, let us discuss how you can design the Conceptual Model.
Concepts in Conceptual Model
You should always try to have concepts in your web application that the user is familiar with. This will cut down the learning curve and make your web application easy to use.
However it is not always possible to have the same concepts in the web application as what the user is aware of. You will eventually want to build foreign concepts into the web application.
For example, you can introduce the concept of creating Tags on the Appointments so that the user can classify the appointments as Personal, Professional, Customer appointments etc.
The concept of tagging the appointments is a foreign concept to the traditional way of creating appointments. The user’s Mental Model will never have taken this account.
Now the user has to learn this new concept to use it properly.
Keep in mind that if you keep on adding more foreign concepts into your design, the user will have to learn that much more and it will make your web application complex and difficult to use.
When Gmail introduced the concept of Labels instead of Folders for organizing emails it confused many people and still does.
So introduce foreign concepts into your web application only when they are necessary.
But in contrast to this, if the concepts are not foreign, then you can add as many as you need. Its true that the web application will still become complex and difficult to use but since the user is not foreign to these concepts when he starts out using the web application, his Mental Model would have already taken those concepts into account. So the learning curve will not be too steep.
Ultimately what concepts to have and what not to have in the web application comes down to defining the scope of the application.
Tasks in Conceptual Model
You should always keep the Conceptual Model focused on the tasks the users will carry out in the web application.
Those tasks should use the concepts that are familiar to the user. You should avoid having foreign concepts into the tasks as much as possible. Only add the foreign concepts when they add value to the user.
In case of the Appointment Scheduling application, the task of creating an appointment will involve concepts of maintaining the Calendars and Appointments. These are concepts the user is familiar with. But the concept of tagging the Appointments is foreign and should be avoided. Only add the tagging concept if you think your users really need it.
Objects in Conceptual Model
Maintaining Calendars, Appointments, Contact Lists etc. in the Appointment Scheduling application are concepts. The Calendars, Appointments, Contact Lists etc. are the Objects.
Every Conceptual Model will have Objects for performing tasks.
The Conceptual Model should clearly identify those Objects. The users will eventually interact with these Objects while carrying out tasks within the web application.
Other than identifying the Objects, the Conceptual Model should also identify the relationships between these objects. This relationship between the objects can be hierarchical or non-hierarchical.
For example, Personal Calendars and Professional Calendars are types of Calendars or we can say that they are child of the Calendar object. Similarly, Calendars will contain Appointments. This forms the non-hierarchical relationship between the Calendar and the Appointment objects.
Defining such relationships between objects in the Conceptual Model will give you a good idea of how to present these objects to the user in the UI.
Actions and Attributes of the Objects
Every object will have a set of attributes and actions that can be performed on the object.
Start Date, Duration, Attendees etc. are all attributes of the Appointment object. While create, edit, delete etc. are actions that be be performed on the Appointment object.
The Conceptual Model should clearly identify these attributes and actions. Doing this will help you immensely when you sit down to design the actual UI of the web application.
Now, since you have already defined the relationships between objects, you can think of making the actions generic so that they can be used across the different objects.
For example, an action to inactivate a Calendar can be carried out on both Personal as well as Professional Calendars.
Defining the Terminology
Every Conceptual Model should clearly define the standard terminology that will be used within the application to represent the concepts, objects, actions etc.
For example, Appointments should not be called as Meetings. If you are standardizing on the term Appointment then make sure that this same term is used throughout the application. Do not call it as Meetings in one place and Appointments in another.
But if you want to use the term Meetings somewhere, then you need to justify why you want to change the term and how it is different from Appointments.
Defining the terms not only applies to the objects but also to the attributes, actions, help text, hints, messages etc.
Defining the terms early on in the Conceptual Model will help to keep your entire development team on the same page as well as give the users a better user experience.
Defining Use Cases
Once the Conceptual Model is designed, you can write the use cases detailing the scenarios of how the user will interact with the application while carrying out the various tasks within the application.
For the Appointment Scheduling web application example, you can write use cases of how the user will carry out the task of creating an Appointment, Calendar, adding a Contact to the list etc.
Note that the use cases are only detailing how the user will interact with the application and will not be mention the specifics of the UI.
For example, the use case will say that the user will open the Calendar and create an Appointment on the desired date. It will not say that the user will right click inside the Calendar on the desired date and invoke the create action to create an Appointment.
How the task will actually be carried out in the UI should be designed while designing the UI.
Designing the UI from the Conceptual Model
Now, that the Conceptual Model is in place and you have defined the use cases, you can start designing the UI based on the Conceptual Model and the use cases.
From the Conceptual Model you already know the following things:
- The tasks the user can carry out,
- The objects that the user will work with,
- The relationship between the objects,
- The attributes of the objects,
- The actions the user can take on the objects,
- The actions that can be made generic across the objects,
- The terms to be used to refer the objects, attributes, actions etc.
From the use cases you know how the user will interact with the application.
Once you know these things you can now design the UI by turning the abstract concepts, tasks, actions etc. of the Conceptual Model into concrete presentations of UI fields, icons, menus, layouts etc.
You can now re-write the use cases to be more UI specific.
Over To You
Designing web applications that can clearly communicate the design to the user helps to make the web application easy to learn and use.
Designing the Conceptual Model helps you to exactly achieve that.
This step of designing the Conceptual Model becomes even more important if you are designing web applications that are to be used by businesses. This is because every business has it is own concepts and tasks that it works with.
So it is critical that you get this step of the design process done correctly.
