Interactive System Design: Understanding Users in Contextweb4.cs.ucl.ac.uk/uclic/annb/docs/inaugural.pdf · Interactive System Design: Understanding Users in Context 6 the same effect

Inaugural Lecture, Middlesex University 7th June 2000

1

Interactive System Design:Understanding Users in Context

Professor Ann Blandford

7th June 2000

Abstract

Is computer system design primarily concerned with pushing forward thetechnological frontiers, or with enhancing quality of life and productivity? What

are the qualities that we seek in design? The starting point for this lecture is thatdesign should yield systems that are usable, useful and interesting.

The question is: how do we achieve systems with such qualities? The challengeof designing and implementing systems grows greater by the year. The technical

possibilities are expanding rapidly, from traditional desktop machines throughnetworked computers to nomadic and ubiquitous computing. Despite the rapidtechnical developments, the users of those systems – arguably the very reason fortheir existence – are evolving slowly, if at all. The environments within which

they work, and their motivations and tasks, change gradually in response to newpossibilities.

Engineering effective interactive systems demands an appropriately expressed

understanding of the properties of users, interactions and contexts of use. In thislecture, we will explore some approaches to representing essential componentsof interactive systems in context, and how those representations can be used toguide the design and evaluation of systems. We will consider a variety of

systems – from safety critical and distributed systems to personal electronic aids.

Pre-amble

First, a comment about technology. I am choosing to use an overhead projector forthis talk rather than (for example) the whiteboard or direct projection from my

computer display. I have used a range of sophisticated tools to prepare it, which Icould not have done if I were now using the whiteboard, but now I prefer thereliability and look-ahead of slides to the chance to create effects that might make

you go “Wow!” and the relative low cost of direct projection. This issue of choiceof tools and fitting tools to purpose will be one of the topics that reappears later.

Introduction

The starting point for this lecture is that design should yield systems that areusable, useful and interesting. That is: computer systems are tools that should behelping people to achieve their goals and aspirations in a satisfying way. Of

Interactive System Design: Understanding Users in Context

2

course, this covers an enormous range of requirements. It includes the obvious

wish that your standard office application, such as the word processor orspreadsheet program, should be reliable, displaying and printing what you specify.It includes more abstract requirements such as that educational software should

genuinely support learning; that aeroplanes should fly safely; that games should befun; and that finding information should be efficient. The list of desirable qualitiesfor interactive systems is almost endless. The fundamental question, then, is: how

do we achieve systems with such qualities?

Challenge: the pace of change

The pace of change in computing is difficult to comprehend. It is only just overfifty years since the first programmable computer was run for the first time.

Manchester “Baby” computer, c. 1949.

© Manchester University. See http://www.computer50.org/. Reprinted with permission.

Today we have mobile ’phones that can access the Internet from almost anywherein the world, interfaces that are sensitive to gesture or touch or facial expressions,

diary systems that can point out clashes and errors, aeroplanes that can fly withouthuman intervention and video conferencing systems that can filter out sociallyunacceptable images.


3

Matt and his WAP ’phone

Looking to the future, we may have washing machines that advise us on what cansafely be washed in a particular way, ’fridges that place orders at the supermarket,and electronic toys that take on the role of “best friend” – maybe. If that is what

society chooses.

In 1964, Gordon Moore predicted that thenumber of transistors that could be put on a chip

would double every year. Although the rate ofdoubling has now slowed down to about onceevery 18 months, “Moore’s Law” still broadly

holds. It has been observed that “If transport hadadvanced at the same rate as computing, it would bepossible to cross the US from coast to coast in 30seconds, for 50 cents”1. It is this increase in ‘power’that has made such technological developmentpossible.

Meanwhile, back with the users…

While the technology is changing rapidly, users are hardly changing at all. If we

compare the couple in the picture, taken over 70 years ago, with ourselves there

1 ITEC Technology Group Forward Look Paper, Version 11, 23rd March, 1999. UK Government

Foresight Programme.

Moore’s Law of exponential

increase in ‘power’


4

are no significant differences in our capabilities. Certainly, we cannot process

