Relationships Between Concepts
Enumerating the objects and actions of the task-domain allows designers to notice actions that are shared among objects. Designers can then use the same user interface for actions across a variety of objects. For example, consider a drawing application that allows users to manipulate both rectangles and ellipses. If creation works the same way for both types of
objects, when a user knows how to create a rectangle and wants to create an oval, they already know how to do it. Similarly, if users can constrain rectangles to be squares they should also be able to constrain ellipses to be circles. This makes for a conceptual model that has fewer distinct concepts, is simpler and more coherent, and is more easily mastered.
If objects in a task-domain share actions, they can probably be organized in a specialization or type hierarchy, in which certain  conceptual objects are specializations of others. If so, making that hierarchy explicit in the conceptual model may help users comprehend it more easily. While only programmers understand object-oriented analysis, most users can understand the idea of specialization. For example, a checking account is a type of bank account, and a book is one type of product or
item a store might sell.
Depending on the application, objects may also be related by a containment hierarchy, in which some objects can contain other objects. For example, an email folder contains email messages, and an organization can contain employees.
Finally, concepts in a task-domain are related to each other in importance. Some concepts are encountered by users more frequently than others. For example, closing a checking account is an infrequent operation compared to, say, entering a transaction into an account. The relative importance can be used to focus the design: It is more important to make frequent operations easy, even at the expense of less frequent ones.