Introduction

Many governments worldwide have undertaken programs to establish some form of electronic government (or e-Gov), in an attempt to provide information to the general public, as well as extending and improving public services, reducing social inequality, and promoting democracy. The multidisciplinary nature of e-Gov research involves various issues, ranging from technical to organizational, economical and social [22]. In all cases, the involvement and participation of all citizens is important [13]. In this context, accessibility is a necessary aspect to be considered, as these services must be made available to the entire community, including the elderly, those with various disabilities, and individuals with a low level of education. Moreover, not all will have access to personal computers for access to the Internet [25, 28, 32, 44].

Accessibility is crucial for e-Gov systems to be effective, and various guidelines and specific techniques have been proposed as tools to guarantee accessibility [9, 67, 69]. Concepts and methods have been adopted from human–computer interaction (HCI) to provide better interfaces, and from Web engineering to support design, development, evolution, and evaluation [10, 11, 16, 25, 56]. However, aspects such as quality of use and accessibility are not usually considered during the development of Web engineered applications. Special efforts will be necessary if Web application systems are to be developed using artifacts and methods designed to promote social inclusion and universal accessibility for the population.

The development and deployment of suitable information systems (IS) in the e-Gov context requires consideration of legal, cultural, and social aspects throughout the construction of these systems. One must know who is involved and what will be needed in order to create a system, which will potentially influence social practices. While organizational semiotics (OS) suggests how to model and deal with social context and participation, HCI methods can help develop quality in use and stimulate the participation of the population.

Interoperability is also important in e-Gov applications, since various levels of public administration (federal, state, and local) need to be able to interact with one another if accessible, efficient, and satisfactory services are to be offered. One of the challenges of e-Gov initiatives is to make possible direct interaction between citizens and administration in an agile and transparent fashion. In this context, given the great heterogeneity of public infrastructure, service-oriented architecture (SOA) [46] has arisen as an option for dealing with interoperability. This architecture also provides multiple channels for government services. The use of SOA in the development and deployment of inclusive online services for the public involves more than just an understanding of the technological aspects of implementation (e.g., interoperability, reuse, and flexibility). The designers also need to realize the policies and practices, which SOA can promote in terms of meaningful services for clients [62].

The present paper outlines a development process model, based on universal design, which is designed to facilitate the development of effective e-Gov systems. Using OS, artifacts, and methods help situate system development in the socio-cultural context, while the use of participatory design (PD) techniques (from HCI) enables design practices and activities with the citizens. These artifacts, methods, practices, activities, and techniques are considered from the beginning of the development process to achieve universal access to e-Gov services.

The paper is organized as follows: Sect. 2 presents accessibility and interoperability as requirements for e-Gov projects. Section 3 presents the theoretical and methodological background for this work, based on concepts and practices of HCI and OS. Section 4 presents the context, methodology, and the activities carried out in the Digital City Case Study. Section 5 presents the preliminary results and delineates the proposed process model. Section 6 discusses the approach and presents some lessons learned. The conclusion summarizes the work and points out to areas of further research.

Accessible and interoperable e-Gov services

The primary goal of many e-Gov initiatives is to improve interaction between a government and its citizens by means of an infrastructure that takes their reality into consideration [41]. Marchionini et al. [40] proposed a classification for the infrastructure options of such information technology (IT) initiatives based on the following hierarchy:

  • Access to information: citizens access information provided by the governmental institutions; this is the most common type of e-Gov application.

  • Transaction services: citizens use computational systems to complete transactions provided by the government, such as application for passports and licenses.

  • Citizen participation: this concerns the use of IT governmental services to promote the participation of the people in decision making. This category includes very controversial issues, such as e-voting and the potential participation of citizens in rule making.

Technological issues (i.e., performance, integration, and availability) and administrative aspects (i.e., cost and increased income) are certainly very important, but they configure only two dimensions of the e-Gov problem. Another major challenge is to analyze local needs, taking into consideration both social and human aspects of all sorts. Certainly, such needs cannot be identified by using only interviews with public administrators or by carrying out simple laboratory tests with users. This paper argues that, to deal with this challenge, e-Gov systems should be the result of a socially shared understanding of the problem from the planning stages. To reach such an understanding, citizens, public administrators, and representatives from other types of organizations must participate from the conception of the system and continue throughout the development process. Moreover, new models of collaboration for the delivery of governmental services must be defined, whether between two or more public agencies or between public and private entities [12]. Interoperability must be considered in these models, as the use of computational artifacts will be required.

Promoting both accessibility and interoperability is one of the current challenges in the development of e-Gov system. To address this challenge, a process model is needed, a model which includes activities to encourage direct interaction with citizens (front office), as well as the internal infrastructure necessary to deploy the services to be provided (back office). While the front office must be accessible and device independent, in the back office, models of cooperation will be intermediated by computational systems. The following sections present the case for both accessibility and interoperability in an integrated system, in an attempt to delineate a process model for the development of information systems for e-Gov.

e-Gov accessibility

When a user is not able to achieve his/her goals while interacting with a computational system, the usability of the system relative to this user is jeopardized [3, 30]. Accessibility, therefore, is necessary for quality of use in interactive computational systems [3, 4, 21, 58], and this is a definite requirement for e-Gov systems [8, 67, 69].

Various countries have established national guidelines for the promotion of Web accessibility. These are often based on the recommendations of the World Wide Web Consortium (W3C) [14, 32, 69]. The USA, for example, developed Sect. 508 Standards [67], whereas Brazil has developed a similar model (eMAG) [9]. These models provide recommendations for making information technologies accessible to people with disabilities, as well as encouraging the development and adaptation of information about the government for access on Internet. These recommendations suggest that Web site developers should use semi-automatic accessibility tools to create and evaluate sites (e.g., daSilva,Footnote 1 WebXAct,Footnote 2 Cynthia Says,Footnote 3 LiftFootnote 4 and TawFootnote 5), as well as assistive technologies to facilitate access by users with disabilities, such as the use of screen readers (e.g., Dosvox/Webvox,Footnote 6 Jaws for WindowsFootnote 7 and Virtual VisionFootnote 8) to facilitate access by the blind.

The W3C also specifies options to facilitate the development and use of Web sites, such as markup languages, style sheet verification and checkpoint-based evaluation, as well as the use of graphic and text browsers. A range of recommendations for testing is also made. The participation of users with disabilities in accessibility evaluations usually employs adapted usability tests [24]. Wood et al. [71] argue that Web interfaces cannot be evaluated with a single strategy, as such an approach would be likely to yield incomplete, misleading, or erroneous results. They propose a multidimensional approach to ensure that Web-based service delivery meets customer and citizen needs. Their Web evaluation methods fall into four major classes: (1) usability testing, which includes various techniques applied in a controlled laboratory environment, (2) user feedback, which includes methods for getting qualitative feedback from real users, (3) usage data, which includes approaches for collecting quantitative data by using a Web log, and (4) Web and Internet performance data, which include measures of technical performance (e.g., latency, availability, and transfer rate). Graupp et al. [21] also recommend relatively simple verifications by the developers themselves before involving users.

Accessibility in e-Gov systems goes beyond access by people with disabilities. It also involves socio-cultural issues, which influence the way information should be provided. Especially in countries like Brazil, with a significant number of functionally illiterate people and large numbers of economically disadvantaged who lack physical access to the Internet, accessibility must encompass additional aspects. In addition to the possibility of access to the Web via a personal computer, services should be made available in public access booths and from mobile phones. Since the direct participation of all citizens is important, e-Gov must deal with such alternative needs from the beginning of the design and development process. Services must be provided via flexible access, in such a way that different users, experiencing different environmental conditions and/or using different means of access, can be accommodated without discrimination.

e-Gov interoperability

Interoperability involves the collaboration of various public and private entities in the provision of services, whether these are government administrations, hospitals, or schools. Interoperability often requires communication between different computational systems, although these systems are based on different technologies, suppliers, and platforms in different agencies, departments, and administrative units. One solution for providing interoperability is the SOA and its implementation with SOAP/HTTP communication protocols. This architecture emerged in response to the problems of integration involving a large number of protocols, representations, and adapters in the development of complex systems, and is especially important in e-Gov contexts. SOA can be used to construct systems based on services from the perspective of both business and user.

Complex applications are composed of services; some of these entail services to humans, whereas others involve IT systems. SOA provides a guide to all aspects of the life cycle of a service, from conception and implementation to deployment and maintenance. Moreover, it suggests mechanisms to define and provide data exchange and business processes for the IT infrastructure. It provides a high level of abstraction, in which functionality can be specified, published, and/or consumed [62].

While previous object-oriented approaches require focusing on the use of a specific execution environment technology, SOA focuses on the description of the business problem. It is not constrained by a specific type of technical implementation. SOA implements services in a way that is transparent to the consumers. In other words, it does not matter if a service is implemented using Java, Corba, .NET, or a legacy language, nor is it important what methods and protocols are used to request it.

The component-based development and integration (CBDI) forum [62] cites five principles of a good service design, all enabled by SOA characteristics: (1) reusability: the reuse of the service, not reuse by copying code/implementation, (2) abstraction: the separation of the service from implementation, (3) publishing: publication of the specifications of the service interface, not its implementation, (4) formal contracts: existence of a formal contract between provider and consumer, and (5) meaningful service: relevant functionality presented at a granularity recognized by the user as a meaningful service.

Nowadays web services are the most popular technology for the implementation of SOA. Some governments have invested in broad national projects designed to create patterns of e-Gov interoperability. In many cases, these emphasize Web service patterns, such as the Federal Enterprise Architecture (USA) [18], European Interoperability Framework (EU) [29], and e-Ping [15].

