Neville A Stanton
email: n.stanton@soton.ac.uk

Human Factors Engineering as the Methodological Babel Fish: translating user needs into software design

Keywords: Human Factors Methods, Requirements Specification, Case Study

The aim of this paper is to show, by way of two case studies, the value of including Human Factors in interaction and interface design specification. It is argued that Human Factors offers and unique and useful perspective and contributes positively to design. Human Factors sits between subject matter experts and software engineers, translating user requirements though the applications of theory, models and methods. This results in software design requirements that have been intelligently interpreted and presented in a graphical manner. The two case studies demonstrate the differences between the interfaces with and without Human Factors input. Both cases show quantitative and qualitative benefits of including Human Factors in design. Performance improvements between 20-70 percent were demonstrated, which is typical of Human Factors design interventions.

Introduction to Human Factors Methods

The purpose of this paper is to show the benefit of Human Factors (HF) methods in system specification and design. Human Factors has a broad remit, covering all manner of analysis from human interaction with devices, to design of tools and machines, to team working, and general aspects of work and organisational design. The Human-Centred Design of Systems is also covered by the International Standard ISO13407. This emphasises the need to focus on the potential users of systems at all stages in the design and development process in order to ensure that requirements have been adequately defined and that functions are allocated between user and technology appropriately [START_REF] Stanton | Human Factors Methods: A Practical Guide for Engineering and Design[END_REF]. Much has been made about the timeliness of Human Factors input into projects, arguing that the appropriateness of the analysis will depend upon a number of factors [START_REF] Stanton | Handbook of Human Factors and Ergonomics Methods[END_REF][23] [START_REF] Stanton | Human Factors Methods: A Practical Guide for Engineering and Design[END_REF], including which stage of design the project is at, how much time and resources are available, the skills of the analyst, access to the end-user population, and what kind of data are required [START_REF] Stanton | A Guide to Methodology in Ergonomics: Designing for Human Use[END_REF]. [START_REF] Stanton | A Guide to Methodology in Ergonomics: Designing for Human Use[END_REF] [START_REF] Stanton | A Guide to Methodology in Ergonomics: Designing for Human Use[END_REF] showed that many of the methods they reviewed were flexible with regard to the design stage they could be applied to. Indeed many of the methods could be applied to very early stages of design, such as to concept models and mock-ups. Many methods may be used in a predictive as well as an evaluative manner. This flexibility of application to the various design stages bodes well for Human Factors methods. Other factors that the analyst needs to be aware of when choosing methods are: the accuracy of the methods (particularly where a predictive element is involved), the criteria to be evaluated (such as time, errors, communications, movement, usability, and so on), the acceptability and appropriateness of the methods (to the people being analysed, the domain context, resources available, and so on), and the cost-benefit of the method(s) and the product(s). Methods form a major part of the Human Factors discipline. For example, the International Encyclopaedia of Human Factors and Ergonomics [START_REF] Karwowski | International Encyclopaedia of Ergonomics and Human Factors Vols I-III[END_REF] has an entire section devoted to methods and techniques. Many of the other sections of the encyclopaedia also reference to, if not provide actual examples of, Human Factors methods. In short, the importance of Human Factors methods cannot be overstated. These methods offer the ergonomist a structured approach to the analysis and evaluation of design problems. The Human Factors approach may be described using the scientist-practitioner model [START_REF] Stanton | Human Factors Methods: A Practical Guide for Engineering and Design[END_REF]. As a scientist, the Human Factors researcher is:

• extending the work of others;

• testing theories of human-machine performance;

• developing hypotheses;

• questioning everything;

• using rigorous data collection and analysis techniques;

• ensuring repeatability of results;

• disseminating the finding of studies.

As a practitioner, the Human Factors engineer is:

• addressing real-world problems;

• seeking the best compromise under difficult circumstances;

• looking to offer the most cost-effective solution;

• developing demonstrators and prototype solutions;

• analysing and evaluating the effects of change;

• developing benchmarks for best practice;

• communicating findings to interested parties.

According to Stanton et al (2005) [START_REF] Stanton | Human Factors Methods: A Practical Guide for Engineering and Design[END_REF] Human Factors will work somewhere between the poles of scientist and practitioner, varying the emphasis of their approach depending upon the problems that they face. Human Factors and Ergonomics methods are useful in the scientist-practitioner model, because of the structure, and potential for repeatability, that they the offer. There is an implicit guarantee in the use of methods that, provided they are used properly, they will produce certain types of useful products. It has been suggested that Human Factors and Ergonomics methods are a route to making the discipline accessible to all [START_REF] Diaper | Task Analysis in Human Computer Interaction[END_REF] [START_REF] Wilson | A framework and context for ergonomics methodology[END_REF]. Despite the rigor offered by methods however, there is still plenty of scope for the role of experience. [START_REF] Annett | Task Analysis[END_REF] [START_REF] Annett | Task Analysis[END_REF] summarised the most frequently asked questions raised by users of Human Factors methods as follows:

• How deep should the analysis be?

• Which methods of data collection should be used?

• How should the analysis be presented?

• Where is the use of the method appropriate?

• How much time/effort does each method require?

• How much, and what type, of expertise is needed to use the method(s)?

• What tools are there to support the use of the method(s)?

• How reliable and valid is/are the method(s)? [START_REF] Annett | A note on the validity and reliability of ergonomics methods[END_REF] [START_REF] Annett | A note on the validity and reliability of ergonomics methods[END_REF] questions the relative merits for construct and criterionreferenced validity in the development of Human Factors theory. He distinguishes between construct validity (how acceptable the underlying theory is), predictive validity (the usefulness and efficiency of the approach in predicting the behaviour of an existing or future system), and reliability (the repeatability of the results). Investigating the matter further, Annett identifies a dichotomy of Human Factors methods: analytical methods and evaluative methods. Annett argues that analytical methods (i.e., those methods that help the analyst gain an understanding of the mechanisms underlying the interaction between human and machines) require construct validity, whereas evaluative methods (i.e., those methods that estimate parameters of selected interactions between human and machines) require predictive validity. This distinction is made in Table 1.

Results from independent samples agree

This presents an interesting question for Human Factors, are the methods really mutually exclusive? Some methods appear to have dual roles (i.e., both analytical and evaluative, such as Task Analysis For Error Identification), which implies that they must satisfy both criteria. However, it is plausible, as [START_REF] Baber | Evaluating Human-Computer Interaction[END_REF] [START_REF] Baber | Evaluating Human-Computer Interaction[END_REF] argues in terms of evaluation, that the approach taken will influence which of the purposes one might wish to emphasise. The implication is that the way in which one approaches a problem, e.g., along the scientist-practitioner continuum, could well have a bearing on how one employs a method. At first glance (particularly from a 'scientist' perspective) such a 'pragmatic' approach appears highly dubious: if we are selecting methods piecemeal in order to satisfy contextual requirements, how can be certain that we are producing useful, valid, reliable etc. output? While it may be possible for a method to satisfy three types of validity: construct (i.e., theoretical validity), content (i.e., face validity), and predictive (i.e., criterion-referenced empirical validity), it is not always clear whether this arises from the method itself or from the manner in which it is applied. This means that care needs to be taken before embarking on any application of methods to make sure that one is attempting to use the method in the spirit for which it was originally designed.

Prior to embarking on any kind of intervention (be it an analysis, design or evaluation of a system), an Ergonomist needs to have a strategy for deciding what methods to use in and how to adapt to the domain context [START_REF] Annett | Conclusions[END_REF]. Determining an appropriate set of methods (because individual methods are rarely used alone), requires some planning and preparation. [START_REF] Stanton | A Guide to Methodology in Ergonomics: Designing for Human Use[END_REF] [START_REF] Stanton | A Guide to Methodology in Ergonomics: Designing for Human Use[END_REF] proposed a process model to guide the selection of methods, as shown in Fig. 1. As Annett (2005) [START_REF] Annett | Conclusions[END_REF] points out, care and skill is required in developing the approach for analysing the problem, formulating the intervention, implementing the intervention, and determining the success of the intervention. Complex systems may require the Ergonomist to have a flexible strategy when approaching the problem. This can mean changing the nature of the analysis and developing a new approach as required. Thus, pilot studies are often helpful in scoping out the problem, before a detailed study is undertaken. This may mean that there can be several iterations through the criteria development and methods selection process. Of course, from a practitioner perspective, the time taken to carry out pilot studies might simply be unavailable. However, we would argue that there is no harm in running through one's selection of methods as a form of 'thought-experiment' in order to ascertain what type of output each method is likely to produce, and deciding whether or not to include a method in the battery that will be applied. While it is important not to rely too heavily on a single approach, nor is there any guarantee that simply throwing a lot of methods at a problem will guarantee useful results.

