We report a case study in which conceptual design was applied to create a user interface of an innovative software tool. The Session Directory Tool (sdr) allows users to set up and participate in real-time interactive multimedia events on the Internet. To make this functionality available to users who are not familiar with the underlying network technology and videoconferencing, we identified a metaphor which could be extended into a design model (Electronic TV Listings Guide), and communicated this model through linguistic and structural features of the user interface. Evaluation results indicate that this effort was largely successful: new users handled sdr competently after a short training session and 5 days’ practise, and articulated their knowledge of the tool in terms related to the design model. The case study demonstrates the potential of conceptual design, integrated with tangible HCI design techniques, for developing user interfaces to innovative technology.

conceptual design, mental models, users’ models, Internet conferencing

Over the past 5 years, the Internet has developed from a research network - used mainly by academic researchers to transfer files - into a global network used by the general public. Thanks to innovations in network and compression technology, parts of the network are now capable of supporting interactive real-time multimedia traffic. Users can watch remote broadcasts, hold meetings or job interviews, and even stage remote parties, concerts and arts events - provided they know how to set up and join such events. Software tools have been developed to support these activities, but they assume technical knowledge of networking and multimedia. The challenge is to make this technology available to users who not only lack detailed knowledge of the underlying technology, but also have no conception of a real-world task which the tool supports. This paper reports on an attempt to apply conceptual design to create a user interface which facilitates access to this novel technology.

Conceptual design as proposed by Norman (1986) is based on the assumption that users construct internalised users’ models (often referred to as mental models) of computer systems, and that appropriate users’ models result in successful user-system interaction. Users’ models are formed as a result of user-system interaction, but can also be influenced by instruction. The process of conceptual design starts with the construction of a design model: an accurate, consistent and complete representation of system functionality. The design model is communicated through the user interface (or system image). If this process is successful, users interacting with the system should develop an appropriate users’ model (see Figure 1). This process seems straightforward enough. Conceptual design is included in all modern HCI textbooks, and research publications on this topic reflect a general consensus that users’ models exist and are important for successful user-system interaction. Yet, there is a dearth of reported cases in which conceptual design has been successfully applied to the design of user interfaces.

Tognazzini (1991), an eminent user interface designer who subscribes to the idea of conceptual design, reports from experience that formulating a design model and communicating it through the system image, does not necessarily result in the user’s model and user behaviour intended by the designer. Firstly, other factors (mainly users’ previous knowledge and experience) influence the model-building process. Secondly, constructing a "good" design model and communicating it through the user interface is not necessarily a straightforward process. Norman (1986) suggests that

The notion of grounding the design in the user’s task is central to conceptual design. HCI has produced a number of techniques for analysing and representing users’ tasks, but it is not clear how a designer can turn the output into a design model. Due to the lack of guidance as to how users’ tasks should be analysed and represented, it is often the designer’s model of the user’s task, rather then the user’s model of the task, on which the design model is based.

Early HCI literature (e.g. Carroll & Carrithers, 1984) often argued that users are experts at the real-world tasks they are trying to complete (and should not be expected to be experts in electronics and programming as well). Assuming that users have a "perfect" model of the real-world tasks may, however, provide an unrealistic starting point for a conceptual design model, and thereby cause a conceptual design approach to fail. With innovative technology, users may have no conception of a real world task at all for designers to draw on as a starting point for the design model. This leaves users’ existing knowledge and experience as a starting point: designers should identify an existing knowledge structure which can be used as a metaphor and function as a design model. There is little guidance on how to identify suitable models, so designers tend to select metaphors they themselves are familiar with. Even when a metaphor is drawn from users’ knowledge and experience, many designers do not appreciate that metaphors can facilitate access to and provide a starting point for users’ models, but the process of adapting and extending a metaphor into an appropriate user’s model needs to be supported for the metaphor to be successful (Wozny, 1989).

Finally, there is little guidance on how to communicate a design model through the user interface; guidance here is limited to generalisms such as "Design user interface objects which encourage and facilitate user behaviour that is consistent with the design model" (Tognazzini, 1991).

