Keywords

1 Introduction

Agile User-Centered Design (AUCD) evolved from different motivations. On the one hand, Agile aims to satisfy customers through timely releases and responsiveness to change requests without compromising software quality. On the other hand, User-Centered Design (UCD) aims at ensuring appropriate usability of the implemented software, a characteristic that has not been sufficiently considered either in traditional plan-driven approaches nor in agile approaches. UCD addresses this issue but does not consider Agile principles [4]. There is an inherent tension between both schools of thought, and this tension is a core reason why researchers, seeing the value of both arguments, have been investigating how to integrate both approaches [9].

First concrete attempts to integrate Agile and UCD approaches were published about a decade ago. For instance, Sy [30], Fox et al. [12], Ferreira et al. [11], and da Silva et al. [8] came up with very similar proposals about the integration between these two approaches. However, such interaction on a daily basis is still a concern, and one of its main problems is how to facilitateFootnote 1 communication between the invariably distinct involved practitioners aiming to build a shared understanding regarding the project context.

This shared understanding among Software Engineering (SE) and Human-Computer Interaction (HCI) individuals is critical to the success of several agile projects, but little has been known about how communication works [5]. Furthermore, the reliance on communication within agile teams is a fundamental characteristic [29]. In AUCD, designers and developers must be prepared to communicate and collaborate.

As Brhel et al. [4], we advocate the idea of artifact-mediated communication in this scenario. Aiming to identify and understand the artifacts used to facilitate the communication between designers and developers in an AUCD approach we carried out a netnographic study in a globally-distributed online community of agile practitioners.