Develop criteria for ergonomic analysis

Assess pool of methods against criteria

Decide upon ergonomics intervention

Select and apply methods: Analyse output

Assessment of the effectiveness of the intervention

Validate selection process

Validate criteria development

Validate assessment process

Fig. 1. Validating the methods selection and Human Factors intervention process (adapted from

Stanton & Young, 1999 [START_REF] Stanton | A Guide to Methodology in Ergonomics: Designing for Human Use[END_REF]).

As shown in Fig. 1, method selection is a closed loop process with three feedback loops. The first feedback loop validates the selection of the methods against the selection criteria. The second feedback loop validates the methods against the adequacy of the ergonomic intervention. The third feedback loop validates the initial criteria against the adequacy of the intervention. There could be errors in the development of the initial criteria, the selection of the methods, and the appropriateness of the intervention. Each should be checked. The main stages in the process are identified as: determine criteria (where the criteria for assessment are identified), compare methods against criteria (where the pool of methods are compared for their suitability), application of methods (where the methods are applied)), implementation of Human Factors intervention (where an Human Factors programme is chosen and applied) and evaluation of the effectiveness of the intervention (where the assessment of change brought about by the intervention is assessed).

Two case studies are presented to demonstrate the added-value of Human Factors to system design and engineering. They also demonstrate some aspects of the requirements specification process. The first case study is based on the development of the drivers interface for a Stop and Go Adaptive Cruise Control system. Further information on the system development and evaluation may be found in [START_REF] Stanton | Detection of new in-path targets by drivers using Stop & Go Adaptive Cruise Control[END_REF] [START_REF] Stanton | Detection of new in-path targets by drivers using Stop & Go Adaptive Cruise Control[END_REF]. The second case study is based on the development of the pilots interface for a Mission Communication Planning system. Further information on the system development and evaluation may be found in [START_REF] Stanton | Designing mission communication planning: the role of Rich Pictures and Cognitive Work Analysis[END_REF] [2221].

Case Study 1: Stop & Go Adaptive Cruise Control

Stop & Go Adaptive Cruise Control (S&G-ACC) is a system that maintains cruise speed in the same way as a conventional cruise control system, but also maintains the gap to the vehicle ahead by operating the throttle and brake systems. The S&G-ACC control module is mounted at the front of the vehicle, which uses radar to measure the gap and closing speed to the vehicle ahead. Once the vehicle has become stationary, the driver must intervene. This can be achieved by pressing the resume button, which will reactivate S&G-ACC providing a sufficient distance to the vehicle ahead has been attained, or by depressing the throttle, which will always override the system. The system is immediately cancelled by either the cancel button or driver braking. S&G-ACC is an extension to regular ACC, which has previously only operated above 26 kph. The capability of S&G-ACC over ACC is achieved by adding radar that can operate at slow speeds over short distances. The system has a built-in monitoring capability and so the speed is limited to that chosen by the driver, and the level of deceleration is also limited by the designers of the system. The system will not undertake emergency braking and under such conditions the driver will be required to intervene. When the driver is required to operate the brakes, i.e. the maximum S&G ACC brake level is reached, the system warns the driver by an audible warning. Due to the limited braking of the system, the driver may be called upon to intervene when approaching a slow moving or stationary object. The likelihood of the driver needing to intervene increases with the speed of the vehicle. The S&G-ACC system had also been designed for assistance in queuing scenarios, to keep a set distance behind slow moving vehicles.

The original system to be tested presented an amber follow icon when the vehicle enters follow mode and the icon is extinguished when the vehicle leaves follow mode. This is the simplest interface, as shown in Fig. 2a. A re-development of this interface was to indicate the presence of a new in-path target (e.g., a new vehicle) by flashing the icon red at first (as shown in Fig. 2b), before assuming steady state of the amber icon. The third interface represented a departure from the follow icon design. This interface encapsulated the driver requirements on temporal, spatial and mode information, by mapping the in-path target data onto a representation of the radar display (as shown in Fig. 2c). This offered a direct relationship between the position of the in-path target in the world (i.e., the position of another road user) and its representation on the driver interface (i.e., the highlighted ball in the centre of the display at 21 metres). The mapping between the different interface designs and the elements of Situation Awareness (SA) is indicated in Table 1. As Table 2 shows, all three interface designs support mode awareness but only the radar display supports spatial awareness and, to a limited extent, temporal awareness. Cognitive mismatch is a general problem for automated systems [START_REF] Baxter | Cognitive mismatches in the cockpit: Will they ever be a thing of the past[END_REF], so design needs to focus on communication of the appropriate modal, spatial and temporal information.

It was therefore anticipated that performance of drivers, in detecting new in-path targets that had been acquired by the S&G-ACC system, would be superior with the radar display. Seppelt & Less (2007) [START_REF] Seppelt | Making adaptive cruise control (ACC) limits visible[END_REF] argue that interface design needs to communicate the system limits in a continuous manner to the driver. The radar display analogy offers continuous information on modal, spatial and temporal changes (which the driver can compare to information in the world) whereas the two other iconic displays only communicate discrete information on modal changes.

Table 2.

Mapping interface design and the SA elements.

Interface Design

Modal Awareness

Temporal Awareness

Spatial Awareness

Standard Icon

Flashing Icon

Radar Display

The dark shaded area in Table 2 indicates that the interface supports the type of SA. For example the standard and flashing icons only support mode awareness, because they are only lit if a target vehicle is being tracked by the S&G-ACC system, which changes the vehicle from 'cruising' mode to 'following' mode. As well as mode awareness, the radar display can also communicate spatial awareness information, i.e., the range and direction of the target vehicle. Some limited temporal awareness information may also be communicated via the radar display (shown by the lighter shading) as the target gets closer to or further on away from the host vehicle, i.e., the rate of approach of the target vehicle. Additional time-to-contact information would need to be provided to better support time situation awareness. For the driver of a car with S&G-ACC, spatial relevance of other vehicles (e.g., longitudinal and lateral position of in-path target), temporal relevance of other vehicles (e.g., time to impending contact), and modal relevance of other vehicles (e.g., acquisition of a new in-path target or not) are extremely important. Integration of all this information should help to ensure that the driver responds appropriately to the dynamic roadvehicle environment. Bookhuis et al (2008) [START_REF] Brookhuis | Driving with a congestion assistant: mental workload and acceptance[END_REF] report high driver acceptance of a congestion assistant that was functionally similar to the S&G-ACC system. Further [START_REF] Bliss | Alarm mistrust in automobiles: how collision alarm reliability affects driving[END_REF] [START_REF] Bliss | Alarm mistrust in automobiles: how collision alarm reliability affects driving[END_REF] propose that drivers are more likely to accept systems that have greater operational reliability in reporting of information about the state of the world as well as optimizing driver responses.

As shown in Fig. 3, far fewer changes in in-path target were detected with the icon interfaces. This suggests that driver's were more likely to commit mode errors in these conditions, as they were less able to detect the fact that the S&G-ACC system had acquired a new in-path target and was no longer tracking the old one. With multiple in-path targets present, it would seem to be important that the driver should know which one is being tracked by the S&G-ACC system. In summary, drivers were more able to detect the change of an in-path target with the radar display than the two icon displays (based on data from in-path, multiple-target, test -to simulate a vehicle queuing scenario where other road users (such as cyclists, pedestrians and motorcyclists) might pass between the host vehicle and the tracked vehicle). This means that, in a situation with multiple vehicles, drivers were more likely to mistake the target vehicle being tracked by the automatic S&G-ACC system when using the iconic interfaces. The finding that drivers in the iconic display conditions were less able to identify changes of the in-path targeting by the system, raises the idea that mode errors were more prevalent in iconic conditions, as the drivers' reports of system status departed from its actual status. Mode errors are of particular interest, because they are the result of people's interaction with technology. In his classification of human errors, [START_REF] Norman | Categorisation of action slips[END_REF] [START_REF] Norman | Categorisation of action slips[END_REF] singled this error type out as requiring special attention in the design of technological systems. The misclassification of the mode of the automatic S&G-ACC system could lead to driver errors which might have serious effect. Mode awareness by the driver should be of utmost importance. A measure of the success of the design will be the extent to which drivers are aware which mode the system is in, and how that relates to the behaviour of the vehicle in any given situation. The mode errors in this study were related to the drivers' failure to appreciate that the automatic system had changed its in-path target vehicle. This means that the driver thought that the S&G-ACC system was tracking one target whilst, in fact, it was tracking another. Other studies have shown that mode errors can have potentially disastrous outcome on system performance [START_REF] Norman | The "problem" with automation: Inappropriate feedback and interaction, not "overautomation[END_REF][18] [START_REF] Woods | Behind Human Error: Cognitive Systems, Computers and Hindsight[END_REF]. In the case of S+G-ACC, one can imagine a scenario where the host vehicle is tracking a leading vehicle when a motorcycle pulls between the host and tracked vehicle. The question for the driver of the host vehicle is whether the S&G-ACC system had acquired the motorcycle as the new in-path target, or is still tracking the original vehicle. This judgment becomes even more important if the original tracked vehicle increases its speed, as the host vehicle will similarly increase speed in order to maintain the gap between the two vehicles [START_REF] Seppelt | Making adaptive cruise control (ACC) limits visible[END_REF].

If the driver is able to determine that the S&G-ACC has not acquired the motorcycle as the new in-path target, then they will be able to prepare for a manual intervention. The findings from the study reported in this paper suggest that the radar display will be more useful to the driver in the scenario described above than the iconic displays in reducing cognitive mismatch [START_REF] Baxter | Cognitive mismatches in the cockpit: Will they ever be a thing of the past[END_REF] and these effects are likely to become more marked over time [START_REF] Lai | The long-term effect of intelligent speed adaptation on driver behaviour[END_REF].

Case Study 2: Mission Communications Planning

The main function of the MPS communications software is to allow helicopter pilots to load a collection of radio frequencies such that when airborne, pilots have easy access to all of the frequencies they will require, and that each of these frequencies is properly labelled with regards to where and with whom that frequency is associated. The MPS software contains a visual display of a map of the United Kingdom displaying the boundaries of all major controlled airspaces, including military danger zones and minor and major air fields and airports. By studying the proposed route, marked on the map by a solid black line, pilots must decide what frequencies they will need for their mission. These frequencies must then be looked up in one of the Royal Air Force (RAF) Flight Information Publications, for example the British Isle and North Atlantic en-route supplement (BINA). A detailed description of the process of planning communications in MPS can be found in McIlroy, [START_REF] Mcilroy | Developing expertise in military communications planning: Do verbal reports change with experience?[END_REF] [START_REF] Mcilroy | Developing expertise in military communications planning: Do verbal reports change with experience?[END_REF] and in [START_REF] Stanton | Designing mission communication planning: the role of Rich Pictures and Cognitive Work Analysis[END_REF] [START_REF] Stanton | Designing mission communication planning: the role of Rich Pictures and Cognitive Work Analysis[END_REF].

In its present guise, the communication planning software interface is perceived as difficult to use, which has implications for training and mission planning, as indicated by the following quotes from experienced pilots who also train others:

"The AH has an incredibly capable communications suite. However, it is regularly under-utilised by the front-line as the planning and setup process is overly complicated and error prone." "Training aircrew to configure the wide variety of voice, data and frequency agile encrypted radios on the Helicopter is an overly intensive task for both staff and students -primarily due to the overly complex tools used to configure various radio, channels & Nets."

Some of the complexity is due to the inherent complexity of the system components (e.g., there are 4 radios, 60 call-signs, 10 presets, 4 boot-up channels -all doubled for a two day communications plan) coupled with the constraints acting on communications planning (e.g., the standard operating procedures for communications settings, the mission timings, changes in airspace authority and so on). Helander (2007) [START_REF] Helender | Using design equations to identify sources of complexity in humanmachine interaction[END_REF] notes that computerisation of systems is making the coupling of systems even more complex, and that uncoupling of system elements may make interaction design more achievable. Although the current generation of communications planning starts with the presentation of a map with a route, communications planning resorts to a series of tables, fields and buttons (as shown in Fig. 4). We suspect that this results in a disconnection between how pilots think about planning their communications and what the software requires of them to prepare a communications plan. This line of reasoning was explored in the research presented within the current paper. At the beginning of the project, two full day meetings were held with a subject matter expert (SME) in which the analysts were introduced to military communications in general and to the current software technology in particular. The analysts were supplied with a version of the MPS software to inform analyses. Across a further six days, the analysts worked with the SME to further their understanding of the mission planning process and the MPS software through SME walkthroughs of different communications planning tasks. During these meetings the SME produced a number of Rich Pictures [START_REF] Checkland | Systems Thinking, Systems Practice[END_REF] of the communications planning task. A Rich Picture is graphical representation of a problem, concept, situation or work domain. It can include any kind of figure or text and has no prescribed rules or constraints. The Rich Picture has its origins in Soft Systems Methodology [START_REF] Checkland | Systems Thinking, Systems Practice[END_REF][9] and its primary purpose is to describe a system in such a way that is useful to both individuals external to, and actors within that system; it serves to organise and structure the body of information provided by the expert. Rich Pictures are commonly used in information systems education [START_REF] Horan | A new and flexible graphic organiser for IS learning: The Rich Picture[END_REF], as they can often provide easily interpretable depictions of complex systems. An example of the Rich Picture for the concept of air-to-ground communications is presented in Fig. 5. In the route is displayed by the solid line with waypoints and circles on the line. The dashed circles indicate airspace boundaries associated with an airfield (the cross on a circle in the centre of the airspaces). The dashed line indicates the planned diversion. The boxes represent collections of frequencies associated with each airfield. One of the most significant problems with MPS was the lack of correspondence between the user's mental model and the system model. A mental model is an internal, mental representation of the way things exist or work in the real world. A mismatch between system model and user mental model results in a system that is unintuitive; the way the user thinks about the task is not reflected in the way the user must interact with the system. Rather than relying on a mental representation of the task to guide behaviour the user must use a learnt sequence of actions to progress through the system. For the air-to-ground communications planning stage of the task, results from a think-aloud study (reported in McIlroy, Stanton, & Remington, 2012 [START_REF] Mcilroy | Developing expertise in military communications planning: Do verbal reports change with experience?[END_REF]) suggested that thought processes are map based. The expert explicitly stated that he was using the map to not only guide the decision making process (when deciding which frequencies to include in the plan) but also when getting an overview of the plan so far and when reviewing the completed plan. The Rich Picture presented earlier underlines this mismatch. In this diagram the SME graphically represented his concept of the air-to-ground communications process. The route is presented in such a way as to draw attention to those airspaces that are passed through, and those that are close by. Furthermore frequencies are directly linked to an airspace (indicated by the boxes in Fig. 5); they are not in a separate table only identified by ICAO (International Civil Aviation Organisation) codes (as is the case with the current version on the system and the frequencies are in a separate window shown in Fig. 4, which covers the map).

Another significant issue pertaining to the volume of information requiring management was relatively straightforward to address. In the current system the user must refer to a reference document (BINA) in order to get the frequencies associated with each airspace controlling authority. They must refer to a different reference document (RAF flight information handbook) to find out the name of an airport, airfield or special user airspace from the ICAO code given in the CSF or preset channels list, as these names are not contained within MPS. All of this information, although currently used from a paper-based format, is also held within an electronic database, the Digital Aeronautical Flight Information File (DAFIF). The information held in this file covers the entire globe, and all authorities contained within the file have both frequencies and coordinates associated with them. By taking advantage of this information it is possible to directly link frequency data with map data. In addition, the name of each airspace controlling authority can be displayed with the ICAO code. By linking communications data to the map, the problems of both task organisation and mental model mismatch are addressed, at least for air-to-ground communications.

Fig. 6 displays a screenshot of the proposed interface; on it, a map with a route marked on it is displayed as it would be in MPS, with the exception that there are communication symbols and frequency tables included. The symbols indicate that there is some communications information associated with that position on the map whilst the tables display that information. The symbols were designed and refined in an iterative process via repeated meetings with a subject matter expert. The symbol is displayed on a white background on the so that even if the map is predominately a dark colour, the symbols will still be clear to the user. The symbols are displayed just off centre of the airspace such that runway information is not obscured. The distance of the icon from the centre of the airspace is based on distance on the screen, not mapbased geographical distance. For each airspace a label displaying all associated frequencies is presented alongside a number of options for selection. This presentation of frequencies is largely based on the depiction of frequencies in the Rich Picture for air-to-ground communications, in Fig. 5. To compare the proposed system with the current MPS software tool two simulations were created; a simple one comprising 4 contactable airspace authorities and a complex on containing 8 contactable airspace authorities. The simulations, based on a series of possible screenshots, were constructed such that the amount of mouse travel, number of mouse clicks and number of keystrokes necessary to complete the plan could be recorded (see Table 3). Although the sequence of actions was fixed for each simulation, the method for advancing through the simulated plans was a realistic one. By moving the mouse cursor to the relevant area on the screen and only then clicking to progress it was possible to estimate the amount of mouse travel and number of mouse clicks necessary to complete the plan. The number of keystrokes was estimated from the amount of information requiring insertion by typing. To verify the validity of the proposed system a focus group with a number of SMEs was arranged. During the focus group, which lasted for approximately 6 hours, four Helicopter pilots (responsible for training new recruits in MPS) and two software engineers were present along with the researchers. A presentation was given in which the research conducted, and the resulting proposed system were explained at length. Comments, suggestions and criticisms were encouraged, and although a number of minor changes and additions were recommended, the proposed system was accepted as a vast improvement on the MPS software tool. All of the recommendations to come from the focus group were implemented, and all are contained within the proposed system.

