# Facilitating User Involvement in a Large IT Project: A Comparison of Facilitators’ Perspectives on Process, Role and Personal Practice

Øivind Klungseth Zahlsen, Dag Svanaes, Yngve Dahl

## ► To cite this version:

Øivind Klungseth Zahlsen, Dag Svanaes, Yngve Dahl. Facilitating User Involvement in a Large IT Project: A Comparison of Facilitators’ Perspectives on Process, Role and Personal Practice. 18th IFIP Conference on Human-Computer Interaction (INTERACT), Aug 2021, Bari, Italy. pp.219-238, 10.1007/978-3-030-85616-8_14. hal-04196867

HAL Id: hal-04196867

https://inria.hal.science/hal-04196867v1

Submitted on 5 Sep 2023

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
<figure><img src="image_2.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Facilitating User Involvement in a Large IT Project:
A Comparison of Facilitators’ Perspectives on
Process, Role and Personal Practice

Øivind Klungseth Zahlsen¹, Dag Svanæs¹,² and Yngve Dahl¹

¹ Department of Computer Science, Norwegian University of Science and Technology,
Trondheim, Norway

² Digital Design Department, The IT University of Copenhagen, Denmark
{oivind.k.zahlsen; dag.svanes; yngveda}@ntnu.no

**Abstract.** Studies indicate that the way structured participatory design activities are facilitated significantly effects participation, power relations, and generated output. Although facilitation is always adapted to the conditions of each design project, the way facilitation is enacted primarily depends on the individual facilitator. It is assumed that enactment on an individual level is influenced by how the facilitator conceptualizes both user involvement and their own role. To address these issues, semi-structured interviews were conducted with three facilitators in the same development unit of a large-scale health IT project. The primary focuses were the individual facilitator’s perspectives on the *design process*, their *role*, and their *practice* in the project. An in-depth qualitative content analysis of the transcribed interviews showed that the three facilitators held highly divergent perspectives on the facilitation of participatory design activities. Similarities were found between the facilitators’ perspectives and how user involvement is understood in different system development traditions. Based on the findings, a reflective approach towards facilitation is proposed along with examples of possible co-reflection activities among facilitators.

**Keywords:** Facilitation, Participatory Design, User involvement, Co-reflection, Large-scale IT systems.

## 1 Introduction

User involvement is widely recognized as best-practice in the development of usable IT systems and is a fundamental principle in user-centered and participatory design (UCD and PD). In interaction design literature *user involvement* and *user participation* refer to activities in which users are actively involved in informing the design of products, systems, or services [1, 2]. Some of these activities, such as focus groups and co-design workshops, are structured activities that are typically managed or *facilitated* by a designer or other project associate. The person responsible for facilitating participa-
tory design activities is commonly referred to as *facilitator*. Creating the right condi-
tions for constructive user engagement in design-related questions is a central part of
facilitation, as illustrated in [3-7].

Despite the facilitator’s central role in structured participatory design activities, there
are relatively few design-related studies that have focused explicitly on the facilitator
as a *practitioner* or facilitation as *practice*. Rejecting the idea of the PD practitioner as
neutral or instrumental in the application of PD methods, Light and Akama [8] argued,
“*We cannot know participative methods without the person or people enacting them*”.
In their opinion, a facilitator’s enactment of participatory methods has strong implica-
tions both for the nature of participation and the output of participatory activities and
processes. This could be studied empirically through detailed analysis of how facilita-
tion is practiced (e.g., [8, 9]). However, to provide a better understanding of the con-
ceptual ideas that may motivate practice, this study focuses on how facilitators of par-
ticipatory activities in a large-scale IT project understand their own role. The implicit
assumption is that attitude towards user participation and the understanding of one’s
role as a facilitator has a strong impact on how facilitation occurs.

Thus, putting the facilitator center stage raises an interesting question that is highly relevant for PD discourse: *How do facilitators of participatory design activities regard (i) the design process, (ii) the facilitator role, and (iii) their personal facilitation practice?*

To answer this question, a qualitative interview study of three facilitators working
in a large health IT project in which the involvement of healthcare professionals (i.e.,
user representatives of the produced IT solution) is intended to take place across all
project phases was conducted. This paper provides an in-depth analysis of the verbal
accounts offered by the interview respondents with a special focus on their perspectives
on the design process, the role of a facilitator, and their personal facilitation practices.
Drawing on the analysis, this study argues that the facilitation of participatory design
activities may be dependent on facilitators’ individual perspectives on these three as-
pects. The key findings from this study are then used as a basis for recommending the
adoption of co-reflective activities among facilitators to help foster conscious aware-
ness regarding facilitation thinking and practice.

## 2 Background: Facilitation of Participatory Design Activities

Few design-related studies focus on the role of the facilitator. The studies described in
this section cover what we consider the most relevant work in this regard.

One of the first investigations into the role of the facilitator in the context of partic-
ipatory activities was conducted by Luck [10], who studied the relationship between
facilitator expertise and opportunities for user engagement in an architectural project.
Analyzing the spoken interaction between the facilitator and participants, the study
found that more experienced facilitators tended to create richer opportunities for user
engagement and that the development of such behaviors need to be honed through prac-
tice.

Light and Akama [8] investigated relations between context, facilitation, and out-
comes in designing with communities in disaster mitigation. In particular, the study
compared how facilitation took place in two different situations to engage with relevant concerns. The study brought attention to the ways in which facilitation style, scoping, structure, and control can affect participation as well as how facilitation practice needs to be considered in terms of the context in which it takes place. Seeing the facilitator's engagement with participants to involve an embodied knowing, the authors argued for a reorientation in PD towards participatory practice as opposed to participatory methods alone, i.e., a direction where the PD method and facilitator are no longer seen as detached.

Inspired in part by Donald Schön's [11] reflection-on-action theory, Dahl and Svanæs [9] brought attention to the often subtle and unforeseen ways in which facilitator actions (and non-actions) in participatory activities can influence the ways in which values become embedded in design solutions. They suggest that continuous introspective analyses and reflections may improve the facilitator's attentiveness to actions that may inadvertently impede participants who are disfavored vis-à-vis other partakers due to factors such as status, language, or eloquence.

There are also examples of studies that highlight the empathic qualities that facilitation of participatory activities may necessitate to understand users' perspectives in certain design contexts. Lindsay et al.'s [5] design work with people with dementia is a good example of how development of empathic relations with the user group led to strategic changes in the facilitator's interactions with participants in workshops.

All of the above studies acknowledge the strong impact of the individual facilitator on the ways that participatory activities are enacted. In terms of research methods, they all conducted detailed studies and analysis of facilitation practice. All studies were done in small or midsize projects, consequently not addressing the added challenges of user participation in large-scale projects [12-14].

To our knowledge, an in-depth investigation of the “mindsets” of facilitators of participatory activities has not been conducted before. This has motivated us to perform a qualitative study to unpack the views and perspectives that may lie behind the facilitation of participatory design activities. Our study thus complements the existing practice-oriented studies. The study is motivated by the assumption that enactment on an individual level is significantly influenced by how the facilitator conceptualizes both user involvement and their own role.

# 3 The Case

This interview study was conducted between January and March 2020 in the early phase of an ongoing electronic health record (EHR) system implementation project in which the respondents acted as facilitators of participatory activities related to a specific system module. A brief overview of the key characteristics of the project and their participatory activities is presented below.

## 3.1 The Project

The aim of the project is to implement a common EHR system for all primary and secondary healthcare services in Central Norway. The estimated cost of the project is
EUR 270 million. The (current) post-contract part of the project is scheduled to last approximately four years and consists of seven distinct sequential phases. The following stakeholder organizations are part of the project:

* *Client organizations:* The client organizations consist of the regional public health authority, the municipality of the region's administrative center, and primary care physician offices. Healthcare workers employed in the client organizations will be the users of the new EHR system.

* *Client project organization:* The client project organization is a joint-stock company owned by the client organizations. In addition to its permanent staff, the company has recruited more than 400 workers (domain experts) from the client organizations. These experts also act as user representatives. The company is mainly interested in implementing an EHR and a patient administrative system for the client organizations.

* *Developer organization:* The EHR vendor is headquartered in the US and relocated 30 employees to Norway for the duration of the project. The vendor owns a configurable EHR system that can be customized according to the healthcare institution at which it is installed. The vendor's main interest is to deliver on the contractual commitments and securing a regional foothold in the national healthcare system.

While the project has a strong focus on the involvement of user representatives (primarily domain experts) in all its phases, the project does not focus on user empowerment as understood in the PD tradition [15, 16]. This is a procurement-through-tender project, meaning that the signed contract works as the overall requirement for the project and also regulates the legal relationships between the stakeholder organizations, the budget, and the overall time constraints. As stated by Bratteteig and Wagner [17], "A PD project is embedded in a context that offers both constraints and opportunities for what and how to design." Implicit in the statement is a conceptualization of participation as a relative term, meaning that for a given project, participation may range from weak (or non-existent) to strong and that the level of participation may vary throughout the project. The current project is considered to be participatory mainly due to its ambition to give a large number of domain experts (user representatives) a say in the configuration of the new EHR system.

## 3.2 The Facilitated Participatory Activities

The project follows an implementation approach characterized by scheduled participatory activities (meetings) where invited project participants gather to decide on specific aspects related to the configuration of the EHR system. The participatory activities we studied as part of our investigation took place in the Specification phase (4 months), which followed the initial Preparatory phase. The activities typically include vendor representatives (e.g., activity facilitators and developers, with the latter only present via video conference from a different time zone), healthcare professionals with backgrounds relevant to the activity topic (domain experts), and client organization representatives responsible for tailoring the system. Most domain experts confer with their peers in their home organization between the participatory activities.
# 4 Methods

## 4.1 Interviews

Data for this study was collected via semi-structured narrative interviews with three facilitators working in the EHR implementation project described above. Each interview lasted between 30 and 60 minutes. An interview guide was developed that addressed the three topics relevant to the research question: design process, facilitator role, and facilitator practice.

All three interview respondents had responsibilities involving the facilitation of multi-stakeholder project meetings that aimed to inform the design of a specific EHR system module. Two of the respondents were US citizens employed in the developer organization who had moved to Norway to work at the project site for the duration of the project. The last respondent was a Norwegian employee in the client project organization. None of the respondents had received formal education in the facilitation of participatory design activities prior to the project. Two of the respondents were male, and one female. Their formal backgrounds were quite diverse, including international politics, computer science (human-computer interaction) and biology. Their work experience includes project management, software development in general and in relation to the health domain. To maintain respondent anonymity, we have not given specific background information for each respondent. For similar reasons, references to the gender of the respondents have been removed and replaced with gender-neutral terms (e.g., “he/she”) throughout the paper.

## 4.2 Complementary Field Observations

To improve general understanding of the project and the project meetings prior to the interviews, and thereby provide a frame of reference for interpreting the respondents’ feedback, complementary field observations were conducted at the project site. This involved both fly-on-the-wall observations of project meetings (typically 5–12 participants in size) and by being present at the project site in order to interact with project employees outside of meetings. Given the complementary role of the field observations, they have not been subject to systematic analysis. Getting access to the facilitators’ perspectives on their own role, the design process and their practice required us to involve the facilitators in in-depth interviews as these are aspects that cannot be understood from simply observing facilitators in action.

## 4.3 Data Collection and Data Analysis

The interviews were video recorded, transcribed verbatim, and analyzed. The analysis of the transcribed interviews consisted of three steps; a deductive coding of the transcriptions, identification of those transcript excerpts considered most relevant to the research question, and a qualitative content analysis of the coded units in the transcript excerpts.

During the initial coding process the transcriptions were examined for meaningful units of text, or *phrases*, pertaining to the three main topics of relevance to the research
question (process, role, and practice). Relevant phrases were then marked with one or more matching keywords or *codes* ("Process", "Role", and "Practice"). The coded phrases were then checked for consistency to ensure that the codes had been applied in a coherent manner.

After identifying the most relevant transcript excerpts with regards to the research question, a qualitative content analysis of the coded phrases contained within an excerpt was performed with a focus on the *inferred meaning* of the utterances. In contrast to semantic analysis, which is concerned only with the literal meaning of syntactic structures and their interrelations independent of context, latent (deep structure) qualitative content analysis addresses what is being communicated non-literally, i.e., the implicit meaning of utterances [18]. *Context* plays an important role in such an analysis as it provides a conceptual lens that can help infer meaning; context lends subtext to the meaning. The interpretations of the analysis were reviewed several times by the authors, both individually and in plenary, to ensure a common understanding.

# 5 Results

This section presents the results of the qualitative content analysis described above. For each interview respondent, three selected transcript excerpts and the interpretations thereof (with codes) are presented in a tabular format. Each excerpt is divided into *phrases*, i.e., meaningful units of text (left column), with corresponding interpretations (right column). Square brackets with associated codes (e.g., *role, process*) appear in the interpretations to show how different phrases were coded. As with all semi-structured interviews, the exact order of questions posed to the respondents varied, but the list of topics covered was the same. The initial interview question associated with each excerpt is described in the top row of the relevant table.

## 5.1 Facilitator 1

Tables 1–3 present the selected transcript excerpts from the interview with F1 and the interpretations thereof.

<table><caption>**Table 1.** Excerpt 1 with interpretations.</caption><thead><tr><th>Phrase</th><th>Initial question: What is a good facilitator?</th><th>Interpretation</th></tr></thead><tbody><tr><td>I think a good facilitator, especially in these settings, will drive the meeting forward.</td><td></td><td>[role, process] From the perspective of F1, ensuring progression in meetings, possibly relative to predefined goals or items on a meeting agenda, is a central responsibility of a facilitator.</td></tr></tbody></table>
So, I think it's very... [pause]... it's a balance between moving the meeting forward [and] trying to make people speak up.

So, I think what I was trying to do [in the meeting] yesterday ... when the [domain experts] were silent—[I was] trying to get them to say the things that I know they said to me earlier.

[role, process] F1 also considers it part of the facilitator's responsibility to actively involve participants in discussions by encouraging them to express their views on relevant matters. However, F1 sees a potential trade-off between active involvement and progression in meetings.

[practice] F1 explains how he/she attempted to prevent inactivity during a meeting by asking participants a direct question.

The interpretations provided in Table 1 regarding F1's views on the design process, the facilitator role, and personal facilitation practice can be summed up as follows:

* Process: The design process should actively involve participants in design-related questions; participants should be given the opportunity to present their perspectives to one another.

* Role: The facilitator of a participatory activity should ensure both that participants are given an opportunity to voice their opinions and that progression is being made.

* Practice: Asking users direct questions is one way to give participants an opportunity to present their views to others.

<table><caption>**Table 2.** Excerpt 2 with interpretations.</caption><thead><tr><th>Phrase</th><th>Interpretation</th></tr></thead><tbody><tr><td>So, the meetings you [the interviewer] have been in particularly have been trying to get our developers and the [domain experts] here on the same page—and I'm kind of a bridge between them.</td><td><b>[process]</b> From F1's perspective, the meetings are aimed at creating a shared understanding between the US-based developers and the local domain experts.<br><b>[role]</b> F1 sees himself/herself as an intermediary that helps the developers and domain experts understand one another.</td></tr><tr><td>So, the developers have been talking to the [domain experts] for years in terms of making the plans, but I'm here living and breathing with the [domain experts] and so I have more of a pulse on what their emotions are.</td><td><b>[practice]</b> Through consistent in-person interaction with the domain experts as opposed to sporadic online discussions, F1 has developed a more intimate, and possibly empathic, relationship with the domain experts than the US-based developers. Through the development of such relations, F1 has gained an acute awareness of the needs of the domain experts and their feelings regarding design suggestions.</td></tr></tbody></table>

The interpretations of F1's perspectives in Table 2 illustrate the following:
* *Process:* The participatory process should help form a shared understanding between the participants.

* *Role:* The facilitator is a mediator (“bridge”) between participants that helps establish a shared understanding.

* *Practice:* In order to effectively act as a mediator, it is necessary to develop empathic relations with user representatives. Developing such relations requires close interaction over time.

<table><caption>**Table 3.** Excerpt 3 with interpretations.</caption><thead><tr><th>Initial question: What would you say is your role in the meetings I have been in?</th><th>Interpretation</th></tr></thead><tbody><tr><td>And after the meeting time is when some importance, like emotions and feelings or understandings, are achieved.</td><td><b>[process]</b> The statement suggests that F1 considers non-verbal empathic aspects of communication to play an important role in aligning perspectives. The statement also implicitly suggests that F1 feels that the formal project meetings are an insufficient arena for establishing common ground.</td></tr><tr><td>And that's the kind of thing that our developers, who are only ever on the phone, are never gonna get to be a part of until they come here to visit.</td><td><b>[process]</b> In terms of the intimacy characterizing the informal after-meetings, F1 believes that US-based developers, who are physically remote and only participate in meetings via video, are deprived of the ways in which alignment of understandings and establishment of common ground are achieved. The physical distance between the domain experts and the developers impedes qualitative aspects of interactions.</td></tr><tr><td>I am in those little after-meetings and I did hear how they were saying, and I saw that look of panic on their face. I can message our developer and be like: "Not good (laugh), not good".</td><td><b>[practice]</b> Elaborating on how he/she is able to act as a "bridge" between domain experts and developers, F1 explains that working closely with the domain experts attuned him/her towards their subtle non-verbal aspects of communication such as tone of voice and facial expressions.</td></tr></tbody></table>

A summary of the key elements of the interpretations in Table 3 follows:

* *Process:* The structure or form of participatory activities affects how the participants interact and, consequently, the extent to which they are able to establish shared understandings.

* *Practice:* Being attentive to non-verbal aspects of participants' communication (both within and beyond scheduled project activities) and conveying responses from user representatives to the development team in a sincere manner are important for a facilitator.

