Eliciting People’s Conceptual Models of Activities and Systems

Introduction

If there is poor conceptual fit between users and the systems that they work with, users are forced to “translate” between concepts that may only be meaningful to system developers and ones that are meaningful to themselves. This imposes additional workload on the user (Payne et al., 1990). The focus of this paper is on techniques for eliciting people’s conceptual models as a stage in the process of designing or evaluating interactive systems.

Cooke (1999) defines a conceptual structure as comprising “domain-related concepts and their interrelations”, while Johnson and Henderson (2011) define a conceptual model as comprising the target task domain; the concepts the application presents to users; the relationships between those concepts; and the mapping between task-domain concepts and application concepts. This definition makes it explicit that task-domain concepts and application concepts may not always be identical. In this paper, we focus on what Cooke calls “domain-related concepts”, and Johnson and Henderson refer to as “task-domain concepts” – i.e., the concepts users are working with when performing a real-world activity.

These concepts may include what Johnson and Henderson (2011) refer to as “application concepts”, and that we call “system concepts”, because the way users think about their activity is often shaped by the systems they use, as discussed in more detail below. Sometimes, this is unavoidable, and presents few problems to users. However, when people have to expend effort on “translating” between domain concepts and system concepts, we refer to these as “misfits” between the user’s model and that implemented in the system. Misfits typically indicate usability difficulties, and may also represent new design opportunities, highlighting possibilities for systems that better fit the users’ needs (Blandford et al., 2008a). This approach of focusing on concepts complements most traditional methods for designing and evaluating interactive systems, which typically focus on task structures and processes rather than concepts (Blandford et al., 2008b).

People’s conceptual models that they bring to an interaction are based on their prior experience, both of performing the activity (“doing work”, or the leisure equivalent) and of using analogous systems. To take a very simple example: someone using a shower will typically think of their requirements in terms of the temperature (too hot / too cold / just right) and the pressure (too forceful / too feeble / just right) of the water. Earlier generations of taps and showers forced the user to work separately with the force of hot water and of cold water, engaging directly with the underlying “system model” of separate hot and cold water supplies being delivered and mixed together (Figure 1a). Prior experience with such taps means that people can quickly work out how to use new showers they encounter that are based on this model. However, such showers can be difficult to control well. More modern shower controls that allow the user to control temperature and pressure independently are typically easier to work with: this interaction better matches the user’s conceptual model, even when, as illustrated in Figure 1b, the controls have an old-fashioned appearance.

Figure 1.

Shower taps that (a) directly reflect the underlying system model and (b) better match the user’s conceptual model

Background

Many traditional approaches to the design and evaluation of interactive systems have focused on task structures – i.e., on understanding how people structure tasks in terms of sub-tasks and procedures (e.g. Card, Moran & Newell, 1983) and on the design of task structures for interactive systems (e.g. Hackos & Redish, 1998). Task structures have an important role to play in the design and evaluation of interactive systems, but can be difficult to manage when tasks are ill-structured or highly complex. Even a task as superficially simple as running a shower of the desired temperature and pressure can be surprisingly challenging to describe in terms of task structure. For example, using hot and cold taps (Figure 1a), the task structure might be: