Design criteria for public e-services

June 4, 2017 | Autor: Stefan Cronholm | Categoria: Human Computer Interaction, Empirical Study, Business Process, Design Criteria
Share Embed


Descrição do Produto

DESIGN CRITERIA FOR PUBLIC E-SERVICES Annie Röstlinger, Linköping University, Dept of Management and Engineering, 581 83 Linköping, Sweden, [email protected] Stefan Cronholm, Linköping University, Dept of Management and Engineering, 581 83 Linköping, Sweden & University of Borås, Business and Informatics, 501 90 Borås, Sweden, [email protected]

Abstract This paper focuses on design criteria for public e-services. The paper challenges traditional lists of usability criteria supporting design and evaluation of IT-systems. Traditional criteria within the field of human-computer interaction are perceived as too limited and an expanded view of the communication and business process is proposed. Within this expanded view, existing usability criteria are considered as important but not sufficient. Based on this claim, criteria also supporting communication and business actions are proposed. The proposed criteria are generated from an empirical study concerning a development of an e-service. The aim of this e-service is to support the communication between companies and the municipality when companies are going to get permission for running business. Analysing the communication need in this context has been of particular interest in order to generate complementary criteria for design and evaluation. Examples of criteria generated are: good conditions for users to become knowledgeable (support for perception, comprehension and information), differentiate between informative and performative parts, provide meta information (purpose and content). Keywords: Usability, human computer interaction, e-government, e-service

1

INTRODUCTION

In the e-government field there is a rapid growth in the development of e-services (Ancarini, 2005; Buckley 2003). Such an e-service is a public service mediated electronically through a user interface that is generally available. Public e-services can be used by citizens or company. These users can be inexperienced and infrequent users of the public e-service. If e-services are to be used, they must be easy to use and be beneficial to the user. Important questions are: How to create usable e-services and what properties are desirable for such IT-systems? There exist several lists of usability design criteria. Examples of criteria lists are: 10 usability heuristics (Nielsen, 1993), Eight Golden Rules (Shneiderman, 1998), design guidelines for small screen devices (Kärkkäinen & Laarni, 2002), context-aware mobile applications (Häkkilä & Mäntyjärvi, 2006) and Participatory Heuristic Evaluation (Muller et al, 1998). These lists are explicitly not web oriented; however, Nielsen (1999) has presented criteria for designing web usability. In our literature research we could not find any list belonging to the context of public e-services. The importance of identifying different contexts is acknowledged by Henninger et al. (1995). They claim that “If the potential of usability guidelines as an interface design technique is to be fully realized, they need to be augmented with context-specific guidelines and examples that synthesize isolated guidelines into domain-specific solutions to design problems”. A reasonable question to ask is “why are not existing criteria good enough?”. Our answer to this question is that criteria are always derived from a specific theory or perspective. That, which means that the usage of criteria lists support a specific focus of the phenomenon studied. To set a focus on something also means that other aspects are de-emphasized. The identified criteria lists are constructed in the field of human-computer interaction and their aim is to focus on the aspect of the interaction between a human and a computer. Our hypothesis is that the existing usability criteria can be too limited for supporting design and evaluation of the context of e-government. The reason for this claim is that we view e-government as a communication intensive context. In this context there are citizens or companies that need to communicate with e.g. representatives of municipalities or other authorities. When citizens communicate with municipalities they are often instructed to use artefacts such as answering machines or the internet. It is not an exaggeration to say that communication via traditional face-to-face situations is successively replaced or complemented by communication via information technology (e-services). Based on this we claim that there is a need for a complementary perspective (and design criteria) focusing on the e-service mediated communication between humans instead of a more limited human-computer interaction (see section 3). Our hypothesis is supported by Hartson et al (2001) who claim that “Usability is seated in the interaction design” .Our hypothesis is also supported by findings in Cronholm & Bruno (2008). A result from this study is that “most of the existing usability criteria are predominantly supporting a human-computer interaction perspective”. Furthermore, Gould and Lewis (1985) claim that existing design guidelines are limited since they are not detailed enough. We are not saying that the criteria lists referred to above are unusable; on the contrary they seem to provide good support for analyzing human-computer interaction, but they are not mainly supporting design of IT-mediated communication between humans. Many of the existing criteria lists seem to be constructed for usage in any situation (e.g. Nielsen, 1993; Shneiderman, 1998). The risk of using too general criteria is that these do not provide enough contextual support that is needed in a specific domain. They can be perceived as too superficial and thereby not usable enough. The aim of this paper is to propose a set of design criteria primarily to be used to support professional designers and evaluators within an e-government context. In this paper we restrict the discussion of criteria to design criteria for public e-services. This is the context of our case study described below. From this context we have found the traditional design criteria not enough supportive for our design decisions concerning communication between the municipality and the companies using the e-service.