We have thus identified three problems which user interface designers who are trying to put conceptual design into practice, are likely to encounter:

1. How to construct a design model on the basis of the users’ tasks.
2. How to identify users’ existing knowledge and experience which provides a basis for a design model.
3. How to communicate a chosen design model through the user interface in a manner which supports the construction of an appropriate users’ model.

In section two, we present two simple methods we have developed to assist designers in overcoming the last two problems: a method for identifying appropriate models from users’ existing knowledge and experience, and using linguistic elements of the user interface to cue and communicate design models.

Sdr is a tool for advertising and joining real-time multimedia sessions on the Internet. Sessions are either broadcasts or interactive meetings, using a combination of audio, video and shared workspace tools. Sdr is presently being used to advertise meetings, ranging from weekly meetings of geographically distributed researchers to NASA broadcasts of space shuttle launches; there are also Internet "radio" and "TV" stations. The functionality provided by sdr can be distinguished into 4 high-level tasks:

1. Seeing what sessions are available.
2. Joining sessions - sdr automatically starts up the relevant audio, video and shared work space tools for the session.
3. Setting up and advertising sessions.
4. Making quick private multimedia "phone calls" to other sdr users.

Like many other new applications which are taking advantage of the new possibilities that the Internet offers, sdr represents a new concept in communication. Explaining what sdr does requires explaining an entire new concept in communication ¾ sdr provides, among other facilities, functions which support Internet telephony, videoconferencing and selecting radio and TV-type broadcasts. Sdr therefore makes an interesting candidate for trying out conceptual design.

Our approach to supporting conceptual design is based on the belief that language plays an important part in forming people’s mental models. Johnson-Laird’s (1983) theory of mental models identified procedural semantics as the process through which models are constructed, and Manktelow & Jones (1987) state that "verbal material can be used to evoke existing schemata [mental models] or direct memories". Likewise, "verbal material" like everyday talk can be used to elicit people's mental models (Anderson & Alty, 1995). Aitchison (1994) argues that every word is associated with a mental model which in turn brings up associated mental models. For example, if someone hears the word cat, she will not only think of a cat in its strictest sense as in a dictionary entry, but probably also think of a particular cat that she used to play with as a child. Depending on her previous experiences with cats, words like cuddly or smelly might surface as well. Furthermore, there is a good chance that the word dog will come to mind as the two words are often used together.

Different people form different mental models of the same thing, and the words that they associate with a particular word will be different from person to person. Our mental models are shaped by cultural factors and individual experiences. Cultural differences can appear between different nations around the world, or different departments in the same company. In this case we are worried about the differences between software designers and users. An expert on networks and multimedia communication will invariably have a different user’s model of an application like sdr than a user who has no knowledge of networks.

It was important to try and bridge this gap between the designer and the users by choosing a design model, in this case a metaphor, that could help users form correct users’ models of the application. Furthermore, it was important to make the language, i.e. the labels and any instructions (tutorial and help system) linguistically consistent with the design model.

Redesigning the user interface of sdr involved three stages:

1. Identifying a suitable basis for a design model;
2. Applying the design model to sdr;
3. Communicating the design model through the user interface.

To find a suitable metaphor to use as a design model, we interviewed existing users of sdr at University College London, and sent out questionnaires to existing users at other sites in the UK and Europe. Our aim was to establish

• which tasks existing users apply sdr to
• which existing functions were most frequently used
• which existing functions users felt were most useful

The responses showed that the most common use of sdr was to see what multimedia events are taking place on the Internet. 11 out of the 16 users who answered the questionnaire use sdr to see what sessions are on more than 3 times a week. 7 users join a session from sdr more than 3 times a week, and only 3 users set up sessions more than 3 times a week.

We also asked existing users how they would explain sdr to a user who was new to Internet conferencing and sdr. Two metaphors emerged from the explanations:

• "Radio Times", a weekly TV listings guide, and
• "Yellow Pages", a telephone directory for businesses.

We compared both metaphors to sdr and decided that the "Radio Times" covered most of its core functionality. The broadcasting domain of the "Radio Times" - selecting or locating TV or radio programmes, and maybe recording them - is more closely related than the telephony domain; for instance, sdr has a strong notion of time built into it which is not covered in the Yellow Pages metaphor. Since the task most existing users apply sdr to, is seeing what sessions take place and when they take place, this is a key element that the model needs to cover.

Anderson et al. (1994) suggest that for an interface metaphor to be effective, the features of the metaphor must not differ too much from the features of the application. The core features of the system should be supported by the metaphor. At the same time, the metaphor should not have too much conceptual baggage - i.e. a high proportion of features that do not apply to the system compared to the amount of features that the metaphor and application have in common. Metaphors with too much conceptual baggage make inefficient design models.

If we look at the core features of sdr and compare them with the actual programme guide in the "Radio Times", we shall see that the main functions of sdr are supported well (see Table 1).

For each programme in the "Radio Times" the following are listed (see Table 2):

The major difference between the "Radio Times" and sdr is that the "Radio Times" is printed on paper and sdr is electronic, so rather than using the "Radio Times" as a design model, we extended the metaphor to encompass features of an "Electronic Radio Times".

As stated above, we believe that labels and terms which appear in the user interface are an important vehicle for communicating the design model through the user interface and supporting the construction of a user’s model. We therefore wanted to establish the terms the "Radio Times" metaphor would evoke in potential new users of sdr. Does a TV programme have a name or a title? What is the bit underneath the name called - summary, review, description? We also considered general broadcasting terminology in an attempt to make the entire user interface linguistically consistent with the metaphor. Another issue was how to deal with the fact that the design model is an "Electronic Radio Times", something which does currently not exist. To find answers to these questions, we interviewed 14 potential users recruited from UCL staff and students, and employees of a major UK bank, representing a diversity of people as prospective sdr users would be, and none of them with previous multicast conferencing experience. The interviews were recorded on tapes and partially transcribed.

From the interviews we identified the words and terms in which users described the "Radio Times." We also found that those users who are familiar with hypertext systems easily imagine an electronic version of the "Radio Times" and the functionality it might provide. The interviewees had many ideas of what features they would like that only an electronic listings guide could provide them with, such as:

• being able to see what was on at a particular time on all the channels;
• a list where only the programme names showed and by clicking on the name, more information about the programme could be obtained;
• program their video recorders by pressing a button in the "Radio Times".

Many similar suggestions were made, and most of the suggested features are already supported in sdr. Users who were not familiar with hypertext systems, on the other hand, were not able to imagine such innovative functionality for an "Electronic Radio Times".

Sdr consists of four main windows: The Main Window lists the sessions alphabetically (see Figure 2). The default setting is a list of all sessions that have been announced. In the next version of sdr to be released, users will be allowed to choose to have sessions listed according to their category - meetings, broadcasts, tests etc. This particular feature was on the wish list for an "Electronic Radio Times": People wanted to be able to list garden programmes or films for the following week.

From the main window it is possible to open a calendar where the user can see what sessions have been scheduled to take place at any particular day and at what time (see Figure 3). This feature is very similar to the "Radio Times". The only major difference is that the "Radio Times" lists programmes according to which channel they will be broadcast on and within each channel, the programmes are listed in order of appearance. In multimedia communication on the Internet, there are no channels, each session just takes up a certain amount of bandwidth, so the sessions in the calendar are listed alphabetically. But the graphical representation makes it easy to see what sessions are on at any particular time.

By clicking on a session in either the Main Window or in the Daily Listings Window, a Session Information Window with more information about the session can be opened (see Figure 4). The window will say when the session is scheduled take place; it might contain a link to a web page; it tells the user who is responsible for the session, or who set it up; which tools or media the session makes use of, audio, video, whiteboard and/or text; the user can invite other people to take part in the session and finally, the user can join the session. By pressing join, sdr will start up the relevant tools for that particular session.

