CHAPTER 11

A SCENARIO-BASED DESIGN METHOD FOR HUMAN-CENTRED INTERACTION DESIGN

David Benyon¹ and Catriona Macaulay²

¹Napier University, Edinburgh, UK

²Duncan of Jordanstone College of Artand Design, Dundee University, UK

OVERVIEW

We describe a method for the design of interactive systems. The aim of the method is to ensure that the interactive systems that we design are usable, useful, and engaging. The method is scenario-based and uses four different types of scenario: user stories, conceptual scenarios, concrete scenarios and use cases. We also include a method for arriving at a conceptual system design from a ‘corpus’ (i.e. a logically coherent and complete set) of scenarios using and object/action analysis.

APPLICABILITY

The method was developed while working on a European research and development project to produce a new device—a home information centre (the HIC). One key feature of this setting was the large cross-disciplinary and multi-lingual project team. There were also several people working in parallel on different applications for the device. Scenarios proved very effective at providing a ‘lingua franca’ for the project (Erickson 2000) allowing different people to focus on concrete settings and characters in order to express their concerns and design ideas. The method also proved useful in arriving at appropriate functionality for the applications through undertaking an object/action analysis of the scenarios. Since then it has been used on another similar large European funded research and development grant to develop an online partner searching system known as OPaL (Davenport 2003). Overall the method may be most applicable for the development of more ‘blue sky’ products where conceptualisation of future use is key. However, because the method is inherently object-oriented, it fits well with many mainstream software development approaches.

FIGURE 11.1 The star life cycle (Adapted from Hix and Hartson 1991)

POSITION IN THE LIFE CYCLE

The method is inherently associated with a star life cycle (Hix and Hartson 1993) or with a spiral approach (Boehm 1988) to development. In the star model (see Figure 11.1), evaluation is central; everything gets evaluated as the design moves from one phase to the next. Our method starts from the user stories that have been gathered during requirements generation exercises such as observations or workshops. It finishes with a specification of a system in terms of its functionality (specified as use cases), structure (specified as a conceptual object or data model) and look and feel (specified as a design language, including interaction patterns). The amount of formality in this approach is appropriate for a wide range of systems. We do not think that the specification could simply be handed to a programmer without further elaboration, discussion, and involvement with the design team. However, we do think that the specification captures enough of the essential aspects of a design to be used for developing prototypes.

KEY FEATURES

The different types of scenario and the ways that they are used are key features of the method. The scenarios become more formalised as the design process progresses. Thus, the transition from one representation to another is also important. Another key feature is the way that claims and requirements are captured and cross-referenced through the structured representation of a scenario. Finally, we would draw attention to the way that the scenarios fit into an object-oriented analysis and design (OOAD) approach.

STRENGTHS

As with any scenario-based design method, it is thoroughly human-centred. Stories come from the future users themselves, and can be elicited using participatory methods such as workshops, focus groups and brainstorming sessions. It provides a useful ‘lingua franca’ for such broad-based design teams. In practice, people have rapidly begun talking in terms of specific scenarios and characters (or ‘personas’).

WEAKNESSES

The method appears most suitable for envisioning and designing novel systems rather than more traditional information processing applications. However, this may turn out to be a strength as increasingly we see information technology being applied to areas in which ‘soft knowledge’ is key. We are not as interested in the simple retrieval of hard facts as we are in the more subtle ‘qualia’ of information. Davenport (2003) comments that in the case of Knowledge Management software ‘[scenarios] must yield or deliver insights pertinent to judgements about behaviour that involve soft insights about tacit knowledge: trust, rapport, social capital, and social networks’.

THE METHOD

An overview of the method is shown in Figure 11.2. The clouds represent activities carried out during system or product development. The boxes represent artefacts. It creates a system specification in the form of a set of use cases, a conceptual object model and a design language, though all the documentation contributes to the full specification. The process is highly iterative.

Scenarios in the Method

The method employs four different types of scenario used for different purposes during design,

• user stories,
• conceptual scenarios,

  

  FIGURE 11.2 Scenarios throughout the life-cycle

• concrete scenarios, and
• use cases.

Figure 11.2 illustrates the relationship between the different types of scenario. The lines indicate that many user stories will be represented as a single conceptual scenario, which in turn may generate many concrete scenarios. Several concrete scenarios will be represented by a single use case. The difference between these types is elaborated below.

User Stories

User stories are the real world experiences, ideas, anecdotes, and knowledge of people. These may be captured in any form and comprise small snippets of activities and the contexts in which they occur. This could include video of people engaged in an activity, diary entries, photographs, documents, the results of observations and interviews, and so on. User stories are rich in context. They often capture the intentions of the users, leading to a more goal-centred design (Cooper 1999). That is, rather than focusing on the tasks that people perform, the aim is to understand, and design for, their personal and practical goals. User Stories also capture many seemingly trivial details usually left out of more formal representations.

Conceptual Scenarios

Conceptual scenarios are more abstract than user stories. Much of the context is stripped away during the process of abstraction (see below), and similar stories are combined together. The designer begins to design possible implementation objects from a blend of the physical objects described in the stories (Imaz and Benyon 1999). Conceptual scenarios are particularly useful for generating design ideas and for understanding the requirements of the system.

Scenarios can become messy, so in order to control the scenarios a structure is needed. We use a framework known as PACT (People, Activities, Contexts, Technologies) to critique scenarios and to encourage designers to get a good description of the domain (Benyon et al. 2004). For each scenario the designer lists the different people who are involved, the activities they are undertaking, the contexts of those activities and the technologies that are being used.

We also try to structure scenario descriptions. Each scenario should be given an introduction. The history and authorship should be recorded, along with a description of how the scenario generalises (across which domains) and the rationale for the scenario. A PACT analysis should be provided. Each paragraph of each scenario should be numbered for ease of reference and endnotes included where particular design issues are raised. Endnotes are particularly useful in documenting issues raised during the development of the scenario. They are a way of capturing the claims being made about the scenarios (Rosson and Carroll 2002). Examples of relevant data and media should be collected. Figure 11.3 provides an example scenario in this format. It was one of the conceptual scenarios developed for a project exploring designs for an HIC and looked at a particular application of a more generic scenario ‘what shall we do now’ (discussed below).

When working in a large design team, it is useful to accompany scenarios by real data. This means that different team members can share concrete examples and use these as a focus of discussion. Another key feature of writing scenarios is to think hard about the assumptions that are being made: to make assumptions explicit or deliberately avoid making things explicit in order to provoke debate. In the scenario sample shown in Figure 11.3, for example, the couple are deliberately kept gender neutral; so discussions about gender issues can either be avoided or can be confronted. In another scenario, an elderly woman with arthritis might be one of the characters, thus bringing to the foreground issues of access and how the physically impaired interact with technology.

Finally, with these scenarios it is important to provide a very rich context—hence the details such as food on the table, or where they had been holidaying. As already mentioned, the guiding principles for scenario writing are people, activities, contexts and technologies. A simple web-based hypertext system can be developed to help with the organisation of the scenarios, linking the user stories that led to the conceptual scenarios (Figure 11.4).

Concrete Scenarios

When people are working on a particular problem, or an issue raised by one of the endnotes or other part of the scenario, they will often identify some feature that applies only under certain circumstances. At this point they may specify a more specific elaboration of the scenario and link it to the original. Thus one reasonably abstract scenario may spawn several more concrete elaborations, which are useful for exploring particular issues.

FIGURE 11.3 Example scenario fragment

FIGURE 11.4 The scenario web

Concrete scenarios also begin to dictate a particular interface design and a particular allocation of functions between people and devices. Concrete scenarios are particularly useful for prototyping and envisioning design ideas and for evaluation because they are more prescriptive about some aspects of the technology. For example, the scenario in Figure 11.3 has an endnote stating that how the HIC is activated is not considered. Different possible designs—an ‘off/on’ switch, voice activation, touching the screen and so on—result in different concrete scenarios.

For example, if the designer considers touch screen technology and works with a concrete version of the scenario ‘Jan touched the screen to activate the HIC’, someone might point out that with all this food lying about perhaps the screen would get very dirty. Two observations about this are worth noting. Firstly, it is only by including the rich contextual descriptions that such issues will arise. If the scenario did not mention food, people are less likely to think about the results of having food lying around. Second, notice that the concrete scenarios do not have to be implemented to prove useful in prototyping and envisioning ideas. Just working through a concrete scenario with a colleague can throw up many important design issues.

When planning more formal evaluation, the concrete scenario chosen needs to be considered very carefully. For a more formal evaluation a running prototype is often required, so design decisions about colour and screen layout and dialogue structure and so on all need to have been decided upon. This leads finally (after much evaluation) to the design language (see below).

Use Cases

A use case describes the interaction between people and devices. Each use case therefore covers many slight variations in circumstances—many concrete scenarios. The lines in Figure 11.2 indicate how many concrete scenarios result, after the process of specification and coding, in a few use cases. The line looping back illustrates that each use case will have many (concrete) scenarios associated with it.

Before use cases can be specified, tasks and functions have to be allocated to human or to the device. The specification of use cases both informs and is informed by the task/function allocation process (see below).

OTHER ARTIFACTS IN THE METHOD

Besides the four different types of scenario, four other artefacts are produced during the design process: requirements/problems, scenario corpus, conceptual model and design language. These are represented as boxes in Figure 11.2 and are explained further below.

Requirements and Problems

In the gathering of user stories and during the analysis and abstraction process, various issues and difficulties will come to light. These help the analyst/designer to establish a list of requirements—qualities or functions that any new product or system should have. For example in the HIC example, the device has to be used by the elderly and short-sighted. Another requirement was that it should look good in a living room and should not look or behave like a personal computer running Windows. The format of the requirements and problems is a prioritised list of issues.

Scenario Corpus

In our approach we seek to develop a representative and carefully thought through set, or corpus, of conceptual scenarios. Having undertaken some analysis activities, the designers will have gathered a wide range of user stories. Some of these will be very general and some will be quite specific. Some will be fairly simple, straightforward tasks and others will be more vague. It is important at some point for the designer to pull these disparate experiences together in order to get a high level, abstract view of the main activities that the product is to support. These conceptual scenarios will often still be grounded in a real example; the trick is to find an example that shares characteristics with a number of other activities.

The rationale for the development of a corpus of scenarios is to uncover the ‘dimensions’ of the design situation and to demonstrate different aspects of those dimensions. Dimensions include characteristics of the various domains within which the product will operate (e.g. large and small domains, volatile or static domains, etc.), the various media and data types that need to be accommodated and the characteristics of the people who will be using the system. The corpus of scenarios needs to cover all the main functions of the system and the events that trigger the functions. Different types of interaction need to be present along with any key usability issues. The dimensions include different types of content and how that can be structured, issues of style, and aesthetics.

A corpus of scenarios might consist of 10 to 12 scenarios depending on the complexity of the domain. For example, in the HIC study we had 11, and for an MP3 application (which of course is much more specific—just playing, sorting and organising MP3 files) we had six and for the OPaL partnership building system (see case study below), we had nine. The aim is to specify the scenarios at a level of abstraction that captures an appropriate level of generality that will be useful across the range of characteristics that is demonstrated within a domain.

Object Model

The object model results from the process of conceptual modelling including developing the scenarios and undertaking an object/action analysis (see below) of the scenario corpus. This will be a conceptual object model, rather than the object model that will be used to implement the system. The object model shows the main objects in the system, their attributes and the relationships that exist between them.

Design Language

The design language produced consists of a set of standard interaction patterns and all the physical attributes of a design—the colours, shapes, icons, and so on. These are brought together with the conceptual actions and objects and the ‘look and feel’ of the design is completed. A design language consists of a set of design elements such as the use of colour, style and types of buttons, sliders and other widgets and some principles of composition (i.e. the rules for putting them together). A consistent design language means that users need only learn a limited number of design elements and then they can cope with a large variety of different situations. A design language is how designers build meaning into objects enabling users to understand what things do and to make distinctions between different types of objects (Rheinfrank and Evenson 1996)

Any language provides a way of expressing things and design languages are ways of expressing design concepts. Languages are useful for particular purposes if they have appropriate elements, appropriate organising principles and use an appropriate medium for both expression and transmission. Design languages help ensure transparency, helping people to understand what is going on inside a device. They also afford transferability of knowledge from one device to another. The user of one Nokia phone can generally expect to find similar design elements and principles of composition on another phone. Rheinfrank and Evenson developed their ideas while working on the Xerox photocopiers using colours and symbols to provide a consistent design across a range of products. Design languages also encourage people to more readily see opportunities to use a device or function and will expect certain behaviours, structure, or functions. Finally, people will identify with a style, which helps to define their identity; they act through the design language.

A part of the design language will be a set of interaction patterns. The idea of patterns—‘regularities of usage’—was originally developed in architecture (Alexander et al. 1977) and was later enthusiastically adopted by the object-oriented design community. This idea has now arrived in the design of interactive systems as interaction patterns. For example, on a normal PC if you double click on something it opens it, while if you right click on it, it displays a menu of operations you can perform. Macintosh computers have only a single mouse button, so the ‘right click’ pattern is unknown to Macintosh users. (Interestingly though various work-arounds have now been introduced with different mice and software controls to provide the functionality of a right click pattern.) Most playing devices—VCRs, DVDs, cassette tapes, MP3 players on a computer, and so on—will have a play, stop, fast forward and rewind interaction pattern (and associated design language of single and double headed arrows). Patterns build up into the complex interactions that we are familiar with of menus and mice; patterns of layout of menus, of the highlighting when the mouse rolls over an item, flashing when it is selected and so on.

Patterns are usually described in some standard format so that they can build up into a pattern ‘book’, referring to one another to provide a rich guide to designs. The key elements for a pattern are to have a clear statement of the design problem, a discussion of the issues surrounding the problem and hence a solution for the problem. There are many examples of patterns for good HCI design in general and for more specific design situations. A good example is the web usability pattern language ‘wu’ (Graham 2003).

PROCESSES OF THE METHOD

The clouds in Figure 11.5 indicate the activities or processes that have to be undertaken. There is no prescribed order for undertaking these activities and, indeed, considerable iteration around them is inevitable as in the star life cycle (Figure 11.1). They are described in this section.

Abstraction

The process of abstraction is one of classification and aggregation: moving from the details of specific people undertaking specific activities in a specific context using a particular piece of technology to a more general description that still manages to catch the essence of the activity.

Aggregation is the process of treating a whole thing as a single entity rather than looking at the components of something. In most domains, for example, one would aggregate a screen, processor, disc drive, keyboard, and mouse and treat this as a single thing—a computer—rather than focusing on the components. However, in another situation one of the components—processor speed, or disc size, say—may prove to be critical and so it would be better to have two aggregations: fast computers and slow computers, say.

Classification is the process of recognising that things can be collected together and so dealing with the class of things is simpler (more abstract) than dealing with the individual things. There are no set ways to classify things and so the analyst has to work with the stories that have been gathered and with the users themselves to decide which things belong together and why.