Synthesizing F1's perspectives on the design process, the facilitator role, and personal facilitation practice (Tables 1–3) leads to the following key characteristics:

* *Process:* The design process is an intimate group process that should help establish a shared understanding among participants.
* *Role:* The facilitator is a mediator, assisting participants in establishing a shared understanding. The facilitator should also ensure progress is made.

* *Practice:* To successfully fulfill the role, one needs to take steps to actively involve the participants in discussions, remain attentive to subtle aspects of their communication and responses (non-verbal and emotive aspects), and build empathic relations with user representatives over time.

## 5.2 Facilitator 2

Transcript excerpts from the interview with F2 and associated interpretations of these are presented in Tables 4–6.

<table><caption>**Table 4.** Excerpt 4 with interpretations.</caption><thead><tr><th>Initial question: <i>Can you tell me about group dynamics and how people are involved?</i></th><th>Interpretation</th></tr></thead><tbody><tr><td><strong>Phrase</strong><br>There are 10 000 people at [the development organization], so, there might be somebody that actually knows more about something than the person you are talking to... and the culture [in the development organization] is that you pull that person in to make sure we have the best information possible.</td><td><strong>[process]</strong> F2 considers his/her colleagues in the development organization to be knowledge resources (i.e., that knowledge is contained within an individual) and that some individuals have more knowledge about a given topic than others. The typical way for a facilitator to optimize a meeting in the development organization is, according to F2, to ensure that the right persons, i.e., the optimal knowledge resources relative to the agenda of the meeting, are present. The knowledge of these resources can then be conveyed as information to other participants.</td></tr><tr><td>The same thing will happen here at [the client project organization]. Sometimes we say: "We don't have the right person". We make sure we talk to this person, so we pull them in.</td><td><strong>[practice]</strong> F2 suggests that he/she will continue to follow a strategy similar to the one employed in the development organization when organizing meetings in the project, i.e., trying to ensure the optimal knowledge resources are present in meetings.</td></tr><tr><td>I think more about: "Do we have the right people discussing this? [...] what makes anything successful for the design of this project, is that you don't want any surprises at go-live.</td><td><strong>[process]</strong> F2 relates the constellation of knowledge resources in project meetings to the success (or failure) of the final design solution and the overall project.</td></tr></tbody></table>

The summary of the interpretations in Table 4 illustrate the following in terms of F2's perspectives on process and practice:

* *Process:* For design processes to result in a successful design, the optimal constellation of knowledge resources (user representatives and developers) relative to topics being discussed at any time needs to be present.

* *Practice:* The facilitator should work towards optimizing the constellation of knowledge resources present in specific participatory activities.
<table><caption>**Table 5.** Excerpt 5 with interpretations.</caption><thead><tr><th>Initial question: What is your role in the meetings that I observed?</th><th>Interpretation</th></tr></thead><tbody><tr><td><strong>Phrase</strong><br>Pretty much my role is to make sure we are prepared in those meetings because we sit in those meetings. But it's actually a lot of work to get done even before that meeting. For instance, I'll speak to [peer in the project organization], because [we]—[him/her] from [the project organization] and me from [the developer organization], technically—like, own the success of this. I will talk about what I mean by success in a bit, but we want to make sure: “Do we have the right agenda; do we have the right people?”<br><br>Because what we never want to do is start a meeting and say: “What shall we talk about?” That usually doesn't get us like very far when we are trying to meet a deadline, because at the end of the day we are just trying get certain deadlines met. So that's what [peer in the project organization] and I am thinking about: “We have this deadline coming up. How do we get this deadline met?” And that's by making sure that this meeting we talk about this. In this meeting, we have the answers to this. In this meeting, we get information.</td><td><strong>[role]</strong> As a facilitator, F2 puts particular emphasis on the preparation of meetings because he/she considers it both a personal responsibility and the responsibility of his/her Norwegian peer to make the meetings successful.<br><br><strong>[practice]</strong> Together with his/her peer, F2 puts efforts into the preparations, particularly when it comes to optimizing the constellation of knowledge resources vis-a-vis the agenda of a meeting.<br><br><strong>[process]</strong> F2 considers thoroughly prepared meeting agendas to be important for a meeting to be productive and effectively inform design decisions. Productive meetings are considered a means to ensure that project deliverables are completed before scheduled deadlines. In order to reach project deadlines, project meetings need to provide answers to specific questions on the agenda that are relevant to the developers.</td></tr></tbody></table>

The key takeaways from Table 5 are summarized below:

* *Process:* The participatory process should effectively help produce the highest quality answers to questions on the meeting agenda that drive the design process forward so that project deadlines can be met. Participatory activities are “information collection points” that should help developers determine how to proceed.

* *Role:* The facilitator is a preparer, one that “sets the stage” for participatory activities.

* *Practice:* Preparing participatory activities by ensuring that the optimal knowledge resources on matters relevant to the agenda are present is an important part of facilitation.
<table><caption>**Table 6.** Excerpt 6 with interpretations.</caption><thead><tr><th colspan="2">Initial question: So, you are in a way steering what is going to be the product?</th></tr><tr><th>Phrase</th><th>Interpretation</th></tr></thead><tbody><tr><td>The way I see it, I'm making sure that the right people are talking to each other in the correct way. So, I may be managing it with [peer in client project organization] but at the end of the day, I'm not the one who is going to use the system. I'm not even the one who is going to build it. It's most important that the developers know what they are developing and agree that it makes sense. It's important that the operational people that we meet with—that we have involved, who are great—that it is going to work for them.</td><td><b>[role, process]</b> F2 sees himself/herself as less affected by the results of the design process than the developers and the domain experts because he/she only manages the preparations for the meetings.<br/><b>[process]</b> The developers understanding and agreeing to what they are designing and ensuring that the solution will fulfill the needs of the domain experts when it is employed in their daily work life is essential for the design process.</td></tr><tr><td>So, what we often have a hard time with, I think, as humans in general, is [that] we all come from different backgrounds and are starting to speak the same language, especially with something as complex as software, medical software.</td><td><b>[process]</b> F2 regards the establishment of shared understandings between participants in the design process to be a key challenge, particularly in the context of developing medical software.</td></tr><tr><td>And so my job is to make sure people are ready for that meeting and to keep them on the path where I think progress is.</td><td><b>[role]</b> F2 considers it is his/her responsibility to both prepare participants before the meetings and to ensure that the meetings evolve in ways he/she considers productive.</td></tr></tbody></table>