The concepts, principles, and practices of SOA have a direct impact on the way systems are developed, and there has been a great deal of research in this area. Kotonya et al. [33] present various issues that organizations have to address in the development of SOA software. These include the unsuitability of traditional software development approaches, the general lack of tools for analysis and design of development with reuse, the general lack of methods for mapping functionality onto services and the grouping of services into logical domains, the need for effective mechanisms to support service orchestration, and finally the need for models to define schemes for monitoring, defining, and authorizing changes of existing suites of services supported within an enterprise.

The software industry has invested in the construction of a process for the development of SOA software. This is the case of the Rational Unified Process® (RUP) Update for SOA [31], which introduces new activities and artifacts for analysis and design. Some examples of tasks introduced during the development processes include: service identification and conception, construction of a distribution model for the system, specification of service contracts, modeling and design of services, and composition or orchestration of services according to a business process. Nevertheless, many aspects of a SOA development process are still on the research agenda. Service-oriented software engineering (SOSE) [66], for example, deals with various aspects related to service development, including the life cycle of service-oriented systems, requirement analysis and evolution, service specifications, and the development of personalized services.

Erl [17] has adapted a top-down strategy for SOA delivery, resulting in eight steps: (1) define enterprise business models, (2) compose SOA, (3) define enterprise service model, (4) perform service-oriented analysis, (5) perform service-oriented design, (6) develop services, (7) test service operations, and (8) deploy services. As proposed by Erl [17], SOA enterprise business models can incorporate a formal ontology, an enterprise entity model, enterprise-wide logical data model, a standardized data representation architecture, and other forms of models generally associated with enterprise information architecture.

In the context of this paper, the concept of interoperability is not restricted to communication between computational systems; it should also be adopted for communication between the individual and various entities, mediated by computers. Principles and practices of SOA are investigated, which are helpful for the development of inclusive e-Gov projects, in which services are aligned with socio-cultural needs and promotion of social inclusion.

Background

This section summarizes the aspects of HCI and OS, which are relevant to the proposed approach.

Human–computer interaction and information systems design

Researchers and practitioners in the HCI field have developed and assessed various methods and tools for the promotion of quality in use of interactive systems. Aspects related to human factors in the use of these systems have been given special emphasis. In order to refer to design of systems that are allied with the user’s point of view and expectations, Norman and Draper [49] introduced the term “user-centered design” (UCD). Nowadays, this is a very active line of research in HCI.

According to Bevan [4, p. 3], UCD provides a valuable framework for “design for all”, so that usability and accessibility requirements can be identified and the capacities of different user groups assessed, including individuals with special needs. Bevan emphasizes that: “For a design process to take a user-centered approach to the identification of requirements, the process must include activities that can capture both usability requirements derived from the capabilities of the end-user groups, as well as accessibility requirements for users with special needs.”

Almost 20 years after the introduction of “user-centered design”, Norman [50] argues that this approach has a limited view of design, focusing on a page-by-page analysis. He proposes that the design process also considers all human activities in an activity-centered view.Footnote 9

One alternative for user-centered design approaches is usage-centered design, proposed by Constantine et al. [10]. This involves a systematic and model-oriented search for a solution to the user interface design. Their approach, which focuses on the task instead of the user, involves successive refinements of models (e.g., user role model, user task model, and interface content model) to fit the final user interface design. According to Constantine et al. [10], such models are initially designed on the basis of existing information, but they are constantly improved with feedback from field research with a very well-defined focus, as well as observations, surveys, and other investigations. Moreover, this approach allows a more direct integration with software engineering process models.

For design processes, usability engineering incorporates principles such as user involvement from the initial phases of development, empirical measurement, iterative design, and the integrated design of all aspects of system usability [26, 48, 55, 68]. The phases of the usability engineering life cycle can be summarized as follows: pre-design, design (initial design and iterative development), and post-design [48, 55]. The pre-design phase aims at identifying information about the users, their work context, and about related systems, as well as providing interface patterns, guidelines, and development tools. Initial design deals with the preliminary user interface specification, while iterative development deals with feedback and tests of the achievement of usability objectives. During the post-design phase, the system is installed in the user’s workplace and its use is followed to evaluate user reactions and system acceptance. This general model provides some guidance for the organization of a process model, which takes quality in use into consideration.

One option for achieving a broader view of design is to encourage potential users to participate during the entire engineering life cycle. By using this approach, the interface is designed with the users, so that they participate in design decisions, and express their opinions about activities, practices, tasks, and usage context. Participatory design (PD) in system development has its roots in work done in Scandinavia during the 1970s, and promotes direct user involvement in various phases of the design process, including problem identification and clarification, establishment of requirements and analysis, as well as high-level design, detailed design, evaluation, user customization and redesign [45]. In PD, collaboration between designers and users is considered essential to achieve democracy in decision making, quality in use, and acceptance of the resulting product. PD also promotes mutual learning [35] from the combination of different experiences.

A large amount of research in the PD field has been conducted to establish meaningful practices for the provision of a common ground for discussion among those directly involved in the design and use of technology [59]. Participatory techniques are useful instruments for the discussion of users’ social context, since they promote active participation. Nevertheless, as argued by Grønbæk et al. [23], PD techniques seldom go beyond the early analysis/design activities of project development [2].