The proposal of criteria is based both on existing criteria lists (see section 4) and on new experiences from the case study (see section 5). The introductory section is followed by a description of the research method (section 2). Section 3 describes the theoretical basis used and in section 5 we present the design criteria used in the case study. Finally, in section 6 we present some conclusions.

2

RESEARCH APPROACH

This study is part of a research project for improving the conditions of commercial and industrial life in municipalities. The project is a joint project between four municipalities and some researchers. In order to develop design criteria for e-services we have used three different knowledge or data sources: a case study, existing usability criteria lists and theories of communication and business processes. In the case study we acted as both researchers and designers of an e-service. The research process can therefore be characterized as action research since we intervened in the process (e.g. Lewin, 1946; Avison et al, 2001; Baskerville, 2001). The case study has functioned as a data source for inducing design criteria. The overarching questions asked were “How can companies and municipalities benefit from an e-service?”, “How can companies and municipalities communicate with each other through an e-service?” and “How can companies interact with an e-service?”. The study started with a broad process analysis discovering problems and goals concerning the interaction between the companies and the municipalities. Based on this investigation a decision was taken to start developing e-services and redesigning processes. A critical analysis of forms was conducted. It was important to critically examine existing forms, e.g. content, structure and terminology. This was done in order to avoid transferring bad existing paper forms into e-forms. We have used existing usability criteria as a source of inspiration and have reused or refined relevant criteria. The design criteria generated were also explicit compared to three existing usability criteria lists. The reason for choosing two of them was that they are well known. These lists are: 10 heuristics (Nielsen, 1993) and Eight Golden Rules (Shneiderman, 1998). The third list is called Actability Principles (Cronholm & Goldkuhl 2002). This list was chosen since it is based on a communicative perspective. It is more comprehensive but is not as commercially used as the other two lists. Behind the idea of comparing the developed design criteria with the list of Actability Principles was to understand if and how criteria generated from a communication perspective could contribute to design criteria for the domain of e-services. Finally, the communicative and business perspective has also had an impact on the development of the design criteria. We have continuously refined the proposals of design criteria and the e-service, which means that there has been a shift between action and reflection/evaluation. Through this the design criteria have emerged in an iterative way.

3

THEORETICAL BASIS: A COMMUNICATIVE PERSPECTIVE

In this paper we apply communicative and business perspective in order to develop design criteria for e-service. The theoretical sources for viewing IT-system as communication and business systems are social action theory (e.g. Weber, 1978) and language action theory (e.g. Goldkuhl & Lyytinen, 1982; Habermas, 1985; Searle, 1969; Winograd & Flores, 1986). The main message in Weber’s (1978) theory of social action is that communication is intentional. Using a social action perspective means that it is not acceptable to view IT-systems as a black box with some social and organizational consequences (Dietz, 2001). IT-systems are instruments for business action. Language action theory discusses communication as one type of action, and IT-systems are not considered as “containers of facts” or “instruments for information transmission” (Goldkuhl and Ågerfalk 2002). The language action perspective emphasizes that communication is to establish interpersonal relationships between the sender and the receiver (Searle 1969). The communicative perspective emphasizes a user communicating with other users through a user interface. It is a human-