Between them, aggregation and classification produce abstractions. Of course there are different degrees of abstraction and it is one of the skills of a designer to settle upon an appropriate level. The most abstract level is to treat everything simply as a ‘thing’ and every activity as ‘doing something’, but such an abstract representation is not usually very useful. Rosson and Carroll (2002) discuss abstract scenarios such as a ‘browsing’ scenario or an ‘authoring’ scenario. We would consider these to be rather too abstract for the design process and would like to take one step further towards the concrete, whilst still keeping the conceptual scenarios quite abstract. For example, we had a general ‘information searching’ scenario in the HIC project that we felt was too abstract. It became the slightly less abstract scenario below, which helps to focus attention on some important details of the system, before finishing up as the conceptual scenario in Figure 11.3.

Design Constraints

As the design process continues, certain design decisions will be made. These decisions will result in design constraints—features of the technology or its usage that impose a certain way of working. Given these constraints, each conceptual scenario will generate many slight variations and concrete scenarios. The distinction between conceptual and concrete scenarios is not absolute. It depends how abstract the designer wants to be for a particular reason and how detailed the design constraints are. And of course there will be considerable iteration between these different representations.

Formalise Design

Finally, after much iteration the design is completed and so all the specific interactions with a particular system or device can be specified in terms of the use cases. The design is also formalised through providing a model of the system structure in terms of an (conceptual) object or data model and through the provision of a consistent design language that specifies the look and feel of the system. The design can only be formalised once the task, or function, allocation process has been completed (see below). Formalised design is dependent on a particular device and on how that device has been designed to function. Use cases can then be written.

Specifying Requirements

This is the process of understanding what happens now, what people would want to happen and what problems there are with existing systems or products. The use of user stories and the process of abstraction will help generate requirements, which can gradually be collected together into a prioritised list of both functional and non-functional requirements.

Conceptual Design

Conceptual Design CD involves moving from the requirements and problems that have been uncovered from the user stories and the conceptual scenarios that have been generated to an abstract model of the objects and actions that the new system should provide. A good way of doing CD is to undertake an object/action analysis of the scenario corpus. For each of the scenarios in the corpus, the analyst works through the scenario description identifying the various objects that are mentioned and the various actions that are performed. Objects are often indicated by nouns or noun phrases and activities; actions are indicated by verbs.

Working with a corpus of scenarios in this way requires four stages.

1. Analyse individual scenarios, distinguishing between specific actions and more general, higher-level activities.
2. Summarise objects and actions from each scenario, merging similar or identical actions where necessary.
3. Bring together the analyses from the individual scenarios, collating them into summarised objects, actions and more generic activities.
4. Merge actions and objects where they are identical and give them a single name.

For example in an MP3 music playing scenario a paragraph might read:

Analysing this produces the actions ‘select’ and ‘search’ and the object ‘play function’. In undertaking this type of analysis, verbs often indicate actions and nouns often indicate objects.

Actions that could be thought of as generically similar can now be grouped together, prior to the final distillation stage. For example, ‘select’ might be called ‘specify’ in a different part of the scenario. This requires careful attention, to avoid mistakenly merging together slightly different actions. The guiding principle is to look for conceptual or functional parallels among the actions, indicating likely candidates for grouping. The process continues until an object model can be produced.

Prototyping, Envisionment and Evaluation

Designs need to be visualised both to help designers clarify their own ideas and to enable people to evaluate them. Prototyping and envisionment is concerned with finding appropriate media in which to render to design ideas. The medium needs to be appropriate for the stage of the process, the audience, the resources available and the questions that the prototype is helping to answer. Techniques for prototyping and envisionment include any way in which abstract ideas can be brought to life. Sketches ‘on the back of an envelope’, fully functioning prototypes, cardboard mock-ups are just some of the methods used.

Evaluation is tightly coupled with envisionment because the nature of the representation used will affect what can be evaluated. The evaluation criteria will also depend on who is able to use the representation. Any of the other design activities will be followed by an evaluation. Sometimes this is simply the designer checking through to make sure something is complete and correct. It could be a list of requirements or a high-level design brief that is sent to a client, an abstract conceptual model that is discussed with a colleague, or it may be a formal evaluation of a functional prototype by future system users.

Techniques for evaluation are various depending once again on the circumstances. The important thing to keep in mind is that the technique used must be appropriate for the nature of the representation, the questions being asked and the people involved in the evaluation.

Physical Design

Physical design is concerned with how things are going to work and with detailing the look and feel of the product. Physical design is about structuring interactions into logical sequences and about clarifying and presenting the allocation of functions and knowledge between people and devices. The distinction between conceptual and physical design is very important. The conceptual design relates to the overall purpose of the whole human-computer system. Between the people and the technologies, there has to be enough knowledge and ability to achieve the purpose. Physical design is concerned with taking this abstract representation and translating it into concrete designs. The functionality is expressed as a set of use cases, and the look and feel as a design language. There are three components to physical design.

Operational design is concerned with specifying how everything works and how content is structured and stored. Representational design is concerned with fixing on colours, shapes, sizes, and information layout. It is concerned with style and aesthetics and is particularly important not only for issues such as the attitudes and feelings of people but also for the efficient retrieval of information. Interaction design is concerned with the allocation of functions to human or to technology and with the structuring and sequencing of the interactions.