Pekkola et al. [53] argue that a multi-methodological approach using prototyping and a set of various means of communication is necessary to stimulate end-user participation in development processes. It is important that the people involved share a model for the representation of the work domain in the prospective system. Meaning-making is constructed as the result of cooperation between designers, developers, interested parties, and prospective users of the technology being designed. Therefore, extensions and adaptations of the techniques are necessary (e.g., use of tactile cues, use of high contrast solutions, sign language interpretation, and assistive technology compatibility) to enable the participation of people with different needs, skills and interests, including people with disabilities [43]. The participation of each and every individual must be promoted so that he/she can perceive, understand, communicate, be understood, and interact with his/her peers [42].

Organizational semiotics and the design of information systems

Semiotics, the doctrine of signs, leads to an understanding of information as various properties of signs. Anything standing for another thing or used to signify something else [54] is an example of a sign: words, sentences, traffic lights, diagrams, the wave of a hand, and facial expressions. Organizational semiotics studies organizations using concepts rooted in semiotics [52]. The rationale behind OS is based on the assumption that any organized behavior is affected by the communication and interpretation of signs by people, both individually and in groups [37].

Early work on OS dates from the 1970s. Research by Stamper advocated semiotic thinking in IS [60]. He also introduced the organizational onion, a meaningful way for understanding the structure of organizational IS in levels. As shown in Fig. 1, at an informal level (of the organizational onion) there is a sub-culture in which meanings are established, intentions are understood, beliefs are formed, and commitments involving responsibilities are made, altered, and discharged. At a formal level, form and rule replace meaning and intention. At a technical level, part of the formal system is automated by a computer-based system. The informal level subsumes the formal one, which subsumes the technical one. Modifications that occur on any level impact on the other levels. Thus, for example, changes in the informal or formal levels have implications for the technical information system, and the introduction of a computer-based system in an organization (technical level) can generate modifications in the formal and informal levels of the organization. The OS approach provides a methodological basis for the articulation of the organizational levels in a system design.

Fig. 1
figure 1

The structure of an organization, adapted from Liu [37, p. 109]

Full size image

OS methods have been found useful for dealing with the influence of social aspects in organizations and in the elicitation of system requirements [6, 36, 38, 39, 60, 61, 65]. Among the methods employed by the OS community is a set of methods known as MEASUR (methods for eliciting, analyzing, and specifying users’ requirements) [64], which deals with the use of signs, their function in communicating meanings and intentions, and their social consequences. MEASUR involves the analysis of stakeholders in a focal problem, as well as considering their needs and intentions, and the constraints and limitations related to the prospective software system. Figure 2 summarizes the logical sequence of the main methods of MEASUR. The following sections present a summary of some of the methods adopted.

Fig. 2
figure 2

An overview of the selected organizational semiotic methods

Full size image

Problem articulation

The set of methods known as problem articulation (PAM) is applied in the initial phase of a project, when the definition is still vague and complex. The analyst finds support in defining system units that will be validated by stakeholders. The following is a list of the PAM methods adopted and their justifications:

  • Stakeholder analysis This method allows the investigation of the interested parties who either directly or indirectly influence, or are influenced by, the information system under analysis.

  • Evaluation framing This method allows the identification of the interests, questions, and problems of each stakeholder, so that possible solutions can be envisaged [7].

  • Semiotic diagnosis (or semiotic framework) This method is used to examine the organization on the basis of Stamper’s six semiotic layers [63]: physics (dealing with the physical aspects of signs and marks), empirics (dealing with static properties of signs when different physical media and devices are used), syntactic (dealing with combinations of signs without considering their exact signification), semantics (dealing with the relationships between a sign and what it refers to, as well as with signs in all modes of signification), pragmatics (dealing with the purposeful use of signs, intention, negotiation, and the behavior of agents), and social world (dealing with the social consequences of using signs in human affairs, including beliefs, expectations, commitments, law, and culture).

  • Collateral analysis This method allows the analysis of relationships between unitary systems, which constitute a complex system. It locates the effective limits of the system in the environment, and the predecessor system, as well as the focal system and its infrastructure. Collateral systems provide maintenance, backup and recovery, as well as inputs and outputs.

Semantic analysis

The semantic analysis method (SAM) is used for the analysis, specification, and representation of requirements. The outputs of this method are semantic models, called ontology charts, which identify agents in the problem domain and their patterns of behavior, named affordances [20, 37].

SAM assists analysts and users or problem owners in eliciting and representing their requirements in a formal and precise model. With the analyst in the role of facilitator, the participants construct an ontology chart, which describes a view of responsible agents in the focal business domain, as well as the patterns of behavior. The meaning of the words used in the semantic model is treated as a relationship between the signs and appropriate actions of the agents. The semiotic conference method [6] can also be adopted by users and designers in the modeling of an ontology chart in parallel with interface prototypes.

Norm analysis method