Conclusions

In the first case study of Stop and Go Adaptive Cruise Control, the relative merits of different approaches to in-car display design, several conclusions may be drawn from the work presented in this paper to do with design of the driver interface and testing of that interface on drivers. The interface need only capture the essential features to enable the driver to make direct mappings between the world and the representation of it. In terms of the dynamics of S&G-ACC, this would include the representation of the leading vehicle, its spatial reference to the host vehicle (i.e., spatial situation awareness), an indication of whether or not the leading vehicle has changed (i.e., modal situation awareness), and leading headway of the in-path target vehicle (i.e., temporal situation awareness). Spatial representation is perhaps the easiest to design, and the radar display design attempted to show the relation between the in-path target vehicle and the host vehicle. Modal awareness is more difficult, as it requires representation of a change in state of the system. The flashing of the 'ball' in the radar display (and flashing icon in the icon display) is one way of drawing the driver's attention to the fact that a new target has been detected. Whatever representation is chosen, it needs to be able to communicate the information quickly and effectively to the driver [START_REF] Baxter | Cognitive mismatches in the cockpit: Will they ever be a thing of the past[END_REF] [START_REF] Seppelt | Making adaptive cruise control (ACC) limits visible[END_REF]. Temporal awareness is even more difficult to display. None of the interfaces in the study communicated this information completely effectively. A digital time-to-contact displaying 'seconds' could communicate this information, but it would increase workload dramatically. In the second case study, the Rich Pictures [8][9] were constructed by an SME primarily to the researchers gain a fuller understanding of the communications planning task independent of MPS. Not only did the pictures gave a valuable insight into the way in which the expert conceives the task, they also proved an invaluable tool in designing the interface for the proposed communications planning system. The air-to-ground Rich Picture was particularly useful in inspiring the design of the new system; it outlined the SME's representation of the task, showing that the arrangement of frequencies is not list-based but organised into groups of frequencies, each relating to an airspace controlling authority on the map of the ground. The representation of the aircraft's route as it travels through and around airspaces was similar to representation of the route on the map display in MPS; the major difference being that the selection of frequencies, i.e. who will need to be contacted, is done while studying the route, not after studying the route. This has been capitalised on in the proposed system; frequencies are directly tied to the map and can be selected from that view. Mapping the structure of the system interface and interaction design to the user's conceptual models of communications planning has increased the usability of the mission planning software for the communications planning task.

In conclusion, the aim of this paper has been to demonstrate the valuable contribution the Human Factors has to make in the specification and design of systems. The unique insights that arise from the application of Human Factors theories, models and methods appear to result in a deeper understanding of the interactions between people, the tasks they are performing and the requirements for interactions and technological interfaces. Human Factors approaches are both system-oriented (i.e., focusing on the interactions) and systematic (i.e., structured and holistic). The value they add, over and above traditional software engineering, seems self-evident in the two case studies presented. Both projects were undertaken with engineers and subject matter experts who had been involved in the previous design solutions. The role that Human Factors played in these projects was to translate the user requirements into meaningful design representations (i.e., graphical rather than textual) that the engineers could readily code into a prototype interface. It is apparent that this did not occur to the same extent in previous iterations of the interfaces. The benefits were demonstrated in the evaluation, which show improvements of between 20-70 percent over the more traditional design approaches. These benefits are typical of Human Factors interventions.

Fig. 2 .

 2 Fig. 2. The standard icon display.

Fig. 2b .

 2b Fig.2b. The flashing red icon (left) followed by the standard icon (right) display.

Fig. 2c .

 2c Fig.2c. The radar display analogy.

Fig. 3 .

 3 Fig. 3. Detection rates by drivers using the three interfaces.

Fig. 4 .

 4 Fig. 4. The call-sign frequency list for the communications planning.

Fig. 5 .

 5 Fig. 5. Rich Picture of air-to-ground communications.

Fig. 6 .

 6 Fig. 6. Example new communications planning interface.

Table 1 .

 1 Annett's dichotomy of Human Factors methods (adapted fromAnnett, 2002 [1]).

		Analytic	Evaluative
	Primary	Understand a system	Measure a parameter
	purpose
	Examples	Task analysis, training needs analysis,	Measures of workload, usability,
		etc.	comfort, fatigue, etc.
	Construct	Based on an acceptable model of the	Is consistent with theory and other
	validity	system and how it performs	measures of parameter
	Predictive	Provides answers to questions, e.g.,	Predicts performance
	validity	structure of tasks
	Reliability	Data collection conforms to an
		underlying model

Table 3 .

 3 Results for simple and more complex communications plan.

		Findings for simple plan	Findings for more complex plan
		Current	Proposed	Percent	Current	Proposed	Percent
		system	system	decrease	system	system	decrease
	Mouse travel (m)	19	9	52	26	22	17
	Mouse clicks	206	86	58	283	120	58
	Keystrokes	291	32	89	534	116	78
	Time (mins)	22	5	77	32	10	69


Brigit Van Loggem
email: brigit.vanloggem@ou.nl

Assessing Use Complexity of Software: a Tool for Documentation Designers

Keywords: user documentation, use complexity, documentation design

One way to support end users of software is to provide documentation materials such as user manuals and online Help. As not all software is equally difficult to master, documentation designers need to determine the quality and quantity of the information to be included in the user documentation. A first step towards this end would be to assess the complexity of the software from the user's point of view. This paper suggests one approach to such an assessment, based on the idea of use complexity as a multidimensional construct. A consideration of width, depth and height of use complexity can help designers determine documentation requirements.

Introduction

Among the practitioners who work to support users of software are the designers of user documentation. Since manuals and Help systems contain information that is recorded and stored before the software is used in naturalistic environments, documentation designers cannot observe the software being applied to real-life tasks. Matching the quantity and quality of the information to the user's needs, without being able to assess those needs directly, constitutes a major challenge when designing user documentation. Documentation designers need to couple their own indepth knowledge of the software to be documented with a methodical approach; so that even if they can carry out only abstract analyses, these yield valid starting points for design.

This paper briefly outlines one such approach, in which a series of abstract analyses is carried out to assess software complexity from the user's point of view. This is referred to as use complexity: that part of task complexity that originates from the software rather than from other elements in the task environment, including the user. Unlike design complexity, which is the degree to which a program exhibits emergent behavior [START_REF] Aiguier | A Formal Definition of Complex Software[END_REF], use complexity is a measure of the learning requirements (and therefore the documentation requirements) for a particular software system.

As user documentation aims to support users in applying software to real-life tasks, its design must be task-oriented rather than system-oriented [START_REF] Schriver | Dynamics in document design[END_REF]. To do so, it must contain more than straightforward procedural instructions on how to interact with the system, and cover the whole of the "User Virtual Machine" or UVM; which is defined as "not only everything that a user can perceive or experience (as far as it has a meaning), but also aspects of internal structure and processes as far as the user should be aware of them" [START_REF] Van Der Veer | The Human-Computer Interface is the System: A Plea for a Poor Man's HCI Component in Software Engineering Curricula[END_REF]. The visible part of the UVM is what these authors refer to as the "perceptual interface" and what is more commonly referred to as the user interface; but the UVM as a whole is a much larger conceptual machine that exists in the user's mind. A software system is a self-contained "world" with its own objects (think of the Clipboard in many operating systems; of templates, style sheets and fields in a word processing environment; or of layers in an image editor). These software-specific objects, with their mutual dependencies and the rules governing their behavior, are as much part of the UVM as is the interaction layer through which they are accessed. A user needs a thorough understanding of the UVM to gain complete mastery of a particular software tool, and apply it successfully to every task it can possibly be applied to. Such understanding is fostered through metacommunication in the shape of documentation or training [START_REF] Van Der Veer | On the interaction between system and user characteristics[END_REF].