information 270 times as fast or retain 270 times as much information in memory.The important differences all derive from our contrasting experiences, so that (forexample) this couple were much more proficient at animal husbandry while we are

probably all better at word processing.

Evan and Hannah Bowen, c. 1929.

Overall, if we chart the rate of change ofhuman capabilities in the same way as wecharted Moore’s Law, we get a horizontal

line.

Bringing the agents together

Of course, the two graphs shown above are

largely meaningless when it comes toconsidering the capabilities of interactivesystems, beyond the fact that different

agents in an interactive system (people and computers) have different properties,and that overall power and efficiency cannot be increased simply by throwingmore computing power at the problem.

To understand the nature of interaction, we need to consider the properties of theindividual agents in the system and also how they interact with each other.

Rate of change of human

capabilities


5

Computer systems– at least at the moment – work just with binary data: 1 or 0; on

or off; true or false. They operate in a ‘closed world’, in that they have to beprogrammed; they can only process data that is represented explicitly; and they arereliant on logic.

People, in contrast, adapt rapidly to new situations, are naturally social, are awareof their surroundings and able to interpret information in sophisticated ways, and

make a lot of use of ‘soft’ (poorly

defined) information.

Having said that, though, peopledo not behave randomly like the

proverbial monkey typingShakespeare. Our capabilities andbehavioural patterns are highly

constrained; we attend to things,remember things and react to ourenvironment in ways that have an

underlying pattern to them. Whileeach of us is an individual, it ispossible to find useful

approximations – without that,there would be no ‘psychology’ tostudy. Those approximations can

be used to guide design. Here arejust a couple of examples.

Firstly, perception: visual perception involves several stages of processing from

the moment when patterns of light hit the eye to the time when that light pattern isinterpreted as meaningful information; thestructure of the eye is such that only a

small area at the middle of the back of theeye is really sensitive to colour and detail;peripheral cells are specialised to detect

movement. So the user of a computersystem can only focus attention on oneplace at a time. So what? Well, designersmight want to attract the user’s attention to

a different place on the screen. How to doit? Flashing or scrolling text, maybe. Inmany respects, this is an uninteresting

example: in general, designers experience

Sketch of eye

Fovea


6

the same effect as users, so a detailed understanding of vision may not improve

their instincts about effective design.

That is a simple example; we will consider one more, concerning memory. Humanmemory can usefully be characterised as consisting of a long-term memory store

and ‘working memory’ of information that is being actively processed. Theworking memory is of finite capacity: the figure 7+/-2 is often quoted. However,what matters is not how many items can be remembered at one time, but how

designers can help ensure that users remember necessary information.

Example: sending a mail message with (or without) an attached document (a).

Example: sending a mail message with (or without) an attached document (b).

A design example: most electronic mail systems now allow users to attachdocuments to be sent with messages – rather like the traditional practice of sendingenclosures with letters. I have a store of messages I have received that say “Oops!

I forgot to attach the document. Here it is.”, or equivalent. Why do people sending


7

messages so often forget to attach documents? Are they particularly forgetful? Or

are they simply human?

There appear to be a combination of factors that make forgetting come so easily:firstly, the computer system forces the user to structure the task in a particular way

– specifying first who a message is to, then presenting the screen in such a waythat the ‘obvious’ sequence of actions is to specify the subject, who any copies areto go to, then the content of the message. Secondly, the option to queue the

message (which effectively means to send it) is clearly displayed on the screen,but the option to attach a document is not, so the display does not support theuser’s memory. Because the extended sequence of actions the user has to complete

is typically demanding on working memory, users are particularly likely to forgetattachments if they do not get any support for remembering.

This example is less ‘obvious’ than the first to designers. (It must be, or systems

would surely not be designed this way.) This is partly because the effect is notreliable: it is a persistent but occasional error. It is probably partly also because weare all used to forgetting things sometimes, so it may not be obvious that there are

actually ways to reduce the frequency of such errors.

Designers’ assumptions

This brings us on to consider the people who design interactive systems. Whendiscussing vision and attracting attention just now, I commented that designers can

understand this particular phenomenon easily because their experience matchesthat of most other people. Of course, even in saying this, I made an outrageousassumption: that both designer and user have normal vision. If there is any