The norm analysis method (NAM) focuses on social, cultural, and organizational norms that govern the actions of agents in the business domain. A norm, in both a formal and an informal sense, defines the responsibility of an agent engaged in a task, or a condition under which certain actions may (must, must not, etc.) be performed by an agent. Norms are related to the social and pragmatic layers of Stamper’s framework, and are identified and encoded into specific parts of the ontology chart.

From practice to process model: Digital City Project

The process model for the e-Gov context discussed in this section is the result of activities carried out in the context of the Digital City (DC) Project [7]. Participatory activities were developed with the purpose of understanding the context of the specific town involved in the project, as well as discussing general requirements for an e-Gov development process.

The scenario and method

The project was undertaken in a city of nearly 115,000 citizens, located in a rural area of the State of São Paulo in Brazil. The local economy is based on agricultural activities, although an incipient industrialization process is underway. The majority of citizens have little or no access to IT infrastructure.

The city‘s mayor started by forming a committee to review the IT infrastructure so that public services and activities could be improved. The program was called the “Digital City Project”, and one of the major issues addressed was social inclusion. In the beginning of the Digital City Project, some of the existing internal administration systems were replaced by an integrated system, although this was not considered part of the solution, since it did not eliminate the need to go to governmental agencies to access the services. Researchers were contacted and asked to conceptualize and design an e-Gov system. The project was conducted as follows.

Participants

There were three main groups among the participants:

  • Town hall team One public employee from the secretary of education, two from the secretary of finances (which is responsible for the IT infrastructure), and one back office system designer.

  • Research team Five researchers in the field of computer science/information systems, two in the field of education, and one in the field of communication/multimedia.

  • Citizen representatives These were identified during the project activities, using the stakeholder analysis method. In practice, the DC project involved three representatives from the community and two from a non-governmental organization (NGO) which works directly with various communities in the city.

Process

PAM was adopted to promote an understanding of the city in economical, social, and political terms, as well as ascertain its main needs and problems. The method adopted involved an adaptation of the original method in that the main questions and problems were explored with each group of stakeholders, and possible solutions were discussed. The following description outlines the use of PAM with the participation of the involved parties.

PAM diagrams are artifacts used to organize ideas and group discussions. They include: the stakeholder frame, which groups the ideas about potentially interested parties for each level of the project (informal, formal, and technical); the semiotic framework, which groups the issues according to the semiotic level whether physic, empiric, syntactic, semantics, pragmatic, or social; the evaluation framing diagram, which groups problems and solutions the stakeholders have at informal, formal, and technical levels; and the collateral analysis diagram, which explores ideas about the project life cycles. The diagrams are mounted on large posters and hung on the wall to mediate these discussions during the workshops. A facilitator introduces a discussion based on each semiotic diagram. In a brainstorming format, the participants discuss the ideas, each expressing his/her own ideas using post-its that are stuck on the posters. During brainstorming, the position of the post-its on the diagram is also discussed, so that related ideas are grouped together to provide a structure. The participants are also invited to discuss conflicting ideas, even though some conflicts will potentially appear only during later stages of the project. The main objective here is to identify conflicts from the beginning. After brainstorming, each participant is invited to write a synthesis of the themes discussed, and these are then presented and discussed.

Figure 3 illustrates a meeting room showing the presence of the semiotic framework and the stakeholder frame. Each meeting was attended by approximately 15 participants, including research workers, designers, public administrators, and community representatives. During the project, three workshops were organized according to the sequence described in the following sections.

Fig. 3
figure 3

Example of use of PAM as participatory tools

Full size image

Data sources and analysis

The main sources of data analyzed are posters filled with post-its, other meeting records (i.e., reports and photos), documents from the city hall, and back office systems. The study was not limited to the information expressed in speech, writing, or charts, but it also considered the semiotic aspects of the organizational products and productive resources from physical to social layers.

The content of the post-its was transcribed to electronic format. Although the data were already structured according to the PAM diagrams, additional aspects of the suggestions and ideas were analyzed by the research workers to identify the requirements of the project. In a first analysis, the similarities and the relations between problems and solutions were identified. Recurrent issues and terms were identified informing the process principles. After that, methods and techniques of the proposed process model were defined according to the principles elicited and the questions discussed.

Participatory practices

This section presents the organization of participatory practices, as well as some examples of the issues discussed. Basically, PAM artifacts were used to construct a shared understanding of the development context. Figure 4 shows the sequence of meetings, preparations, and workshops conducted. These led to the identification of accessibility and interoperability as central concepts in this e-Gov context, and suggested basic requirements to be included in the process.

Fig. 4
figure 4

Initial participatory meetings, preparations, and workshops

Full size image

The first and second meetings were conducted with the participation of the town hall team and the research team. During these meetings, the participants discussed the main project goals and established an initial strategy for conducting the project. This included preparation of the practices for the following three workshops. Figure 5 illustrates different moments and artifacts used in these workshops.

Fig. 5
figure 5

Snapshots of the participatory workshops using PAM

