A Working Example of a Conceptual Model
An Object/Action Analysis
Conceptual models are all about representation. And the way something is represented is important, both when understanding something, and when creating something. When attempting to understand a thing, we try to make sure our conceptual models aren’t faulty, so we practice logic and critical thinking. Else, biases or fallacious thoughts may steer us in a wrong direction while we experience a discussion with somebody, and miscommunications may happen, and/or the discussion is derailed. Likewise, in an early phase of building a product, we flesh out our conceptual model of that product, so as to not be steered in a wrong direction. We avoid adding unneeded features early. We explicate the most essential features and stay focused on them, that way we can get a clear picture of the relationships between our objects and their functionalities, if multiple actions in an app can use the same functionality.
Defining a conceptual model early will inform UI design in a way that avoids redundancy and it can keep people on track, so they don’t design and implement unneeded features. And when the design phase starts, it will be more efficient. Prototyping can begin earlier.
Below is an example of a hypothetical Object/Action analysis before designing an email system. I am posting this because there are not a great number of examples online for this kind of thing. This example will consist of a first version and a final version; in our first versions of these models, it is very easy to add excessive features and to needlessly complicate things. For this reason, as with most works, it is often necessary to go back and revise. Cut. Cut. Cut. Until the conceptual model is as simple as can be and represents the absolute bare-bones of the application you have in mind, trim all excess.
First Draft (Flawed):
| Objects | Attributes | Operations |
|---|---|---|
| Mailbox | Owner, Current Focus, Inbox, Starred, Sent, Draft, Spam, Trash | Examine, Compose, Delete, Mark as Read, Search, Archive |
| Mail Message | Sender, Recipient, Date, Subject, Content, Attachment Description (if any) | Compose, Delete, Print, Reply, Forward, Report, Block |
As noted, the first version is often flawed, and should be iterated on. The second table illustrates edits that were made to the first table.
Final Draft:
| Objects | Attributes | Operations |
|---|---|---|
| Mailbox | User, Current Focus, |
Examine, |
| Message | ||
| User | Name, Address | Examine, Message, Add, Remove |
Mailbox:
For Attributes, I’ve crossed out Inbox, Starred, Sent, Draft, Spam, and Trash because they are not fundamental to the object and operations. I also replaced ‘Owner’ with ‘User’ as it interacts better with the Mail Message object (describing creator and receiver of messages). I also added Mail Message because they are contained (fundamentally) within the mailbox. I’ve added Organize to the operations because it is a verb that summarizes multiple actions: Delete is organizing into a Trashcan, Archiving is organizing, and placing into Spam and Drafts are also both organizing actions. I removed Compose because it is not essential to the mailbox itself; I only considered it an operation because there is a compose button in the CatMail interface, in other words, because of an implementation.
Mail Message (to be concise):
For attributes, I’ve removed Sender and Recipient and replaced both with User. For Operations, I removed Compose, Reply, and Forward; Send is an operation that condenses all of these actions, that isn’t implementation-based. Forward and Block were removed because they do not have a fundamental link to messages.
User:
For attributes, I’ve added Name and Address because they are user properties. For operations, I added Examine, Message, Add, and Delete because these simple terms can represent addition to lists (like report or block, reply list, forward list, etc.), and users are obviously attached to messages (and the mailbox is owned by the user, too).