mismatch, then it is clear that the designer has to make a point of finding outenough about the user population to be able to design effectively for them. AsTom Landauer argues2 , when there is no evidence to the contrary, designers tend

to assume that the users are ‘just like me’ – that they can rely on their designerlyintuition to know what is going to be easy or difficult for the average user.However, as designers, it is their job to learn a lot about the design situation,

requirements and possibilities. It then becomes impossible to ‘unlearn’ all thiswhen they put themselves “in the user’s shoes”. I will illustrate this using atechnique that Landauer uses: showing you a picture that is difficult to make sense

of.

2 Landauer, T. (1995) The trouble with computers; usefulness, usability and productivity. MIT

Press.


8

A picture: what is it? (Answer later in document)

Once you know what this picture depicts, it is almost impossible not to see it; until

that time, it is difficult to see it. So it is with design: once the problem isunderstood, it is almost impossible to imagine not understanding it.

This has resulted in a widespread implicit assumption (dating back to the earliest

days of computing) that users are adaptable and flexible, will always know whatthey should do next, and can be relied upon to work with almost any system.Paradoxically, this assumption seems strongest in the safety critical systemscommunity, where the dominant mode of thinking is still that safety engineering

has to be conducted with well understood components, that user error simply hasto be ‘designed out’ as far as possible or, conversely, that users can often beconsidered as ‘mitigating factors’. That is: if the hardware or software system were

to fail, the user should be able to identify and correct any resulting hazard before itleads to an accident. Over time, safety engineering has shifted from just verifyinghardware to software verification, but the natural extension to considering users as

part of the system has not been made rigorously. There are several reasons for this;one is that it is difficult: users are not as predictable and deterministic as hardwareand software components. This is something we have been investigating in our

work: how we can represent users as core components of safety critical systems tominimise the risks of user error.


9

While the need for reliability is most obvious in safety critical systems, it is in facta general requirement. Without this, any other usability concerns are a waste ofeffort. In a discussion on the adoption of formal methods in software development,

the authors of a Foresight document wryly observe:

“In the vast majority of software development, time to market isperceived as the overriding driver, far above quality. The "guess andtry" method is believed to deliver results more quickly than carrying

out proper design, and it probably does if the software only has towork some of the time.”3

Software should, at least in an ideal world, work all the time; i.e. design for usable

systems should be rigorous. There are various design methods that supportdesigners in the development of systems. Many of them have a formalmathematical basis that supports the kind of logical thinking that is needed to

design effective computer systems. BUT there is no corresponding accuraterepresentation of all users.

This idea has been the driving force behind much of our work over the past few

years: that if we are to deliver usable, useful computer systems we need to haveways of reasoning about the users of those systems that mesh well with theexisting representations that are used in software design. Just as “guess and try” is

inadequate for software development, so it is inadequate for interactive systemdevelopment: development projects fail not just because the software is unreliable,but also because it is not useful or usable… or because it is not better than the

existing alternatives. But if users and work settings are only introduced when the

3 ITEC Technology Group Forward Look Paper, Version 11, 23rd March, 1999. UK Government

Foresight Programme.

Hardware

components

Software

components

User

components

Levels of verification for interactive systems


10

software has been designed and implemented, that is too late. We needs to

eliminate the “guess and try” element regarding users and work settings as well assoftware and hardware.

Models

Designs can only be tested with real people and real work settings once there is atleast a prototype implementation. By then, most important design decisions havealready been taken. To take account of users and work settings from the earliest

stages of design, we need

some abstract representationof relevant parts of theinteractive system to be able

to reason about usability along time ahead ofimplementation. We will

refer to such an abstractrepresentation as a ‘model’.Just as artists occasionally

work with abstract models ofpeople, or aeronauticalengineers work with

mathematical models of fluidflow when designing wingshapes, so we can work with

models of people – not of their shapes, sizes and hair colours, but of the ways theythink, reason, plan, remember and interact – and of work settings to help in design.

The logical meets the rational