via-computer-to-human communication; it is not a limited human-computer interaction. Thereby, the use of IT-system is viewed as a social process consisting of technology mediated business communication. In order to present our view on interaction we use the Elementary InterAction Loop (EIAL). EIAL was originally introduced in Ågerfalk et al (1999) and revised in Goldkuhl et al (2004). EIAL consists of an interactive situation divided into four phases: informing, execution, IT-system reaction and interpretation (see figure 1). The informing phase means that a business actor interprets the action repertoire offered and possible messages from other business actors in order to reach a decision about what to do. The execution phase describes that the user is performing the action chosen. The ITsystem reaction phase describes the IT-system’s response to the business actor’s action. Finally, the interpretation phase describes how the business actor interprets the result of the IT-system’s reaction. In the middle of the EIAL a screen document is placed. A screen document is any designed interface with which the user interacts (e.g. a form on a web page). The screen document plays different roles in the different phases. Therefore the screen document is multifunctional. In the informing phase the screen document is used when the user is reading the screen to figure out what to do. It contains information about the action possibilities and other action conditions. In the next phase the screen document is used for execution. In this sense, the screen document functions as an action medium. For example, the user enters some data in a field and clicks on a button on the screen in order to perform an action. Finally, the phase of the IT-system reaction should be understood as a response to the user execution. The IT-system’s reaction can result in changes of the screen document (as a feed-back to the user). In this sense, the screen document consists of action results and functions as a basis for interpretation.

Figure 1. Interaction: The Elementary InterAction Loop (based on Goldkuhl et al., 2004) The central concepts of interaction, communication and business process discussed above are depicted as three sets or three levels (see figure 2). As pictured, an interaction is the interplay between a user and an IT-System, The communication takes place between two users, mediated by an IT-system. The arrows in the figure above symbolize the business; a business that produces something (a product or a service) for a client. The communication level is viewed as a subset of the business process level and the interaction level is viewed as a subset of the communication level. This means that if the IT-system is considered as providing good support for the business level it also provides good support for the lower communication level and interaction level. On the other hand, if an IT-system is evaluated at the interaction level no predictions can be made of the higher communication level and business process level. The aim of figure 2 is to bring forward three important and related levels. We are not saying that criteria formulated on the interaction level are useless; ideally we would like to see criteria residing on all the three different levels and that they are coherent and complementary. The model is chosen since e-services are supposed to support a type of business that is highly communication intensive (see section 5.1).

Interaction level

Communication level

Process level

Figure 2. Relations between interaction, communication and process (based on Goldkuhl, 2009)

4

ANALYSIS OF EXISTING CRITERIA IN HCI

In order to motivate our proposal of design criteria for e-services we have analyzed two familiar and popular usability criteria lists; the Ten Heuristics proposed by Nielsen (1993) and the Eight Golden Rules proposed by Shneiderman (1998). We have also analyzed a criteria list that is not equally well known, this list is called Actability Principles (Cronholm & Goldkuhl, 2002, 2005). An overarching result from studying these criteria lists is that we have found them important to consider while designing IT-systems; but they are not sufficient. Analyzed from a communicative perspective they are viewed as too limited, i.e. they are supporting the interaction that is going on between a user and a computer. Our claim is that they do not fully support communication between humans and they are not formulated to support business processes. Examples of criteria representing this limited view are “Visibility of system Status”, (Nielsen, 1993), “Enable frequent users to use short cuts” (Shneiderman, 1999) and “Clear feedback” (Cronholm & Goldkuhl, 2002, 2005). Another result from our analysis is that we find several criteria hard to understand. The problem of comprehensibility is often to do with that: 1) the criteria are not categorized 2) the label of the criterion does not correspond to the adjacent explanatory text and 3) the label and the description of one proposed criterion often consist of several criteria. The criteria proposed by Nielsen (1993), Shneiderman (1999) and Cronholm & Goldkuhl (2002, 2005) are presented as flat uncategorized lists; i.e. the criteria are considered as belonging to the same abstraction level. The advantage and role of a multilevel abstraction hierarchy is discussed in Rasmussen et al (1994). They compare a multilevel abstraction hierarchy with a means-end hierarchy and claims that a multilevel abstraction hierarchy is often used in practical problem-solving processes. The second problem, the correspondence between the label and the adjacent explanatory text, is best illustrated by an example chosen from Shneiderman (1998). The label of the criteria reads: “Offer informative feedback”. The explanatory text reads: “For every operator action, there should be some system feedback. For frequent and minor actions, the response can be modest, while for infrequent and major actions, the response should be more substantial”. The keyword in the formulation of the label is “informative feedback”. The explanatory text is discussing when and how much feedback that should be provided. There is no explanation or recommendation of how to provide informative feedback. Another example of the lack of correspondence between the label and the explanatory text can be found in the criterion “Flexibility and efficiency of use”, proposed by Nielsen (1993). In the explanatory text Nielsen (1993) mainly discusses accelerators. We conceive it to be a too large abstraction gap between “flexibility and efficiency of use” and “accelerators”. We did not expect to find a discussion about accelerators in order to define flexibility and efficiency of use. The third problem, that the label and the description of one proposed criterion actually consists of several criteria, contributes to the confusion of what is going to be evaluated. Several formulations of labels refer to more than one criterion. To clarify our criticism we use the same example again:

“Flexibility and efficiency of use”. According to our interpretation of the concepts, “flexibility” is one criterion and “efficiency of use” is another. Hence, they should be treated as separate measures.

5

PROPOSAL OF NEW DESIGN CRITERIA

5.1

Prerequisites for the case study

A company may need different permissions from the local authority to set up and run a business. Permissions are often necessary e.g. when selling food, use chemicals or building a factory. To get permission easily and quickly is important for the company since permission is a prerequisite for running a business in a legal way. We have identified five main phases in the permission process: 1) Search info about application [company] 2) Formulate and send application [company] 3) Assess application [municipality] 4) Decision [municipality] and 5) Send decision [municipality]. This process is easy to conceptualise but different problems may occur when companies are going to apply, e.g.:

• Companies do not have sufficient knowledge about: 1. The legal rules; e.g. what are we allowed to do and not to do, is permission needed or not for different kinds of businesses? 2. The process of application, assessment and decision organised by the municipality; e.g. who is the executing officer, is the application supported by a form, what aspects are assessed, what is the fee, when do we get a decision? 3. How to get answers to questions; who is the right person to contact, by telephone, e-mail or by visit, how to find understandable information about regulation and permission process and application forms?

• Executing officers at the municipality are overloaded with rather simple questions, they have to handle incomplete and difficult-to-read applications, and they need to contact the companies to get completed applications. The companies regarded the municipality as too bureaucratic and not service-minded enough while the municipality regarded the companies as ignorant and unwilling to follow legal rules. The identified problems are all located in the communication process between the municipality and the companies and also have implications for the conditions in the business process. The consequences are both inefficient municipality processes and inefficient and delayed business processes. The four studied municipalities all had existing web sites but these were not informative enough. The web sites did not seem primarily to be designed to support the companies’ application processes. Some municipality web sites had reading functionality and application forms in pdf-files but none had functionality for sending information, e.g. questions and applications. Many of the application forms were designed to support the case handlers’ assessment processes rather than the companies’ process to produce a complete application. There were no proper e-services within this domain. To improve the communication between the case handlers and the companies we started a pilot study to design e-services for firms active in food business. The first step in the study was to support the communication in the first two phases of the permission process: companies searching information about food permission and then sending their application to the municipality. 5.2

Designing the e-service

The pilot study has resulted in a web-based IT prototype. In the design process we have actively used a prototyping approach (Vonk, 1990). The e-service prototype holds information relevant for the application process and companies going to apply, e.g. information about legal rules, municipality principles for handling applications and decision making, information about the subsequent municipality control of the company handling food in a proper way. The e-service also includes

different supporting functions for applying: 1) an application form to fill out by companies 2) guides with proper questions depending on type of food business 3) completion control of forms 4) function for sending an application. Some of the food case handlers participated in the design process together with the researchers. The aim of the e-service was to support both companies and case handlers. Besides making it easier for companies, the aim was to ensure that case handlers achieved correct and necessary information. Knowledge from the workpractice was an important basis when we created the e-services prototype but also practical theory including usability criteria and actability principles was important. The aim was to create an e-service easy to use for experienced and inexperienced users and frequent and infrequent users, i.e. all companies trading in food. The prototype was refined in an iterative design process until we got a satisfied e-services prototype. In this refinement process the researchers and the case handlers reviewed the prototype based on their different views on “what is meant by useful”. When we demonstrated the prototype, also case handlers from other permission areas were interested. We decided to transfer properties from the food prototype to a new e-service prototype for building permission. In order to detect characteristic and important properties we examined the prototype expost and also reconstructed our design decisions. We found several characteristics of importance for success when using the e-service in the permission process. Then, when we compared the detected attributes to the existing design criteria we found it difficult to relate each of our attributes to any particular criterion from the criteria lists. We had achieved an e-service which met the case handlers’ and researchers’ aims and expectations, but it was not because of the existing criteria. As mentioned above, we found the existing criteria important and valid but limited in terms of support to the designer. 5.3

