User Conceptual Modeling

“Flying is done largely with one’s imagination! If one’s images of the airplane are correct, one’s behaviour in the airplane will quite naturally and effortlessly also be correct.”

Wolfgang Langewiesche (1907–2002) ‘Stick and Rudder: An Explanation of the Art of Flying’ 1944*

1         Introduction

The user’s mental model of a system (the information about it that they hold inside their head) should contain sufficient detailed information to enable the user to operate it successfully. There are obviously issues about how this model gets into the head of the user, and of how to determine just what it should contain. The development of a user conceptual model explicitly addresses the second of these issues, and will support in addressing the first. It does this by giving a method to analyse the collected task scenarios to identify the things the user must find represented in the system and the actions they must be able to apply to them.

The purpose of deriving and documenting the users’ concept model is primarily to provide input to the initial interface design, but it can also assist in creating help and training materials. To assist interface design it is important that only a minimal conceptual model is derived; the model should contain all of the task domain elements required to execute the users’ tasks, but no more. Irrelevant elements introduced into the interface may confuse the user and cause errors.

The authoritative source for what elements to include in the conceptual model is the set of task scenarios that have been developed for tasks involving a particular user class. Different users of a system may need different conceptual models and different interfaces. The task scenarios should contain an accurate description of how the user would expect to perform their tasks and this will have been confirmed by representative users and/or other stakeholders. All of the necessary task domain elements that the user must know about are contained in the scenarios; they must be identified and presented in a systematic way.

A conceptual model is created for each user group by derivation from associated task scenarios. It contains information on:

  • The task domain entities (things, objects) that are represented by data in the computer
  • Any physical artefacts (documents, other systems) that are involved in the tasks (and may also be represented by data)
  • The attributes of these entities and artefacts, i.e., the characteristics that distinguish them, recorded as the names and types of data items
  • The actions the user can initiate on each entity and artefact
  • The significant relationships that pre-exist or are created by operation of the system

In addition to the static aspects of the system described above, for some systems exhibiting particular complexity it is also necessary to capture their dynamic aspects. How to do this is the subject of another method document. The task domain entitles’ information can be presented as text but is often more useful in diagrammatic form, in which case the standard software engineering diagrammatic notation, the Universal Modelling Language (UML), particularly the Static Relationship Model can be used. However it must be born in mind is that it is the users’ understanding of the system that is being captured. To software developers, the user conceptual model many appear naive and overly simplistic, however the model must not be elaborated beyond what is contained in the task scenarios.

2         Method

The method describe here is based on that presented in Redmond-Pyle & Moore [1995]. The task of deriving a user conceptual module proceeds through four stages:

  1. Marking up scenario text to identify task domain objects, attributes and actions
  2. Associating objects and actions in a systematic textual description
  3. Generating a diagram to include significant explicit and implied relations between task domain objects
  4. Verification of the model by users representatives and other stakeholders

2.1         Mark up scenarios

This involves a simple linguistic analysis of the scenario text, identifying relevant parts of speech that indicate potentially significant entities. These are:

  • Nouns (naming words): putative task domain objects or attributes
  • Verbs (action words): putative user actions on task domain objects

This can be done with paper and highlighters or using a word processor. Work through the scenario text sentence by sentence, highlighting nouns in one colour and verbs in another.

2.2.1         Example

An example marked up task-scenario fragment is given below. Nouns and verbs are highlighted thus.

The customer browses through the stock items available.

They identify a 1 litre aerosol can of boiler paint, stock code PA0094 and place it in their shopping-basket.

The description of the item names it, and can be replaced with the more general noun ‘item’.

They only require one item on this occasion and so go to the check-out to pay and arrange delivery.

The contents of their shopping-basket are presented for confirmation:

Code: PA0094

Item: 1 litre aerosol, boiler paint

Price: £5.47

Quantity: 1

Item Total: £5.47

Order VAT: £1.09

Delivery: £3.45

Order Total: £10.01

2.2         Associate objects and actions in a systematic textual description

The objective is to associate unambiguously the actions that the user carries out with the task domain objects that they are applied to. In the text this may not always be clear. The objects may be referred to by pronouns (e.g. ‘it’) and other contextually interpreted parts of speech may be used (e.g. “Move it here.”). Different words may be used for the same entity: e.g. the verbs ‘move’ and ‘place’, and nouns ‘part’ and ‘component’ may be used interchangeably, so “move the part to the shopping-cart” and “place the component in the shopping-trolley” may mean the same thing. A decision must be made to use one word consistently, ideally the word that the users would naturally use.