For much of the rest of this talk, we will focus on a particular property of users:that they are (by and large) rational. As Terry Pratchett4 puts it, “…human beingshave always preferred common sense to logic.” What does this mean? Well, there

are various definitions of rationality that can be summarised as follows:

A rational agent monitors the state of its environment, and when thatstate is not entirely to its liking it adopts goals to improve the state,

and chooses actions to address those goals. The choice of actions isbased on the agent’s knowledge of the state and of the effects ofactions.

4 “Interesting Times” p.13. (Corgi Books, 1995)

A simple model


11

To take a simple example: Paul is

working late and becomes aware thathe is a little hungry, so he adopts thegoal of eating a chocolate bar. His

knowledge of the state of the worldincludes the facts that it is now 6pm,that the shop closes at 5pm (so it is

now closed) and that there is achocolate machine in the Mall, so hechooses actions that are expected to

result in him getting chocolate fromthe machine. He walks down to themachine, remembering to take

appropriate money. Unfortunately,when he gets there, he finds themachine is out of order, so he has to

reconsider whether to look further forchocolate or whether to go home and have a meal…

The three important concepts in this definition of rationality are goals, actions and

knowledge.

One strand of our work has been toconsider the user as a rational

problem solver, and to investigateways of integrating that representationof a user with existing design

descriptions. While the rationalityassumption may have limited validity,it is a useful place to start – certainly a

better place than some of thealternatives (e.g. that users behaverandomly, or that users are omniscient

and always perform correctly). Thecore idea behind this approach is that the designer – or some other individual –should write down:• Some typical goals the computer system is designed to achieve.

• What the user is expected to know about the system and the tasks it issupporting.

• What the user has to know (in detail) about the state and possible actions so

that they can make a rational choice of actions to achieve the goals.• Where the user is expected to get that knowledge from.

The PUMA logo

Rationality illustrated?


12

Done thoroughly, this specification

of user goals and knowledge isquite like ‘programming’ a simplemodel of a user – hence the

acronym for this project:Programmable User ModelAnalysis.

Example: Domino printer

It is difficult to generate smallexamples that are easy tocommunicate in a lecture such as

this, if only because most usabilitydifficulties that are concerned withuser knowledge can be traced back

to complexities in the design thatare difficult to describe succinctly.The example I have chosen here is

one where the system design isclear from a designer’s perspective,but where there are things about it

that the user cannot know, or that are more complicated than necessary.

The example is an industrial printer made by Domino plc, which we worked onwhen only an early prototype system existed. This printer is of the kind used to

print information such as ‘best before’ dates on cans and packets of food as theypass along a conveyor belt.

This industrial printer has a control unit that allows the user to adjust various

parameters to do with the ink supply and to define the message that is printed oneach object that passes the print head. It has a password-based security feature thatis activated by pressing a ‘lockout’ button on the front panel. The security feature

can be enabled or disabled, and there is a higher level of security access just forservice engineers. Both hardware and software are engineered to a high standard,and the effect of the user pressing the lockout key can be described from a

software engineering perspective fairly simply:• If user has pressed lockout and lockout is enabled then disable

all functions until user enters a correct password.• If user has pressed lockout and lockout is disabled then permit

access to operator level functions only.• Else if last password entered is operator level then permit

access to operator level functions only.• Else if last password entered is service level then permit

access to all functions.

Domino A400 inkjet printer: the control unit

© Domino plc. Reprinted with permission.


13

However, if one uses the PUMA approach to describe this from a user perspective,

it is surprisingly complicated. The user is expected to be aware of the differentlevels of access and may be expected to know one or two passwords; they areexpected to know what level of authorisation is needed for the different printer

functions, and whether the device currently allows that level of access; they mayneed to know whether lockout is currently enabled, and whether it is currentlyactivated. While many users will not need all of this information every time they

adjust the printer, simply laying out these concepts helps to suggest simpler waysof implementing a security system. When we interviewed designers about theproduct, they had a clear view of ‘the user’ as any person who adjusts the

machine; in practice – as we found when we interviewed users about it – ‘the user’may be any one of several individuals, so what any individual user knows aboutthe state of the machine is not necessarily what the most recent user knows about