Different aspects of an e-service

A public e-service is about two actors communicating. A company needs information from the municipality in order to make decisions about the business and the application, i.e. the company needs to be informed by the municipality and the municipality needs to inform the company. The company needs to send an application to the municipality to get a decision from the municipality; i.e. the company needs to inform the municipality and the municipality needs to be informed about the application from the company. The company is both a sender and a receiver and these are also the roles of the municipality in the communicating process. A public e-service is also about two organisations conducting their respective tasks. One important task for a municipality is to give permission to firms doing business, and for the company it is important to get permission in order to produce results, e.g. selling food in a shop or in a restaurant. This means that the e-service developed is created to support the producing processes in two different types of workpractices, one producing food permissions (a municipality) and the other producing food to customers. Of course, public e-service is also about a human actor interacting with a computer. Handling the computer in an efficient way is important and a prerequisite for achieving communication between actors via the computer. A good working communication between the sender and the receiver contributes to results in the workpractices. We have identified three levels of e-services (see figure 3) where the IT-system plays an important role. The three levels concern different aspects of the workpractice and also focus on different aspects of the IT-system. Thus, to get an e-service that is useful and supports producing results in workpractices we have to consider the three levels of IT when designing e-services. As mentioned above, we found the existing criteria in the lists mostly related to the interaction level. A public e-service is not only about human-computer interaction. It is also about human to human communication via computer and furthermore about humans (with IT support) producing results in favour of humans.

When designing e-services it is important to recognise all three levels of human and IT-system actions and the e-service must be designed to support these levels. Thus, when designing e-services for public municipalities we also need criteria related to these levels, not only to the interaction level.

E-services to support production of results in organisations Business process level

Communication quality supports quality in business processes

E-services to support human to human communication Communication level

Interaction quality supports quality in communications

E-services to be used by human Interaction level

Figure 3. Three levels of e-services in organisations 5.4

Criteria for usable e-services

Every item carrying information intended for the user, i.e. words, pictures and sounds, should also be perceived by the user. The user should quickly and easily be able to detect adequate information without risk to miss something. Important features for achieving this goal are e.g. colour, shape, size/volume and location. All these properties may have values which make them highly perceivable or not perceivable at all. The perception differs between people, e.g. different people perceive colours in different ways. It is also important to be careful with hidden and concealed functionality. Every sign perceived should also be comprehended by the user. The user interprets the perceived signs to understand its meaning. The user should easily and quickly be able to understand the information without risk of misunderstanding. The key features are e.g. simplicity, recognition and consistency. - Simple but informative expressions and symbols. - Signs related to the task and the users’ knowledge and understanding. Important aspects are e.g. the language and vocabulary used, signs related to standards, local standard in the IT-system and global standard in other IT-systems, other well known artefacts and other objects. - Avoid homonyms and be careful with synonyms. To perceive information is a prerequisite for achieving the goal of comprehension. The different properties for perception (colour, shape, size/volume and location) also have functions with importance for achieving simplicity, recognition and consistency. The user should not only be able to perceive and understand; the user should also be informed by the signs. The information perceived and comprehended should make a difference; the user should become knowledgeable and prepared for action. That the receiver is informed by the sender is an aim of communication via e-service. Important features contributing to knowledge when the user perceive and comprehend the information are: information related to the user and to the task, the action which the user is going to perform or has performed, the process in which the information is a part of. In this context, properties as structure, thematizing, level of detail (detail, aggregation and summery) and level of knowledge (elementary, advanced) are important. Perception, comprehension and informing are all basic aspects of importance for the IT-system and its use. These aspects must be taken into account in the designing process, whether the information is about a subject like food permission, navigation in the IT-system, feedback information or error