SUMMARY

The method for scenario-based design described here identifies four types of scenario

• User stories: are gathered from people and are effective at understanding what they do now (with the existing technologies), what problems people have and what they want to do in the future
• Conceptual scenarios: are generated by the analysts and designers (which may of course be a single person), with participation from the users, from the user stories. They are useful for generating ideas and for scoping the extent of the proposed system.
• Concrete scenarios: are generated by the analysts and designers, with participation from the users, by introducing design constraints and specific interaction methods to the abstract scenarios. They are useful for evaluating alternative physical and logical designs.
• Use cases: are generated by the analyst/designer as part of the formal specification of the designed system. They gather together a number of concrete scenarios into more generic interaction episodes.

The key activities involved in the method include

• Requirements specification by gathering and understanding user stories: through interviews, ethnographic methods and the use of various probes such as getting them to keep diaries, giving people disposable cameras to photograph situations, and so on.
• Abstraction: looking for regularities in the stories, grouping them into meaningful conceptual scenarios, scoping the dimensions of the domain and providing the basic ‘lingua franca’—the shared language that designers, developers and users need to establish
• Interaction design: deciding how the logical processes and data that are needed from some activity are distributed between devices and people.
• Establish design constraints: this also includes establishing design opportunities. It is not all negative. This process will result in the look and feel of the system, the design language that embodies a consistent, recognisable and understandable set of actions and objects.
• Object/action analysis: for establishing a conceptual object model from the scenario corpus. The extent to which this is a rigorous process or not depends on the analyst's skills.

There is always a debate in interaction design circles as to the extent to which a method can compensate for a bad analyst/designer against whether a good analyst/designer needs a method at all. Our experience of using the method is that the different types of scenario and the clear steps that transform one into another do indeed provide analysts with a good structure that helps them go into a new domain and explore the design space.

WORKED EXAMPLE

OPaL was a European Union research and development grant concerned with developing a new system to assist people in forming partnerships without having to make physical contact. OPaL stands for ‘online partner lens’. The aim was to build a system for small and medium enterprises that could represent partners in ways that allow them to be sampled as ‘experiential’ goods (as opposed to just seeing a bland description of a company), and to assess each other's suitability in online interactions. Such a ‘rich’ representation was challenging in terms of knowledge elicitation—it must capture and accommodate characteristics that are difficult to model formally, such as trust, compatibility, and confidence. It was also challenging in terms of interaction design: it must accommodate potential partners’ evaluations of each other and represent them effectively. OPaL would provide users with the ability to explore the influence of ‘social attributes’ in contingent partnerships by building a system that assesses the strength of partnerships based on 1) matched competences, 2) compatibility and 3) perceived confidence, both separately and in combination.

The project consisted of three development partners and three user partners. The countries involved were Germany, the UK, and Spain, each of which had a user and development partner. In each country, the user partners were encouraged to produce user stories and from these develop abstract scenarios. Some partners used very participative methods to gather the stories, others used more observational methods and in other circumstances the partners came up with the stories themselves with little input from the analysts.

The documentation of the outputs was slightly different than presented earlier—but the key thing to observe is the concepts that are employed rather than the exact representation. Although representation can be important to the usability of a method, it is the key constructs that are critical. In the example below, the looser form of the scenario suited the context better, but perhaps lost some of the clearer understanding that is provided by the suggested structure and method described in the previous section.

The On-Line Partner Lens (OPaL)

The overall aim of OPaL is to provide a software facility that enables the formation of partnerships between geographically remote small to medium sized organisations. To some extent it is like a computer dating service, or a brokering service: it is a software environment that brings together organisations allowing dynamic configuration of teams. An innovative feature of OPaL is the idea that it would have three ‘layers’; the first would deal with general competences, the second with compatibility issues and the third with confidence and trust.

The following sections show the original user story and how it was used to generate a specific part of the overall design. This is only a small portion of OPaL, which in fact included nine such stories. The scenario that was generated from this and similar stories is included in detail, so that the range of design decisions—and how the scenario helps generate them—are exposed. The story concerns a small IT consultancy firm, DCA.

USER STORY

For a number of years, DCA had been involved in the collection of learning opportunity data. More recently, the company had begun to get involved in software development, primarily to facilitate its data collection and aggregation activities across Scotland. It was part of the company's strategy to safeguard and expand its data collection activities and also to seek opportunities to explore further software development opportunities.

DCA collected learning opportunity data for an increasing number of areas within Scotland for the purposes of producing a Scottish database of learning opportunity information. In England, such data collection activities were carried out by around 80 individual organisations each covering a specific geographic location (known as Training and Enterprise Councils). Some of these TECs collected their own data while others contracted with third parties to collect the data. Although some TECs shared data with each other, there was no national database covering England as there was in Scotland. The Employment department in England was keen to put this situation right and in addition to ensuring there was a national database it was also intending to launch a national helpline that would provide information on education and training to callers across the country.

