Introduction

Mobile and Internet technology is developing more and more rapidly, enabling many different services that are marketed with expectations that are too optimistic; technologies like the Wireless Application Protocol (WAP), the Universal Mobile Telecommunications System (UMTS), and Positioning technologies (like Cell-ID, A-GPS) have failed to make good on their promise and they have turned out to be very expensive for developers and investors alike. The rates that are charged for basic phone services are dropping rapidly, the worldwide market for handsets is becoming saturated and mobile phone penetration in most developed countries is exceeding 100%. Broadband mobile telephony opens additional avenues to provide information conveniently as quickly and easily as possible, when needed and where needed (Fjermestad et al. 2006). However, the actual use of value-adding mobile information and entertainment services is increasing only slowly compared to that of mobile phones voice communication or text messaging (Bouwman et al. 2008).

Literature on the diffusion of innovation fairly uniformly concludes that new technology is adopted on the basis of demand pull rather than technology push (Von Hippel 1988, Rogers 2003). This does not mean, however, that a technology push approach should be completely abandoned. It would make no sense for the mobile service industry to stick to obsolescent technology. New capabilities, like high bandwidth, positioning possibilities and mobile video players are ten times or even a hundred times more powerful than the ones they replace. The challenge is to combine a demand pull and a technology push approach to benefit from technological developments without losing sight of the customer. In the mobile service industry, the demand pull approach can be realized by focussing on the customer’s context (Coutaz et al. 2005).

In designing mobile services, it is crucially important to take the customer’s context into account. Mobile phones are used in a wide range of environments and, moreover, when people move between environments, this involves significant changes in context (Blom et al. 2005). Examples of relevant contexts are whether the user is a tourist who visits an unknown city; whether he or she is a victim in a crisis situation, such as a car crash, where the driver has no idea of his or her exact location; or a parent whose daughter is missing at Disneyworld. What exactly a context is, is a much debated and controversial issue. Tamminen et al. (2004) argue that the reason it seems difficult to capture context in any general sense that would support design is that context is closely connected to a person’s internal and social interpretation. Kang et al. (2008) distinguish two types of user context: internal and external. The internal context describes the state of the user, including personal events, communication context and the emotional state of the user, while the external context refers to the state of the environment, which includes location, proximity to other objects, temperature, time, etc. Often, when the word context is used, it refers to the external context only. Sun (2003), for example, defines user context as the user-sensitive information related to consumer behavior, including the location, surroundings and physiological information of the user.

We argue that future progress in mobile services will come from combining a technology push approach with a demand pull approach, by matching the technological components that come from the labs with the context of the user. The aim of our research is to help close the gap between a supply-driven technology innovation and a demand-driven awareness because the preference and behaviour of customers should be given top priority when it comes to the adoption of such innovations. In this respect, it is crucially important to make sure that we have a correct understanding of user requirements defined here as users’ wants and needs in a specific situation, in a certain context. The aim to understand the users’ wants and needs can be realized by involving the users early on in the design process, an approach that, although it is becoming more and more accepted (Fjermestad and Romano 2003) still requires further fine-tuning (Mao et al. 2005). When it is possible to do this efficiently, system developers can use this method to start their design process with deriving ideas for services that are wanted and needed.

The research question in this paper is:

“How can we efficiently involve users early on in a mobile service design process?”

The paper is organized as follows. In the next section, we present a discussion of existing processes and techniques with regard to the retrieval of user requirements, building on collaboration and group support literature. The combination of techniques aimed at gathering user requirements and group support knowledge has resulted in an approach that we describe in the third section of this paper. In the fourth section, we present three cases in which we applied the approach, after which we discuss the results and address the lessons that can be learned from our study. We finish by presenting our conclusions and suggesting possible directions for further research.

Literature

This study is positioned in the overlapping field of two research domains, e.g. the domain of user requirement elicitation and the domain of Group Support Systems that support collaboration in groups. This article builds forward on the research results in those two domains.

The existing body of literature regarding the adoption and use of mobile services is quite extensive. Bouwman et al. (2007) have discussed literature with regard to the adoption of mobile innovations, as well as the barriers and benefits of mobile services. Most studies that focus on this area of research are based on the Technology Acceptance Model (TAM) (Davis 1989) and the Unified Theory of acceptance and use of technology (UTAUT) (Venkatesh et al. 2003), and most of them explain the use of mobile services with hindsight, without addressing the question of how to retrieve user requirements before a service is designed. Studies aimed at forecasting user demand at a macro level, for instance Blackman et al. (2007), do not describe the process involved in gathering user requirements for the design of specific services either, in spite of the fact that, according to Orlikowski (2000), it is important to ‘better understand how and why people are likely to use their technologies’. Asking people what they would want and need from a service that has yet to be designed poses a serious challenge. Requirements elicitation is the process in which this challenge is taken up: understanding and capturing user requirements.

Techniques aimed at gathering user requirements can be divided into several non-exclusive categories (Nuseibeh and Easterbrook 2000, Hickey and Davis 2004). Some techniques involve individual users, whereas other techniques benefit from the interaction of a group of users. Some techniques are quantitative in nature and focus on the ‘what’ question, whereas more qualitative techniques focus on the ‘why’ question. Without intending to be complete, we list some well-known techniques to gather user requirements. Traditional techniques include questionnaires, surveys and interviews with individual users. Group-oriented techniques are aimed at fostering user agreement by exploiting team dynamics to gain a better understanding of user needs, and include brainstorming, focus groups and Rapid Application Development/Joint Application Development (RAD/JAD) workshops (Wood and Silver 1995). When there is a great deal of uncertainty or when early feedback from stakeholders is required, prototyping can be used (Davis 1992). Cognitive techniques include a series of methods that were originally developed for the purpose of knowledge acquisition, such as thinking aloud and card-sorting (Shaw and Gaines 1996). Contextual techniques, which present an alternative to traditional as well as cognitive techniques, include techniques like participant observation and conversation analysis (Goguen and Linde 1993).

Every technique has advantages and disadvantages, and the decision which method to use depends on the objective, the kind of information that is needed and circumstances such as the available time and resources. Combining various techniques is usually very productive: combining prototyping with cognitive techniques, for example, allows users to think aloud, while at the same time being able to experience a new system. Hickey and Davis (2004) describe a model that helps select the best (combination of) information-gathering techniques. They argue that a technique should be chosen on the basis of the requirements that are already known and the intended system. They emphasize that the preferences of the analyst or researcher involved also play a role. Based on the selection model of Hickey and Davis (2004), we decided to use the focus group as an information-gathering technique, because understanding the context of the user in an early phase of the process is essential for the development of mobile services. In a focus group, the researcher conducts in-depth interviews, which usually last 1 to 2 h, with a group of six to 12 members of a target population. Using a focus group has a number of advantages. First of all, it is a relatively time-efficient approach, it offers a higher degree of flexibility (depending on the group, the various steps can be adapted along the way), the output is easy to understand, the information that comes available is relatively rich, and information that may otherwise have remained hidden tends to emerge (Langford and McDonagh 2003, Ulwick 2002). Second, focus groups allow researchers to view a topic from the user’s point of view (Ulwick 2002). Some of the disadvantages are that focus groups tend to involve more time-consuming preparation, that they are more difficult to manage, that individual participants may either be very dominant or silent, that participants may respond in a socially desirable manner (Wooten and Reed 2000), that they may be unwilling to discuss sensitive or personal issues (Morgan 1997), that recruiting participants takes a great deal of time and effort, that analyzing the results is time-consuming and complex, and that the participants are not really representative of the larger target market (Langford and McDonagh 2003). Some of these disadvantages can be countered by using group support systems (Kontio et al. 2004).

Group support systems (GSS) are computer systems that support collaboration in groups, including electronic brainstorming and voting that allow for anonymous and parallel participation, that alleviate many of the disadvantages associated with focus groups. Because GSS allow people to take part anonymously, silent or shy participants are more likely to participate actively, and everyone will participate more equally. Ideas will be judged on the basis merit rather than one who presents them. In addition, people find it easier to talk about sensitive and personal issues in an anonymous setting. Working in parallel allows groups to be at least as or more productive: the quantity and quality of ideas will improve (Underhill and Olmsted 2003, Valacich et al. 1994). All the results are stored electronically and are readily available for analysis. The success of GSS meetings is often attributed to specific GSS characteristics: anonymity, parallel input, and group memory (Fjermestad and Hiltz 1998–1999). Previous studies have reported a reduction in time and costs of up to 50% (de Vreede et al. 2003, Post 1993–1994, Grohowski et al. 1990, Dennis et al. 1999, Nunamaker et al. 1997). However, some of the disadvantages of focus groups are more difficult to reduce. Participants with poor typing skills may be outperformed by those with better typing skills, and people of different cultures will respond differently to the use of GSS (Klein et al. 2007).

Research method

We set up a focus group aimed at gathering user requirements, using GSS as a support tool, and applied it in three cases. We followed an action research approach, which is considered more appropriate when the subject under investigation is too complex to be studied in a constructed setting. Action research is especially useful with regard to answering ‘how to’ types of questions and it involves the practical application of tools and methods (Argyris et al. 1982, Checkland 1981). Gathering user requirements with a combination of focus groups and group support systems in an early phase of mobile service design hardly ever occurs ‘naturally’, which makes a more passive approach, such as case studies, impossible. We used the model proposed by Zuber-Skerrit (1991), who argues that a study of the kind we wanted to conduct involves four consecutive activities: planning, acting, observing and reflecting. The process involved is not sequential but iterative in nature: the researcher can go back to earlier phases many times (Zuber-Skerrit 1991). This allows us to slightly redesign the focus group session after each case.

Role of the researchers

During the focus group sessions, the researchers played the roles of observer and subject at the same time. As subjects, the researchers facilitated the process. This included scheduling, preparing and moderating the focus group meetings. Although playing a dual role as observer and subject enables researchers to study unique situations, it also creates the risk of bias, because there is a chance that they become advocates for the groups or phenomena under investigation. The researchers only intervened to allow the focus groups to realize their objectives. They had no personal interest in any of the cases. The main reason the client organizations decided to involve the researchers was that they themselves lacked the expertise needed to conduct this kind of research.

Selection of cases

We used the following criteria to decide whether or not to include a case in our research:

  • The aim of the client organization should be to assess the potential of new technologies to offer value-adding mobile services to end-users.

  • The client organization should allow us to use and report on the results and process of the focus groups.

The first case involved designing services aimed at the visitors of a university campus, and it involved a European mobile operator, the second case was aimed at exploring the possibilities of wireless applications in the process industry for a start-up firm specialized in Ultra Wide Band, and the third case involved developing crisis management mobile solutions. In all three cases, we only describe the information-gathering sessions of the focus groups.

Collaborative approach to gathering user requirements

On the basis of studies concerning focus groups (Langford and McDonagh 2003, Bruseberg and McDonagh 2003, Morgan 1998) and the GSS meetings (Clawson et al. 1993, Nunamaker et al. 1991, Briggs et al. 2003). we have designed focus group sessions specific for mobile information services. In the case of mobile information services for new emerging technologies, participants are asked to imagine a yet unknown future. Since it is highly unlikely that they will be able to tell what they want in the future, the activities involved in the GSS sessions should help them project what they currently have and want onto various possible futures (Ireland and Johnson 1995, Johnson 1992). Another approach to supporting users to “rehearse” the future is to give them an example of how the future may unfold, which will give them a better idea of the objectives and possibilities involved (Maguire 2003, Schneider and Wintersm 1998), although there is also a risk that this may lead to unrealistic expectations. This led to the following approach.

Inviting participants

There are a number of guidelines when it comes to selecting participants. The participants of the focus groups need to have prior experience with regard to the context of the cases as well as be able to express their wants and needs within that context. They should be chosen through non-random sampling as opposed to the kind of random sampling that usually applies to surveys because they:

  • need to be reasonably knowledgeable about the topic under investigation and have an active interested in discussing it;

  • should feel comfortable interacting with each other, although over-familiarity may have an adverse effect on the results;

  • and, the group should not include too many different types of people.

The available facilities could easily accommodate 50 participants but we aimed to invite at least eight and at most 20 persons for one session.

Given these guidelines and given the fact that, in the case of mobile information services, users and their contexts are likely to be very diverse, it is to be expected that several sessions will be needed to gather the user requirements. We want to emphasize that the participants are not expected to play the role of designers, but are only asked to offer suggestions to the designers. In all three cases, we made sure that the people we invited to take part in the focus group sessions matched the criteria expressed in the above-mentioned guidelines.

Planning the focus group activities

A key element in the success of an electronic focus group session is to have a predefined schedule and structure. We designed sessions of about 3 h, since this is a suitable length for focus group sessions and because this mostly fits best in people’s calendar.

At the start of the sessions, the goals and ground-rules of the session are explained to the participants and they are introduced to the GSS facilities and to each other. The session then moves on to the actual subject at hand, in this case gathering user requirements. Combining the participants’ understanding of their everyday experiences with a demonstration of future scenarios results in the following activities:

  1. 1.

    Analyzing the problems involved based on current daily experiences: a context of use is given and the participants brainstorm on what they experience in such a context: what are their problems? Which information do they miss? What do they want? After diverging and gathering many ideas this was followed by converging rounds in which the x most important wants are chosen and reformulated. (How much x exactly is depends on the division of the votes over the ideas, mostly around five. The exact number of ideas for follow-up is decided by the facilitator).

  2. 2.

    Generating solutions based on the x most important problems/ideas: at this point the new technological options are not presented yet to the participants. They have to think themselves, with their knowledge on how they should solve the problems or realize the ideas.

  3. 3.

    Demonstrating future scenarios: experts join the session and present what they know about technological possibilities. This might be done by presenting new functionalities that will become available in an understandable way or by already integrating this in future scenarios.

  4. 4.

    Redefining the solutions: rather than asking the participants what their requirements are, their requirements will become clear in the course of redefining the solutions. The participants work in pairs on one of the problems identified in step 1. They know the solutions which participants identified in step 2 and they have the knowledge of new technological possibilities presented in step 3. In this offline step they draw and describe the mobile service on paper and slides as how they should like it. Next, they present this to each other. While they are presenting others can comment in GSS.

These four steps served as a basis for the focus group sessions.

Selecting techniques

For each activity designed to gather user requirements, specific techniques have to be selected. We used thinkLets which are modular components aimed at building a “script” to facilitate a group process. Each thinkLet addresses a specific subtask. In all, there are about 50 thinkLets and they are designed to guide a specific group through one of six activities: generate, reduce, clarify, organize, evaluate and build consensus. For more information on thinkLets, see Briggs et al. (2003). The decision which specific thinkLet to use is determined by the number and types of participants, and by the starting point and intended results. For our sessions, we decided to use the activities ‘generate’, ‘reduce’, ‘clarify’ and ‘evaluate’, and selected the thinkLets ‘FreeBrainstorm’, ‘FastFocus’, ‘BroomWagon’, ‘LeafHopper’, ‘OneUp’ and ‘Group Outliner’. We implemented the thinkLets with the GSS. In all three cases, the GSS we used was GroupSystems™.

Data collection

We collected data from both quantitative and qualitative sources: direct observation, questionnaires, and the electronically stored session data in the GSS. Given the exploratory nature of the study, we analyzed the data we collected in an iterative process, identifying recurring themes with regard to ways to gather user requirements early on in a mobile service design process.

Results

We applied the electronically supported focus group sessions to the three cases presented below.

Mobile services for campus visitors

The European mobile operator T-Mobile set up a UMTS test bed at Delft University of Technology (TU Delft) to carry out pilots for UMTS services. One of the pilots was a mobile information and entertainment service aimed at campus visitors. The design project started with three GSS sessions designed to identify the wants and needs of people visiting a campus they have never visited before (Fig. 1).

Fig. 1
figure 1

Design of the mobile services for campus visitors’ sessions

Full size image

The participants

It is possible to distinguish various groups of visitors to TU Delft, including foreign students and students from other universities, high school pupils, post-academic students, friends and relatives of students, researchers and practitioners from all over the world, business partners and suppliers. We decided to focus on three different user groups, which we expected to have different requirements: foreign academics (both students and researchers), Dutch academics and Dutch practitioners. We organized a separate session for each of these groups. We selected participants from our network of academics and practitioners who visited the campus and invited them to participate in the focus group meeting. People who were interested in discussing the topic accepted our invitation.

The activities and techniques used