The key takeaway points from the interpretations of F2's responses (Tables 4–6) are as follows:

* *Process:* The design process is an information collection process in which the quality of collected information depends on the participating resources, i.e., the knowledge of those taking part.

* *Role:* The facilitator is a preparer (organizer) of activities related to the participatory process.

* *Practice:* Being a preparer involves taking steps to optimize the constellation of knowledge resources per activity, thereby maximizing the quality of the information transferred from domain experts to developers.

## 5.3 Facilitator 3

Transcript excerpts from the interviews with F3 and the corresponding interpretations are presented in Tables 7–9.
<table><caption>**Table 7.** Excerpt 7 with interpretations.</caption><thead><tr><th>Initial question: <i>Can you tell me about your facilitation and the methods you apply?</i></th><th>Interpretation</th></tr></thead><tbody><tr><td><strong>Phrase</strong><br>[A competent facilitator has] the ability to abstract—not everybody is equally good at it.<br><br>What I'm trying to say is that, as an enterprise architect [in the project], I know a little about everything but I'm not particularly good at anything. And that is perhaps the strength of having such a role; that you are not too deep into the details but have an overview, which in turn enables me to ask "silly questions" in quotation marks: "Is it really like that? Does it have to be that way or could we have done it differently?"— these kinds of open questions.</td><td><strong>[role]</strong> F3 considers the ability to think in abstract terms to be essential to the role of the facilitator.<br><br><strong>[role]</strong> F3 feels that his/her skills as a facilitator are related to another role of his/hers within the project, that of enterprise architect.<br><br><strong>[practice, role]</strong> The enterprise architect role has provided F3 with an overview of the project. This overview helps F3 take a more engaging role as facilitator by enabling him/her to ask questions in meetings that encourage discussions and reflection among participants, for example, concerning alternative solutions to design-related questions. This also implicitly suggests that F3 considers encouraging discussions among participants to be central to the facilitator role.</td></tr></tbody></table>

The key elements of the interpretation of F3's perspectives are provided in Table 7.

* **Role:** Abstract thinking and maintaining an overview of the project are central to the facilitator role. The latter can especially help in terms of creating opportunities for engagement and discussion, another key factor.

* **Practice:** Asking questions that promote discussions among participants helps facilitators fulfill their role.

<table><caption>**Table 8.** Excerpt 8 with interpretations.</caption><thead><tr><th>Initial question: <i>What is your role in the meetings that I observed?</i></th><th>Interpretation</th></tr></thead><tbody><tr><td><strong>Phrase</strong><br>What I experienced in those meetings was that they [the participants] didn't understand one another. No! And I felt that we were not talking about the same thing. We have a different understanding of what the need is and different understandings of what the solution we will receive is going to be like.</td><td><strong>[process]</strong>: F3 describes how participants have "talked past" each other in a series of meetings without fully realizing it, resulting in a state of confusion. F3 considers this confusion to be an obstacle to a constructive design process. According to F3, a shared understanding between participants should comprise both user needs and ideas about the future solution.</td></tr></tbody></table>
So that was when I talked to the process owner —I cannot remember who that was—and then I said: “We cannot continue on this course because then we will fail to hit the nail on the head”.

[role, practice]: F3 feels that it is his/her responsibility to report the lack of a shared understanding between the participants to the project associate responsible for the module.

[process] F3 feels that the lack of a shared understanding could potentially compromise the end result.

Key aspects of the interpretations provided in Table 8 are below.

* *Process:* Establishing a shared understanding between participants with respect to both user needs and the final product is essential for a constructive design process.

* *Role:* A facilitator needs to be mindful about challenges related to communication and understanding between participants.

* *Practice:* Reporting challenges related to a lack of a shared understanding between participants can potentially prevent the problem from escalating.

<table><caption>**Table 9.** Excerpt 9 with interpretations.</caption><thead><tr><th>Initial question: What is your role in the meetings that I observed?</th><th>Interpretation</th></tr></thead><tbody><tr><td>So, my role there is to find roughly the right level of abstraction, describe the tasks using a form of language that makes it possible for others to understand, and to try to see things from different perspectives, and, yes, that's my job. I will not take control, but I will help them think in more general terms.</td><td>[role] From F3's perspective, helping participants understand each other and see design issues from various perspectives are central facilitator responsibilities. Rather than seeing the facilitator as someone who leads a group, F3 considers his/her role to primarily involve encouraging holistic thinking among participants.</td></tr><tr><td>And what's good about making a type of artifact—making something together? First, a joint ownership is established, because those who have been involved feel an ownership: "I have been involved in making this; I recognize myself in this." And then it becomes far easier to discuss.</td><td>[Process, Practice] F3 highlights the value he/she sees in co-designed artifacts that emerge from participatory design activities. F3 considers such artifacts important in terms of establishing a shared ownership of the solution among participants, thereby increasing the likelihood of active engagement.</td></tr></tbody></table>
When you're in a meeting where there are many interests you often end up with what I call "hobby-horse racing". Each actor is concerned with his own thing, riding his hobby-horse, and is unable to move forward in the discussion before having spoken out about things they are deeply passionate about: "Now you are at the start, now we're here. But, but, what you're concerned about now won't become relevant until towards the end".

**[Process]**: F3 considers individualistic thinking among meeting participants, i.e., only thinking in terms of how the solution might be beneficial (or harmful) from the individual domain expert's perspective (and the specific users he or she represents) to be counterproductive to the design process.

**[Role, Practice]**: To ensure constructive meetings and avoid impeding the design process, F3 believes that it is important for the facilitator to manage discussions in such a way that issues that are important to specific user representatives are brought up at appropriate times.