The last of the main windows allows the user to create and advertise sessions of his own (see Figure 5). This basically means inputting the information that will appear in the session information window.

In this section we describe the main changes which application of the design model to sdr necessitated. Table 4 lists the main changes to sdr, followed by bullet points describing the changes in further detail.

• Daily Listings used to be called Calendar in the original version of sdr. We changed it because we wanted to make it clear that Calendar is the "Radio Times" part of sdr. "Radio Times" was referred to as "programme listings" "programme guide" and "programme directory" by the people interviewed about the "Radio Times". The Calendar corresponds very closely to the "Programme Guide" section in the "Radio Times". However, as "programme guide" and "programme directory" are synonymous, it would not make sense to have the main window called "Session Directory" and then a button called "Session Guide". We therefore settled on "Daily Listings" which is a label that clearly signals that the sessions will be listed daily rather than alphabetically.

• We decided to maintain the word sessions to signify that there is a difference between sessions and TV programmes. TV programmes are broadcast, whereas sessions are often interactive with shared workspaces.
• The other major change was to the concept of "lifetime" and "active" which existed in the original version of sdr. "Lifetime" referred to the length of time a session was announced, whereas "active" referred to the time when something was actually happening in the session. If a user were to set up a session today to take place every Wednesday between 14.00 and 16.00 for four weeks, the session’s "lifetime" would be from the first Wednesday at 14.00 till the end of the last of the four sessions. The session would be "active" for four Wednesdays between 14.00 and 16.00. This information was conveyed both implicitly and explicitly: A session would appear in the list of sessions in the Main Window from when it was set up and throughout its "lifetime", whereas it would only appear in the Calendar on the days where it was "active". Explicitly, this information could be found in the Session Information Window, where by default the "lifetime" would be displayed, and the "active" times could be seen by clicking a button labelled Detailed Times. However, for a one-off session, "lifetime" equals "active" time, and the Detailed Times button would not appear in the Session Information Window.

• The last major change was to change the balloon help to be consistent with the labels in the user interface and to reinforce the design model.
• The changes to the user interface resulted in longer labels (for instance "Calendar" is 8 characters long, "Daily Listings" is 14 characters long). This proved a problem for frequent users who have sdr running on the screen all the time. They want the sdr window as small as possible without it looking "squashed". The solution to this was to introduce a customisable interface where users can choose between long and short labels.
• We also performed a heuristic evaluation and did some general "tidying up" to make the user interface consistent.

The goal of the evaluation was to determine if users who were new to sdr would form users’ models based on the "Electronic Radio Times" design model. We were, in other words, not only looking for competent performance on a set of tasks, but also aimed to detect the users’ models of sdr. We were looking for linguistic evidence of the "Electronic Radio Times" design model, as correct completion of tasks does not necessarily mean that the user has a correct user’s model, i.e. the user might do the right thing for the wrong reasons. Having a correct user’s model, i.e. doing the right thing for the right reason, is important in situations like error recovery etc. In other words, possession of a correct user’s model is a prerequisite for effective use of a system. Sasse (1996) reviewed empirical work on users’ models and concluded that performance results alone may not be reliable indicators of users’ models, and strongly recommends using verbal protocols in addition. So we were looking for ways of making the users verbalise their thought processes in a natural way. One way of doing this is to have the user to teach someone else about the application (Miyake, 1986). But first we had to introduce the users to sdr and give them time to consolidate a user’s model. In the following section we describe the training and evaluation procedure.

To enable us to compare users’ models, we studied both the existing and the new interface. The new user interface was evaluated with 12 users who had never used sdr before (new users), and the existing user interface was tested with 12 users who had been using the original version of sdr (existing users). The reason for evaluating the original as well as the new interface was to provide a control group that we could compare with when eliciting the new users’ models. The study was divided into three parts:

Task completion. Users were asked to complete six tasks while thinking aloud. They were told that we would prefer them work out how to do the tasks themselves, but if they got irreversibly stuck, they could ask for help. The tasks were scored, based on whether the subjects had successfully completed the tasks without help or not, and problems that the users had completing the tasks were noted.

Mindmaps. Users were given paper copies of the four main windows of sdr, a large piece of paper, a pen and some glue, and asked to glue the windows onto the piece of paper and draw arrows from one window to another if they thought they could get from one window to the other in sdr. The arrows from the mindmaps were listed in tables and added up to see if there were any differences in the mindmaps of the new users and old users.

Teach-back. Users were asked to teach sdr to a contrived co-learner, whom they were told was new to sdr. In fact, the co-learner knew sdr well and prompted users to explain sdr functionality and behaviour of the user interface. The teach-back sessions were transcribed to supply data in which to look for linguistic evidence of users’ models. As mentioned earlier, words are linked together in a semantic network, i.e. words which are closely related will tend to be present at the same time. When looking for evidence of "Electronic Radio Times" based users’ models, we were therefore not only concerned with the actual words "Radio Times" and "Daily Listings" but also words closely related to the entire concept of TV and broadcasting.

Existing users performed all three parts in one session. New users did the first part one week and the second and third the following week. The first part the tasks was performed as a practice session for the new users, but they were also asked to use sdr in the week between the first and the second session to familiarise themselves with it. Part one and three were recorded on videotapes and transcribed. The videotapes contain an overlay of two images. One is a frontal image of the users, recorded with a video camera next to the workstation. A camera is an integral part of a multimedia workstation and is a necessary accessory when using sdr and it should therefore not be extraordinarily intrusive to the user. The other image was the screen the users were looking at. By overlaying these two images, and recording them onto a videotape, it is possible to see and hear the user as well as see what the user is doing on the screen, all at the same time.

The Calendar, or Daily Listings Window as it is now called, was one of the key areas of change to the user interface, and where we expected to find the biggest differences between existing and new users’ models. The results show major differences in the mindmaps: 9 of the new users had made the link from the Daily Listings Window to the Session Information Window where sessions are joined from; only 4 of the existing users connected the two windows and only 2 had the arrow pointing the right way. All the existing users had an arrow directly from the Main Window to the Session Information Window, whereas only 9 of the new users had that. This shows that the new users are to a much larger extent aware of the Calendar/Daily Listings Window.

The transcripts from the teach-back sessions show that 8 of the new users began with showing the Calendar/Daily Listings Window to the co-learner, whereas only 1 of the existing users did that. The use of language also differed considerably between the two groups: Half of the new users explicitly used the "Radio Times" metaphor to explain certain features of sdr (mainly the Daily Listings Window), but even new users who did not explicitly mention the "Radio Times" used language belonging to the "Electronic Radio Times" design model. They referred to different "stations" or that sessions were "on" etc. Existing users stated that sessions would be "active".

The change from "lifetime" and "active" to "Session will take place" also evoked differences between the two groups. Most of the existing users had in one way or the other been involved in the development of tools relating to multimedia conferencing. They are very knowledgeable about the technical aspects of sdr, but only one of them could confidently explain the difference between "lifetime" and "active/detailed times". Typically, an existing user would state that a session with a "lifetime" of two months, would be "active" for two months. None of the new users had any problems finding out when the sessions were on. The fact that new users with less knowledge of the domain developed an accurate representation of the functionality where users experienced in the domain had a misrepresentation is a very encouraging result.

Results indicate that 8 of the new users had few or no problems teaching sdr to the co-learner. 5 users communicated models clearly based on the "Electronic Radio Times" design model. (We suspect that the number could have been 7, had it not been for a software bug in the Daily Listings Window which caused some sessions not to appear in the Daily Listings Window, despite the fact that they were "on" ¾ this appears to have disturbed the construction of their users’ models, particularly because the sessions that did not appear in the Daily Listings Window, were "exciting" ones like the NASA shuttle launches and a Canadian Internet TV station.)