it, and one of the challenges for design is to communicate more about the relevantaspects of state, so that users will find the machine predictable, and will beconfident about what state it is in.

Working on even this simple example, we found both strengths and weaknesses ofPUMA. PUMA does one job – relating user knowledge to device design to supportreasoning about the details of interactive behaviour – and arguably it does that

particular job well. It can beused early in design, andforces the analyst to be

explicit about assumptionsbeing made about the userpopulation. However, it is

difficult and expensive toapply thoroughly to a largedesign; it does not

accommodate context on itsown; and it does not dealwith qualities of interaction.

Scalability

PUMA is one of a class oftechniques (most of them developed in the U.S.) that focus on the details ofbehaviour. The analysis is aiming towards a description that says broadly “The

user does this, then the computer does that, then the user … ” and compares thatprocedure with what the designer intended the user to do. Clearly, in anysubstantial interaction there is a lot of optionality: there are a large number of

possible behaviours that are all equally rational. Investigating each and every one

PUMA focuses on the user-computer interaction


14

of them is not likely to be an efficient and effective way of proceeding. There are

several ways of trying to deal with this:

• Mathematical abstraction – throwing away all but essential features, andreasoning with the simplest possible representation of the problem. This takes

a lot of skill and / or trial and error, so is not for the faint-hearted.

• Recruiting the computer to support the reasoning and help keep track of whatstage of analysis we have got to. This work is still at an early stage of

development, but it’s looking hopeful.

• Reducing the formality of therepresentation – focusing on semi-

structured questioning about the design,particularly to do with what the user’sgoals are expected to be and what they

can reasonably be expected to know andwhat the consequences of them notknowing might be. We found this the best

approach when doing safety engineeringwork with Praxis Critical Systems Ltd..One promising avenue that we are

pursuing at the moment is the idea of‘footprints’ – that, as long as the analysthas grasped the basic concepts of goals

and knowledge, a design has features thatshow the presence of particular kinds ofusability difficulties, and that those

features should be identifiable withoutresorting to full analysis.

• Focusing on knowledge in a different way – not on ‘know how’ but on ‘know

that’.

This idea underpins our work on “Ontological Sketch Modelling” – meaning thatwe construct a sketchy model (or partial description) of the core concepts (the

ontology) the user has to work with when using a system to support their work.The description is presented in terms of entities and attributes (i.e. things and theirproperties), actions and constraints. As a system gets more complex, the number ofpossible behaviours increases exponentially, but the number of underlying

concepts the user has to work with increases linearly, so this kind of approach isbetter suited to large scale systems and to poorly defined tasks than the behaviour-oriented approach.

"Footprints" mark out existence of

probable difficulties


15

The original idea came from working with drawing tools. We realised that the

thing that make a drawing program easy or hard to use is not understanding theprocedures so much as understanding some of the rather alien concepts, such as‘handles’ and ‘layers’, and then interactively working with them. So the user who

has learned how to draw a house (say) should be able to easily transfer thatunderstanding to draw a ship or a whale or an organisational chart. This does notrely on remembering the procedure, but on using an understanding of the

underlying concepts to do something new – maybe something that has never beendone before.

Drawing tools: a whale with some ‘handles’ … and manipulating the tail

Today, rather than talking about drawing tools (which have a tendency to getcomplicated rather quickly), I am going to discuss a more familiar set of

technologies: those that support time management. These typically include diariesand to-do lists.

At one level, time management tools are really easy to use. You just need a pen or

pencil to write in a paper diary; even most personal digital assistants andcomputer-based diaries are – on the surface – easy to use. Yes, people sometimesmake mistakes such as putting next week’s appointment in the diary for June

1998, or forgetting to turn over the page and therefore missing the Mondaymorning meeting. But otherwise they are fairly easy to write in and read.

In a study of diary use, however, we found a lot of more subtle usability issues that

have never been well understood. Mackinlay et al (1994) claim that “electroniccalendars are gradually becoming more desirable than paper calendars”5. Since theearly 1980’s people have been writing as if electronic organisers (individual and

5 Mackinlay, J. D., Robertson, G. G. & DeLine, R. (1994) Developing calendar visualizers for the

information visualizer. Proc. UIST'94. 109-118.


16

shared) are the obvious and only sensible way forward. And yet take-up is very