Note that we are only interested here in the actions that the user carries out, i.e. not actions of the system or other agent. Also the objects identified should be task domain but not interface domain ones (e.g., buttons, links, tabs, etc.). If the task scenarios have been written properly then reference to the (yet to be designed) interface should not occur.

A simple notation based on that used in object-oriented programming languages (‘dot notation’) can be used. An action that may be applied to an object is expressed as:


E.g. from the example above:

i. Part.place_in_shopping-trolley

Note that:

ii. Shopping-trolley.place_part_in

will almost certainly be incorrect. The action is immediately applied to the specific entity represented by ‘Part’ of which there may be many, whilst there is likely to be only one shopping-trolley (for this user). In ii. the specificity of the particular part is lost, and anyway that is not how shopping-trolleys work in the real world.

Clearly disambiguating these details requires some understanding of the context of the task scenario being worked on. Associating objects and actions in a number of different ways may each be legitimate in particular cases. So expect to go through the object/action descriptions a number of times to iron out inconsistencies.

It is useful to use a word-processor for this task, placing the scenario text in the left column of a two column table and the interpretation of each line in the right column. Using a word-processor also facilitates sorting the object/action descriptions alphabetically to group objects’ actions together and eliminating duplicates.

Where nouns have been used to distinguish particular instances of objects but have not had actions applied to them, e.g., in “Place the part with code ‘A24’ in the shopping-trolley.”, then ‘code’ is an attribute of ‘part’. Attributes should be listed against the object that they apply to.

2.2.1         Example

An example task-scenario fragment is given below, comments are italicised.

The customer browses through the stock items available.

Customer.browse OR Stock.browse

Both descriptions are possible. However it is the actions of the customer (as user) on task domain objects, not on themselves, that we are interested in.

They identify a 1 litre aerosol can of boiler paint, stock code PA0094 and place it in their shopping-basket.


Item.place_in_shopping_basket OR Shopping-basket.place_in_item

As discussed above.

They only require one item on this occasion and so go to the check-out to pay and arrange delivery.


This describes a user’s goal, but not an action on something in the system.

Check-out.arrange_delivery OR


Should ‘delivery’ be treated as an object? More information is needed. A ‘delivery note’ may be produced.

The contents of their shopping-basket are presented for confirmation:

Code: PA0094

Description: 1 litre aerosol, boiler paint

Price: £5.47, Quantity: 1

Item Total: £5.47, Order VAT: £1.09

Delivery: £3.45, Order Total: £10.01


Attributes of Item:

Code, Description, Price

Attributes of Shopping-basket:

Order_VAT, Delivery, Order_total

For each Item:

Quantity, Item_Total

As can be seen from this brief example, the process of creating object.action descriptions is not straightforward and several iterations may be required.

2.3         Generate diagram

The listing of objects with their associated attributes and actions already constitutes documentation of a user’s conceptual model. However there are more details that it is useful to record. These are the relations that hold between the task domain objects in the system, the raison d êtrefor the system being designed; to enable the relations between objects represented as data in the system to be changed. In the shopping example, to create the relation between ‘customer’ and ‘stock-item’ of ‘purchased’. Whilst these relations could simply be listed as text, it is usually clearer to show them in a diagram and the UML Static Structure diagram notation has been created specifically for this purpose.

The basic elements of the UML Static Structure diagram are:


  • Named
  • Attributes (-)
  • Actions (+)
Association Relation

  • Labelled in each direction
  • Show arity (number of objects allowed at each end)
Composite Relation

  • Object at head is made of objects at the tail.
  • Head does not exist without tail.
Aggregation Relation

  • Object at head uses objects at tail.
  • Objects may exist independently
Inheritance Relation

  • Object at tail is a more specialised version of object at head.
  • Attributes Actions and Relations are inherited.

Microsoft® Visio® has templates to support UML diagramming and other tools are available.

2.3.1         Example

Here is an example fragment from a shopping scenario model.

A Customer must use one and only one shopping-trolley per visit:

  • Customer and Shopping-trolley are linked by the relation ‘Used by/Uses’
  • The arity at the Shopping-trolley end is ‘1’