messages. In this way these basic aspects can be related to all three levels of e-services in organisations (in figure 3), What is a user going to do with the acquired knowledge? When the user becomes knowledgeable and prepared, the action taken can be: a) within the IT-system, b) via the IT-system or c) outside the ITsystem. To navigate to the next page in the web site is an action within the IT-system (a) on the interaction level. To read information initiated by the case handler about e.g. legal rules and permission is instead an action via the IT-system (b) on the communication level. To send a question to a case handler is also an action via the IT-system (b) on the communication level. It is important to recognize that when a user communicates with a case handler through e-service the user is at the same time interacting with the computer. Thus, this action is multifunctional. Action multifunctionality builds on and extends the concept of pragmatic duality (Sjöström & Goldkuhl, 2004). To send a complete application to the case handler is an action via the IT-system (b) but on the business process level. An action via an IT-system on the business process level always also includes both the interaction and the communication levels. To have obtained food permission through the e-service and then running a restaurant is also an action on the business process level but outside the IT-system (c). Actions outside the IT-system are separated from the IT-system and these actions are restricted to the business process level only. The three different levels (interaction, communication, business process) are related in a way that all the lower levels are prerequisites for all the higher levels (see figure 3). Lack of quality on a lower level affects the quality on higher levels. Informing and performing are different e-service functions. In a user interface every object is information. But the information objects can have different functions: to be used to inform or to be used to perform. Through the informing function the user is being informed about something. Every object has some informing function. But some objects also have a performing function which allows the user to perform something and that means more than being informed. There is a big difference between the user only getting information about something, e.g. how to pay, and the user performing a payment. In an IT-system it is highly important to clearly differentiate between these two functions. The user has to be aware of what is going on. Only receiving information is often not associated with heavy consequences. However, to conduct by sending information (e.g. a payment, an application, an update or a deletion) can be more serious. In the e-service for food permission we clearly differentiated between informative e-services and performative e-services. By the informative eservices the user can get information about e.g. legal rules and the application process. By the performative e-service the user can perform the application process, i.e. parts of the process with filling out the form and sending the complete application to the municipality. The IT-system for food application permits every user to read information (an informative e-service) but only logged in users are permitted to perform an application (a performative e-service). Purpose and content; i.e. meta information about the main topic. What is the user offered by the eservice? Who benefits from the use of the e-service? It is important that a user as soon as possible is able to get an overview of what the system can give; what information to receive and what information to send? The user should have a basis to decide, “is this a ‘right’ site for me or should I leave the web site or the current page?” The function of this information is also to stimulate interest among prospective users. For example, on top of the first page on the web site for food e-service there is an overview picture and a synoptic description of purpose and content and the expected type of user. The description of purpose and content continues on the top of all other pages, where the user can find a description or a title that indicates what the page is about. Clearly expressed main topic; the informative and/or performative e-service on the communication and the business process level. This is the content in the communication between a sender and a receiver, and also the purpose of using the e-service. The structure and the context of presenting the main topic are very important. The information should be displayed from the users’ point of view and the purpose of using the e-service (Eliasson & Hedström, 2005). In the example from the food eservice we related to the application process and structured the information in 1) information about legal rules 2) information about the application and 3) information about permission process. This

information is displayed for the user in both an aggregate and a detailed way. The user is able to receive information about the application process but also to conduct the process via the e-service. Filling in the form is structured according to different generic themes (who, what, where, when) related to the business process. The application process begins with a clear starting point and ends with a clear ending point. Navigation. Information about principles and functions for information access and also information that allows performing navigations. Where and how can the user find the information in the ITsystem? The design of the navigation has consequences for accessing the informative and performative e-services. The navigation can be open or limited. Open is when the user has the option to choose among pages and functionalities. Limited is when the user does not have any choice but the IT-system chooses the path within the IT-system. A fully open navigation is hard to realise; various mixtures of open and limited are more realistic. In an open navigation the user has flexibility to perform different actions, but in a limited navigation the IT designer may choose a proper way according to the user and/or the task. In the food e-service we have chosen a design to make the user knowledgeable before conducting an application. The user will be guided to read information before performing an application. The user has also the possibility to navigate directly to pages for performing an application (aimed for more advanced users). The pages for filling out the form can be accessed in any order. The informative and performative e-services concerning the main topic are supported by functions as e.g. forward, feedback, redo and rectify. Indicate forward. The user should be able to navigate and act in a confident way within and through the IT-system. The IT-system must contain clear information that indicates what result the user can expect by using the system. In the e-service for food permission all buttons have a descriptive sign, for instance. Feedback. The system should give feedback to the user, information about what the user has done and what the IT-system has done. The IT-system can display the result, e.g. accessed information about rules for food permission, or describe the result, e.g. your application is sent to the municipality. Redo. If possible, the IT-system should permit the user to change actions already done. Information about opportunities to change is imported. Sometimes changes are possible and sometimes not. Rectify. Support for error handling. When and how it is possible to correct an error, (i.e. an undesirable result not changeable by redo). When designing the e-service it is important to pay special attention to the main topic, the navigation function and the difference between the informing and performing functions. The functions of feedback, indicate forward, redo and rectify are relevant in all actions in the IT-systems. However, the most basic prerequisites when using the e-service is its support to the trajectory of perceiving, comprehending and becoming informed as a basis for action.