The interpretations of F3's perspectives (Table 9) can be summarized as follows.

* *Process*: The design process should promote strong commitment among all participants and should lead to a design solution that benefits all user groups. The design process should therefore help participants see beyond their individual needs and work towards a common good.

* *Role*: The facilitator should help establish a shared understanding between participants and encourage holistic (as opposed to individualistic) thinking among participants. The facilitator needs to manage discussions in order to promote holistic thinking and constructive participatory activities.

* *Practice*: The use of artifacts that have been co-designed by participants is one way to help establish common ground. Careful sequencing of the topics to be discussed is an example of how participatory activities can be managed to encourage holistic thinking in the design process.

Synthesizing the interpretations of Facilitator 3's responses concerning process, role, and practice (Tables 7–9) results in the following characteristics:

* *Process*: The design process is a managed collaborative process with the aim of designing for a common good.

* *Role*: The facilitator is a debate moderator that should encourage holistic (as opposed to individualistic) thinking among participants.

* *Practice*: Taking steps to encourage discussions and reflections by frequently asking critical questions but also sequencing topics to be discussed to avoid individualistic thinking are important aspects of the role.

# 6 Comparing the Facilitators' Perspectives

Having presented the analysis of the three facilitators' perspectives on the design process, the facilitator role, and personal facilitation practice, attention now turns to how the different viewpoints compare and contrast with one another. The synthesis of each
facilitator's perspectives on the three aspects will be used as a basis for the discussion. A systematic overview of the syntheses is presented in Table 10 for clarity.

<table><caption>**Table 10.** Comparison of the facilitators' perspectives on process, role, and personal practice.</caption><thead><tr><th></th><th>Facilitator 1</th><th>Facilitator 2</th><th>Facilitator 3</th></tr></thead><tbody><tr><th>Process</th><td>The design process is an intimate group process that should help establish a shared understanding among participants.</td><td>The design process is an information collection process in which the quality of the collected information is closely linked to the knowledge resources involved.</td><td>The design process is a managed collaborative process with the aim of designing for a common good.</td></tr><tr><th>Role</th><td>The facilitator is primarily a mediator that assists participants in establishing a shared understanding.</td><td>The facilitator is mainly a preparer (organizer) of activities related to the participatory process.</td><td>The facilitator is a debate moderator that should encourage holistic thinking among participants.</td></tr><tr><th>Practice</th><td>Being a mediator between participants requires the development of empathic relationships with user representatives, actively involving them in participatory activities, and remaining attentive to subtle aspects of their communication and responses.</td><td>Being a preparer involves taking steps to optimize the constellation of knowledge resources per activity, thereby maximizing the quality of the information transfer from domain experts to developers.</td><td>Being a debate moderator means encouraging discussions and reflections through critical questions. It also involves sequencing topics to be discussed to avoid individualistic thinking.</td></tr></tbody></table>

The intention here is not to rebuke or praise any of the facilitators' perspectives. Instead, the goal is emphasizing the conceptual differences and similarities within the various viewpoints. The conceptual difference will later be used as a foundation for discussing the key implications of these findings (Sect. 7).

## 6.1 Process

The analysis showed that facilitators conceptualized the design process differently. F1 regarded the process as an *intimate group process*, F2 described the process more as an *information collection process*, and F3 felt that the process was a *managed collaborative process*.

In comparing the three views, the most significant difference seemed to be between F1 and F3 on the one side and F2 on the other. Both F1 and F3 highlighted the forming of a shared understanding between participants to be a key component of the participatory process and regarded their active involvement in design-related questions to be central. These conceptualizations of the design process are in many ways aligned with
the emancipatory and collective notions of PD in which knowledge and understanding
is created through interaction between stakeholders [16].

F2, by contrast, describes the design process in terms of information. The individual activities in the process are *information collection points* where information relevant to further development is passed on from domain experts to developers. F2 sees knowledge primarily as residing *within* a person, as opposed to the more interactional perspective on knowledge creation expressed by F1 and F3. According to F2’s assessment, the knowledge a person possesses can then be conveyed to others as information. This person-as-information perspective is particularly reflected in the way that F2 regards the ideal participatory design process as being dependent on having the optimal constellation of knowledge resources present. Such a constellation is seen to provide the qualified answers that developers need to continue developing the system and ensure that project deadlines are met.

One of the most significant differences in the perspectives of F1 and F3 in terms of
the design process is related to how they conceptualize facilitator-participant interac-
tion. While F1 highlights emotive aspects and the quality of participant interaction as
central to a successful process, F3 puts more emphasis on the collaborative aspects and
working towards a common goal.

While this study does not intend to label the three interviewed facilitators, the dif-
ferent conceptualizations of the design process outlined above reflect three distinct sys-
tem development traditions to some degree. For example, F1's strong focus on devel-
oping empathic relations with participants is in line with principles of Empathic Design
[19, 20]. F2's participants-as-information perspective reflects to some degree the posi-
tivistic notions of the requirements engineering phase as understood in Software Engi-
neering [21]. Lastly, F3's holistic design thinking and goal to promote reflections in
participants are similar to PD philosophy [16].

6.2 Role

The facilitators’ views on the facilitator role also varied; their views on the role re-
flected their perspectives on the design process. F1, who regarded the design process
to be an intimate group process, felt that her role was to act as a *bridge* or a *mediator*
between different stakeholders taking part in meetings. F1 sees it as her responsibility
to be able to interpret and convey user representatives’ “true” responses to members of
the developer organization and not simply to let emotions unfold.

F2, who emphasized that a successful design process is dependent on having the
right knowledge resources (people) present in specific meetings, considers it a key fa-
cilitator responsibility to identify and recruit those knowledge resources. As such, F2
regarded the role of the facilitator to involve being a *preparer* or *organizer* of meetings.

Similarly to F1, F3 associated the facilitator role with actively helping participants communicate and understand each other. However, in contrast with F1, F3 highlights the need for a facilitator to help participants work towards a common goal, meaning that the facilitator needs to manage discussions, particularly when it comes to the question of which topics are appropriate to discuss when.