We analysed the transcripts from the teach-back sessions for "Electronic Radio Times" based users’ models. All users successfully completed all main tasks for sdr. However, they all encountered problems at some time during the session. These problems were divided into major and minor problems. The users who successfully completed all tasks without any major problems, were categorised as having successful task performance.

The criteria for determining whether users had an "Electronic Radio Times" based user’s model were:

• Users who had no major problems, or one major problem unrelated to the listing of sessions, and who explicitly used words like "Radio Times", "TV guide" or "TV listings" to explain the functionality of the Daily Listings Window and who implicitly placed importance on the Daily Listings Window by, for example referring to it often or pointing out that to them the Daily Listings Window was an important feature of sdr, showing the Daily Listings Window as the first thing to the co-learner etc., or simply using "Radio Times" related language were classified as having "Electronic Radio Times" based users’ models (4 users).
• Users who did not explicitly mention "Radio Times" but who implicitly indicated that it was the foundation of their user’s model as described above, were also classified as having "Electronic Radio Times" based users’ models (1 user).
• However, users who explicitly mentioned the "Radio Times", but did not show any implicit evidence, were not classified as having "Electronic Radio Times" based users’ models (2 users).

Table 5 shows a list of users with an indication of whether they had successful task performance (STP) and "Electronic Radio Times" based user’s models (ERT), followed by a few examples as to why they were categorised as such.

# (user number), STP (Successful task performance) ERT ("Electronic Radio Times" based user’s model)

The paper reports a case study of applied conceptual design to create a user interface for a tool with novel functionality; results indicate that users’ models of the tool were successfully shaped through:

• identifying a suitable metaphor from users’ existing knowledge and experience;
• adapting the metaphor into a suitable design model;
• communicating the design model through the user interface through structural and linguistic features.

The evaluation results show that new users, without prior experience with multimedia- or videoconferencing, competently performed a set of tasks after a short period of training and practice. Linguistic evidence indicates that many (7 out of 12) were drawing on the design model when describing sdr, whereas a comparison group of existing users did not. The design model was communicated via the labels in sdr’s interface. This indicates that the linguistics elements of the user interface are very important in cueing the construction of users’ models, and that careful engineering of these elements can support the construction of the desired user’s model. Our next step will be to engineer the visual elements of the user interface in a similar manner. Visual elements, such as icons, are already widely employed to communicate metaphors, but we would argue that they would be more effective if their selection and use would follow a procedure similar to the one employed for the linguistic elements in this study.

When constructing the design model, it is of paramount importance to start from the users’ view of the task, or existing knowledge and experience. If potential users have no experience with videoconferencing, for instance, there is little point in using this as the basis for the design model. Likewise, ensuring linguistic consistency within the metaphor in the interface is an important part of supporting users building a correct and useable user’s model. Both of these tasks are painstaking and piecemeal work, but we feel encouraged to persist in developing conceptual design in this manner. By adding more concrete techniques for identifying, adapting and communicating design models, we can develop the idea of conceptual design into an applicable method through which designers can support users in the construction of appropriate users’ models. The emphasis must be on techniques which help designers to identify and build on users’ tasks and knowledge and experience. In our experience, designers often reject suitable models as "too simple" or "wrong"; this assessment is made on the basis of their own knowledge and experience, and that of their peers. The results from this study illustrate that simpler models can be extremely useful if they are selected and implemented with care; the resulting user interface may enable users without knowledge of the underlying domain to use applications as competently as experienced users with knowledge of the domain.

We would like to thank Mark Handley, the designer of sdr; for his co-operation in the design and implementation of the new user interface. We would also like to thank Anne Adams who acted as the contrived learner in the study. Finally, we would like to thank all users who took part in the study as users. For more information about where to obtain sdr etc. see http://www-mice-nsc.cs.ucl.ac.uk/mice-nsc/ For more technical details of multicasting on the Internet, see Handley & Jacobson (1996) and Macedonia & Brutzman (1994).