To contextualize our findings, we present a general view of the artifacts used in AUCD (Sect. 2). Then, we detail how the netnographic study was planned and conducted (Sect. 3), and then we present our main findings (Sect. 4 and discuss (Sect. 5). Finally, we draw upon our findings to elaborate our conclusions (Sect. 6) and future work (Sect. 7).

2 Artifacts in AUCD

Salah et al. [24] conducted a systematic review to identify restriction factors regarding Agile and UCD integration and explored practices to deal with them. One of their findings in this review was about the dynamics between developers and designers which addresses the ongoing and continuous communication between the teams. Regarding sharing and understanding design tasks, some practices have been used, such as design studio, developers participating in User Interface (UI) specifications and shared artifacts within the team.

Brhel et al. [4] identified five principles for the integration of Agile and UCD in their study. The fifth one is: “artifact-mediated communication – in AUCD approaches, artifacts should be used to communicate, and document product and design concepts, and should be accessible to all involved stakeholders.” For these authors, this principle consists of the use of tangible and up-to-date artifacts – accessible to all involved stakeholders – to document and communicate product and design concepts, which corroborates Schön et al. [26] that state that artifacts can also be used for communication, elaboration, validation, and documentation of requirements in agile environments.

Bearing in mind the importance of the artifacts for the Agile UCD integration, Garcia et al. [13] carried out a systematic mapping to identify which are the artifacts used and in which contexts they have been used to facilitate the communication in Agile User-Centered Design approaches. In this systematic mapping, the authors identified 20 different artifact groups that play a critical role as a communication facilitator. Prototypes and User Stories stand out as the most used artifacts. Besides, Personas, Sketches, Scenarios, and Wireframes also emerge as essential means for organizing communication and collaboration among AUCD team members.

This mapping study [13] also revealed five distinct events involving artifacts used as communication mediators – Discovery, Planning, Iterative Cycle, Review Meeting, and General Meetings. The Iterative Cycle was the event with the greatest sharing of artifacts, and, in this event, Prototypes, and User Stories once again were the most cited artifacts. Furthermore, artifacts are being used both in physical and electronic formats. Physical artifacts are commonly used throughout Planning and Discovery events; whereas the electronic ones are mostly used during the Iterative Cycle, often as a basis for development.

The importance of the role that artifacts play for AUCD is evident in the literature. However, while their importance is clear, there is no evidence concerning which artifacts are used for the communication between developers and designers, and how and in which ceremonies they are used.

Based on the studies analyzed – AUCD and Artifacts within this context – we can emphasize the importance of specific artifacts to improve teams’ communication. Therefore, to understand – from a practitioners’ perspective – how and when these artifacts have been used to promote communication within AUCD contexts, we carried out a netnographic study as described as follows.

3 Method

During the last two decades, online environments became rich and vital grounds for ethnographic studies [23]. In the same period, online communities have become one of the most popular forms of online services [21]. Online communities are essentially forums for meeting and communicating with others [2], or in a more detailed definition, online communities are web-based online services with features that make it possible the members to communicate with each other [21]. Along with online environments, the growth of online communities brought by Computer-Mediated Communications (CMC) established a solid research field for online ethnography studies [20].

Online ethnography adopts principles of ethnographic research molded in offline environments and applies them to online environments with necessary adjustments [23]. One of the online ethnography methods is netnography. Developed by Kozinets, netnography is a qualitative research method which adapts ethnography research processes to study cultures and communities that are emerging through CMC [17]. According to Kozinets [18], online ethnography is a generic term used when performing any type of ethnographic research using some sort of online method. Thus it is important to define netnography as a method by referring to a “specific set of related data collection, analysis, ethical and representational research practices” [18].

Thereby, we adopted the netnography method to identify and understand the artifacts used to facilitate communication between developers and designers. The netnography method performed in this study followed the steps of planning and entrée, community observation and data collection, data analysis, and reporting as per Kozinets guidance [18] on conducting netnography.

3.1 Planning and Entrée

This step involves the formulation of the research objective and questions, screening and identification of appropriate online communities. Furthermore, it is important to learn about the communities of interest and define the criteria to select the community that will be studied.

Definition of Research Questions. The goal of this netnographic study is to understand how artifacts are used to facilitate communication between designer and developer on AUCD approach according to practitioners, which participate in discussions on online communities. Therefore, we defined three research questions: (RQ1) Which artifacts are used to facilitate communication between designer and developer? (RQ2) In what events are these artifacts being used? and (RQ3) What’s the role the artifacts play?

Identification of Online Communities. In order to discover appropriate online communities, we took into account the research goal, which led us to search for communities containing the terms “Agile”, “User-Centered Design” or “Agile User-Centered Design”. Ideally, the community should focus on AUCD, but since this is an approach that can be taken by Agile and UCD, all the three terms were included. Moreover, it is important to mention that in the industry the term User-Centered Design is widely known as User Experience Design, hence we also included this wording to search for communities of interest.

We performed this search using as base Facebook and LinkedIn groups as well as Slack communities. These revealed 36 communities that seemed relevant to the study. Communities containing the research topic but related to job offers, focused in a specific region or country and created for a particular company were not included.

Criteria Definition to Select the Community. The selection criteria were composed of seven factors including relevance, activity, interactivity, substantiality, heterogeneity, richness, and experientiality [18]. The relevance is the first and most important factor. For a community to be considered relevant it should have relation to the research focus and questions. The community needs to be active containing recent and regular communications. Interactivity factor is related to the flow of communication between members. Substantial factor regards to the mass of communicators and energetic feel. The heterogeneity factor concerns about either a variety of difference or a consistency of similar type of participants. The community should be rich in data offering more detailed or descriptive data. Finally, there is the experiential factor which is related to the experience that the community offers to the members.

Community Selection. Based on the selection criteria, and considering the relevance as the most important factor we selected the Scrum Practitioners LinkedIn Group. The decision to cherry-pick this community was based first on the relevance factor, once the community’s topic was aligned with the research focus. In addition, the main purpose of this community is to help and spread the knowledge and implementation of agile for practitioners actively practicing the agile product development. Secondly, this community had the most activity containing the average of 2 posts (main threads) and 33 messages per day, the most interactive with the average of 18 comments per post, and therefore contained the most data. Moreover, the community was considered substantial containing 98431 members.

3.2 Community Observation and Data Collection

The second step of the netnographic research involves community observation and data collection [18]. Once we chose the community we could start collecting the data. However, foremost it is imperative to ensure ethical procedures for any online ethnographic study.

Ethical Procedures. Prior to the observation and data collection, ensuring ethical research must be an important part of the netnographic research planning. Therefore, to address the ethical issues we followed the procedures defined by Kozinets [18]: identifying the researcher profile and informing members about the research; asking for proper permissions; gaining consent when needed. Thus, we updated our user profiles containing the role as Researcher, additionally, we used the affiliation to openly, and accurately identify ourselves to the community and administrators.

Scrum Practitioners is a closed LinkedIn group with well-defined rules and two administrators. A group administrator is a legitimate gatekeeper who the researcher should approach prior to contacting other group members or collecting any data [18]. In LinkedIn Groups, gatekeepers assume the roles of Owner, Manager or Moderator and they are deemed a ‘data controller’ as stated by LinkedIn Groups Terms of Service [19].

Because of LinkedIn Groups terms, and considering the administrator as a gatekeeper, we properly asked the group’s manager for permissions aimed at data analysis and interaction with the group. Besides, group members were informed about the research with an accurate description of the research focus and interest. No direct quotations were used in the report or publications to ensure the user’s anonymity; once direct quotes are increasingly easy to identify through search engines. Also, all data were treated using pseudonyms for the group members.

Data Collection Strategy. Netnographic data can assume three forms [18]: archival data, which is already recorded and stored; communicatively co-created or elicited data; and, participative-authored field note data. Additionally, data collection has two elements, which are the data the researcher straight copy from online communities’ platforms and the data the researcher writes in from their observations of the community.

Loanzon et al. [20] described that data collection in netnography usually is textual. As per observation, Scrum Practitioners group is mainly focused on textual communication, and their interactions happen through a post, that is usually a question from some agile professional, and the comments on this post from other members trying to collaborate with an answer. Based on LinkedIn Groups post structure, we collected textual data from posts and comments focused on the research questions. Thereby, the collected data derivate from historical posts (archival data), researcher interactions (elicited data), and researcher sketches as field notes (participative-authored data).

We collected archival data bearing in mind the research questions. Thus only posts related to the study topic were downloaded. LinkedIn groups keep all historical posts available, but only posts from March 2015 were gathered to have the most recent discussions. Furthermore, LinkedIn groups provide a search engine inside the community, which supported the archival data exploration. We performed the data collection from August 2017 to January 2018.

Posters Categorization. Posters are community members who interact with the group. According to Kozinets [17] they can be sorted in four categories: Tourists, Minglers, Devotees, and Insiders. To match the reality of this study, the description of each category was adapted to be aligned with the study’s subject; thus instead of use “consumption activity” wording to define the member engagement, as originally stated by Kozinets, it was adapted to “group topic”. Thus, all four categories are detailed next.

Tourists, who lack strong social ties, maintain a superficial interest in the group topic. They have shallow participation in the community, and potentially their participation in the group will not last very long. Tourists are in the community to get information [20]. Minglers, are members who have strong social ties but least interest in the group topic. They have high visibility but limited influence. Devotees are members who maintain a strong interest in group topic but few attachments to the online group. They do not participate actively in all posts, but only in some specific threads that they are interested. Insiders are the leaders of the community, they are both passionate about the group’s topic and sensitive to the social welfare of the community. In other words, they have strong social ties and a high group’s topic interest. They are well respected by other community members and have frequent and highly visible participation in almost all posts. Therefore, we categorized the members according to these four categories for all collected comments. Besides, we collected information related to the members’ industry, job position, region, and skills to help contextualize their comments.

3.3 Data Analysis and Interpretation

Data collection and data analysis is a simultaneous process in qualitative researches [7]. Thus, this netnographic research step occurs concomitantly with community observation and data collection [17]. This step involves organizing, reading, coding, categorizing, and interpreting the data.

Data Analysis. We followed the data analysis approach from Creswell [7] through the six defined stages. The first stage commences with data organization and preparation for the analysis. The second stage regards to read and look at all data, in order to have a general sense of information and reflect on its overall meaning on the information collected from participants. Stage 3 addresses the data coding, which is the process of arranging the data by grouping and writing a word representing a category. Stage 4 concerns to generate a description of the setting or people, and also create categories or themes for analysis. Themes or categories can also use the approach of coding, and they are described as the major findings in a qualitative study. In stage 5, it is the moment to define how description and themes will be pictured. Stage 6 is the final step in data analysis, which involves an interpretation of the findings or results. Hence, we took advantage of these six stages approach to analyze the data. Also, we used the qualitative data analysis software QSR International’s NVivo 11 [22] to perform the data analysis.

Data Organization. Whereas we used the software NVivo to analyze and code all the collected data, it is essential to describe how we organized it. First of all, we imported collected posts into the tool as internal sources and organized them as archival data or elicited data as previously mentioned. Each post was defined as a major case, and each member’s comment was considered as an inner case, which was helpful for the coding process. Codes are treated as nodes on NVivo; consequently, we organized and created all codes under the nodes structure. Finally, we classified all inner cases containing the posters information and details according to the posters categorization.

Data Coding. Data coding is the process of organizing the data by grouping related data and labeling these categories with a term [7]. Since we have benefited from the results of Garcia et al. [13] we defined a preliminary codebook based on the theory which evolved during data analysis, ending up with 31 codes. From all codes, “Events” and “Artifacts” had sub-nodes that were used to break down the analysis per event and artifact. Furthermore, data coding was performed manually on text-based data since the collected data was textual.

4 Findings

The final set of collected data comprises six main posts, with a total of 134 comments, including archival and elicited data (Table 1). Most of the posts were from 2017, with no related posts between March 2015 and March 2017. Altogether 63 distinct members, from 18 different countries, participated in the posts discussions. The majority of the members who interacted in the collected posts were categorized as Devotees and Insiders due to the level of engagement in Scrum Practitioners LinkedIn group. From the 63 members, 49 were categorized as Devotees, 11 Insiders, and 3 Tourists. Summing up, 95,3% of the members who participated in the collected posts were Insiders and Devotees. According to Kozinets [17], preliminary research reveals that enthusiastic, devoted, energetically involved, and experienced user segments are represented by Insiders and Devotees in online communities.

Table 1. Collected data

Our first analytical lens was focused on answering the question (RQ1) Which artifacts are used to facilitate communication between designer and developer? Our findings reveal that seven distinct artifacts were mentioned by Scrum Practitioners community members as facilitators in communication between designer and developer. Moreover, the results from Garcia et al. [13] demonstrate that 20 artifacts accomplish this purpose. Therefore, to concentrate on the most used artifacts, we highlighted the intersection between this systematic mapping study and the findings herein presented (Fig. 1). The list of artifacts that were mentioned as communication facilitators includes user story, wireframe, prototype, mockup, sketch, and persona.

Fig. 1.
figure 1

Intersection between the Systematic Mapping and the Online Ethnography

All these artifacts may be used in different events of AUCD approach, which led us to answer the second question (RQ2) In what events are these artifacts being used? Our findings demonstrate that artifacts facilitate the communication throughout the AUCD events, starting with discovery sessions and going to the agile events including planning, iterative cycle, review, and backlog refinement.

For each event, the artifacts can be used for distinct purposes. The outcomes for question (RQ3) What’s the role the artifacts play? disclosed that during discovery session artifacts as wireframes and prototypes are used to communicate and validate an idea, while personas delineate the user profile and create a shared understanding, as noted by some practitioners. User stories and wireframes were the most cited artifacts on Scrum Practitioners community, consolidating 50% of all artifacts references.

Users story helps to clarify what should be implemented. As TrentonFootnote 2 has noted, a well-written user story facilitates the communication, when the designer describes the interactions in the acceptance criteria, and the developers can estimate the effort necessary to implement the story (Trenton, posted on Scrum Practitioners, March 15, 2017). These user story roles are also mentioned by Beyer et al. [3]. They state that user stories are shared with the development team and they can use them to estimate how much effort they require for the next iteration. User stories also facilitate discussions to define if a determined feature will deliver or not value for the product. This discussion also involves the breakdown of large user stories into thin vertical slices, which involves all architectural layers from the user interface to the backend code.

Wireframes support the description of a user story. They are used to support the acceptance criteria and communicate illustratively how a user interface should be structured. Since they illustrate high-level concepts and behaviors [15], wireframes complement user stories description and are necessary to define when a story is ready for development (Ambrose, posted on Scrum Practitioners, December 17, 2017). An overview of all artifacts correlated with the events where they were mentioned and their roles are represented in Table 2.

Table 2. Overview of artifacts, events, and roles

5 Discussion

The qualitative data analysis and interpretation resulted in two major themes related to our research questions: (1) Artifacts Facilitate Communication and (2) Artifacts Support Collaboration. Nevertheless, before start addressing them, it is essential to discuss team structure. In all collected posts, there were discussions regarding where the designer should work, if as part of the Scrum Team or as part of a “Design Team”. This discussion was generated because Scrum Guide [28] states that the Scrum Team consists of a Product Owner, the Development Team, and the Scrum Master, and has no citation to design discipline or designer role. However, the Scrum Guide also explains that Development Teams are cross-functional, containing all the necessary specialized skills to create a product increment. Thus, the community understanding is that the team must be cross-functional and the designer should be part of the team. Furthermore, considering the approach of AUCD, which has design discipline involved, the team must have a person with great skills in design as part of the team. Donnie has commented about having the designer as part of the team, stating that the designer sits with the team when he/she is not interacting with the end-users (Donnie, posted on Scrum Practitioners, March 24, 2017). Donnie’s comment was also supported by other members. Several citations of word “together” referring to the team, were encountered in the analyzed data, as displayed in the word tree (Fig. 2). Moreover, other synonyms were used to state that the designer should be part of the team, such as “along”, “alongside”, “part of”, “sitting with”, “whole”, “integrate”, “embedded”, “jointly”, and “work with”.

Fig. 2.
figure 2

Word tree generated from word “together”

5.1 Artifacts Facilitate Communication

Agile Manifesto asserts in the first sentence: “Individuals and interactions over processes and tools” [27]. Thus, interactions among professionals in the AUCD approach are essential to conduct the product to the right course and deliver value. A common form of interaction is communication. Designers and developers communicate in different agile events using different artifacts as facilitators. The communication occurs throughout the entire AUCD flow, starting from discovery session, passing through all agile events including planning, iterative cycle, review, and backlog refinement.

As Mathew has noted, during discovery sessions the team, including developers, testers and designers, meet to create low fidelity prototypes to verify the User Interface and interactions feasibility in terms of technical support (Mathew, posted on Scrum Practitioners, December 20, 2017). Thus, the team uses low fidelity prototypes to communicate how the User Interface should be created considering user experience and technical perspectives.

Wireframes and personas were also mentioned as communication facilitators through discovery sessions. Personas are used to delineate the user profile and create a shared understanding between the designer and the developer regarding the product focus. On the other hand, designers use wireframes to validate an idea with users and then employ these same wireframes to validate whether the development team can build it considering how much effort it takes in terms of feasibility and finances. Herman has mentioned that developers can understand what the requirements are, estimated how much effort it will take, and define how they will build them (Herman, posted on Scrum Practitioners, December 19, 2017). Furthermore, Ambrose has commented that these resultant artifacts from discovery sessions are used as foundation to write user stories and/or refine the acceptance criteria of existing user stories that will feed the product backlog, ensuring that the highest priority backlog items are ready to be designed and built (Ambrose, posted on Scrum Practitioners, December 17, 2017). Therefore, wireframes are used as a mean of communication to explain what are the user needs resulting from discovery sessions, as well as to validate and estimate how the requirements should be built.

Likewise, prototypes, as well as user stories, are relevant during planning events where they are used to define what will integrate an iteration. During the estimation process, designers use these artifacts to provide more details to developers for a more accurate estimation [10]. In general, at this event artifacts use to be more flexible and lightweight to facilitate face-to-face communication. Therefore, in the planning, the artifacts are intended for clarifying and sharing the work for the iterative cycle that is starting.

During the iterative cycle, the preliminary prototypes created throughout discovery sessions are used as a reference for designers to generate mockups. All along the iterative cycle, mockups are used to communicate how the user interface should look like, supported by the prototype and user story, which together define the user interface behavior (Frederick, posted on Scrum Practitioners, March 18, 2017). Thus, mockups are important to communicate the user interface details such as colors, typography, and spacing, while prototypes and user stories provide the user interaction definitions. Personas were also mentioned as a communication facilitator during the iterative cycle. This artifact helps both designer and developer to focus and discuss the core product functionalities. Personas are used as means to confirm that the team is going to the right direction to implement the user stories, thus delivering value to the product (Sophia, posted on Scrum Practitioners, December 15, 2017).

By the end of each iteration, there is the sprint review event. During this meeting, while the developers demonstrate the work that has been done, designers can show what is the result of parallel design track. Frederick has posted that wireframes, mockups, and prototypes are shown as result of designer’s work in the sprint review, even knowing that these artifacts cannot be deployed as part of the product increment (Frederick, posted on Scrum Practitioners, March 18, 2017). Thus, during sprint review designers can communicate what are the resultant artifacts, and use them to provide an overview of what will be possibly included in the next sprint.

Finally, before the succeeding sprint planning, it is time for product backlog refinement – also known as backlog grooming by practitioners. For the time of refinement, sketches are used to describe the backlog item quickly. They are used to add brief details to a user story, and the designer can easily communicate with the developers about what is expected from the user story even before to have a wireframe or a prototype. (Tylar, posted on Scrum Practitioners, October 20, 2017). Therefore, sketches facilitate quick communication during refinement and help other team members to have a shared understanding.

5.2 Artifacts Support Collaboration

The collaboration between designers and developers should be supported by facilitating communication of design vision [25]. As mentioned by the authors, sharing an understanding of the design vision can be achieved via design thinking [6], engaging the whole team in design practices and UI specifications, and sharing design artifacts. Design thinking discipline creates an atmosphere of collaboration where the entire team, including designers and developers, can create low fidelity prototypes together to match users needs and technical feasibility (Benjamin, posted on Scrum Practitioners, December 18, 2017). Consequently, the collaborative environment is extremely tied to the community understanding related to the team working as a whole. Figure 3, shows some excerpts considering the code collaboration, which corroborate the idea of close collaboration.

Fig. 3.
figure 3

Word tree generated from code “collaboration”

Moreover, InVision [16] and Confluence [1] were mentioned as collaborative tools. InVision provides a collaborative view where developers and designers can interact over shared mockups and prototypes, posting comments and defining the user interface (Marianna, posted on Scrum Practitioners, October 22, 2017). Confluence provides a template where wireframes can be attached, and it also contains a section to add comments and discussions about the artifact (Marlina, posted on Scrum Practitioners, October 21, 2017).

Another collaborative approach mentioned by the community was Lean UX. Lean UX stands on three foundations: design thinking, agile software development, and Lean startup method [14]. Since this approach stands on these three foundations, it also considers the team is working as a single unit, creating a collaborative environment. The author states that the artifacts such as stick notes, sketches, wireframes, and paper prototypes, created during kickoff and ideation sessions – also named discovery stage – are meaningful to the team since they created these artifacts together. Thus, Lean UX also defends the idea of using artifacts to support collaboration and creates a shared understanding necessary to create the team synergy.

6 Conclusion

Agile and UCD methods aim to design and produce quality software from different perspectives. Agile User-Centered Design approach attempts to close the gaps between these areas by bringing the most effective techniques, methods, and artifacts of each of them. Nonetheless, not only different aspects affect this integration, but also the communication between different professional profiles, such as designers and developers, have a high influence on it.

The study herein presented focused on the artifacts used to facilitate the communication between designers and developers in an Agile User-Centered Design approach. Through an online ethnography study applying a netnography method, it was possible to identify and understand the artifacts that facilitate communication, which event they are used, and what is the role they play to facilitate communication. The findings pointed out two major themes: (1) Artifacts Facilitate Communication and (2) Artifacts Support Collaboration. The themes interpretation and delineation show the usage of artifacts to facilitates teams’ communication.

The outcomes of this study contribute to further studies regarding Agile User-Centered Design approach, integrating both Software Engineering and Human-Computer Interaction areas. Also, they highlighted how the artifact-facilitated communication ensues in the industry through a perspective of practitioners that participate in online communities.

Overall, contextual factors such as skill sets, experiences, and personalities of people involved impact on artifact-facilitated communication. Moreover, the choice of artifacts may vary over time, both as context change and as the team members learn what is effective for them. Additionally, team configuration and distributed teams influence on how the team’s interactions and collaboration occurs, likewise including artifact-facilitated communication.

7 Future Work

A future study might extend the work presented in this paper. It became clear during the netnography analysis that communication factors impact the distributed teams, and artifacts that are used face-to-face cannot be applied to this team configuration. A member from the analyzed community even commented that distributed teams should be avoided whenever possible, due the complexity to manage communication between people (Vicent, posted on Scrum Practitioners, March 1, 2015). Other members also commented that even the teams are distributed, it is important to get together for events such as planning and retrospectives, to work in the same space for some time, and to build a rapport among the team members.

Another point mentioned by several members is that planning meetings should involve the entire team, if possible in the same physical place if it is not possible video conferences can be used to have all team members understanding the work and sharing it. Thus, considering the distributed teams scenario, how are the distributed teams impacted by artifact-facilitated communication? Which are the applied artifacts when teams are distributed geographically?

Furthermore, it is possible to research the impact of different artifacts combination and interrelation; for instance, the sequence they are created and how they support the creation of new artifacts. Another perspective that can be studied is communication not only between developers and designers but also extended to reach the strategic levels of decision-making.