Full size image

Workshop 1

In the first workshop (Fig. 5a), the interested parties were identified using an adapted version of the original PAM stakeholder analysis diagram and this served to promote discussion about perceptions of the interested parties in the project.

Figure 6 shows how the main stakeholders were identified. The left-hand diagram shows how the post-its identify the stakeholders in the Digital City Project on the basis of their level of involvement: technical, formal, and informal. Four different groups of stakeholders were identified: project co-executors, regular stakeholders, governmental departments, and certain employees working closely with the mayor; each group was represented on the poster with a different color of post-it. The right-hand diagram focuses on aspects of the technical system.

Fig. 6
figure 6

Diagram of stakeholder analysis filled with post-its

Full size image

Results of this first workshop revealed the complexity involved in understanding the different people interested in e-Gov services, provoking the consideration of strategies for involving the citizens in the conception, design, and evaluation of the prospective system. The need for cooperation between different agencies and the perception of the existence of heterogeneous back office systems revealed the need for the development of interoperability. Representatives from various social agencies and non-governmental organizations shared their concerns about the heterogeneity in the educational background of the population. The representatives pointed out the need for alternatives so that they could access e-Gov products and services, thus reinforcing the need for practices to promote universal access. This analysis also served as the basis for the identification of additional participants for the following workshops, including members of non-governmental organizations and representatives from social agencies involved in the project.

Preparation 1 was conducted by the research team to classify the stakeholders and to prepare artifacts for the following workshop.

Workshop 2

During the second workshop (Fig. 5b), the focus was on collecting the opinions of the main stakeholders and assessing their problems and doubts, as well as their proposals for possible solutions. The technical possibilities for the prospective system were also discussed. Participatory use of evaluation framing was made by the organizing committee with the representatives of social agencies, non-governmental organizations, and the research team.

The problems and questions related to the project context were grouped into the three levels of the onion: informal (e.g., low educational level of the population), formal (e.g., necessary investments), and technical (e.g., interoperability issues). The participants also discussed solutions for anticipated problems. Examples of questions and possible solutions elicited are as follows:

  • Informal level. “What are the real interests of the communities?” and “what is the difficulty of the less educated citizens in expressing their problems?”, and proposed possible solutions included: “to have meetings with district and community representatives to discuss their interests”; and “to construct an accessible communication portal for the project, so the population can express their needs”.

  • Formal level. “Long queues in the public health system” and “use of the system to promote transparency in the administration”, although not uncommon problems, potential solutions elicited at this level included: “the availability of personal assistance for online services”; “access to transparent accounts of legislative decisions”.

  • Technical level. “How will the population access the system?”; “how will the local systems interact with the state and federal systems?”. Some potential solutions were: “use of Internet kiosks”, “use of automated teller machines as an interface metaphor to guide the design”, “use of audio devices at all access points”, “video-based interactions”.

The second preparation step was conducted by the research team to plan the use of PAM artifacts for the following workshop. Also, the team identified the main goals of the project on the basis of the previous discussion and existing IT infrastructure.

Workshop 3

In the third workshop (Fig. 5c, d), the focus was on deciding the practices, activities, and resources needed for the conception and design of the prospective system. The semiotic framework and collateral analysis diagrams were used with participation of the stakeholders’ representatives.

Table 1 presents a synthesis of the ideas included in the semiotic framework, which was used for the discussion of topics in the six layers, from the social world to the physical world. Among the topics discussed were digital inclusion (social level), transparency of the public administration (pragmatic level), the use of popular terms in the interface (semantic level), language of legacy systems (syntactic level), software certification (empiric level), and network infrastructure (physical level).

Table 1 Synthesis of the semiotic framework
Full size table

Results from participation in the discussion of collateral analysis were used to establish directions for the subsequent steps of the project. Various services were focused on, including: online appointment in the public health system, online public school registration, online access to the legislature, and process tracing. The group considered legacy systems, city hall, and the legislative Web portal to be predecessor systems.

Example of environments identified in the data collected during the collateral analysis, included district-wide associations, public schools (on weekends), public departments, public hospitals, and communication media. Proposed input for the system included citizen questions and citizen identification cards; project output included: socio-economic map of the city; communication portal; participatory public planning; training of government employees; and transparency in public finances.

Aspects related to development were also discussed, including use of development standards, platform independency, interoperability, usability and accessibility, and use of open sources. Discussions regarding resources involved aspects such as network infrastructure, data center, distributed access points, low cost terminals, and electronic security.

The topics raised in the workshops served as the basis for the identification of the process requirements and are presented in the next section.

Preliminary results: delineation of a process model for the development of inclusive e-Gov systems

To achieve the general objectives and requirements identified during the meetings and workshops of the DC Project, a model for the system development process was proposed. Previous experience in the use of OS methods and artifacts were also considered in the process definition, including that of the different stakeholders, such as people with disabilities [5, 43, 44, 60].