To get the session under way, we asked the participants what irritated them about mobile phones (activity 0). Next, we asked them to think of any questions or problems they might have when visiting Delft, and invited them to select the problems they would be most interested in solving (activity 1). We focused on possible solutions to these questions and problems (activity 2) and demonstrated UMTS by showing video clips of possible UMTS services (activity 3). Finally, we asked the participants to redefine their solutions based on the features of UMTS that had been presented to them (activity 4). In the first session, we asked the participants to identify the best ideas and to explain why they felt the ideas they had selected would be an improvement on the existing situation. The explanations they provided should yield valuable information about the user requirements within a given context. However, after the first session we had to modify the fourth activity, because the participants found it hard to come up with better solutions, and even harder to indicate why they felt the solutions they suggested were indeed an improvement. A possible explanation for this state of affairs is that the participants were too tired to perform such a highly cognitive task. In the following session, we replaced this activity with a design-oriented activity. For each of the key issues that had been identified during the problem analysis (activity 1), a sub-team was formed. Each sub-team described a so-called ‘use case’. The sub-teams presented their various designs to the other sub-teams, who commented on them electronically.

Outcome of group sessions

The sessions indicated that, although the various visitor groups had a number of similar questions and demands, there were also some differences. In all three sessions, it became clear that information regarding location and route were considered important, as well as issues of a more social nature: who are the relevant people to contact, what are their interests, how can I get in touch with them, and where are they? The foreign academics expressed an additional concern with regard to the weather and with regard to information on medical and non-medical emergencies. The Dutch participants were also interested in social events: what can we do, and where can we have dinner. The Dutch practitioners were especially interested in information regarding the appointments that bring them to the university: where is it, at what time, etc.

The ideas mentioned by the users were input for the service concept and user interface designers. They developed a mobile service for conference visitors which comprised the wants and needs mentioned by the three groups. Some tradeoffs had to be made considering the technical possibilities. During the design process users were involved to test prototypes. The final prototype was used by 20 persons for various countries during a conference on simulation in Delft, the Netherlands.

Wireless applications for the process industry

The emerging Ultra Wide Band radio technology (UWB RT) was the reason we organized the second focus group. UWB belongs to the group of wireless networks that also includes radio technologies like IEEE 802 family Bluetooth (for an overview of the relevant technologies, see Porcino and Hirt 2003). Although regulation by the Federal Communications Commission in the USA (FCC) and the European Commission (EC) is still in the making, questions as to what will be the so-called “killer” application in this area have already presented themselves (e.g. Scholtz et al. 2005). A start-up firm specializing in UWB protocol stacks approached Delft University of Technology to organize a feasibility study for the process industry: in what kind of situations do potential customers in the process industry expect wireless networks to be advantageous and what criteria do they use when it comes to selecting a particular application.

The participants

The participants were people who work in instrumentation and automation departments within the process industry and their suppliers. The participants were selected and invited by the industry association based on: their knowledge and interest, the fact that they represent a wide range of companies from the industry and their suppliers, and their willingness to participate. The participants included plant managers and instrumentation or process automation specialists and they worked in the chemical and food industry, for instance at Shell, Dow Chemical, Dupont, Exxon, Heineken and Unilever. Participants from the process industry suppliers included equipment builders and project managers in the area of industrial plant construction from companies like Enraf, Controlec and Produca.

The activities and techniques used

To a large extent the session conformed to the structure discussed above. To get the session underway, we asked the participants to discuss possible disasters in their work environment (activity 0). We invited them to come up with ideas for wireless network opportunities in their environment, after which we asked them to prioritize the resulting 200 ideas (activities 1 and 2). Rather than asking them to define the problems first and then think of possible solution, as we had done in the UMTS session, we decided to combine the two activities. After formulating the 28 most important opportunities, we asked the participants to explain why these 28 opportunities were important for them (activities 1 and 2). We added this activity to collect additional input for the requirements analysis. We ended with the seven most important opportunities for wireless networks in general, followed by a presentation concerning the features of UWB, which included a number of examples (activity 3). Questions from the participants regarding the promising functionalities were answered by UWB experts from the industry and university. The participants then elaborated offline on the context, the idea behind the application and the effect it might have on the seven most important opportunities (activity 4). The solutions were presented while the other participants and the experts typed their comments and ideas into the GSS.