One key difference in the respondents’ perspectives regarding the facilitator role
concerns the participatory activity and the extent to which this requires management as
it plays out. While F1 and F3 sees the facilitator role as active and attentive, F2 appears
to view the facilitator as more passive. For F2, facilitation is mainly associated with
preparation of participatory activities.

6.3 Practice

Similar to the close relationship found between each respondent's perspectives on the design process and the facilitator role, there is also a strong link in the role-practice relationship. For example, F1 and F3, who consider playing an active part in meetings to be part of a facilitator's responsibility, describe how they pose questions in a meeting with the goal of involving participants. F3's use of artifacts to help participants create common ground and mindful sequencing of topics for debate are other examples of an active facilitation style. F1 also describes how he/she invests time with domain experts beyond scheduled project meetings and the ways in which this helps her become better attuned to their responses.

F2 appears to be less concerned with taking an active part in meetings; his/her facil-
itation efforts primarily go into planning and organizing the meetings, i.e., recruiting
the “right” people in regard to the meeting agenda.

7 Implications: Towards a Co-Reflective Facilitation Practice

The respondents held distinctive perspectives and attitudes towards the design process, the facilitator role, and facilitation practice. As discussed earlier, some of the expressed viewpoints reflect notions of different system development traditions, such as Empathic Design, Software Engineering (requirements engineering phase), and PD. This illustrates how perspectives on user participation, even within related project activities and within the same development unit, may be based on conceptually different ideas. There is currently no empirical data to indicate the actual effects of this multi-paradigmatic thinking among co-facilitators on the outcome of the project. However, the distinct philosophies embedded in the aforementioned development traditions give reason to hypothesize that the implications on actual facilitation practice and generated output related participatory activities could be significant.

Having raised awareness towards the heterogenous perspectives that may exist be-
tween facilitators of participatory project activities, what are the main implications?
With respect to IT projects, especially large-scale projects that are likely to involve
several facilitators, we particularly recommend the adoption of a *reflective* approach
towards facilitation—i.e., an approach that allows facilitators to exchange and compare
perspectives on facilitation and discuss their experiences at regular intervals throughout
the design process. Similar recommendations regarding reflective practices already ex-
ist in agile software development. Fowler and Highsmith [22] suggested in their 12th
agile principle: *At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly. [...] we all recognize that we can't
come up with the right process for every situation. So any agile team must refine and
reflect as it goes along, constantly improving its practices in its local circumstances.*
Various forms of co-reflection have also been employed as quality improvement strategies in teacher education [23] and nursing professional development [24]; the use of video-assisted reflective inquiries is an example of such a strategy. To our knowledge, however, regular co-reflection activities on facilitation practice is far from standard.

The development of local communities of facilitation practice can help enhance facilitation skills in project stakeholder organizations. Rather than striving towards a uniform facilitation “mindset” and one way of practice, discussion and reflection should be goals in their own right. Highlighting the heterogenous circumstances under which facilitated participatory activities may occur, Light and Akama [8] warned against a “one-style-fits-all” approach, stating that there may be multiple meaningful rationales behind adopted facilitation practices. As such, it can be argued that having a conscious awareness towards one’s facilitation thinking and practice is more important than adopting shared mindsets and practices among co-facilitators.

Inspired by best practice in agile software development [22], teacher education [23] and nursing professional development [24], the following list offers some suggestions to support reflection on the design process, the facilitator role, and facilitation practice to provide a concrete idea of how co-reflection among facilitators of participatory activities may be realized.

*   *Design process:* Discussions among co-facilitators, particularly in the planning phase or early stages of a project, concerning the motivation and goals of user involvement can be fruitful. Such discussion can help reveal different priorities and motivations among co-facilitators. Concretizing the different perspectives on user involvement embedded in various system development traditions, in form of a table that allows for comparison of key characteristics of the traditions, is one way that discussions related to the design process may be supported.

*   *Role:* Practitioners could be offered the chance to present their personal views on the facilitator role to encourage reflection. This could be achieved by, for example, allowing practitioners to first write down keywords or short phrases representing aspects they consider central to the role on post-it notes. Each facilitator could present and elaborate on the keywords they wrote down. The post-it notes from all participating practitioners could later be grouped according to thematical similarity and then used as a foundation for a discussion.

*   *Practice:* The use of video footage from other facilitation practices as a basis for comparison and discussion is one way to foster practice-related reflections. Another alternative could be to employ role play, possibly in combination with video recording, where facilitation may be acted out in participatory design activities. Participants could switch between playing facilitators (i.e., their actual project role) and the users involved in the activities. These suggestions could also open up discussions concerning the consequences of practice, i.e., how different practices affect the output of the participatory activities.

An empirical investigation of the potential value of co-reflective activities, such as those proposed above, is beyond the scope of the current study. In order to become a standard practice in IT projects characterized by user involvement, the activities need to be planned in advance. In other words, resources (time and budget) need to be specifically allocated to such activities in the planning of the project.
# 8 Methodological Considerations

It seems appropriate to briefly highlight some methodological aspects that may have affected the presented analysis and findings before concluding.

First, while we found that the interview respondents conceptualized facilitation differently, it should be emphasized that we by no means consider our study exhaustive in terms of identifying facilitator “mindsets” nor has it been our objective to chart such a territory. Instead, the three distinct conceptualizations identified in this study should be considered no more than instances in a potentially multifaceted world of understandings. Considered from a natural science viewpoint, an in-depth qualitative study, such as the current one, can always be criticized for lack of generalizability. Maximizing generalizability, however, was never our intention. Rather, our emphasis has been on unpacking the unique personal experiences of the interviewed facilitators. With only three respondents, we cannot generalize to the whole population of facilitators concerning “mindsets”, but as the three respondents showed very different perspectives, it is reasonable to conclude that the study indicates a high level of heterogeneity.