6

CONCLUSIONS

An IT-system is about information, information to be used for some purpose and with some expected effects. The purpose and effects of the e-service in our case study can be related to the different levels in the three levels model (see figure 3). We used the model as a basic approach when creating the eservice prototype and also when articulating and analysing the criteria. When a criterion was identified at one level, corresponding criteria residing on the other levels were searched for. In this way, the model has governed us to pay attention to formulations of criteria and to search for criteria residing at different levels. The knowledge contribution of this paper consists of design criteria for e-services. We have generated new criteria, refined existing criteria and reused existing criteria. In this sense our approach can be characterized as a cumulative approach. The most important new criteria that we have identified are to create good conditions for users to become knowledgeable, differentiate between informative and

performative parts and provide meta information (purpose and content). Examples of reused criteria from the HCI-field are feedback, redo and rectify. The special character of governmental services has influenced the evolution of these e-service criteria. A municipality’s role is both to exercise public authority and to provide service. The municipality needs to inform the companies and handle applications in a legal and proper way. Different legal rules need to be clarified and readily available. The company managers need to be knowledgeable before making an application. The municipality has regulated obligations toward companies but also the companies have regulated obligations towards the municipality. The companies are in some situations forced to get permission and then to turn to the municipality to get that permission. There are no alternative ways for the companies. These conditions have influenced the e-service criteria, e.g. knowledge support, thematized forms and division into informative and performative services. One message in this paper is that criteria proposed by HCI scholars are important to consider, but they are not sufficient. Our claim is that they are too limited and that they are not formulated to support the communication process or the business processes. They are formulated to support one individual user interacting with one computer, just restricted to human-computer interaction. Our view is that human-computer interaction is important, but we view IT-systems as media or instruments used to support communication between users and business actions that are performed in the business process (Goldkuhl 2005). Therefore, the use of an IT-system is only a means to achieve a higher goal: to support the communication between a sender and a receiver in order to successfully manage a business process that produces value for the client. This means that we propose a changed perspective on design or evaluation of public e-services: An expansion from a more limited humancomputer interaction perspective to a human-to-human communication via computer perspective.

ACKNOWLEDGEMENTS This research has been financially supported by the Swedish Governmental Agency for Innovation Systems (VINNOVA).

REFERENCES Ågerfalk P J, Goldkuhl G, Cronholm C (1999). Information Systems Actability Engineering – Integrating Analysis of Business Processes and Usability Requirements, in Proceedings of the 4th Intl Workshop on the Language Action Perspective (LAP99), Copenhagen Ancarini A (2005). Towards quality e-service in the public sector: The evolution of web sites in the local public service sector, Managing Service Quality, Vol. 15 (1), p 6-23 Avison D, Baskerville R, Myers M (2001). Controlling action research projects. In Information Technology and People, Vol 14, No 1. MCB University Press. Baskerville R (2001). Conducting Action Research: High Risk and High Reward in Theory and Practice. In Qualitative Research in IS: Issues and Trends (Trauth E M ed). Idea Group Publishing, London. Buckley J (2003). E-service quality and the public sector, Managing Service Quality, Vol 13 (6) p 453-46 Cronholm S, Bruno V (2008). Do you Need General Principles or Concrete Heuristics? - a Model for Categorizing Usability Criteria. Accepted to Australasian Conference on Computer-Human Interaction Conference (OZCHI). Dec 10-12, Cairns, Australia. Cronholm S, Goldkuhl G (2002). Actable Information Systems-Quality Ideals Put Into Practice, Information Systems (ISD). Riga, Latvia Cronholm S, Goldkuhl G (2005). Actability at a Glance. VITS/IEI Linkoping University Dietz J L G (2001)."DEMO: Towards a discipline of organisation engineering," European Journal of Operational Research (128:2) pp 351-363.