Not all TECs in England used the same software to store learning opportunity data and this made it difficult to aggregate data into a single database. At the same time DCA was keen to win a contract with the Employment Department to develop a version of its Scotia software for the English Market.

The Employment Department issued a contract notice that combined a number of elements including a range of Call Centre software applications that would allow for data to be imported irrespective of the original format of the data. It was the software development activities, which appealed to DCA and initiated the process outlined in the scenario below.

Although DCA had some contact with many of the agencies doing similar work in England via a number of networks that looked at software and standards issues there was a much limited number who played a significant role. The organisation, referred to as Company B below, had been active in this field for a number of years and already held contracts with the Employment Department to carry out research and promote national co-ordination in the area of data collection. It therefore seemed most appropriate that DCA initially made contact with this organisation.

Conceptual Scenario

This story and others like it were finally grouped together into the ‘invitation to tender’ scenario. It is reproduced here in its entirety, complete with the footnotes illustrating how the scenario helped to raise design issues.

1. Scenario Type
2. Invitation to tender
3. Rationale
4. The invitation to tender is a familiar activity for many SMEs. Tenders are issued by government agencies and are posted to a web site and published in a paper journal. Typically, any single SME will not have the full range of expertise needed to fulfil the tender so they will have to find willing and able partners. These partners must also be compatible in their ways of working and there must be confidence that the collaboration will be successful.
5. People—Hugo of DCA.
6. Activities—Finding partners and evaluating them in terms of working relationships for a particular tender.
7. Context—In the DCA office with all associated support.
8. Technologies—The proposed OPaL system, full Internet access, etc.

Scenario description

P1	Hugo browses through the OJEC (Official Journal of the European Commission) one morning and identifies an invitation to tender that would suit DCA. He requests the tender specification from the OJEC and begins working through it to identify what needs to be done for the bid.
P2	First, he notes that the closing date for tenders is less than two weeks away and so he needs to move quickly. The proposed system is divided into two subsystems, a network system and a client-record database system. The description of requirements suggests that some legacy equipment exists, requiring integration into the new work system.
P3	At this point Hugo begins to recognise the need to form a partnership with a Network consultancy although he has no one in mind as yet. Page 13 of the tender specification, a rough floor plan, further emphasises this need. The invitation to tender suggests that some history of developing similar systems inclusive of cost-breakdown indications are considered as bonuses by the clients and so Hugo intends to refer to his ‘history record’ on the OPaL site. Furthermore, whilst it is suggested that tenders to supply one of the two required sub-systems will be considered, it is favourable towards tenders offering the whole system. This makes Hugo committed to finding a partner who can enable DCA to bid for the whole project.
P4	A ‘pulling’ factor of this bid is that there is the prospect of further work. The proposed system is to act as a pilot scheme from which it could be tailored to a further 80 sites across Scotland. Additionally, each of these sites would need integrating and so a successful bid could be very lucrative to DCA. Hugo begins to build an outline for a bid and decides that he now needs to find a partner with the additional skills set to complete his bid.
P5	Having identified the skills that DCA requires (ability to network, membership of CIPFA, ability to complete tasks on time, etc.), Hugo logs on to OPaL and inputs his search criteria. Just to make sure, Hugo checks his ‘hits’ for possible advances being made to him, but at this point there do not appear to be any.
P6	The browser recognises five possible companies. The first company that Hugo contacts via e-mail is busy for the unforeseen future. The second company Hugo recognises as having a bad reputation (from personal past experience) for meeting deadlines and so chooses to ignore this company. He is now left with three companies.
P7	He needs to find out more about the remaining three companies and so explores their profiles that are posted on OPaL. None of these companies X, Y, and Z is perfect but they all seem interesting. Hugo intends to trade off against suitable shared work practices and other bonuses, and so on and play for the most appropriate, for DCA and the project tender. He decides to make contact via email. He invites them individually to layer two of OPaL.
P8	Company X and Y both respond within 4 hours and company Z does not respond for another 48 hours. Hugo takes this to be a bad sign in terms of work practices and meeting deadlines and so writes off company Z. Two companies remain, X and Y.
P9	In layer two, Hugo opens up the online messaging component and initiates communication with each company individually. First of all he contacts company X. Hugo does this right away. After the initial correspondence Company X checks DCA out on the OPaL system and finds that they would seem to be a good company to enter into a partnership with. They flick through the tender specification and decide that they are keen to be involved with this partnership.
P10	Hugo and company X re-enter the online messaging function for some question and answer communication. This interaction will indirectly identify things like shared practice, shared understanding of the tender specification, approaches to be taken, and so on. Examples of questions asked are, when did you last do a costing of this kind? Do you think this is feasible or should we question the specification? What about page 3? Both companies DCA and company X later go to check the interaction patterns that have emerged from the online messaging task and find that they seem compatible.
P11	Hugo now contacts company Y. After a similar interaction with company Y, they take the initiative and invite Hugo to move to layer 3 for some ‘gaming’. Hugo decides that this is not the way in which he would like to progress and considers this a bad sign. They are likely to have conflicting ways of working. He is fortunate, as Company X is looking very promising. Hugo responds to company Y's request thanking them kindly for their interest, but feel that for this project they would not be suitable.
P12	Hugo now feels that he would like to invite company X to layer three. Company X agrees and they decide to undertake a structured interaction. During this task, they open a shared document space through which they can both up-load and work on documents. They undertake a conference call in which the sharing out of tasks and responsibilities for writing the bid are negotiated. Disagreements are resolved and time scales are met for the preliminary drafts.
P13	The partnership looks as if it may work well. Having drafted out a plan of action, the intended outcome of the task, they agree to meet again (conference call) the following morning and discuss the next stage and the results of the confidence analysis. The analysis shows that there are some delicate areas that may require discussing at this point, for example, contested roles. At this point, further discussion is required to avoid further breakdowns and to ensure that they consider some repair mechanisms.