Second, we do not know the extent to which perspectives expressed by the facilitators who took part in the study affect the nature of their facilitation practice. We have relied exclusively on their verbal accounts. The distinctive ways that the respondents conceptualize facilitation, nevertheless, could suggest a similarly distinctive practice.

Third, the presented content analysis makes claims about phenomena based on interpretation of statements from the respondents. Such an analysis can easily raise validity issues due to the risk of potential misinterpretations. Measures taken to reduce this risk included complementary field observation aimed at improving our basis for valid interpretation as well as multiple individual and plenary reviews of the interpretations conducted by the authors.

# 9 Summary and Concluding Remarks

The current study investigated the ways in which facilitators of participatory activities in a large-scale health IT project understand the design process, the facilitator role, and their personal facilitation practice. The conceptual ideas embedded in the respondents’ narratives were unpacked based on an in-depth qualitative content analysis of interview transcripts. It was discovered that many of the ideas pertained to different system development traditions such as Empathic Design, Software Engineering (requirements engineering phase), and PD.

While we consider our findings to be indicative rather than conclusive, they bring attention to a potential lack of systematic reflection among practitioners in terms of what it means to be a facilitator and what facilitation of participatory activities implies. We therefore proposed a co-reflective approach towards facilitation in individual projects and gave examples of possible co-reflection activities for facilitators.

This study hopes to contribute to the recognition of design facilitation as a practice and key methodological challenge for PD.
## Acknowledgements

This study was conducted as part of the KonPas and PlatVel projects. Our special thanks go to the interview respondents for sharing their time, commitment, and viewpoints.

## References

1. ISO 9241-210: Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems. International Organization for Standardization (2019)

2. Bjerknes, G., Bratteteig, T.: User participation and democracy: a discussion of Scandinavian research on systems development. Scand. J. Inf. Syst. 7, 73–98 (1995)

3. Dahl, Y., Linander, H., Hanssen, G.K.: Co-designing interactive tabletop solutions for active patient involvement in audiological consultations. Proceedings of the 8th Nordic Conference on Human-Computer Interaction: Fun, Fast, Foundational, pp. 207–216. Association for Computing Machinery, Helsinki, Finland (2014)

4. Svanæs, D., Seland, G.: Putting the users center stage: role playing and low-fi prototyping enable end users to design mobile systems. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pp. 479–486. ACM, Vienna, Austria (2004)

5. Lindsay, S., Brittain, K., Jackson, D., Ladha, C., Ladha, K., Olivier, P.: Empathy, participatory design and people with dementia. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pp. 521–530 (2012)

6. Sahib, N.G., Stockman, T., Tombros, A., Metatla, O.: Participatory Design with Blind Users: A Scenario-Based Approach. 14th International Conference on Human-Computer Interaction (INTERACT), pp. 685-701. Springer Berlin Heidelberg, Cape Town, South Africa (2013)

7. Cumbo, B.J., Eriksson, E., Iversen, O.S.: The "Least-Adult" Role in Participatory Design with Children. Proceedings of the 31st Australian Conference on Human-Computer-Interaction, pp. 73–84. Association for Computing Machinery, Fremantle, WA, Australia (2019)

8. Light, A., Akama, Y.: The human touch: participatory practice and the role of facilitation in designing with communities. Proceedings of the 12th Participatory Design Conference: Research Papers-Volume 1, pp. 61-70 (2012)

9. Dahl, Y., Svanæs, D.: Facilitating Democracy: Concerns from Participatory Design with Asymmetric Stakeholder Relations in Health Care. Proceedings of the 2020 CHI Conference on Human Factors in Computing Systems, pp. 1–13. Association for Computing Machinery (2020)

10. Luck, R.: Learning to talk to users in participatory design situations. Design studies 28, 217-242 (2007)

11. Schön, D.A.: The reflective practitioner: How professionals think in action. Basic books (1984)

12. Dalsgaard, P., Eriksson, E.: Large-scale participation: a case study of a participatory approach to developing a new public library. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pp. 399–408. Association for Computing Machinery (2013)
13. Pilemalm, S., Timpka, T.: Third generation participatory design in health informatics—making user participation applicable to large-scale information system projects. Journal of biomedical informatics 41, 327-339 (2008)

14. Simonsen, J., Hertzum, M.: Participative design and the challenges of large-scale systems: extending the iterative PD approach. Proceedings of the Tenth Anniversary Conference on Participatory Design 2008, pp. 1–10. Indiana University, Bloomington, Indiana (2008)

15. Bødker, S., Kyng, M.: Participatory design that matters—Facing the big issues. ACM Transactions on Computer-Human Interaction (TOCHI) 25, 1-31 (2018)

16. Robertson, T., Simonsen, J.: Participatory Design: an introduction. In: Robertson, T., Simonsen, J. (eds.) Routledge International Handbook of Participatory Design. Routledge (2013)

17. Bratteteig, T., Wagner, I.: Unpacking the notion of participation in participatory design. Computer Supported Cooperative Work (CSCW) 25, 425-475 (2016)

18. Bengtsson, M.: How to plan and perform a qualitative study using content analysis. NursingPlus Open 2, 8-14 (2016)

19. Wright, P., McCarthy, J.: Empathy and experience in HCI. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pp. 637–646. Association for Computing Machinery, Florence, Italy (2008)

20. Postma, C., Zwartkruis-Pelgrim, E., Daemen, E., Du, J.: Challenges of Doing Empathic Design: Experiences from Industry (2012)

21. Hinds, C.: The case against a positivist philosophy of requirements engineering. Requirements Engineering 13, 315-328 (2008)

22. Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R.: Manifesto for agile software development. (2001)

23. Tripp, T.R., Rich, P.J.: The influence of video analysis on the process of teacher change. Teaching and Teacher Education 28, 728-739 (2012)

24. Forbes, H., Oprescu, F.I., Downer, T., Phillips, N.M., McTier, L., Lord, B., Barr, N., Alla, K., Bright, P., Dayton, J., Simbag, V., Visser, I.: Use of videos to support teaching and learning of clinical skills in nursing education: A review. Nurse Educ. Today 42, 53-56 (2016)