Outcome of group sessions

The seven most important opportunities that were worked out into solutions by the participants were related to the unique selling points of UWB. The two most popular applications were the automatic registration and localization of people and the installation of temporary measurements in pilot plants. This session provided information to the UWB experts to understand the wants of the users in the process industry regarding wireless solutions. The technology however was not developed enough yet to start pilots.

Crisis management mobile solutions

A team of researchers at Delft University of Technology developed new technologies to support people during crisis situations: future systems involve human actors and artificial agents working together to achieve their common goals under “chaotic” circumstances, when there is no predictable pattern or trend line, and it is impossible to anticipate events. The research program was developed around a crisis scenario in the International Port of Rotterdam. The crisis scenario involves the collision of two ships, causing poisonous gasses to spread over the Erasmus University area. An evacuation becomes necessary, causing acute crisis and traffic management problems. To identify the service requirements of the actors involved in handling the crisis, we designed GSS sessions.

The participants

We identified four target groups for the GSS sessions on crisis management: (1) decision-makers at the central level (e.g. national government agencies), (2) decision-makers at the crisis location, (3) relief workers (for instance police officers, first aid workers and firemen) and (4) the potential victims who find themselves in the danger zone. For each target group, we designed a session that included a presentation of the technologies that were relevant to the target group in question. In this article, we present the session involving the civilians. The participants in the session were students at Delft University of Technology, which meant that they were able to imagine finding themselves in the situation described in the scenario.

The activities and techniques we used

In this session, we basically used the sequence we had used in the first case, with some modifications, one of them being is that we began by presenting the scenario that had been developed by the crisis management researchers. To get the session underway, we asked the participants about possible disasters (activity 0), after which we presented the participants with the crisis scenario and asked the participants to imagine finding themselves at the Erasmus University in Rotterdam when it becomes clear that a disaster is taking place: the sound of sirens, strange gas smells and an atmosphere of panic (activity 1).

As part of this activity, we presented the participants with the context and gathered information based on their responses to the question: imagine being in the situation we have just described, what are your questions, what are your needs? The participants were asked to select and articulate the most pressing needs from the 60 that had been identified during the brainstorming session (activity 1). The participants narrowed them down to 24 clearly understood information needs, after which they took a vote to determine which information requirements were the most important. Next, the systems that had been developed by the crisis management researchers were presented to the participants (activity 3). The difference between this focus group session and the two other sessions was that, in this case, we did not ask the participants to generate solutions before they received the information from the experts (activity 2 in Figs. 2 and 3). The crisis management researchers presented the solutions that they had already developed, rather than presenting technology as source of various solutions. The participants designed in sub-groups a service to meet the information requirements that had been identified (activity 4). Each of the groups presented their designs, and during their presentations the other participants provided their comments via the GSS (Fig. 4).

Fig. 2
figure 2

Design of the wireless applications for the process industry session

Full size image
Fig. 3
figure 3

Design of the crisis management mobile solution session

Full size image
Fig. 4
figure 4

Crisis management scenarios

Full size image

Outcome of group sessions

The five most important information requirements the participants identified were: If I leave, where do I go? In what way(s) can I leave? Do I have time (and how much?) Will I require treatment? and What happened? The service designs presented by the participants were all aimed at receiving rather than providing information, which was the result of the fact that we had asked them to imagine themselves as disaster victims. Although this had not been planned, some of the crisis management researchers working in the next room joined the presentations and the discussion, allowing them to get direct feedback from potential users. They used this in the next steps of their project.

Discussion

We based our design method on focus groups theories and guidelines from GSS literature, in a process that included three stages: inviting participants, planning focus group activities and selecting techniques. In this section, we discuss the lessons we learned at each stage.

Inviting participants

We already mentioned that the participants should be familiar with the context being outlined to them. In cases like the ones we discuss in this article, that deal with technology-enabled services, the question is whether it would be better to involve representatives of the intended end-users or whether the participants should be more technology-oriented than the average mass market consumer. In our cases, the participants belonged to the latter group, and this worked out well. The question remains what this means for the potential consumers of the services.