slow. Why?

It turns out that time management is an amazingly complex activity for mostpeople. It involves the obvious things like scheduling activities and remembering

to do something at the right time, and prioritising between important and urgenttasks. But it also involves a lot of working with partial information, and makingdecisions at the last minute, and using contextual information.

paper and electronic diaries provide good support for different kinds of activities

The visual structure of electronic tools supports scheduling well, but the less

structured interface of a paper diary provides a better match to most people’sactual time management. The shared nature of some electronic tools also forcespeople to make explicit some things that they would otherwise leave implicit, such

as explicitly making time for preparing for a meeting, which some people view astedious, but others like.

Overall, different time management tools have different properties, whichdetermine their suitability for different people, with different working lifestyles.

These properties include:• Portability – the ability to carry information around and refer to or update it

from almost anywhere.

• Easy sharing for reading and writing – most useful for managers and PAs,particularly when the manager is out of the office (but can access informationover the internet).

• Visual salience in the work setting – can the diary be placed strategically forglancing at or to remind the user to do something specific?

• Fluidity of the visual structure – are there fixed points that help the user

easily locate the desired place and be sure they have got it right?• Expressiveness of technologies – as discussed already• Explicit and implicit information. People are generally very good at working

with partial information, and actually not so good at making everythingcompletely clear, explicit and consistent. Life and circumstances can generallybe relied on to fill in the gaps.


17

Here, we are able to move out from just looking at the user and device in detail to

also start to look at the way the device, or devices, are used in context. Also, weare going out into the work place and gathering new data as a basis for themodelling. So this OSM approach allows us to take more account of the ‘big

picture’, which still centres on the user but involves a variety of tools and takessome account of the work setting.

Understanding the work setting

Qualities of interaction

PUM and OSM both start from the point of view of one individual and the world

as they see it. In practice, in a networked age, much of what the user experiencesdepends also on interactions that are invisible to them – for example, between thelocal ‘client’ computer and a remote host that is providing information – or on the

way different ‘streams’ of interaction are interleaved. We are therefore alsolooking at ‘interactions’ between multiple agents as entities in their own right.

Interactions themselves may have

good and bad properties. If wethink of human-humanconversations, we can see that

some are very purposeful andbusiness like while others rambleon apparently aimlessly; some

are funny while others areaggressive; in some, people aretalking at cross-purposes while in

others they share a lot ofcommon knowledge so that the

Conversations have different properties


18

conversation is almost incomprehensible to an outsider; some multi-party

conversations can be highly structured while others involve a lot of interruptionsand people talking at the same time. Similar things can be true of human –computer interactions.

The challenge in design is to identify desirable properties of interactions, and tryto design them in while also designing out undesirable ones. Because modellingmulti-agent interactions could be almost infinitely complicated, we are studying

one particular type of system at the moment: digital libraries. A digital library is acollection of documents – often including things that wouldn’t be called‘documents’ if they were found in a traditional library, such as pieces of music or

video clips, that are organised in a fairly structured way and come with a set ofaccess mechanisms. For example, one particular library we are studying is theNew Zealand Digital Library, which is structured into a set of collections, each of

which can be accessed in various ways – for example, searching by content, orbrowsing by titles or subjects.

NZDL: the collections and a sample page within one collection

At the moment, we are looking at two particular aspects of libraries. One is how

they are viewed and used by different stakeholders; the other is how we candescribe an interaction in detail and use that description to start reasoning aboutproperties of interactions, and then start to feed ideas back in to design.

We are working with various stakeholder groups – librarians and managers whoare introducing new systems, and users who are expected to access electroniclibraries alongside, or instead of, traditional information sources. Perhaps

unsurprisingly, we are finding some important sources of conflict between groups.For example, library staff and students are clear beneficiaries of a project to putpast examination papers in a digital library, but many academics view this as a

threat: the easier the access to past papers, the more effort they have to make to


19

really vary questions from year to year.

Similarly, in the hospital setting, thereappears to be a strong correlationbetween access to information and