Using the Scenario in requirements

It is difficult to capture all the issues that this scenario raises and how it is used in requirements work. Of course many of the ideas raised in the footnotes were discussed in the project team. The notes included in the section illustrate some further thoughts and issues that arose.

Further notes

Time: Six weeks—Company A works frequently on a basis of ‘fast track’ bids with a six-week preparation time. So this is ‘swift’ partnership.

The approaches to other partners were made on the basis of tacit knowledge—who is good at what—in a relatively small professional network. Third-party recommendations come into play—there is a ‘chain’ of recommendation or a ‘snowball’ effect. Social capital may be a factor here.

The negotiations for the partnership were handled at Director level; the colleagues who would have to work together did not meet each other.

The face-to-face meetings between A and B, and A, B, and C were considered ‘successful’; ‘rapport’ was good. The attributes of rapport need to be explored. These meetings were very task focused, and any underlying cultural factors were not considered.

It would be useful to know what was in the contract.

OPaL issues

Broaden the field of candidates—use of the personal network left potential possibilities unexplored—premature closure? Need to consider what attributes the candidates should have.

OPaL should be linked to tracking services for example OJEC/CORDIS calls.

The OPaL tool should allow a company to direct potential partners to OJEC notices or even allow access to a space where OJEC notices can be ‘pasted’ for view/comment by others.

The discussions with the companies could be held on the conference layer.

Leadership issue: OPaL might help identify/explore leadership styles. It could assist the potential partners in producing leadership criteria for a particular project in order that rational decisions can be taken.

OPaL needs to capture generic information about projects—financial structures, cash flow, deadlines—as patterns of use are likely to vary according to the project/team/partner situation and type.

‘Games’ need to be designed to capture situational features and reveal attributes.

Need for a sub-layer of recruitment that allows ‘lower’ people in the project to explore each other's working styles.

Need to have some information that allows partners motives to be assessed—need to recognise that motives vary across the team. Would standard competitive intelligence reveal anything?

Conceptual Design

The scenarios were examined for objects and actions, and these were aggregated across the nine scenarios. Individual diagrams were produced where relevant, and were finally compiled into the overall diagram of system functionality (Figure 11.5).

Use Cases

Following the process of task/function allocation, it becomes possible to specify the use cases for the system. The following table presents a first draft of Use Cases and the functions contained within each Use Case.

Figure 11.6 provides the more detailed specification of UC03.2 setting privacy levels.

Design Language

At the time of writing, little work has been done on the final design language for OPaL, certainly not much at the detailed level. A number of possibilities for the OPaL interface were discussed at a design meeting focusing on the interface design.

FIGURE 11.5 Systems functionality

FIGURE 11.6 Use case diagram for specifying privacy

A prototype environment was developed as indicated in Figure 11.7. OPaL could be a multi-paned website which allows navigation, connections, diaries and personal organisers, and project schedules. Computer games environments, where users adopt characters and interact with other characters would be included perhaps as 3D environments. The design in Figure 11.7 shows a multi-paned window with different tabs that the user clicks to open up the screens for Profile, Competence, Conference, Confidence, and Review levels.

The language for OPaL could be seen to be developing. Different sections of the environment were represented by tabs at the top of the main pane. E-mail and other functions were enclosed in separate panes at the top level. The usual web-based interaction patterns—click to bring to front, use of ‘Back’ button, scrolling text in panes and so on would be adopted so that new users (of which there could potentially be many) would feel the interface to be quite intuitive. The colours and use of logo would help create an OPaL identity.

Conclusion

The OPaL case study illustrates the method in operation. It was adapted to meet the particular circumstances; the scenarios were not as strongly structured as had been the case in the HIC. We feel that this is not a good thing and that the lack of rigour may have led to misunderstandings; something that can easily happen in scenario-based design, but something that the structured scenario can avoid (Benyon and Macaulay 2002). The scenarios in this case study did help in identifying the major functions and objects that would be needed and they certainly offered a good way of dealing with the gathering of requirements across different sites.

TABLE 11.1 Use case diagram for specifying privacy