Furthermore, the sizes of the groups varied between seven and 15 participants. The groups with more than ten participants functioned better, since the participants were asked to design services in pairs. In groups with less than ten participants the degree of variety was too small.

Planning focus group activities

We experimented with various ways to introduce unknown technologies to the participants of the focus groups. In the campus visitor case, we showed (consumer-oriented) video clips with futuristic mobile services, while in the two other cases new technologies were presented by experts. This proved an effective approach as far as the IT experts from the process industry were concerned, since they were acquainted with the technology in general. In the crisis management case, the technology was presented as a specific solution, which limited the room to explore new ideas. As far as we are concerned, technology should be presented as a set of functionalities that are not to be viewed as complete solutions. In the campus visitor and process industry cases, the participants designed the solutions themselves, based on the technology being provided, whereas the participants in the crisis management case merely offered suggestions to improve the solutions being presented to them. Because it proved difficult for the participants to further enhance the solutions provided by the experts, we would argue that user sessions should preferably be held early on in the design process, allowing the users to begin designing services based only on the technical functionalities being provided.

It was our experience that the length of session had an influence on the activities that were carried out. We found that it is not advisable to ask participants to engage in highly cognitive activities near the end of a focus group session. In the first campus visitor case session, we planned a so-called ‘one up’ activity, in which the participants had to try and improve the designs made by other participants. Because it turned out that this was too much to ask near the end of the session, we asked the participants in the following sessions to comment on each others’ presentations instead. Thus, due to the highly cognitive nature of the ‘redefining solutions’ activity, we decided to focus more on feedback to potential solutions instead. This indicates that we did not directly gather user requirements from the sessions in the way we had anticipated, but that the requirements had to be deduced by the researchers/designers of the mobile service on the basis of the session results. The information we had managed to gather in this, rather indirect, way turned out to be very useful to the designers of the potential services.

Selecting techniques

We used a combination of GSS and an offline activity. GSS was used to generate, reduce and clarify ideas at the beginning of a session, and to evaluate designs at the end. Meanwhile, the participants had to design solutions, and to that end, we used an offline usage-centred design method. We used participatory design to allow the participants to discuss, draw, present and provide/receive feedback. The combination of techniques we had selected worked out fine. The use of the GSS provided relatively rich information and analysing the results was easy and not too time consuming.

Conclusion and further research

In this article, we have presented a group-based approach that offers an efficient way to gather user requirements concerning future technological solutions. Involving end-users early on in the design process helped make the developers and researchers of mobile information services aware of the wants and needs of users in specific contexts of use. The approach contributes to bridging the gap between users and system developers: users got an understanding of the technological possibilities and system developers of the wishes of the users. This enables developers to develop better services.

Among the lessons that can be learned from this study is that it is best to include at least ten participants, to allow for greater variety, that the participants should have an interest in mobile technologies and should feel a high level of affinity with the context presented to them in the focus group meeting, that technologies should be presented as possible functionalities and not as possible solutions and that, at the end of a focus group session, participants should not be asked to engage in a highly cognitive selection process with regard to the various possible user requirements, but be allowed to work in pairs on the design of just one solution.

The findings presented are based on three cases that are different in nature, involved slightly different versions of the general approach, took place in different sectors of industry, and are based on qualitative interpretations of feedback and observations. In this sense, one should be cautious when trying to generalize the information beyond the context in which it was generated. Having said that, we feel that the number and variety of case situations allowed us to gain a rich understanding of the challenges involved, and ‘best’ or ‘worst’ practices with regard to responding to those challenges. It should also be noted that no design approach is static or final. Further field experiences will make it possible to refine and elaborate on the approach. We would argue that our approach is both sufficiently adaptive and flexible to be applied to very different problem situations and types of participants, and that it is structured enough to provide a systematic and repeatable process. This combination offers a useful contribution to existing practices.

The three cases we discussed all had very different settings: designing mobile information services for consumers, designing wireless applications for businesses, and designing services for crisis management situations. The GSS process proved effective in all three situations. We advise service developers to start the design process with a group-based user requirements elicitation process, in which the technological components are matched with the needs of the user. Also, we feel that this is only the first step when it comes to understanding relevant user requirements. The intermediate results of decisions in the next steps of the design process should be tested frequently with users, to provide feedback to the designers.