At any particular time a shopping-trolley may be unused, or used by a maximum of 1 customer:

  • The arity at the customer end is ‘0..1’ (read as ‘zero to one’).

The Stock of the shop is made up of at least one Item:

  • Stock and Item are linked by the composite relation
  • The arity at the Item end is ‘1..*’ (read as ‘one to many’); when the shop has sold the last item it has no stock!

Items may be put in the Shopping-trolley:

  • Shopping-trolley and Item are linked by the relation ‘Put in/Contains’
  • The arity at the Item end is ‘0..*’ (read as ‘zero to many’)

A particular Item may be put into only one Shopping-trolley at a time:

  • The arity at the Shopping-trolley end is ‘1’.

Items are of one of two types, VAT rated and VAT exempt:

  • Item is linked to VAT_rated_item and VAT_exempt_item by the inheritance relation
  • An alternative way of modelling this is to give Item an attribute to record VAT status. Choosing between these approaches will be determined by how differently VAT rated and exempt Items are treated in the full set of scenarios; if very differently then the inheritance approach may be better.

Note that it would have been legitimate to put an association relation between Customer and Item, perhaps labelled ‘Put in by/Put in to’ to record that a particular item was put in the shopping-trolley by a particular customer. However this is already implied by the association relation between Customer and Shopping-trolley. Actually relations can be identified between any two objects in the model (e.g. between Customer and Stock to indicate that the customer chooses from the stock) so the model could become much cluttered. To avoid this, only relations that are necessary (explicitly referred to or implied in the task scenarios) should be included.

3         Additional sources of information

If the system being designed will contain a database then a data model will at some point be created and normalised for implementation, often presented as an ‘entity relationship diagram’. There will be similarities between the data model and the user conceptual model in the naming of records and fields verses objects and attributes. However there will also be significant differences. The data model, particularly if it has been normalised, may contain many more entities than the conceptual model. There may also be fields that do not appear in the conceptual model as attributes. This does not mean that the user conceptual model is incorrect; there may be much more going on inside the computer system than the user needs to be aware of. However, if a necessarily very different database design (perhaps due to technology or implementation constraints) is going to ‘show through’ the interface to the user, then a modified user conceptual model may be required, and a training requirement has been identified.

If the difference is more to do with the nomenclature used in the different models, with the same entity being named very differently, then this may indicate a problem with the systems analysis – or a misunderstanding on the interaction designer’s part, so investigate further. In any case it is generally a good thing to be consistent in naming entities between the real world and their data representation.

3.1         Glossary

Each task domain has words and phrases that are peculiar to it, and may use common terms in very particular ways. To ensure that these are used appropriately and consistently in the user interface a glossary may used to collect these words and phrases as they are discovered and set down their particular usage and meaning. This is an important by-product of modelling the user conceptual model.

A Microsoft® Word template for the Glossary Document is available in the folder containing this document.

4         Appropriate use of this method

It will be clear that a rigorous application of the method described here is quite labour intensive. Should it be used in full on all interaction design projects? The answer has to be, “it depends”. If the project relates to a complex and novel safety critical or high value process, then the benefit of creating detailed user conceptual models is likely to be high. In a small project for a simple, routine and well understood process it may not be necessary. For projects falling between these extremes a more considered decision must be made. It may be appropriate to short-cut the process by directly creating a UML diagram or other representation. However, designers taking short cuts should be very aware of the dangers for the overall design. In this case the danger is of overcomplicating the model, or of missing crucial elements.

An alternative and very succinct description of this technique is given by Johnson & Henderson (2013).

An additional simple example (interaction with a lift) is available here.

5         References

BS EN ISO 13407:1999 The Human-centred design process for interactive systems.

BS ISO/IEC 19501:2005 Information technology — Open Distributed Processing — Unified Modeling Language (UML) — Version 1.4.2

Johnson, J. & Henderson, A. (2013) Conceptual Models in a Nutshell, Boxes and Arrows, [viewed 2nd February 2016]

Redmond-Pyle, D. & Moore, A. (1995) Graphical User Interface Design and Evaluation (GUIDE): A Practical Process, Prentice-Hall.

*A stunning illustration of this observation, and one involving human-computer interfaces in the cockpit, is the Vanity Fair article, The Human Factor, by William Langewiesche (who happens to be the son of Wolfgang Langewiesche) analysing the 2009 crash of Air France Flight 447:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s