Use complexity describes the UVM, providing a measure of what the UVM consists of rather than how a user interacts with it. As such it is not directly or inversely related to usability, which focuses on the user interaction component of the UVM as indicated in the ISO 9241-11 standard by the definition of usability as the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use. Usability is prescriptive, in that high usability is desirable; whereas use complexity is descriptive, in that high use complexity is not necessarily undesirable. Use complexity is a necessary consequence of versatility [START_REF] Norman | The Invisible Computer[END_REF][START_REF] Norman | Living with Complexity[END_REF]] and a complex system may, but need not, have high usability just as a simple system may, but need not, have low usability.

Dimensions of Use Complexity

Complexity is a multi-dimensional construct [START_REF] Nadolski | Development of an Instrument for Measuring the Complexity of Learning Tasks[END_REF][START_REF] Kim | Selecting and measuring task characteristics as independent variables[END_REF]. The quality and quantity of the learning required to achieve full mastery of a particular software tool can be analyzed from a number of different viewpoints. It is then possible to take the idea of dimensions literally and visualize the results of the separate analyses, leading to an image of use complexity offering pointers for the design of documentation.

Width: Novelty

The first dimension of use complexity to look at is involved with quantity of things to be learned. Learning is required when the software brings novelty to the task environment. Novelty comes in the form of hitherto unknown concepts, with their associated rules and interdependencies, that are exposed to the user and with which he may choose to interact. Where the user is exposed to many novel concepts that he can choose to interact with, and many choices are "wrong" in that they will not lead to an optimum end result, there is much to learn before full mastery is reached. Where at the opposite end of the spectrum there is no novelty to choose, or every choice is equal to every other choice, there is hardly any requirement for learning at all. This quantitative dimension, related to the number of meaningful choices open to the user that originate from novelty in the software world, can be pictured as the "width" of the use complexity. The width of the use complexity is proportionate to the number of hitherto unknown concepts (with their associated rules and interdependencies), brought to the task environment by the software, that are exposed to the user and with which he may choose to interact so that his choice makes a difference.

Several theoreticians have independently presented a hierarchical description of interactive systems. Moran [START_REF] Moran | The Command Language Grammar: a representation for the user interface of interactive computer systems[END_REF], for example, distinguished four levels, or layers, at which a computer tool can be described, one of which (the interaction layer) describes physical interactions with the computer hardware such as: "key presses and other primitive device manipulations". In the context of standard computer use, at least for fully-grown users who are not physically restricted and who possess basic computer skills, the interaction layer can a priori be assumed to be fully mastered. This leaves three layers at which to describe software:

• The task layer is that aspect of a software tool that describes the possible end results of the user's interaction with the software. • The semantic layer is that aspect of a software tool that describes the intermediate steps that the user may carry out to realize a certain result. • The syntactic layer is that aspect of a software tool that describes a user's choice of commands with which he directs the software's behavior.

The use complexity is not necessarily equally wide at the syntactic, the semantic and the task layers. At the task layer the user chooses to work towards a certain end result. At the semantic layer he chooses the next step to realize the result. At the syntactic layer, finally, he chooses which screen area to click or touch, which key or keys to press, which sequence of characters to enter, or which command to vocalize. When analyzing the layers one by one it is important to take all novel opportunities for choice into account, as there is no way of knowing which are important and which are not. Since the higher layers build upon the lower ones, even misunderstandings at the syntactic layer can lead to grief. Concepts such as pressing the Enter key on the keyboard resulting in a paragraph being created, or a space character not being nothing can, when not thoroughly understood, make laying out even the simplest text document very difficult. Conversely, novel concepts at the higher layers may provide meaning to the lower ones. For example, the presence of the concept of "wildcards" at the semantic level may lead to unexpected results for an uninitiated user attempting to search his text for the occurrence of an asterisk.

In Figure 1 the width of the use complexity is roughly sketched, using a relative scale of 1 ("very little") to 10 ("very much"), for three different text processing applications that have all been marketed by Microsoft ® . The base corresponds to the syntactic layer, then comes the semantic layer, and the top represents width of the use complexity at the task layer.

Notepad is judged to have very little novelty to interact with at the syntactic layer: its interface is uncluttered and most of the options open to interaction are well known. At the semantic layer a bit more novelty is found, for example in Notepad's dealing with word wrapping and the use of variables in its page setup; while at the task layer its uses are acknowledged as a tool for holding and converting electronic text that was never intended to be printed. WordPad on the other hand holds a little more complexity at the syntactic layer, mostly due to its formatting capabilities, but less at the task layer as it is mainly geared towards producing a document that is to be printed as laid out on the screen. For Word2007 much more novelty is found at all three layers, more so as we move up towards the task layer.

Depth: Mapping

The difficulty brought to an activity by a software tool can be seen as stemming from an experienced gap between the software world and the non-software world. To close the gap, the novel concepts that are open to interaction must be reconciled with meaningful ideas in the pre-existing task world [START_REF] Payne | The Nature of Device Models: The Yoked State Space Hypothesis and Some Experiments With Text Editors[END_REF][START_REF] Payne | On Mental Models and Cognitive Artefacts[END_REF]. This is relatively easy when there exists a correspondence between the novel software concepts on one side of the gap and known concepts in the outside world on the other side. Yet software can bring to an activity not only new ways to do things, but also new things to do.

Where novelty in the software corresponds to pre-known ideas in the pre-existing task world, it allows for new ways of doing things. The knowledge that needs to be acquired then is mostly procedural: specifying how to do something. Yet where the software exposes its users to novelty that does not map directly onto pre-known ideas there is more of a problem. There are now new things to do, and a user who is not even sure what it is that he should be doing in the first place, is unable to frame his interactions in such a manner as to use the software to its full potential. To achieve full mastery, the user will need to acquire more than just procedural knowledge.

This distinction constitutes a qualitative dimension of use complexity that can be visualized as its "depth". The less tightly that the novelty brought to the task by the software is coupled to pre-known concepts, the deeper the use complexity. The depth of the use complexity is proportionate to the degree of mapping between the novelty brought to the task by the software and pre-known concepts.

The degree of mapping between software novelty and pre-known concepts can most readily be determined by considering the outcome of the user's interaction with the software. When the outcome of the interaction lies within the software only, there is no direct mapping. This is the case, for example, at the task layer of software for creating websites and at the semantic layer of text editing software that allows for regular expressions in searching and replacing. In other cases, the outcome of the interaction lies partly outside and partly inside the software. The software then holds a model of something in the physical world or in the user's mind, and it is the model that is modified. The mapping is then much more straightforward. Think, for example, of a kitchen planner such as offered by many home furnishing stores, whose task layer is involved with constructing a model of your new kitchen; or a calculator program where at the semantic layer the memory functions M+, M-and MR mimic a scratchpad holding intermediate results. Figure 2 shows the sketches from the previous figure enhanced with depth to indicate novelty for which there is no straightforward correspondence with the preknown world. Approximately half of Notepad's novelty at the semantic and task layers is considered not to correspond to pre-known concepts; whereas WordPad is judged to expose the user to non-mapping novelty only at the semantic layer, and a significant proportion of Word2007's novelty at all layers has meaning within the software world only.

Height: Impact