power within the organisation. So theintroduction of library access on theward, which makes information much

more readily accessible to nurses, isthreatening to doctors, who havetraditionally viewed libraries as

repositories for information to supporttheir research and have not questionedtheir right to preferential access to that

information. In the long term,technologies have to be designed inways that support all user groups, and

this may involve re-thinking other working practices and relationships – butwithout some understanding of the issues, we have to rely on “guess and try”,which is prone to expensive failures.

In parallel, we are studying the properties of interactions – thinking of theinteraction in terms of levels of detail. At the lowest level (for the current purpose)we have events, which communicate information from one agent to another, which

combine to form traces, or interactions, that have properties – hopefully desirableones. The kinds of properties that we are considering at the moment include:

• Serendipity: does the interaction structure support easily stumbling over

interesting things by chance?

• Familiarisation: how easy is it for one agent to develop an understanding ofanother?

If we think of one digital library as comprising two agents – an interface agent that‘helps’ the user to find things and the underlying collection agent, then we get asuperficially simple linear interaction:

Different views of the new technology


20

The user communicates their wishes to the interface, who forwards that request to

the database, which returns relevant information, which is displayed to user, whothen… but there are all kinds of issues and difficulties: for instance, the user maymisinterpret information from the interface, or fail to notice important details, so

that the two agents have inadequate ‘common ground’ for communication; thecommunication between interface and database may be so slow that the user getsdistracted and goes off and does something else, or starts up a second computer-

based task and then has to keep track of the state of both; the user may sendmaterial to a printer and go away to get it, but get involved in a conversation withsomeone else then lose track of what has been printed and what has not … by now

we have some very complex patterns of interaction that can only remain coherentand efficient if the communication between agents is always timely, and if thecommunicative events – particularly those from interface to user – are effective

and maximise common ground.

This work is at an early stage of development. Even if we never achieve our grandaim of relating design and implementation details to abstract interaction properties,

we are already finding out interesting things about digital library design andinteraction along the way.

Summary

My aim has been to present a problem that I believe to be important, and that I

find exciting and challenging – that of bringing user concerns into design from thevery earliest stages. If we are to get beyond “guess and try” – or, even worse,“guess and endure” – in design then we need appropriately expressed

understandings of users, interactions, work and contexts. The challenge is to findways of allowing us to reason about the logical, the rational and the social allwithin the same frame. I have argued that models allow us to take users and their

working seriously within the design process, and have presented three modellingapproaches that each focus on different aspects of Human – Computer Interaction.Hopefully, over time we are contributing to a ‘tool box’ of techniques. At the

moment, they may have more in common with flint-age tools than finely honedmodern ones, but we have to start somewhere.

Acknowledgements

I am indebted to family and colleagues, without whom research would be no fun atall. I particularly want to thank Chris, Emily & Laura Blandford and Olive & MaxFrancis for their tolerance and constant support.

None of the projects I have mentioned in this talk have been solo efforts. They allowe at least as much – often more – to colleagues, particularly Anne Adams, PhilBarnard, Nick Bryan-Kinns, George Buchanan, Richard Butterworth, Paul Curzon,


21

David Duke, Jason Good, Thomas Green, Michael Harrison, Sue Milner, Gordon

Rugg, Harold Thimbleby, Richard Young, … and so many more I don’t knowwhere to stop.

Cartoons are all provided by Richard Butterworth – thank you, Richard. The talk

has been sanity-checked by Yvonne Kidd (though all remaining errors are mine!).Yvonne and Sardia Alhassan provide support in various forms and Matt Jonesmakes a really good cup of coffee. Other preparations for this event have been

handled by Marianne Panic. Thanks to all.

The paper version of this talk is available fromhttp://www.cs.mdx.ac.uk/staffpages/annb/inaugural.pdf

… and here is a clearer version of the picture:

If you ever refer back to the original again, you willalmost certainly see the cat.

Documents

Interactive System Design: Understanding Users in Contextweb4.cs.ucl.ac.uk/uclic/annb/docs/inaugural.pdf · Interactive System Design: Understanding Users in Context 6 the same effect