Eliason, E, Hedström K (2005). Mediated values in Swedish municipality Website design. Presented at Ethicomp. September 12-15, Linköping, Sweden. Goldkuhl G (2005). Workpractice Theory – What it is and Why we need it. 3rd Intl Conf on Action in Language, Organisations and Information Systems (ALOIS). Limerick, Ireland, 2005 Goldkuhl G (2009) Pragmatic Qualities of Information Systems – Actability Criteria for Design and Evaluation, invited paper to the 11th International Conference on Informatics and Semiotics in Organisations (ICISO), Beijing Goldkuhl G, Ågerfalk P J (2002). Actability: A way to understand information systems pragmatics. In Coordination and Communication Using Signs: Studies in Organisational Semiotics 2, p. 85-113. Goldkuhl G, Cronholm S, Sjöström J (2004). User Interfaces as Organisational Action Media. 7th International Workshop on Organisational Semiotics. Setúbal, Portugal. Goldkuhl G, Lyytinen K (1982). A language action view of information systems. In proceedings of third Internationl Conference on Information Systems, Ginzberg & Ross (eds). Ann Arbor. Gould, J.D. and Lewis C (1985). Designing for usability: key principles and what designers think. Commun. ACM, 28,3, p. 300-311. Habermas J (1985). The theory of communicative action. Volume 1. Reason and the rationalization of society Beacon Press. Henninger, S., Haynes K., and Reith M.W. 1995. A framework for developing experience-based usability guidelines. in Proceedings of the 1st conference on Designing interactive systems: processes, practices, methods, & techniques. Ann Arbor, Michigan, United States: ACM. Häkkilä J, Mäntyjärvi J (2006). Developing design guidelines for context-aware mobile applications. In ACM International Conference Proceeding Series; Proceedings of the 3rd international conference on Mobile technology, applications & systems. Bangkok, Thailand: ACM. Hartson H R, Andre T S, Williges R C (2001). Criteria for Evaluating Usability Evaluation Methods. International Journal of Human-Computer Interaction, 13(4): p. 373-410. Kärkkäinen, L. and Laarni J. (2002). Designing for small display screens. In ACM International Conference Proceeding Series; Proceedings of the second Nordic conference on Human-computer interaction. Aarhus, Denmark: ACM. Lewin Kurt (1946). Action Research and Minority Problems. Journal of Social Issues 2: 34-46. Muller M J, Matheson C, Gallup R. (1998). Methods and Tools: participatory heuristic evaluation. In Interactions. Nielsen J (1993). Usability Engineering. Boston: Academic Press. xiv, 362. Nielsen J (1999). Designing Web Usability – the Practice of Simplicity. Indianapolis, New Riders Publishing. Rasmussen J, Pejtersen A M, Goodstein L P (1994). Cognitive Systems Engineering Wiley & Sons Inc, p. 396 Searle J R (1969). Speech Acts – an Essay in the Philosophy of Language. Cambridge University Press. Sjöström J, Goldkuhl G (2004). The semiotics of user interfaces – a socio-pragmatic perspective, in Liu K (ed, 2004) Virtual, distributed and flexible organisations. Studies in organisational semiotics, Kluwer, Dordrecht Shneiderman B (1998). Designing the user interface: Strategies for effective human-computerinteraction. 3rd ed. Reading, Mass: Addison Wesley Longman. xiv, 639. Vonk R (1990). Prototyping. Prentice Hall. Englewood Cliffs, New Jersey. Weber M (1978) Economy and society, University of California Press, Berkeley. Winograd T, Flores F (1986). Understanding computers and cognition: A new foundation for design Ablex, Norwood.

Lihat lebih banyak...

Comentários

Copyright © 2017 DADOSPDF Inc.