Five general principles were extracted from the topics identified during the workshops and their discussion:

  • Principle 1. Promote the participation of the citizens and other stakeholders in the universal access and inclusive design values. During the workshops, several references (post-its on the evaluation frame poster) were made to the anticipated difficulty of citizens in accessing e-Gov services, and the National Decree for the Promotion of Accessibility (post-its on semiotic framework poster) was discussed.

  • Principle 2. Share an understanding of the social context of the city. The development of e-Gov systems should be based on a shared understanding of the social context revealed by the use of methods and techniques, which represent and explain it. One example of the discussions leading to this principle was the social–economic map of the city (as suggested by post-its on the collateral analysis poster).

  • Principle 3. Include more than just technical issues in the development of e-Gov services. Various references were made to organizational and social aspects, which needed to be considered, e.g., changes in the culture of public services (revealed by post-its on the semiotic framework poster).

  • Principle 4. Promote interaction and interoperability between governmental agencies. The need for interoperation with state and national systems was discussed, as this would be necessary to provide accessible services for all citizens (based on post-its on the evaluation frame poster).

  • Principle 5. Promote quality of service, which incorporates a broader definition of accessibility and inclusive environments. Some of the topics discussed included the coordination of the design with educational activities and the provision of multiple means of access (as proposed by post-its on the evaluation frame, semiotic framework, and collateral analysis posters).

These principles can be contrasted with those outlined in other development processes, such as the rational unified process (RUP) [34] and the Agile Software processes [1, 27]. As shown in Table 2, the principles of RUP and Agile Software focus mainly on the production of software and its quality. These aspects are certainly important in the e-government context, and can be applied, but they do not capture the multidisciplinary aspects of e-Gov projects. In traditional development processes, issues related to accessibility and interoperability are considered only at specific moments (i.e., during the requirements analysis and testing). In this proposal, they were considered part of the principles and were used to guide the definition of the entire process model, which is presented in the following section.

Table 2 Principles in process models
Full size table

Semiotic inclusive process model (SIPM)

The development of the process model is outlined in Fig. 7. This model was designed to guide the development of software systems on the basis of the principles already identified. The process elements are grouped according to the central issues of analysis and modeling, HCI and universal access, interoperability, and system construction. In this process, the understanding of concepts and the elicitation of needs and organizational context serve as the basis for achieving the project objectives. Models from OS are used to promote understanding and a discussion of various aspects related to the organization. Relevant aspects of HCI and universal access, as well as those of interoperability, also inform system construction by providing models, concepts, techniques, and requirements during the construction of software systems.

Fig. 7
figure 7

Main elements of SIPM

Full size image

The usability engineering life cycle is adopted to define the phases of the process model. Interface design and other aspects of software development are integrated, and various procedures, practices, methods, and activities are selected to achieve the objectives delineating each phase:

  • Pre-design. The objective of this phase is the construction of an initial shared understanding of the social context. In this phase, designers must elicit the needs with the participation of the stakeholders. The services proposed should also be described at organizational and social levels. The use of concepts and methods of OS, aligned with participatory design techniques, is employed for the iterative construction of a shared understanding of the problem. Relevant stakeholders and information systems are identified, and a variety of problems and questions are raised, as well as some possible solutions. These are explained, documented, and organized by using problem articulation methods. After that, the focal problem has to be defined, and the agents and their patterns of behavior identified and represented on ontology charts. Norms are also elicited and documented. The related information systems are analyzed in order to identify both positive and negative aspects, so that recommendations can be established for the development of the focal system. Systems requirements are iteratively elicited, documented, and validated. The information system vision document is then drawn up to summarize the scope, objectives, and development milestones of the project, including those associated with interface usability and accessibility. Recommendations, high-level architecture, and the first use case diagrams are specified. The W3C recommendations of accessibility are considered at this point [19, 43, 70]. Descriptions of the business level for services are written and the basis for a business cooperation model is outlined.

  • Initial design. The main objective of this phase is the establishment of the conceptual design for the services to be provided, based on the participation of the stakeholders. The designers and stakeholders have to design the interface cooperatively, with a focus on accessibility, as well as designing high-level services and outlining business process models. Using the initial requirements and use case diagrams as a basis, the activities for participatory prototyping must be developed with the stakeholders. In these sessions, citizens have to be involved, so that a deeper understating of user vocabulary and their organization of this information can be developed. Interface designers and system information architects iteratively design a series of user interface prototypes, and navigational models for service access and use. These interfaces and the ontology charts are evaluated by end users, designers, and other stakeholders through the application of the technique of semiotic conference [6]. The models of the system, including those related to service development (i.e., initial service model and high-level business process modeling) are specified. The graphic art for the end-user interfaces (i.e., wire frames) and style sheets are developed and evaluated. For the Web systems, it is necessary to make sure that the source code (i.e., HTML and CSS) are correct. After that, the preliminary accessibility evaluation must also be conducted with the stakeholders [44, 70].

  • Iterative development. During this phase, the system is implemented and tested iteratively. The development team must integrate and test the user interface, software, and content. Methods such as heuristic evaluation [47, 48] and participatory inclusive evaluation [43] are used to evaluate the user interface. Then the interface must be submitted to compliance tests based on W3C accessibility recommendations. Finally, usability tests are performed [55, 70]. At this stage, those processes which require the cooperation of various individuals and/or business entities are also evaluated with the stakeholders.

  • Post-design. The main focus of this phase is on the effective use and provision of services for actual citizens. If necessary, end users are trained. Organizational changes are put into practice, and the services are delivered. For a certain period of time, the response and acceptance of the system are analyzed, and small adjustments implemented whenever necessary. The end of the development can be formalized, and an operational and support plan implemented to maintain the level of quality of the system and promote evolution as changes and new business requirements arise. The final evaluation of the development process must be conducted with the stakeholders, and the results documented and published.