Turning our attention now to the use that is made of software, we find in Activity Theory a different three-tiered hierarchy; one which is fluid rather than fixed, usercentered rather than tool-centered. Central to the theory is the idea that all human activity is mediated by tools and context and that these fundamentally change the activity. Activity Theory covers many different aspects and offers a rich framework for the development of theory and practice alike [see [START_REF] Bødker | Through the Interface -A Human Activity Approach to User Interface Design[END_REF][START_REF]Context and Consciousness: Activity Theory and Human-Computer Interaction[END_REF]. For the purpose of assessing use complexity of software, however, further details of the activitytheoretical framework can be largely ignored, taking from it only the following decomposition of human activity:

• An activity is a sequence of actions, undertaken one after the other in order to achieve an object, which provides the overall intention to do the work. • An action is a sequence of operations, undertaken one after the other in order to achieve a goal within the wider framework of the activity's overall intention. • An operation is a routinely carried-out observable behavior.

The task layer in any given software tool does not necessarily correspond to the activity, nor the semantic layer to actions or the syntactic layer to operations. Task layer, semantic layer and syntactic layer are tool-centered and objective. To determine what they consist of, it is sufficient to consider only the software. Activities, actions and operations on the other hand are human-centered and subjective. They change over time and from one performer to another and to determine what they are, it is sufficient to consider only the user. Aligning the two hierarchies, the human-centered and the tool-centered, exposes the relative roles of the two partners in a man-machine system.

These are not always the same [START_REF] Mirel | Applied Constructivism" for User Documentation[END_REF]. The software component does not necessarily affect all the levels in an activity: situations are easily imaginable in which only part of the activity is computer-mediated. Software that affects the activity only insofar as it changes the nature of operations is less complex than that which touches upon actions, or even changes the nature of the activities that are possible. As the software's mediation reaches further up into the activity, it adds more uncertainty to constructs that were not very well defined to begin with: the goals of actions and the intention of the activity. This third dimension can be visualized as the "height" of the use complexity, enhancing the impact of the width and depth. The height of the use complexity is proportionate to the degree to which the software can affect an activity (in the activity-theoretical sense of the word). To determine the height of the use complexity, first ask whether the outcome of the task layer could ever be imagined to constitute a valid object, providing the intention to sit down to work. If so, the software reaches up into the level of the activity; if not, its application constitutes no more than the goal of an action and it reaches no further than into the level of the separate actions. This is reflected in the visualization by "pulling up" the use complexity to the level of the actions (left and center in Figure 3) or all the way to the overall activity (right).

The outcomes of Notepad's and WordPad's task layers are relatively modest, and in this example they are not seen to provide more than the goal for an action such as writing a short note or making a shopping list. The outcome of Word2007's task layer on the other hand could well be imagined to be an object in itself, such as the

Fig. 1 .

 1 Fig. 1. Width of use complexity sketched for Notepad (left), WordPad (center) and Word2007 (right)

Fig. 2 .

 2 Fig. 2. Depth of use complexity added to the analysis for Notepad (left), WordPad (center) and Word2007 (right)

Fig. 3 .

 3 Fig. 3. Height of use complexity added to the analysis for Notepad (left), WordPad (center) and Word2007 (right)

complete production and layout of a camera-ready manuscript or the programming of a word processing environment for third parties to use.

Conclusions

Use complexity is a promising concept to structure and direct documentation design efforts. However, much more work is required before it can be fruitfully deployed in sound engineering practice and is scalable for different types of software. A stepwise course of action must be developed for documentation developers to assess use complexity in a methodical manner, and measurable indicators must be established for all three dimensions. How to determine when a concept in the software world contributes to width and possibly depth of the use complexity, and by how much? How to decide whether the task level of the software reaches up into the intention for an activity or merely constitutes the goal of an action? To allow for learning the approach and to limit inter-rater variance, stringent definitions and ordinal scales on all three dimensions must be developed, unambiguously illustrated with standardized examples.

Therefore, further research is very much needed (and indeed planned), preferably in close cooperation with the direct stakeholders: the designers of user documentation.

These are uncharted waters. The field of documentation design tends to focus on the effects of specific interventions rather than underlying mechanisms or methodological approaches to the design process [START_REF] Schriver | Dynamics in document design[END_REF]. Task analysis in HCI (humancomputer interaction) is usually carried out before a new system or version is developed, while CSCW (computer-supported cooperative work) considers tasks and working practices emerging from new technology for groups of people working together, rather than individuals. Usability, as we have seen, refers to only part of the User Virtual Machine and there is no consensus as to its metrics or even its constituent parts [START_REF] Van Welie | Breaking down Usability[END_REF]. Dix et al, for example, see usability as having three constituents: learnability or the ease with which new users can begin effective interaction and achieve maximal performance, flexibility or the multiplicity of ways the user and system exchange information, and robustness or the level of support provided to the user in determining successful achievement and assessment of goals. Each of these constituents is in this framework seen as a function of underlying aspects, resulting in predictability, synthesizability, familiarity, generalizability, and consistency; dialog initiative, multi-threading, task migratability, substitutivity and customizability; and observability, recoverability, responsiveness and task conformance as factors to usability [START_REF] Dix | Human-Computer Interaction[END_REF]. Comprehensive as this overview seems, it bears little likeness to the definition in the ISO 9241-11 standard. Indeed, other authors (for a more in-depth discussion, see [START_REF] Van Welie | Breaking down Usability[END_REF]) present different indicators for the same concept of usability. And although some of the many aspects mentioned (e.g. familiarity) reduce use complexity, others (e.g. flexibility) may actually lead to increased use complexity. Use complexity is thus a concept that, appropriately operationalized to become a practical tool rather than a theoretical construct, can provide practitioners in documentation design with much-needed guidance.


Kay Behrenbruch
email: k.behrenbruch@uni-kassel.de

Martin Atzmüller
email: atzmueller@cs.uni-kassel.de

Christoph Evers
email: evers@uni-kassel.de

Ludger Schmidt
email: l.schmidt@uni-kassel.de

Gerd Stumme
email: stumme@cs.uni-kassel.de

Kurt Geihs
email: geihs@uni-kassel.de

A Personality Based Design Approach Using Subgroup Discovery

Keywords: Technology Acceptance, Personality, Software Engineering, Usercentered Design, Subgroup Discovery

To facilitate user-centered software engineering, developers need an easy to grasp understanding of the user. The use of personas helps to keep specific user needs in mind during the design process. Technology acceptance is of particular interest for the design of innovative applications previously unknown to potential users. Therefore, our research focuses on defining a typology of relevant user characteristics with respect to technology acceptance and transferring those findings to the description of personas. The presented work focuses on the statistical relationship between technology acceptance and personality. We apply sub-group discovery as a statistical tool. Based on the statistically derived subgroups and patterns we define the mentioned personas to help developers to understand different forms of technology acceptance. By integrating the specifically defined personas into existing methods in the field of software engineering the feasibility of the presented approach is demonstrated.

Introduction

Research in the field of Human-Computer-Interaction (HCI) generates models concerning technology acceptance. Those models provide determinants of technology acceptance and explain the causal relation between these determinants. This knowledge from HCI-research is potentially helpful for software-development, but stays isolated from day-to-day praxis of software engineering -mainly because the information is pegged into abstract und theoretical frameworks. In this paper we bridge the gap between theory and praxis by transferring our empirical findings to the textual description of personas [START_REF] Cooper | The Inmates Are Running the Asylum: Why High-tech Products Drive Us Crazy and How to Restore the Sanity[END_REF] that combine personality traits with the determinants of technology acceptance. We use the approved structure of theoretical frameworks as a guideline to implement our findings in the description of personas. A persona is a representation of the goals and behavior of a hypothesized group of users. Personas are described in a narrative text that includes behavior patterns, goals, skills, attitudes, and environment. Fictive but characterizing personal details are added to make the persona a realistic character [START_REF] Pruitt | The persona lifecycle: Keeping people in mind throughout product design[END_REF]. We propose ways to methodologically integrate the personas in software engineering, namely the agile method SCRUM.

To design personas we use data mining techniques, i.e. sub-group discovery and analysis within the framework of the Technology Acceptance Model (TAM) [START_REF] Davis | User Acceptance of Computer Technology: A Comparison of Two Theoretical Models[END_REF]. The data basis for the statistics is the evaluation of a prototype of an innovative application called Meet-U with the potential target group of the application. The evaluation is based on a questionnaire that contains items to acquire the determinants of TAM and the personality traits taken from the Five Factor Model (FFM) of personality psychology [START_REF] Mcadams | Five Factor Model in Personality[END_REF]. FFM encompasses five personality traits: extraversion, agreeableness, conscientiousness, openness to new experience, and emotional stability. Subgroup discovery is conducted with the aim to define subgroups with high impact on technology acceptance. Groups are defined by the characteristics of personality traits in correspondence with Perceived Usefulness (PU), Perceived Ease of Use (PEOU), and Intention to Use (IU) taken from TAM. The focus lies on the potential accepters and rejecters of the application. By this, valuable insight concerning those who will be most likely and most unlikely to accept their design is derived. A specific configuration of personality traits in combination with PU and PEOU reveals the types of potential users with respect to technology acceptance. With this knowledge, software-developers are able to search specifically for solutions that will convince skeptics to accept the application while keeping in mind the interests of likely accepters. The following section explains the theoretical background of the presented approach in detail.

Theoretical Background

In recent years the effect of personality on technology acceptance has been demonstrated by various authors. Especially, the use of social networks has been a major focus of research activity [START_REF] Amichai-Hamburger | Social net-work use and personality[END_REF][START_REF] Hughes | A tale of two sites: Twitter vs. Face-book and the personality predictors of social media usage[END_REF][START_REF] Moore | The influence of personality on Facebook usage, wall postings, and regret[END_REF]. Another field of attention has been personality in acceptance of mobile commerce [START_REF] Aldás-Manzano | Exploring individual personality factors as drivers of M-shopping acceptance[END_REF][START_REF] Zhou | The Effects of Personality Traits on User Acceptance of Mobile Commerce[END_REF]. Many aspects of personality were considered in HCI-research such as innovativeness [START_REF] Aldás-Manzano | Exploring individual personality factors as drivers of M-shopping acceptance[END_REF][START_REF] Nov | Personality and Technology Acceptance: Personal Innovativeness in IT, Openness and Resistance to Change[END_REF], need for recognition and sociability [START_REF] Hughes | A tale of two sites: Twitter vs. Face-book and the personality predictors of social media usage[END_REF], computer anxiety [START_REF] Nov | Users' Personality and Perceived Ease of Use of Digital Libraries: The Case for Resistance to Change[END_REF], computer self-efficiency [START_REF] Devaraj | Research Note--How Does Personality Matter? Relating the Five-Factor Model to Technology Acceptance and Use[END_REF][START_REF] Nov | Users' Personality and Perceived Ease of Use of Digital Libraries: The Case for Resistance to Change[END_REF], resistance to change [START_REF] Nov | Personality and Technology Acceptance: Personal Innovativeness in IT, Openness and Resistance to Change[END_REF][START_REF] Nov | Users' Personality and Perceived Ease of Use of Digital Libraries: The Case for Resistance to Change[END_REF], and interest in the application domain [START_REF] Svendsen | Personality and technology acceptance: the influence of personality factors on the core constructs of the Technology Acceptance Model[END_REF]. The most important characterization of personality is FFM [START_REF] Amichai-Hamburger | Social net-work use and personality[END_REF][START_REF] Devaraj | Research Note--How Does Personality Matter? Relating the Five-Factor Model to Technology Acceptance and Use[END_REF][START_REF] Hughes | A tale of two sites: Twitter vs. Face-book and the personality predictors of social media usage[END_REF][START_REF] Moore | The influence of personality on Facebook usage, wall postings, and regret[END_REF][START_REF] Nov | Personality and Technology Acceptance: Personal Innovativeness in IT, Openness and Resistance to Change[END_REF][START_REF] Svendsen | Personality and technology acceptance: the influence of personality factors on the core constructs of the Technology Acceptance Model[END_REF][START_REF] Zhou | The Effects of Personality Traits on User Acceptance of Mobile Commerce[END_REF].

In many cases structural models were generated. Those models determine causal architectures that combine general personality traits with usage and/or intention to use. A direct causal link from personality to usage/intention is an exception to the rule [START_REF] Aldás-Manzano | Exploring individual personality factors as drivers of M-shopping acceptance[END_REF]. In most models the influence of personality on usage/intention is mediated by PU and PEOU as determinants of TAM [START_REF] Devaraj | Research Note--How Does Personality Matter? Relating the Five-Factor Model to Technology Acceptance and Use[END_REF][START_REF] Nov | Users' Personality and Perceived Ease of Use of Digital Libraries: The Case for Resistance to Change[END_REF][START_REF] Svendsen | Personality and technology acceptance: the influence of personality factors on the core constructs of the Technology Acceptance Model[END_REF][START_REF] Zhou | The Effects of Personality Traits on User Acceptance of Mobile Commerce[END_REF]. TAM was chosen as the theoretical framework of this study because it is the most influential and generally acceptedmodel in information science concerning acceptance [START_REF] Schepers | A meta-analysis of the technology acceptance model: Investigating subjective norm and moderation effects[END_REF][START_REF] Venkatesh | A Theoretical Extension of the Technology Acceptance Model: Four Longitudinal Field Studies[END_REF]. Within TAM the Intention to Use (IU) the technology is influenced by two beliefs of the potential user concerning usage: PU and PEOU. In this paper, we combine TAM with the -in the context of technology acceptance -frequently used Five Factor Model (FFM) of personality psychology. FFM is a well-accepted instrument to grasp general personality [START_REF] Mcadams | Five Factor Model in Personality[END_REF]. We use the Theory of Reasoned Action (TRA) [START_REF] Fishbein | Belief, Attitude, Intention and Behaviour: An Introduction to Theory and Research[END_REF] to integrate FFM with TAM. TRA explains behavior in general and was used as a matrix in the development of TAM [START_REF] Davis | User Acceptance of Computer Technology: A Comparison of Two Theoretical Models[END_REF]. TRA states that personality traits are external variables and affect the beliefs that are important to the behavior in question [START_REF] Fishbein | Belief, Attitude, Intention and Behaviour: An Introduction to Theory and Research[END_REF]. Regarding the use of information technology we assume that the five personality traits of FFM have a direct influence on the beliefs PU and PEOU and that the influence of personality on behavior is moderated by PU and PEOU (see Fig. 1). Authors [START_REF] Devaraj | Research Note--How Does Personality Matter? Relating the Five-Factor Model to Technology Acceptance and Use[END_REF][START_REF] Svendsen | Personality and technology acceptance: the influence of personality factors on the core constructs of the Technology Acceptance Model[END_REF] report a significant influence of personality traits directly on PEOU and PU. Authors [START_REF] Svendsen | Personality and technology acceptance: the influence of personality factors on the core constructs of the Technology Acceptance Model[END_REF] identify a significant correlation between PU, PEOU and IU with extraversion and agreeableness. Moreover, a significant correlation of PU and PEOU with openness to new experience was reported. In addition a significant correlation for PEOU and emotional stability is indicated [START_REF] Svendsen | Personality and technology acceptance: the influence of personality factors on the core constructs of the Technology Acceptance Model[END_REF]. All listed correlation coefficients are lower than 0.21. The significant correlations of emotional stability, openness and agreeableness with PU [START_REF] Devaraj | Research Note--How Does Personality Matter? Relating the Five-Factor Model to Technology Acceptance and Use[END_REF] do not succeed this value either. In fact, none of the articles cited in this chapter found strong correlations (>0.5) of personality factors to constructs used in models for technology acceptance. Even moderate correlations (>0.3) are very rare. Against this background several structural models were constructed that combine different constructs to explain behavior. Structural models display complex networks of relationships that are no more than interesting to practitioners. They lack a direct link to development praxis and stay abstract and theoretical in their nature. In the following section we present a concretization to those models that bears in mind the needs of software-developers. We suppose that correlation coefficients or structural models alone are not handy and convincing enough to find their way into practice. The presented approach, based on the definition of personas [START_REF] Pruitt | The persona lifecycle: Keeping people in mind throughout product design[END_REF], connects research results with common design methods in the field of software engineering and user-centered design.

Empirical Study and Statistics

We conducted an evaluation of a prototype that supports mobile social networks, group interaction and mobility, called Meet-U [START_REF] Comes | Adaptive Applications are Smart Applications[END_REF]. Meet-U is a mobile application for Android devices that is still under development and is designed for the group of 20-to 35-year-olds. Meet-U supports its users in organizing meetings with friends at events. Events can be public or private happenings like concerts or parties. The application helps to plan the event, navigate the user to the event, and supports the user at the event itself. Meet-U proposes events to the users that fit their individual interests as well as their personal calendars. The application suggests means of transport and informs about possible delays, e.g. when using public transport. At the event, information concerning the location, the program, and tickets can be retrieved from automatically integrated services. If desired by the user Meet-U is able to suggest new friends based on the user's settings and interests.

We evaluated Meet-U with the potential user group (157 students, 68 female, 89 male, age 19-37). Participants were given basic information about the prototype in form of a presentation. Next, they were asked to perform tasks with the prototype: compiling a profile, finding and confirming friends, creating an event, searching an event, and being navigated to the event. Subsequently, they filled in a questionnaire. The questionnaire contains items concerning PU, PEOU, and BI taken from [START_REF] Venkatesh | User Acceptance of Information Technology: Toward a Unified View[END_REF] as well as the five personality traits of FFM taken from [START_REF] Gosling | A very brief measure of the Big-Five personality domains[END_REF]. The questionnaire uses a nine-point Likert-Scale reaching from "strongly agree" to "strongly disagree".

The data from the nine-point Likert-Scale was used to build three categories: high, medium, low. Boundaries of the three categories were defined for each construct individually. Therefore we identified first quartile and third quartile for each construct. By this we were able to define equally distributed categories for each construct. We compared our data for FFM with standard values [START_REF] Gosling | A very brief measure of the Big-Five personality domains[END_REF] to assure that there are no particularities in our sample that will cause the relative classification with quartiles to be unrealistic for standard values.

The data abstraction (mapping nine levels to three nominal categories) was conducted for applying subgroup discovery and analysis on the pre-processed data. We applied semi-automatic subgroup discovery for the characterization of "acceptance groups" according to the given data. In general, subgroup discovery [START_REF] Wrobel | An Algorithm for Multi-Relational Discovery of Subgroups[END_REF] aims at identifying interesting patterns with respect to a given target property of interest (e.g., "Accepter"). The method is especially suited for identifying local patterns in the data that only hold for specific subsets. It can automatically uncover hidden relations captured in small subgroups, for which variables are only significantly correlated in these subgroups. We can discover, for example, the subgroup defined by "conscientiousness=low AND PU=high" for the target concept "Accepter" in Table 1. The quality of the subgroup is determined by the lift factor, which measures the target share in the subgroup relative to the target share in the whole data. Thus, a lift of 2 indicates an improvement of the target in the subgroup by 100%. Additionally, we tested the significance using a four-field chi-square test. We applied the open-source VIKAMINE [START_REF] Atzmueller | Semi-Automatic Visual Subgroup Mining using VIKAMINE[END_REF] software for discovering interesting subgroups: The automatic component provided several hypotheses, which could then be semi-automatically refined, evaluated and validated.

Results: Subgroups and Personas

The results of the subgroup discovery are displayed in Table 1. We selected the four subgroups with highest relevance for technology acceptance. Relevance was defined by the lift factor (>2) and the subgroup size (>10% of the sample). Two subgroups are indicated as accepters and two as rejecters. Subgroup size, lift factors, and significances are displayed for each subgroup. Each subgroup combines personality factors with TAM beliefs. All defined subgroups are significant at least on a level of 0.05. Subsequently the statistical findings of Table 1 were implemented in four personas. Table 2 shows a selection of phrases that can be used to transfer high and low manifestations of the big five personality traits to the description of personas. The personas are meant to guide designers in the process of user-centred design. Sex of the personas was determined freely because no significant relation of sex with technology acceptance was found.

Accepter 1: Conscientiousness low and PU high Michael is 24 years old. He is still living at his parent´s home. He studies economics and takes his time. At the moment he should learn for a written exam but he lost the records and decided to take the exam next year. He tested the new prototype. Michael likes that Meet-U helps him to organize things. Often he forgets about dates, misses the train, or forgets to call people when he is late. He hopes Meet-U will help him without much effort from his side.

Accepter 2: Emotional Stability high and PEOU high

Cindy is a 19-year-old who just moved into town and started her studies at the university. She takes courses in psychology but is not quite sure if she will stick to this field of study. She liked high-school a lot but the change and the new situation are also nice. At the moment she is satisfied with exploring campus and university, and making new friends. She participated at the test of Meet-U and plans to download the newest version now. She just finished learning for the first exams and thinks the application will help her to have a good time with interesting events now.

Rejecter 1: Emotional Stability low and PEOU low

Martha is 31 years old and is afraid that she will not be able to pass her last exams to finish her studies in social work. Her mother says she does not mind her taking more time but Martha feels guilty not to be able to make her own living at her age. She participated in the evaluation of Meet-U. When she was told about the features of Meet-U she hoped that Meet-U might help her to meet people despite her shyness. But when she had to perform the tasks with Meet-U she was irritated. To her the application seems much more complicated than the others say.

Rejecter 2: Agreeableness low and PU low Frank is 24 years old and studies chemistry. His girlfriend just moved into his flat and he likes her to be around. She makes him feel good -and also she is much better at cleaning the house than he ever has been. Frank is at home and tells his girlfriend about the evaluation of Meet-U he participated in: "Why should I organize thinks for those who are not able to get along by themselves. I know that I want to go out with you and which places I like. Why should I give all my personal data to Meet-U when there is no use to it."

Methodological Integration

Personas are a part of user-centered design [START_REF] Cooper | The Inmates Are Running the Asylum: Why High-tech Products Drive Us Crazy and How to Restore the Sanity[END_REF][START_REF] Pruitt | The persona lifecycle: Keeping people in mind throughout product design[END_REF]. Often they are used in scenarios that help to describe and explain the context of use. This kind of scenario is part of the process of analyzing the context of use and defining user-requirements. We suggest applying the personas also in the process of implementation of software. The agile software engineering method SCRUM incorporates user stories. Those stories are actually a list of requirements, normally in the form of: "As a <user type> I want to <do some action> so that <desired result>". We propose substantiating the <user type> to a persona. There should be a set of personas well-known to the whole development team. The personas give the team a vivid impression of people, who should use their system. The personas should act as a symbol for or connection to knowledge about the potential users of the system. With respect to technology acceptance and the definition of personas in this paper, the development team will be able to keep in mind the issue of acceptance by being confronted with the personas. In the case of Meet-U question like this arise: "I don't think we should make this dialogue too complex. Martha will be afraid and will give up." It is in the responsibility of the product owner (a role in SCRUM) to decide which persona is the right one for which user-story. In the present case the product owner should be familiar with the issue of technology acceptance.

In addition to that, SCRUM is designed to provide executable software throughout the whole design-process. This feature opens up possibilities to meet the following needs to foster technology acceptance in the development process of innovative applications. We are arguing to intensify the iteration of evaluation in the case of the development with regard to uncertain technology acceptance. Therefore we propose to evaluate partially functional prototypes parallel to programming software. Each sprint of SCRUM provides this kind of prototypes as executable software. Evaluation parallel to programming needs to be fast and flexible. This is why we suppose to let the partially functional prototypes be evaluated by usability experts instead of real users. Experts use inspection methods to check for usability problems and are able to provide results much faster. To incorporate the user's view on technology acceptance the evaluating experts should also be familiar with the personas used in SCRUM. The feedback of the evaluation results to the developers is ensured by the participation of the usability experts in the sprint planning meeting that is done on a regular bases in SCRUM.

Outlook

This paper presents an approach to transfer research findings from HCI-research on technology acceptance and personality to development-practice. We present ongoing research of an empirical study in the context of methodological reflections. At the present stage it is not possible to provide an approved set of personas. Within the VENUS project (http://www.uni-kassel.de/eecs/iteg/venus/) data is currently gathered for technology acceptance and personality traits in two other development projects. The objective is to generalize the statistical findings for Meet-U with respect to different application properties and to other user groups. At the same time we apply the presented methodological integration in three different development-projects and are gaining new insights to further improve it for practical application. The integration of personas to user-centered design and software engineering proved to be a targetaimed approach. The evaluation of partially functional prototypes parallel to the implementation of software is a vital part of the ongoing work and was applied successfully. A major topic of future research will be to approve the effectiveness of the presented approach related to agile software engineering.

Fig. 1 .

 1 Fig. 1. Integration of the Technology Acceptance Model (TAM) with the Five Factor Model (FFM) in compliance with the Theory of Reasoned Action (TRA)

Table 1 .

 1 Subgroups concerning technology acceptance and personality

	Subgroup	Subgroup Size	Lift Factor	Significance
	Accepter 1	17	2.0	p<=0.01
	Accepter 2	16	2.2	p<=0.001
	Rejecter 1	16	2.0	p<=0.05
	Rejecter 2	16	2.4	p<=0.001

Table 2 .

 2 Phrases to describe Persona with extreme occurrence of Personality Factors

	Personality Factors Positive occurrence	Negative occurrence
	Openness to	appreciation of art, inventive,	not cautious, plain,
	experience	creative, curious, sensitive to	straightforward, not subtle,
		beauty, aware of feelings	bad imagination, uninspired
	Conscientiousness	organized, efficient, show	easy-going, careless,
		self-discipline, act dutifully,	unobserving, act unconcerned,
		always prepared, exact	shirk something
	Extraversion	energetic, show positive	solitary, be reserved, seem
		emotions, full of energy,	quiet, keep in the background,
		enthusiastic, action-oriented	withdrawn, distant
	Agreeableness	friendly, compassionate,	antagonistic towards others,
		cooperative, friendly, helpful,	self-interested, unfriendly,
		generous, optimistic	uncooperative, abusive
	Emotional stability calm, even-tempered, secure,	sensitive, nervous, unpleasant
		confident, not easily upset, no	feeling, anxious, depressive,
		persistent negative feelings	vulnerable, worried

Acknowledgments. We thank Hesse's Ministry of Higher Education, Research, and the Arts for funding VENUS as part of the research funding program "LOEWE -Landes-Offensive zur Entwicklung Wissenschaftlich-ökonomischer Exzellenz".