Use Case	Functions
UCO1—Pre-registration	1.1 Public 1.2 Enter as member 1.3 Register
UC02—Registration	2.1 Enter Basic Requirements 2.2 Approve Requirements
UC03—Profile management	3.1 Enter further details 3.2 Privacy settings 3.3 Specific relationships
UC04—Search partner profile	4.1 Search profile 4.2 Browse capability
UC05—Assessment management	5.1 Add assessment to Profile 5.2 Examine interchange 5.3 Review assessment
UC06—Interaction component	6.1 Email 6.2 A/V Content 6.3 Shared workspace 6.4 Online dialogue 6.5 Confidence assessment activity 6.5.1 Perform assessment
UC07—Administration
UC08—Partnership management	8.1 New Partnerships 8.2 View Partnerships 8.2.1 View as owner 8.2.2 View as member

COMPARISONS

The method is most closely related to the one provided in (Rosson and Carroll 2002) and indeed was certainly influenced by their previous writings. Their approach to capturing claims and the trade-offs that are inherent in design is more formal than the footnote method used in our method, but they do not specifically identify the differences between user stories, conceptual and concrete scenarios that we have found particularly useful. However, their problem scenarios are similar to user stories and their future activity scenarios are clearly close to our conceptual and concrete scenarios.

FIGURE 11.7 Possible mock up for OPaL showing beginnings of a design language

Cooper (1999) also recommends a scenario-based approach, but he emphasises the development of personas—fictionalised descriptions of typical systems users containing lots of personal and contextual details first. This leads to considering the goals that people have. The personas are used to walk through different scenarios (‘a scenario is a…. persona using a software-based product to achieve a goal’, p. 179) so that designs can be evaluated. Cooper argues that the design should focus on the ‘daily use’ scenario—the actions that people perform with the greatest frequency—and on ‘necessary use’ scenarios that focus on the actions that must be performed, but are not performed frequently. He also notes the existence of ‘edge case’ scenarios that concern unusual conditions.

ACKNOWLEDGEMENTS

Members of the FLEX project working at Napier University, Edinburgh helped to prototype and revise the approach presented here. Thanks to members of the OPaL team for allowing the case study to be used and particular thanks to Liisa Dawson who undertook this work. Also, thanks to Martin Graham for drawing the functional diagrams and use case diagrams.

KEYWORDS

User Stories

Conceptual Scenario

Concrete Scenario

Use Case

Design Method

Human-Centred Interaction

Design

REFERENCES

Alexander, C., Ishikawa, S., and Silverstein, M., A Pattern Language: Towns, Buildings, Construction, Oxford University Press, New York, 1977.

Benyon, D.R. and Macaulay, C., Scenarios and the HCI-SE design problem, Interacting with Computers, 14(4), 397–405 2002.

Benyon, D.R., Turner, P., and Turner, S., Designing Interactive Systems, Addison-Wesley, 2004.

Boehm, B., The spiral model of software development and enhancement, IEEE Computer, 21(5), 61–72, 1988.

Cooper, A., The Inmates are Running the Asylum: Why High-Tech Products Drive us Crazy and How to Restore the Sanity Sams, Macmillan, Indiana, IN, 1999.

Davenport, E. (2003) Interpersonal Knowledge and Organisational Foresight: The Case of Online Partnership in Micro-Organisations, in K. Srikantaiah and M. Koenig (Eds.) Knowledge Management; Lessons Learned. Learned Information, 379–397, 2004.

Erickson, T., Supporting interdisciplinary design: toward pattern languages for workplaces, in P. Luff, J. Hindmarsh, and C. Heath (Eds.), Workplace Studies: Recovering Work Practice and Informing System Design, Cambridge University Press, Cambridge, UK, 2000, pp. 357–368.

Graham, I., A Pattern Language for Web Usability, Addison-Wesley, 2003.

Hix, D. and Hartson, D., Developing User Interfaces: Ensuring Usability through Product and Process, Wiley, 1993.

Imaz, M. and Benyon, D.R., How stories capture interactions, in C. Johnson and A. Sasse (Eds.), Proceedings of Interact '99, North Holland, 1999.

Rheinfrank, J. and Evenson, P., Design languages, in T. Winograd (Ed.), Bringing Design to Software, ACM Press, 1996.

Rosson, M.-B. and Carroll, J., Usability Engineering, Morgan Kaufman, 2002.

RECOMMENDED READING

Rosson, M.-B. and Carroll, J. (2002) Usability Engineering, Morgan Kaufman. This book provides a good method for undertaking scenario-based design. Many of the concepts discussed here appear in their book, though often under a slightly different name. Rosson and Carroll do distinguish different types of scenario, but tend to focus on different types of activity rather than where they are used in the life cycle.

Cooper, A. (1999) The Inmates are Running the Asylum: Why High-Tech Products Drive us Crazy and How to Restore the Sanity Sams, Macmillan, Indiana, IN. This is a very entertaining and informative book with excellent advice on design and suggestions for taking a goal-centred approach. Cooper emphasises the importance of scenarios and, importantly, the need to develop rich and meaningful descriptions of people.

Benyon, D. R., Turner, P., and Turner, S. (2004) Designing interactive Systems, Addison-Wesley. This new text book covering the whole life cycle of human-computer interaction and the design of interactive systems describes the method used here in defile and includes other examples of this scenario-based design approach.

Carroll, J. (2000) Making Use, MIT Press is a thoughtful book about scenarios in general, where they can be used and where they are most effective.