Discussion and lessons learned

The proposed process model for the development of inclusive and interoperable e-Gov systems is rooted in social agreements among many stakeholders and their representatives. Citizens‘participation sheds light on the requirements and principles involved in the process model, which is not designed to be a prescription to be followed. The model can and should be tailored to each specific project, resulting in unique SIPM instances on the basis of the context and organizational requirements of the project.

It is very difficult to define who the users are in an e-Gov context [51]. The proposed process model suggests practices, based on PAM, designed to elicit and discuss requirements with representatives of the main classes of stakeholders involved in the project. The initial participatory practices enable a discussion of who are the people (whether they be users or not) interested in the technical, formal, and informal aspects of the system. This is the starting point for the identification of representatives of each stakeholder class, so they can be invited to participate in the project. In the case reported here, the municipality itself acted as a facilitator and invited the initial stakeholders to participate.

Practices guided the discussion of the main problems and the subsidiary systems supporting the focal system. Although the basic discussion agenda was limited, the use of PAM artifacts helped structure the suggestions provided into classes, and consequently improve the designer’s vision of the problem. With the semiotic framework, for example, problems, questions, and solutions proposed by the practitioners were distributed into six categories, which helped to distinguish problems of a social nature from those of a more technological nature and establish specific strategies for dealing with them.

The main benefits expected from this proposal are the introduction of a more mature understanding of the true context for the execution of the project, as well as the facilitation of the involvement of community representatives. Governmental contexts are usually very complex, but the involvement of representatives from the interested parties, and the use of appropriate artifacts to mediate discussion, provide a valuable starting point for the implementation of inclusive e-Gov services.

The experience acquired with the Digital City Project can be summarized into some lessons learned in relation to various aspects of the process:

  • Stakeholder identification becomes a problem when the target audience is the whole population. In the DC project, 40 different stakeholders were identified (Fig. 6), and the degree of involvement of each category of stakeholder had to be identified and discussed.

  • The identification of stakeholders is not enough. Strategies and techniques must be defined to promote the participation of at least the key stakeholders throughout the project. In the DC project, public entities and NGOs collaborated by identifying crucial elements.

  • Discussions require careful structuring due to the complex nature of e-Gov. Accessibility in e-Gov contexts usually involves very complex issues, including technological, political, legal, and social needs. By organizing the ideas beforehand, the meetings were much more productive. In the DC project, artifacts such as the diagrams outlining the semiotic framework were used to introduce an agenda for discussion. This agenda focused on all of the six information layers. Additional resources, such as the use of post-its of different colors posted on these artifacts, were also useful in providing a shared view and in organizing the discussion.

Conclusion

Recommendations and techniques aimed at accessible user interfaces have been widely disseminated in the context of e-Gov. Service-oriented architecture is an alternative for dealing with questions of interoperability and the high heterogeneity of public infrastructure. However, literature has not provided a process model for the development of e-Gov systems that articulates both aspects based on an understanding of the underlying social context.

The Digital City Project led to the identification of the main requirements for an inclusive process model in an e-Gov context. These requirements were synthesized into five principles. On the basis of these principles and the results of the experience acquired in this project, this paper has delineated a process model for the development of e-Gov information systems, which integrates concepts and methods from different disciplines in the development of a system based on a socially shared understanding of the underlying social context. Instances of the process model are now being successfully created and applied in other ongoing e-Gov projects.

HCI poses several challenges: “users are no longer only the traditional able-bodied, skilled and computer-literate professionals; product developers can no longer know who their target users will be; information is no longer relevant only to the business environment; and artifacts are no longer bound to the technological specifications of a pre-defined interaction platform” [57, p.165]. Investigation on how to explore ontology charts and norms to provide flexible interfaces in the process model for e-Gov is in the research agenda for further work.

In addition to the flexibility in the interface tier, flexibility in the middleware tier is also being investigated. The SOA/Web service solutions provide technical interoperability by using standard protocols, which allow communication among different front office platforms and hardware solutions, as well as integration of heterogeneous back office systems.

The participatory practices introduced in the proposed model allow for a discussion of the social and organizational aspects of public services, and the practice of an e-democracy, which will enable citizens to become involved not only in the design, but also in decisions regarding actual services to be provided.