Service Design Handover to user experience design – a systematic literature review

Context: Knowledge transfer plays an important role in digital Service Creation Projects where information should flow through service design, Agile UX, and software implementation phases. One context for these handovers exists in projects where the service designers participate in the early phases of exploring and scoping the service, while agile user experience specialists take over the digital parts of service design and programmers the software implementation. Objective: The purpose of this study is to summarise scientific knowledge into best practices for effective information flow in real world Service Creation Projects. Special attention is paid on an important and understudied project phase, knowledge handover from service design to software implementation, which is referred as Service Design Handover in this study. Method: A systematic literature review was conducted to analyse the current scientific knowledge on knowledge transfer in digital Service Creation Projects. PRISMA 2020 statement was used for reporting the review, which also influenced planning and execution of the systematic review process. SCOPUS search brought up 773 publications, and the full content analysis was done for the 41 most relevant publications. Results: Based on the literature analysis, the best practices for effective knowledge transfer are related to communication quality and quantity, circumventing the need for communication, and verifying successful communication. To provide an overview of effective knowledge transfer, frameworks of Service Creation Project information flow and Service Design Handover are proposed. Conclusion: The existing knowledge transfer literature is voluminous, but this literature review is the first to study knowledge transfer in Service Creation Project context. The framework, best practices, and list of potential problem sources in knowledge transfer provide new knowledge for managing the information flow in service creation. The research gaps found in this literature review show the need for future research, such as empirical studies on service creation practice.


Introduction
User experience (UX) movement started from industry [1], and UX design skills are one of the most demanded skills by the technology industry today [2].In academia, user-centred design (UCD) is seen as essential in order to improve the UX of digital systems.However, UCD has not penetrated to commercial Agile UX projects at the same pace as UX design, since much of the UX work in industry is not following UCD principles.Instead, Service Design seems to be more successful in bringing a human-centred perspective in many business sectors [3].Service designers' work focuses on the 'fuzzy front end' of the Service Creation Project, which explores not only user and customer needs and desires, but also business opportunities and the potential scopes of future services [4,5].Academic UX research, however, does not commonly acknowledge Service Design as a distinct design approach, that is seen as valuable for all parties involved in service delivery and utilisation, the actual implementation of the digital parts of the service can begin.Many of the proposed service concepts are not taken forward, and even for the most promising service concepts, the decision of starting the concrete service development project may take months.Eventually, if a go-to-development decision is done, the final scoping of the service may be influenced by earlier project proposals or changes in markets [8].This introduces a temporal gap and a knowledge gap between the fuzzy front end phase and implementation phase of the process, where knowledge transfer needs to rely on a documented service concept.Similarly, knowledge collected on user and customer needs and wants must cross this gap in order to feed the UX design.Therefore, this article pays special attention to the gap between the fuzzy front end service design and the following Agile UX design.We call the knowledge transfer over this gap as Service Design Handover, and refer to the whole process -from the fuzzy front end of service definition to service commercialisation -as Service Creation Project.
The purpose of this study is to advance the knowledge of the interplay between service design and UX design in projects where the two practices proceed in a sequence as in Fig. 1.Specifically, we are interested in understanding the challenges and solutions in knowledge transfer, since the gap between service design and UX design introduces a knowledge transfer challenge.Towards this purpose, this article reviews previous scientific works on knowledge transfer in service design, UX design, and software development.We define handovers as short term knowledge transfer events.Furthermore, we call the knowledge transfer between the early service design and later agile software development project as Service Design Handover.
The original aim of this study was to find academic literature that has studied the flow of information, or knowledge transfer, in different phases of digital Service Creation Projects.However, due to lack of knowledge transfer literature on Service Creation Projects, also literature on similar projects including knowledge transfer were included in analysis.Furthermore, based on our literature review, academic literature has not addressed the different roles of service design and agile UX design.However, they do provide us knowledge on the needs and challenges that relate to knowledge and information in software development projects in general.This allowed us to learn from similar cases and bring the findings of knowledge transfer successes and failures to our framework of Service Creation Project information flow and our initial framework for Service Design Handover to agile UX.This study brings in knowledge from existing literature to all phases of a Service Creation Project.
A holistic view to the whole process of Service Creation Project helps to see how Service Design affects the software development project.The holistic view is also the starting point to understand the need for Service Design Handover.Some information may be created in very early phases.It is crucial to enable the information flow through the whole Service Creation Project.Unsuccessful handovers lead to difficulties during projects when knowledge accumulated earlier in the project is not available for people joining the project later on.Handover inefficiencies can manifest for example in wasted work fulfilling wrongly assumed service requirements, poor market reception, or inadequate match between user needs and service functionality.It is unclear how they could be effectively avoided in Service Creation Projects.
In this study, with a specific focus on knowledge transfer within Service Creation Projects, we define knowledge transfer as one or multidirectional effort to pass information that is relevant to the Service Creation Project.We also define knowledge transfer to be part of information flow in the Service Creation Project.Knowledge transfer happens to known or unknown persons; and in the current stage or future stage of the project.Knowledge transfer can happen in an instant or during an extended period of time; and the knowledge can be represented to the receiver by formal artifacts, boundary objects, decisions or any informal means.We define the information flow to be broader than knowledge transfer.Information is not always knowledge, but knowledge is a subset of information.Furthermore flow includes passive and unintended movements of information and flow does not specify the medium in which the information is moving.Flow also refers to multiple situations where information is transferred.
The knowledge transfer between user research and software development has been studied and addressed by many tools, such as personas, user scenarios, and user stories.However, recent research [7] has shown that a new phase service design precedes the UX design.This means that Agile UX work is not done in vacuum, but UX work starts well before the Agile UX work starts.We need to understand how this valuable information gathered on the needs of different stakeholders can be transferred to the Agile UX project, and how that information should be presented to be useful for the Agile UX team.The objective of this work is to collect the best practices from similar contexts, to contribute to Agile UX research.
To study the Service Design Handover, i.e., knowledge transfer and knowledge utilisation in Service Creation Projects, a selection of knowledge transfer related articles is used to frame the phenomena; and then a systematic literature review is used to study the phenomena in Service Creation Projects.This study contributes to Agile UX research by consolidating the literature into a framework that describes the knowledge transfer needs along the whole Service Creation Project, including the service design phase where the Agile UX team can have an important role.

Related research
While it has become common to integrate service design and UX methods in industry, the best practices for the interplay between service design and UX design are still developing.An online survey of practitioners and academics in 31 countries found that practitioners tend to see the service designer role as more holistic, including organisational design with work and revenue designing elements, while UXD role is seen more focused on individual touchpoints of a service [7].A sequential relationship between service design and user experience design reflects the Service Creation Project advancement from more intangible fuzzy front end to more tangible implementation of the service.As suggested by Roto et al. [7], and in line with Gassmann & Schweitzer [8], Fig. 1, we assume a sequential process model where service design precedes UX design.
The literature on knowledge transfer is voluminous, but we have not been able to find literature reviews focusing on knowledge transfer specifically between service design and UX design.Regarding the transfer of knowledge on customer needs, a literature review by Bagheri et al. [9] provides the closest reference to relevant works.Their literature review identified 268 knowledge transfer challenges in customer knowledge transfer in value networks, and categorised them into 28 challenge types.However, the literature review by Bagheri et al. [9] did not study the solutions to the knowledge transfer challenges, nor did they analyse knowledge transfer throughout development projects.
While Service Creation Projects have not been covered by knowledge transfer literature, knowledge transfer in technology development projects offers a close reference.Eckert et al. [10] studied information flow in two large engineering companies through in-depth interviews of 38 senior engineers and engineering managers.Similarly to Bagheri et al. [9], they focused on the knowledge transfer challenges.Eckert et al. provide a list of 14 reasons behind knowledge transfer failures, which they categorised into 4 groups: Not understanding the big picture, Missing information provision, Information distortion, and Interpretation of representation.For example, one reason behind not understanding the big picture is knowledge receiver's lack of awareness of information history [10, 2nd item].This and many other items in the list of Eckert et al. seem to address salient challenges for Agile UX team in Service Creation Projects.Eckert et al. [10] provide the closest reference to our work with their specific focus on the information flows along complex design projects.Therefore, we will use their work as a reference when analysing knowledge transfer challenges found in this literature review.

Research questions
As described in Introduction section, there is an ongoing transformation in Agile UX practice introduced by service design.Front end service design activities collect knowledge about the needs of customers, users, and service providers, for whom digital applications with user-friendly user interfaces need to be developed.User-centred development needs the collected knowledge as the starting point, which means the collected knowledge has to be transferred to the agile development project.Due to the importance of fluent communication in any organisation, there is an overwhelming amount of knowledge transfer literature.However, it is hard to find the relevant works that provide guidance to this specific knowledge transfer context.Therefore, we aim to summarise the academic literature relevant to knowledge transfer along the Service Creation Projects.The overarching research question of this article is as follows: What can Service Creation Projects learn from knowledge transfer literature?
The overarching research question can be addressed through three more specific questions: 1. What knowledge transfer contexts, phases and scopes are covered in the literature?
To get an overview of the literature, we first study the contexts, phases and scopes addressed in our sample of articles.

How information flows in Service Creation Projects?
Second, we analyse the information flow from the perspective of project team roles involved in knowledge transfer, and the boundary objects created and utilised along the project.

How to improve knowledge transfer from service design to agile UX?
Based on the understanding gained from the previous questions, we can analyse the challenges and solutions of knowledge transfer in Service Creation Projects.The structure of this paper is as follows.Section 2 presents the methods of the literature review and its analysis.Section 3 presents the results and introduces concepts found from the literature relating to Service Design Handover.Section 4 answers the research questions and introduces a framework of the information flow in Service Creation Projects.The last section concludes the findings and contribution.

Method
To answer the research questions, a systematic literature review method was selected.The selected database was SCOPUS because of its wide coverage of publications in this area.Both theories and descriptive case studies were included in the sample.The final set consisted of 41 publications, and the full text of each was analysed via deductive content analysis [11].The first author collected, categorised and analysed the data.Additional categorisation was sample based inductive analysis.Next, the method is reported addressing the relevant items in PRISMA 2020 Statement [12]; search criteria, screening criteria, analysis; bias assessment.

Search criteria
The purpose of the literature search was to form a comprehensive list of articles covering Service Design Handover.By conducting initial searches directly on service handover, researchers discovered that the search criteria had to be expanded in order to find publications.The next approach was to scope a wider variety of research around the Service Creation Projects that would discuss knowledge transfer aspects between the phases.Test searches were performed to find relevant keywords and later the searches were combined to include as many as possible potential handover articles.
The final search query combined three overlapping previous queries.The first part of the query covered results with both topics of user research and agile software development.The second part covered results that discuss knowledge transfer, user experience and either agile or design process in the same publication.The third part covered handovers or knowledge transfers between some sort of phases in the literature that are using either ''design thinking'' or ''service design'' as the terminology.Individually, these queries offered potentially good results, but they were overlapping.Combining these separate queries removed duplicates from the result but the final query become complicated.The final query was performed on 2020-01-31 in SCOPUS database and it gave 773 results.The complete SCOPUS search query was: ''ALL ((''user research'' AND ''agile software development'')

Screening criteria
The list of articles were screened in three stages to identify those discussing relevant topics to Service Design Handover (n = 773, see Fig. 2).
The first screening stage evaluated both title and keywords.The title alone was not adequate to indicate possible indirect contribution to this research topic and so keywords were included to provide context of the article.The purpose during the first stage was to include potential articles, with low threshold, if one or more of the following screening criteria would be met: Article describes 1. a handover or a knowledge transfer directly, 2. design, UCD, UX or RE as part of a process, or 3. a case project involving reflection on design process and knowledge transfer During the title and keywords screening, 87 potential articles were identified.The rest, 686 articles in total, did not meet the eligibility criteria and they were excluded from the second screening stage.These excluded articles were for example on the following topics: Patient handover, medical handover, university, course, students, teaching, text mining, machine learning.We wanted to be inclusive at this phase of filtering and only excluded clear cases.When relevance was not clear from the title and keywords, we included the publication.For example, a case article about the innovation process [13] and sketching [14] were included at this point.
The second stage evaluated abstracts with the same criteria and categorised the articles for the third stage.Based on the abstracts 33 articles did not meet the criteria and they were excluded, leaving 54 articles for the third stage literature review.These excluded articles were for example on the following topics: sketching method [14], usability studies in agile [15], trade shows [16], and customer involvement [17].The excluded articles provided too weak a link to the screening criteria based on their abstracts.
During the third stage of screening, the first author read full texts of the articles and made notes.Total of 13 articles were excluded based on text screening for the following reasons: 6 did not discuss knowledge transfer in any way [13,[18][19][20][21][22], 4 had too vague approach on knowledge or irrelevant context compared to Service Creation Projects [23][24][25][26]), and for 3 the researcher did not have access to full texts (in the first, the journal was not accessible for the author university and contact via ResearchGate gave no response [27], in the second, SCOPUS had the citation but the conference journal was not online anymore [28], and in the third, only preview of the first book chapter was available online [29].The rest of the articles, 41 in total, were then included in the analysis.The list of publications belonging to the sample is as follows: [8,9,.Three extra references in the list (namely [69][70][71]) were chapters from one included book [8].The SCOPUS query result and screening results are available upon request from the first author.

Analysis
The 41 articles were first analysed with deductive content analysis [11].The categories for data analysis were derived from our research questions, and each article was studied to find data about each category.The following topics formed the main categories in the analysis matrix: The data on various processes were rich and required additional categorisation.The first author used inductive analysis to create additional categories from the sample.The data were visualised along a process timeline, as far as the descriptions in the articles allowed.The timeline visualisation (Fig. 3) was based on process activities (blue notes) placed chronologically from left to right, and it included data on created information and boundary objects (orange), roles of the project team and project stakeholders (yellow) and knowledge transfer directions and interactions between the actors.Knowledge transfer problems (red) and solutions (green) were initially placed along the timeline, but later analysed separately.This inductive analysis resulted in the framework of Service Creation Project information flow (Fig. 6).The timeline was used also to analyse coverage of each reported process along the widest presented scope of all processes, which resulted in Fig. 4.
The last coded information from the article were knowledge transfer problems and solutions.Knowledge transfer problems were analysed and structured with source reasons for those problems.Knowledge transfer solutions were also merged and sorted into knowledge transfer strategies and they are presented in the Results section.Solutions that can act as a guidance for practitioners are collected in the discussion section.

Bias assessment
Bias in this study emerges from the assumptions made by the first author to combine the process model, roles and knowledge transfer directions in the proposed framework.It is influenced by the first author's previous industry experience in the area of Service Design Report [68], internal reflective prototypes [35], brief, handout Report handover [30], handover, brief, handout Internal affirmative prototypes [35], intended UX [42], use cases [50], project wiki [43], [68], handover, brief, handout

Results
The results of the literature review are presented in three parts.The first presents knowledge transfer contexts and coverage of Service Creation Project in the studied literature.The second presents the information flow related findings from the perspective of roles and artifacts.The third part focuses on the knowledge transfer problems and solutions that were present in the sample.

Literature knowledge transfer contexts and phases coverage
The first section answers the first research question on what knowledge transfer contexts and scopes are covered in the literature.It is done with three dimensions: parties, duration and timing.This section also evaluates sample's coverage of the Service Creation Project phases.

Knowledge transfer contexts
One dimension of the context of knowledge transfer are the parties involved in the transfer.We categorised the 41 publications based on the parties who were involved in the knowledge transfer.As listed in the horizontal axis of Table 1, parties that transfer knowledge to each other included (1) Two individuals, (2) Constant team members, (3) Changing team members, (4) Two teams, (5) Organisations, (6) Stakeholders.Out of these 6 parties, the 2 mainly participate in Service Design Handover situations and they are highlighted in Table 1.
The two parties are in the middle; the changing team members and two separate teams transferring knowledge.Two individual's dyadic knowledge transferring problems are not in the focus of this article.Constant team members transfer knowledge in a longer time period and the information accumulation within them is less interesting to handover situations than the discontinuous teams.Organisations are too large a subject to be researched about one project and even then a team level inspection would be more valuable.Stakeholders are not the main drivers of the projects so knowledge transfer happening with them falls out of the project work knowledge transfer scope.These columns are included to provide a full picture of the knowledge transfer contexts.
The sample focus on parties who transfer knowledge is within most typical Service Creation Project.A total of 45 knowledge transferring party codes were given (see Table 1 references).Majority of them were on team levels.Given codes per each party category are: Two individuals 2 (4%), Constant team members 14 (31%), Changing team members 3 (7%), Two teams 16 (36%), Organisations 3 (7%), Stakeholders 7 (15%).The results indicate that the Changing team scenario is less reported than anticipated.Discontinuation in team level is fairly common and as shown in later sections, the roles that are involved in the project change during project phases.Therefore Changing team members' context is under represented in research relating to Service Creation Project knowledge transfer.Literature in the sample covers well the team level knowledge transfer and knowledge transfer between teams.
The duration of the knowledge transfer was also a defining factor in the context.The knowledge transfer methods and organisational practices from the articles were separated into four categories based on knowledge transfer duration.They are depicted vertically in Table 1 as (1) One off, (2) Short collaboration, (3) Project, (4) Continuous.Again the hypothesis about separate exploratory team and implementation team changing the active role guided the research focus.Some of the articles in our sample discussed more long term practices including knowledge transfer, which indicates that the focus is not on project work, but in a continuous process work.They were labelled as continuous.The part of the sample that is categorised as project-duration is dealing with project-long durations in which the knowledge is transferred.Whereas in Service Creation Project and two teams with division of labour the whole project is not used to transfer the knowledge, but the duration is shorter.That is why one off and short collaboration durations are highlighted.Together with parties the focus area of the most relevant literature regarding knowledge transfer within Service Creation Projects was revealed.
A clear majority of the sample articles focused on longer term knowledge transfer contexts, i.e., the two last rows of Table 1.In total, 29 out of 41 articles described either continuous or project long knowledge transfer contexts, such as long term teamwork or communication between specialised teams.Fewer of the articles discussed short term knowledge transfer contexts.In total 12 out of 41 articles discussed single point of knowledge transfer in one off situations, such as reports or prototypes, or in short collaborative times, such as single workshops.Sample article dimension amounts from Table 1 with a total of 41 were: One off 7 (19%), Short 5 (12%), Project 12 (29%), Continuous 17 (40%), while including each article only once.

Temporal structure of handovers
Service Creation Projects oscillate between short term knowledge transfer and long term team work containing knowledge transfer.The sample analysis revealed that constant team work and knowledge transfer focuses on development, and there is less academic literature on earlier phases and their internal knowledge transfer.The research on discontinuous knowledge transfer is focused on individual method proposals.The phenomenon has not been observed widely.Method proposals dominate the shorter time frames, and team structures and role descriptions dominate the longer time frames.In Table 1 examples of activities related to the knowledge transfer in each publication are reported for each category.
In the discontinuous situations, during the phase boundaries the knowledge transfer is usually a handover with short term knowledge transfer [30,39,50,52,54,61] or changing project teams [34].Teams are not overlapping for long in phase boundaries.For example if the development starts then the decisions are made with that team, and there are no longer parallel decision making about the project in the previous team.Reports and demos were also one off events [36,46], where knowledge is provided to the team and they adapt to it.Workshops methods were labelled as short term (see [39,52,54]) as they too aim for short term knowledge transfer.
Longer knowledge transfer durations cannot be called handovers, but project temporal level were situations when knowledge transfer had a certain duration defined.The knowledge transfer aimed at some output and the duration in which the team was limited.Examples are roles that transfer knowledge for a longer time period, but eventually leave the team (see [8,34,45,53,58,61,65]). Also organisational and stakeholder level papers had longer, but still limited duration knowledge transfer projects (see [38,40,44,55,60]).
Continuous knowledge transfer involves more stationary working organisations.Continuous label was given when the method does not specify the duration of the arrangement to transfer knowledge and it can be assumed as the status quo for some roles and teams.The sample raises two implementation phase organisations models.The first is a singular cross-disciplined project team [32,36,41,57,63,64,66] and the second is two separate teams with design and development functions separated [33,48,49,51,56,59].The knowledge transfer is a continuous process in both models.Singular handovers happen, but the continuous interaction between teams or members differentiate the context from others.

Phases of new service development
We have synthesised a project process framework from the sample's coded collection of process descriptions which were similar to Service Creation Projects.This process framework enables further analysis of information flow in the projects and identification of knowledge handover situations.In total our framework consists of 7 steps.Next each step is introduced and the similar steps from the sample are listed with references.
1. Situation analysis [8] is the first step and it gives motivation to search something from a certain area of interest.Similar steps were: Foundational elements [71], Innovation strategy, Trends [70], Preliminary opportunity identification [71].
2. Exploration [56,57], the second step consists of exploration of the needs and use contexts.The knowledge is embedded and tacit for certain members who participate in the exploration.In other articles from the sample it was called Analysis [64] or Double diamond first phase [34,37,38,61].Double diamond model is a design process model where the problem domain is explored in the first ''diamond'' and the solution domain is explored in the second ''diamond''.The diamond refers to the visualisation of the model's diverging ''<'' and contracting ''>'' phases.
3. Concept phase is similar to the Double diamond models second phase, and the focus is in the creation of the solution.This phase was called in the sample with names Product vision and concept [34], Product discovery [56], Concept generation [70], Building business case [71]).
4. Decision to invest is the phase where the organisation decides to put more resources into the concept.Development resources are costly, because an organisation might have alternative use for them in other projects.Schweitzer calls this phase go-to-development gate [8].During this phase a completely different set of people might make decisions compared to the previous phases.Their job is to evaluate the potential of the concept and strategic alignment of the goals to the organisation's goals.The limited nature of organisational resources requires prioritisation decisions.Due to the organisational structures there might be a long time required for this phase.That delay is one of the reasons why knowledge transfer becomes harder.
5. Implementation initiation is a short period when a service implementation project is starting and being scaled up.Many articles in the sample called this phase Sprint 0 [48,54,56,57,71].The content of this phase includes the verification of the concept assumptions.In another terminology from minimal up-front design there would be a business analysis phase [57] at this point, but the concept would already be known.Even at the start of agile projects some form of preceding interaction design was deemed to be necessary before the development starts in full [57].
6. Development [38,50,71] phase involves the roles implementing the service.Services might have an automated digital component in which agile software development would take the stage.Alternatives of mentioned processes for development phase were: Scrum [37], New Product Development (NPD) + UCD cycle [41,57,63], Scrumban [49], XP [57], Parallel development and UCD track [56,57].A total of 15 articles discussed about agile software development.Development phase definition consists of services implementation and roll-out.Services might have physical components or the service theatre is completely physical.Implementation of those were not discussed in the sample.
7. Commercialisation [42,71] is the phase when the service enters the market on a large scale.If the corporation has separate functions for commercialisation such as sales or marketing, they require some knowledge transfer as well.
Our combined process framework can be used to contextualise knowledge transfer situations and Service Design Handover.The sequential separation of SD and UXD work [7] imply that the service design steps in the earlier phases include a different role and a Service Design Handover is required.Other knowledge transfer situations could similarly be identified from the phase borders or within phases.In the next section the framework is used to evaluate the sample's representation of the Service Creation Project.

Coverage of project phases
Since this study is interested in the whole Service Creation process, the content analysis also investigated the coverage of process phases in each article.The results are illustrated in Fig. 4. All articles were compared to the Service Creation Project phases created in the previous section.
Literature in the sample covered all Service Creation Project phases as shown in Fig. 4. The sample included articles that covered the whole project of new service development from the earlier phases to the commercialisation [9,38,40,71].The most common coverage of the phases in the sample was shorter: from 2. Exploration to 6. Development (articles were [47,48,53,55,59,63,68]). UXD focused articles dominated the later phases whereas design focused articles dominated the earlier phases.The development phase was well covered with the agile development related articles in the sample.Some of the articles were covering only a single phase in the process framework (namely [31,33,46,49,51,55,72]).
Few articles mentioned the resource allocation between service exploration and implementation phases.8 in total included the framework's middle phase, 4. Decision to invest [8,32,34,37,44,48,70,71].The fourth phase was not mentioned in the other 27 articles which included phases around this project boundary, indicating that the boundary is not relevant in all cases.

Information flow in Service Creation Project
This section answers the second research question on what is information flow in Service Creation Projects.The first part lists the roles that are involved in the projects.The second part lists the produced information in a Service Creation Project.The third final part analyses artifacts and boundary objects and evaluates their role in information flow of the Service Creation Project.This section offers visibility on the information creation and format and its flow between the actors.

Service Creation Project roles
With the list of roles, it is possible to map knowledge transfer situations and boundaries that need to be bridged.Since not all articles specified the phases of the project the role was present, this section summarises only the roles and teams that were identified as being stakeholders in the Service Creation Projects.In the literature there were many agile UX roles, but the review was not limited to those.The term role refers in this study to a defined position that a person has in the project team.Roles which are involved in service creation are plenty and the amount of roles also indicate multiple individuals in new Service Creation Projects.The roles from the literature: • Leadership roles: Director of UX [46], Chief Experience officer [46], Project coordinator [8], Executive members of project [57], Upper management [46], Project owner [49], Business owner, Product owner [47], Principal designer [52] • Early research roles: UX strategist [34], UX Researcher [53], Analyst [73], Business analyst [57] • User representative [73], Customers or end-users [56,70] • Stakeholders [72] • Consultants in innovation process [61] • Designer roles: Designers [38,45,53,55], Service designer, UCD team [56], UX Designer [49], UX implementer [34], UX specialist [46], Interaction designers [57], Visual designer [46,47], • Cross-functional team [53,57], Project team [8] • Development team [45][46][47]56,57], R&D [42] • Other functions: Marketing [46], Sales [42] Knowledge transfer between different experts is harder than within the same expert group.The identified roles and their categorisation indicate the knowledge boundaries faced in the project.These boundaries exist for example between the leadership and the rest [46], early research roles and designer roles [30,34,52] and development team and sales functions [42].Agile software development and scrum specifically define the Product Owner role who is responsible for holding the vision and the guide development actions towards a business goal [32,47].The Product Owner role creates continuation in the project.Another solution was provided by Schulz et al. [34] with two roles that gradually change responsibility over the customer wants-and-needs information.UX Strategist focuses on the early phases and exploration and UX Implementer makes sure that the vision is met by the service [34].They share early concept creation phase and implementation phases, and have a defined handover in the process.Continuation and reduction of hard borders between the roles were generic knowledge transfer strategies in the sample.
Value seeking activities might also be transferred to the implementation capable team from the start.These cross-functional teams were mentioned in the sample (see [8,53,57]).This type of reduction in division of labour among teams decreases the need for communicating the exploratory findings to other roles.

Produced information in new Service Creation Project
In order to understand information flow, this section examines what information and artifacts are created during service creation.During a Service Creation Project different information is produced and utilised during each phase.Part of this information can be called as knowledge but this section does not differentiate them.The information and information related artifacts can be categorised first into two groups.The first is information that is just utilised during an individual Service Creation Project phase and the second group is boundary objects that are used to communicate between boundaries of the project.Mapping the Service Creation Project information from the sample produces an overview of the whole information flow in the project while further analysing the boundary objects illustrates their knowledge transfer qualities.Some of the information in a given project is used directly at the same phase by the same people who produced it, reducing the need for knowledge transfer, whereas some information is needed in later stages of the project and knowledge transfer and information flow becomes a necessity.
From the literature the information and artifacts were coded.Total of 64 types of knowledge in a Service Creation Project were identified and they are listed in this section.Each type of information is placed on our 7 step framework of a Service Creation Project.

Artifacts and boundary objects
Some of the project information needs to be stored so it can be accessed at later time and or the information user is a different project role than which produced that information.This section answers which artifacts and boundary objects are utilised in the handovers in Service Creation Project.
Boundary objects have ''a shared identity across communities and local usefulness within each community'' [75].In the Service Creation Project these communities can exist both in parallel and in sequential order.Communities in Service Creation Projects are linked to the project roles.Early research roles have different community of practice with their unique language and values compared to implementation focused development teams.Compared to the information described in the previous section the information here is shared and communicated to other people.Some of that information is knowledge.Knowledge transfer between these boundaries usually requires boundary objects.Additional difficulty might arise from temporal separation of the teams in sequential order where a early research team has been long disbanded when a development team starts pursuing the concept implementation.
Spanning and utility boundary objects in this study are defined by a two dimensional framework.Dimension one is knowledge transfer between teams.Dimension two is knowledge transfer between project phases.Utility boundary objects transfer knowledge within a team or one project phase.Spanning boundary objects transfer knowledge between teams and multiple project phases.Separating boundary objects into two category provide more insight in their role in knowledge transfer.Spanning boundary objects are transferring knowledge over multiple phases or between teams.Utility boundary objects are the ones that are used mostly within one team or within one phase of the Service Creation Projects across parallel teams.See Fig. 5 for visual version.
Exploration phase produces fairly few spanning boundary objects and the findings from field research, ethnography, contextual inquiry and latent customer needs are mainly turned into concept phase outputs by the same people [30,38,52].Exploration phase results could be task analysis, customer journey mapping and personas [64] that could be used to communicate sticky customer insights to other stakeholders.These results are seldom used as stand alone and are usually used as fuel for the concept ideation.
End result of the implementation is widely used across later in the project and by other organisational stakeholders.Sales team learns the value of the service by using the final service instead of relying on the other material [42].The service touchpoints are where the customers interact with the service, so in a way the end result of the implementation is the farthest reaching spanning boundary object.With service launch or commercialisation actions the service is communicated to the widest audience thus far.
Business model and project plans are spanning boundary objects that most tie the project to the producing organisation.Both of them are updated during the project even if some parts of them might be defined from the first stage while initiating the project during situation analysis.Other boundary objects created during situation analysis might not survive the later stages, but the scoping and decisions made based on those continue to have effect on the project.
Utility artifacts such as light low fidelity prototypes [35] and usability reports [46] serve their purpose as means of communication in singular point of the Service Creation Project.Utility artifacts support a decision made during one phase but they are not utilised as such in later stages of the project.An alternative user interface component from the concepting phase is not put to the table when later phases find the then design insufficient.Some researchers suggest that a technical solution of a central design record should be implemented [50,59] to enhance this time spanning communication.
In this results section the roles, the information and boundary objects involved in the Service Creation Projects have been listed.A synthesis of these results is presented in the discussion and in Fig. 6.Next the strategies to improve the knowledge transfer are presented.

Knowledge transfer strategies
This section answers the third research question, which is how to improve knowledge transfer from service design to agile UX.First the problem sources are analysed and then strategies to overcome the knowledge transfer difficulties are provided.

Knowledge transfer problem sources
Based on the content analysis of the sample there are 4 main sources for knowledge transfer problems: 1. Knowledge transfer is not ensured for later stages for lack of incentives or perspective 2. Information nature of customer needs makes it hard to transfer 3. Communication is not inspiring or actionable

Communication channel errors
The first one is the lack of incentives to ensure knowledge transfer in the later stages [10,62] which leads to situations where knowledge transfer is not ensured to happen later.This happens for example in the fourth step where knowledge transfer needs to happen over the 'go to development' gate to the implementation.Separation of service design phase and agile UX is common in industry as organisations do not immediately give resources for development for every concept.The project implementation go/no-go decision is made by somebody else than the people who have been part of the team (result of Centralisation and Bureaucracy in framework [42]).This leads to lack of traceable communication from previous steps observed by the next team [50,61].The next team does not get a clear image of the previous knowledge if the knowledge transfer has not been planned or ensured to happen.
Another source of knowledge transfer problems emerge from the nature of the knowledge created during the Service Creation Project.Consumer needs-and-wants-information is sticky [70] (see also [42]).the knowledge of user experience is embedded in the observer of those experiences, meaning knowledge about use context is implicit in nature and it loses richness and meaning during knowledge transfer [30].This embeddedness of the knowledge makes it more difficult to transfer.Absorption of sticky information is time-consuming and costly [42,70].Tacit knowledge expression is difficult [9].
The third source of knowledge transfer problems was that insight communication is not inspiring [46,68].Research result presentations do not lead to change in practice [34,46].Only-artifact knowledge transfer showed problems; there is a lack of information in later development phase, as observed in practice [37].The first hand experience is more motivational than the second hand description.The lack of information context leads to poorer information utilisation.
The fourth source was more general communication related.Problems arise when a message is skewed during communication [68] and communication channel errors exist [10].Poor communication medium drops information.User friendly information system is required [9,50].Humans naturally make decisions on narrative data that is given faceto-face [62].Furthermore, the knowledge is used in patterns [65] and providing fragmented information about a concept or an experience does not carry the message that was intended.In addition, the receiver bias is one source of problems [37,68].If a person does not expect a certain type of knowledge they might not receive it [10,62].The sender also might not know what to record or communicate.Sender lacks awareness and does not get feedback [9,10].Two practical examples of this situation are when the problem complexity is not known by solution creators, or concepts are easier to ideate than to implement.Specialists must understand what other specialists need to understand [41].The communication channel loses information when the applicability of the information is not understood.

Knowledge transfer strategies
With further analysis of project practices described in the sample we identified 4 main strategies to improve knowledge transfer in Service Design Handovers to agile UX.These strategies answer the research question 3: How to improve knowledge transfer from service design to agile UX?The 4 main strategies are as follows: 1. Improve communication quality 2. Increase amount of communication 3. Circumvent the need for knowledge transfer 4. Verify knowledge transfer success The 1st strategy to improve communication quality relies both on material use and handover improvement.In the improvement of material use, either objects or mediums are improved.Objects are boundary objects [41], design artifacts [38,44], whiteboard [59], sketches, lists and stories [59], documentation of the system [61].Mediums are system for organising communication [9,50] documenting past process [61], central design record [59].In the improvement of handover, the designers can engage in a co-design with the developers.Examples of these are analysing user research together [37,39,41,48], creating a ''product story'' or a vision with them [37,41], prioritising user requirements into product backlog as shared activity [32,34,37,43,47,56,57,61]. Quality of communication is also improved if the people have a shared language.For example, contextualising, which is sharing semantic basis and having mutual understanding counter the language challenges in value network when transferring customer knowledge [9].Joint team design exercises can also be used to educate other team members about design activities [47] enabling better mutual understanding.
The 2nd strategy is to increase amount of communication of the people who possess the required The methods include increasing either teams one-off communication or increasing teams continuous communication, adopting knowledge owner roles and improving team access to One off communication can be increased by intensifying communication during a short period (e.g. a handover workshop [37]).Continuous communication increase can be done by process change (e.g.synchronising UCD and NPD cycles [41]).Knowledge owner roles can be one person in a team (e.g.UCD owner [41], user researcher as part of Scrum team [34,48], product owner [47]) or separate role (e.g.contact person to previous decisions [61], advisory board for the team [37,61]).End-users are best informants for some aspects of the service and thus increasing their role in Service Creation Projects improves the information flow.End-user involvement with the team can be done with co-creation [70], improving access to users with regular scheduled interaction slots [34] or increasing engagement with customers in the early stages of new product development [58]).Increasing communication and contact is one generic strategy to solve knowledge transfer problems [9].Solutions adjusted from Hodgetts' [32] paper for better handover are (1) increasing understanding of UCD-activities for other project members so they know how the information is created, and (2) taking designers part of the implementation team and categorically promoting daily collaboration between the disciplines.Mutual understanding evolves from more frequent interactions.
The 3rd strategy which is circumventing the need for communication relies cutting the middlemen and shortening the chain from insight to decision with a dedicated role (a product owner [47], an UX Implementer [34] and UX designer [47,49]), a decision delegated to the team itself (e.g.team doing user research analysis [37,39,41,48]), or increasing direct end-user involvement (see previous strategy).Another way is to minimise the decision making hierarchy and delay from exploration and concept to development.The questions to ask are ''Is it really necessary to transfer this knowledge?Can the person having the knowledge do a decision or an transferable output?''Contrasting to the agile software development mentality with flexible developer roles there has been a sign that designer roles are starting to specialise especially in larger organisations [32].This creates a need for more hand-offs between individuals that increase the risk of miscommunications.The specialisation also makes it necessary to take it into consideration when planning the development work creating more complexity [32].Balancing specialisation with drawbacks on miscommunication is important also when agile UX is done by different people than service design phase.
The 4th strategy verifying knowledge transfer success can be deployed in immediate interaction or with delay.Immediate communication verification relies on human interaction cues (e.g. in handover workshop [37], synchronised UCD and NPD cycles [41], or asking feedback on reports [46]), while delayed verifying relies on testing the results (system testing [61], monitoring UI design [48]).Service Design Handover can verify knowledge transfer success in a immediate or delayed way with agile UX.
The four knowledge transfer strategies aim at improving communication and results of the project by improving knowledge utilisation.Practical implications of these strategies are provided in the discussion.The focus on the practical implications are in Service Design Handover.

Discussion
Based on this systematic literature review, the issue of knowledge transfer in the service design context is little studied.This study found 41 articles loosely covering the knowledge transfer in service development and design related projects.The closest matches in the sample were another literature review titled ''Customer knowledge transfer challenges in a co-creation value network'' [9] and a case description in design related roles during Service Creation Projects [34].Knowledge transfer was not in focus in most of the articles and a model in information flow in Service Creation Projects was missing.In addition, there seems to be a research gap on the practice description of project knowledge transfer.Understanding knowledge transfer in project context can improve the project outcomes and efficiency.
The first part of this section discusses the related literature and contribution to knowledge transfer problem sources.The second part presents a framework about information flow in Service Creation Projects and some key boundary objects.The third part presents an initial framework on Service Design Handover to agile UX and suggests practical ways to overcome knowledge transfer problems.

Knowledge transfer problem sources
In the set of 41 relevant articles in this literature review, there were several articles reporting challenges in knowledge transfer and their sources.We analysed the problem sources found in our sample against one of the most comprehensive lists of knowledge transfer problem sources by Eckert et al. [10].While Eckert et al. [10] discusses information flow problems, we have focused on knowledge transfer problems.As we define knowledge transfer to be a subset of information flow, the knowledge transfer problems extend to information flow problems.
Compared to the framework by Eckert et al. [10], this study confirmed the existence of most of the information flow problem sources.However the sample was not ideal for direct comparison to Eckert et al. [10] list.Some of the interpreted connections to Eckert's framework are discussed in this section.The list of Eckert's [10] information flow problem causes are as follows: 1. Lack of awareness of tasks that need to be done 2. Lack of awareness of information history 3. Lack of awareness of how information is applied 4. Lack of awareness of changes to processes The lack of awareness of tasks that need to be done (1st item) is confirmed by service development being complex [41] and the sender of the information being uncertain what the receiver might need [46].One result of limited interaction is knowledge receiver's lack of awareness of information history (2nd item) and status (6th item).They relate to lack of traceable communication [50,61].In a Service Creation Project, the lack of awareness of how information will be applied (3rd item) is displayed when the service designer is unaware of the next user of the information.This would be the case if the investment decision is pending and the implementation team will assemble after service concept creation (suggested by [8], see Fig. 1).Service designers make the handover of a concept to the future team without necessarily knowing the future team's information needs.This problem is visible in specialists needing to understand what other specialists need to understand [34,41,46].The fifth item, no feedback causing problems, came up when reports do not lead to change as their producer is not getting feedback [46].The power structure excluding viewpoints (7th item) did not come up directly but it can be interpreted from different roles making project plan and scoping decisions than the people who participate in them.The loss of context was supported by the sample (see [30,34,37]) and it relates to the knowledge transfer problem source identified in Section 3.3.1 as 3rd item ''Communication is not inspiring or actionable''.Information being oversimplified (9th) and interpretation of ambiguous information being based on context (13th) were thus supported by the results.Hierarchical communication paths (11th) happen when the information is transferred from outside to the team.Different hierarchical roles of the Service Creation Projects, such as executives and team, illustrated this aspect of potential knowledge transfer problems.Recipients are unable to extract the required information from the representation (14th) related to information expectations [62] and medium limitations of the communication [42].In Service Creation Projects, knowledge transfer often takes place between two experts from different disciplines, which likely involves dealing with language barriers and knowledge gaps.An example of this would be when the service design team communicates service concepts to the implementation team using their own jargon.
Differences compared to Eckert's framework was that 4 out of 14 information flow problems did not come up from the analysis.They were the lack of awareness of the changes to process (4th), information is consciously withheld (8th), Chinese whispers (10th), and expertise of intermediary (12th).This may mean that the four problem causes are not frequent in contexts similar to Service Creation Projects that our literature review focused on.Perhaps changes to process are well communicated in service creation processes, teams are openly sharing information, teams use digital communication where messages are not easily distorted, and expertise of intermediaries is on a good level or intermediaries are avoided.The non-finding with this sample does not mean that these items would not be relevant in other contexts, and so we do not suggest removing them from the list.
From this sample of literature, we found some sources for knowledge transfer problems that are not on the list of Eckert et al. [10].Therefore, we suggest extension to Eckert's [10] framework by the following four new items: 15.Information nature of the knowledge 16.Lack of contact between information producer and user 17.Lack of organisational resources directed to internal communication 18. Lack of information system to support communication The first new item addresses the nature of knowledge in Service Creation Projects, which is embedded in customer's context and sticky to transfer between people [8,9,30,42].The first addition is from results Section 3.3.1.(2nd source of knowledge transfer problems).The addition is valuable as the inherit nature of the knowledge is not addressed in the list by Eckert et al. [10].
The second addition is a root cause for many of the Eckert's framework items -the lack of contact between knowledge producer and user.Some of the communication problems listed by Eckert can be diminished with increased interaction between the actors.Many of the result sample papers suggested increasing contact [8,34,37,41,58,61] so the lack of it is a source of information flow problems.
The third addition, the lack of organisational resources for communication, is the root cause for the lack of incentives for knowledge transfer (the results Section 3.3.1.1st source of knowledge transfer problems).For example, the partial reason for lack of contact derives from the system level which is insufficient resources dedicated to communication [9].Lack of resources lead to lack of incentives to ensure communication as project personnel are guided to do other things with their work time.Organisations optimise the costs and the pursuit to optimise costs forms the context in where knowledge transfer happens.This third addition to the Eckert et al. [10] list is addressing a system level source for information flow problem causes.
A fourth addition is related to the medium in which communication happens as it was suggested by two publications [9,50].The publications argue that communication channel errors (Section 3.3.1,4th source of knowledge transfer problems) can be mitigated with a dedicated information system.This article builds on top of Eckert's identified challenges, but also offers practical implications from the literature review to overcome the knowledge transfer challenges faced in service development projects.These strategies for knowledge transfer are derived from case studies and analysis of the information flow in service development projects in general.In the next section the information flow framework is introduced, and the strategies to improve knowledge transfer within it is discussed in the last section.

Framework on Service Creation Project information flow
While the previous section addressed the problems in knowledge transfer, this section focuses on the success cases in the literature.To address research question 2 on how information flows in Service Creation Projects, a framework covering the whole Service Creation Project was compiled.The process coverage of each publication was presented in Fig. 4. The framework on Service Creation Project information flow is illustrated in Fig. 6.The components of the framework include (1) Service Creation Project phases (left side numbered 1 to 7), (2) Project team members and their roles (large colourful circles), (3) Stakeholder groups (small colourful circles), (4) Knowledge transfer contexts (arrows and triangles with direction), and (5) Boundary objects (small black circles).
Agile UX literature often ignores the project phases before software developers are included, but they are very important phases when it comes to the flow of relevant information to Agile UX work.Therefore our framework is a holistic one, i.e., it includes the phases even before there is a recognised need for software solutions, and proceeds all the way to the commercialisation phase.The framework is an idealised model suggesting best practices, and does not depict any single real project as such.Next, the framework content is explained for each step.
The first phase, 1. Situation analysis, is often initiated by the leadership of an organisation.In commercial organisations the driver might come from strategic needs and market opportunities [34,71].Internal and external stakeholders play a significant role producing ideas and signals and in hierarchical organisations executives then give permission or directions for employees to pursue for certain idea.If the organisation has an internal research and development function they are usually scouting potential ideas and opportunities [34].To further work on the idea a market analysis is conducted [69,71].If the results are promising a project might be put up to pursue further knowledge on the opportunity with the role of responsible business or project owner.The strategy and market analysis are the spanning boundary objects that communicate with organisational stakeholders initiating the project and the project team.
During the phase 2. Exploration if the idea relies on understanding customers rather than technological opportunity, a set of user researchers and service designers are involved.In the case of technological opportunity (described in [8,40,71]) a technological exploration and a proof of concept might be created.With customer driven innovation a set of customers or target group is involved, and customer needs are harvested [34,47].Information flows into the project team.To further analyse opportunities the service design method of customer journey mapping [64] might be utilised.The customer journey map then serves as a primary communication tool and spanning boundary object for project stakeholders about opportunities and customer context.
The phase 3. Concept includes the selection of the problem that the service aims to solve.A service vision emerges in a formal or informal manner and it becomes shared by the project team [47].The service vision serves the project for a long time as a spanning boundary object and it is updated when needed.With the vision it is easy to communicate the project purpose to new project members.After selecting the problem, an exploration of the solution space is conducted and this is often referred as second phase in the ''the double diamond'' design process [37].The resulting solution is worked further first as service blueprint or business canvases, which are boundary objects that are easy to communicate to serve several backgrounds of project stakeholders.A business model might be written as a result, that is communication tool for the executive and business goal focused project stakeholders.The concept phase culminates in the creation of the concept or a prototype.Most of the problems and knowledge loss are created in the scoping of the concept creation phase and the required output formats of the project team at that point.The concept creation might be isolated from the other organisation if the research is outsourced to consultants as a separate project.With a continuous research and development team the problem of personal experience availability later is lower.If the only form of interaction between the service designer and implementation team is conducted through a design artifact, the information loss is to be expected [30,37,52].Direct interaction is recommended in forms of joint analysis of user research or in defining of service requirements [34,39,41,48,61,64].
After concepting and finding customer need to serve, the project enters in the phase 4. Decision to invest.During that phase the project concept is evaluated against all other ideas and opportunities that the organisation faces.Furthermore the priority of investing further organisational resources is evaluated using the accumulated knowledge from strategy, market analysis and detailed customer insight, concept and its business model that were created in the previous phases.Decision making process is a case specific and organisation specific, meaning that the amount of hierarchy and bureaucracy involved varies.In the simplest investment decision making case an autonomous team already has a previously allocated budget to pursue any opportunity it recognises separate from other parts of the organisation.At the other end of the spectrum are more hierarchical and centralised decision making structures, often emerging in larger organisations, which can take months to years to reach an outcome on if the concept must be pursued further.During all that decision making time, the world outside of the organisation has changed and previous project knowledge has become less relevant.Discontinuation of the previous project team poses the greatest risk for information flow during the Service Creation Project.Knowledge transfer is required as the project team composition might need different expertise and people for the implementation.The Service Design Handover becomes harder and the insights that were gathered become less relevant.In a case that the resource allocation decision making halts the project, the team is disbanded, and only the artifacts and spanning-boundary objects remain, the knowledge loss is imminent.If the project outputs during earlier phases aim at the decision making and not for the implementation phases later in the project, the knowledge does not transfer in full.During the investment phase a project plan is usually formalised and starts to act as a guiding document for the project.The concept or prototype from the earlier phases are carried as temporally spanning boundary objects.
The implementation of the service concept starts with a phase 5. Implementation initiation where the key people involved in the implementation phase are included in the project.A set of briefs is held to transfer the knowledge from the previous phases, by the previous project team or the acting messengers from the organisational hierarchy.User stories are utilised as the boundary-spanning object and they act as the shared artifact to store the customer insight and user needs [32,37].The agile software development relies on user stories as their basic unit of increments and iteration prioritisation.The knowledge about customer's needs-and-wants from previous phases is transferred into user stories.Other temporally spanning boundary objects, such as service vision, concept or prototypes are used as a reference for the solution.The purpose of the initiation phase is to gather prioritised product backlog, another boundary-spanning object, for effective development phase [32,37,57].The product backlog acts as the main boundary object within the project team during later stages in development.If the information from previous service creation phases is old, another verification of the user needs and concept prototyping might be conducted [56,57].Technological uncertainties can also be solved ahead [8,32,47], and critical architecture of the software is defined.The focus at that point is to verify that the development can proceed effectively when more implementation team is involved in the project.
The service development in the form of software development begins in full in the phase 6. Development where full team allocation to the project is given.The key personnel from the implementation initiation, project leadership and previous phases engage in briefing of new people entering the project.This can be a direct workshop-like environment or with indirect aid from artifacts and temporally spanning boundary objects such as user stories and concept.The development team produces increments and iterations that convey information to stakeholders, such as user interface and minimum-viable-product.These are shorter term boundary objects, but effective in supporting information's team boundary crossing.Users and customers of the future service are involved in varying degree to ensure that implementation decisions fit their needs and the service produces value for them, so new knowledge is inputted from their side.At some point of the development the service can be released to the market.As the software often acts as the touchpoint of the service for stakeholders, the software product is a boundary object.
During the 7. Commercialisation phase focus of the project moves into supporting market adaptation of the service.Customers for the service are wanted in a large scale.Executives start to measure the service against the initial hypothesis of the service business plan, develop new key performance indicators that start to guide service operations.Marketing actions becomes the main driver of operations and marketing material is a boundary object internally and towards the customers.The service concept itself might be pivoted by the larger market scale information or iterated in other ways.
The phases described here are not equal in duration.Development might take considerably longer than service concept creation or vice versa.The phases might not happen right after each other, but there can be gaps between them.The phases can also be interlaced and happen simultaneously.Gaps introduce challenges in temporal dimension in knowledge transfer.When there is a need for more people to be involved in the project then the requirement for handovers increase.Within a project phase the knowledge transfer is more long term and is close collaboration.Between the phases the knowledge transfer is happening in a shorter time period and with fewer interactions and thus changes of miscommunication increase.
Shorter knowledge transfer durations dominate the discontinuous project phases.Namely the beginning of the project, the end of concept finding all the way to the start of implementation, and the end of implementation with service handover from the implementation team.During the first phase, situation analysis, knowledge transfer can be one off task brief.During the second phase the exploration team is building shared knowledge, absorbing and processing knowledge.Concept is built by either the same team or new people join the team and there is a discontinuation and need for knowledge transfer within the new project team.The hardest knowledge transfer gap emerges when the concept is evaluated by the executives and in case the implementation decision is delayed.At that point, between phases 3-5, there is a surge of one off handovers and potential for knowledge loss.Only some of the information is useful for the decision making of concept investment.If the concept is approved for further development, the information acquired in previous phases becomes valuable again.It is however uncertain how much knowledge transfer happens from the previous stages at this point.In contrast, during development the knowledge transfer context is long term and interaction is frequent inside the team.The framework was created to illustrate information flows in Service Creation Projects and the special role of Service Design Handover between if the early phases and later phases are separated by different professions and people.

Best practices for Service Design Handover to agile UX
Finally, we answer the third research question on how to improve knowledge transfer from service design to agile UX by zooming in to the phase of Service Design Handover and providing strategies to overcome knowledge transfer difficulties in this little studied phase.First, we describe an initial framework of Service Design Handover and then summarise the strategies.The initial framework Fig. 7 components are based on the analysis results in Section 3.2.The framework explores the connections of roles, boundary objects and knowledge transfer for Service Design Handover to agile UX.When mapping the components in Fig. 7, we have used analysis behind Fig. 3 and our own knowledge base.Therefore, we call it now an initial framework and it has to be verified in the future studies.

Boundary objects in Service Design Handover
An initial framework of Service Design Handover to agile UX is presented in Fig. 7.It visualises the gradual change from phase to another.Project phase progression is horizontally from left to right.Practices from strategic to implementation are vertically from top to bottom.Service design work takes place in earlier phases than agile UX in Service Creation Projects but the change between them is not a clear cut -they might take place in parallel [37,61].The gradual shift is presented by a diagonal area in the middle.In the figure the agile UX takes over the project gradually as the service implementation advances.Later in the implementation phase the product takes the prototype's place in strategic iterations of the service.The gap between service design practices and agile UX practices is the domain of Service Design Handover, in which the knowledge that is created during service design is transferred to agile UX.This initial framework accommodates the two separate roles changing the leading role relating to the user needs fulfilment described by Schulz et al. [34].In Fig. 7, only boundary objects in the Service Design Handover contexts are included.Their estimated evolution and contribution during the project to other boundary objects is presented with arrows.The roles are placed by their relation to the boundary objects and practices.The service designer role is in the service design and it has close proximity to early phase boundary outputs of customer needs, customer journey mapping, service vision, service blueprint, and prototype.The role of product owner is placed in between service design and agile UX, as the role participates in both practices and acts as an effective service vision advocate [37].The role is also closest to the business model boundary object targeted mainly for business functions of the organisation and strategic practices.The roles of UX designers and software developers are placed within the agile UX practice and more to the implementation practices.Their closest boundary objects are user stories, product backlog, user interface, and product/service.Within the agile UX the iterations are done with the implemented version of the product/service, whereas in service design, the iterations are done with prototypes and are more exploratory.
Service Design Handover happens between service design phases and implementation phases including agile UX.The most important boundary objects in Service Design Handover are service vision, prototype, user stories and product backlog.The service vision communicates widely and leads to further more detailed representations of the vision.The best practice with service vision is to start gradually involve roles from the next phase to the development of the service vision.This can be done, for example, by doing shared user research analysis [37,39,41,48], co-creating and re-creating product strategy [37,41], or keeping a person or persons the same between the phases, as suggested with the product owner role in [37,47].The prototype communicates the features of the service for the development team and it can be processed into the product backlog items.User stories are also a boundary object that can span the exploration phase customer needs findings into more actionable format for the development team.The shared user research analysis in a workshop [37,39,41,48] was a best practice that emerged from the literature as means for this aspect of Service Design Handover.The role of the product backlog in the centre of agile practices [47] makes it integral to the successful Service Design Handover.Adding and prioritising requirements into product backlog from user stories and prototypes in collaboration [32,34,37,43,47,56,57,61] would alleviate the gap from Service Design Handover perspective.The last handover in this model happens when individual items in the product backlog are created and they are defined for implementation.One option is that the service concept phase output are larger epics.In that case more information is needed to split the epic into smaller stories [47].In summary, the best practices for Service Design Handover to agile UX revolve around four boundary objects (service vision, prototype, user stories, product backlog) and their effective use.The boundary objects inside the Service Design sphere can be interpreted as unique for Service Creation Projects (service vision, customer journey mapping and service blueprint) as they emerge from service design practice.Prototypes and user stories are more common boundary objects for the agile UX and a successful handover to agile UX must utilise them.Next, more broad findings from the literature that can help Service Design Handover are discussed.

Strategies for handover
1. Improve communication quality: Practical method to ensure user insight use in later phases is to document it in richer medium, producing a compelling evidence for later phases.The most information packed boundary objects that help projects to move forward are service vision, product backlog and concept or prototypes.Understanding their communicative role as core knowledge transfer mediums between different project parties and stakeholder groups can motivate better practices around them.Social practices in service development can be renewed.Co-design of service vision [37,41] or concept [37,39,41,48] or prioritising user requirements in to a product backlog [32,34,37,43,47,56,57,61] are the most valuable knowledge transfer situations and artifacts.All three of them communicate the mission for the project.Understanding the mission makes the rest of the information flow easier to absorb.Service vision and concept are used to pitch the concept to project stakeholders and onboard new team members.The product backlog is a development team artifact that gives details for service implementation.Realising their role early in service exploration and service concepting improves the handover and the knowledge transfer to the implementation team.Improving the richness of the medium and increasing the collaboration improves the knowledge transfer.

Increase communication amount:
Creating more direct interaction between the parties also improves the knowledge transfer.Task is to first evaluate the necessity of communication and then plan it into the budget and contracts, so that information will be also communicated and not just produced at individual points of the project.The handover workshops need to be included in the schedule.The increased communication and shared analysis activity improves knowledge transfer [37,39,41,48,52].A guidance team or point of contact from earlier phases was the solution in some articles [37,76].Collaborative practices need to be planned to be part of the project.Some aspects of the future capability of knowledge transfer need to be implemented in the project plan from the start even if the incentives at that point are not aligned.

Circumvent the need for communication:
A third way is to go around the need for knowledge transfer by rethinking roles of the people.This can be done by prolonging the duration in which they are participating in the project so they themselves are the ones that can make or advise the later decisions.This can be done by including new task to the project participants and reducing division of labour [32] or by giving teams more autonomy to make their decisions as is the ethos of agile software development [32,47].Stability of the personnel in the project team decreases the need for knowledge transfer as the same people will be contributing to the later decisions.Roles that could remain are Product Owner [47], UCD Owner [41], Service Designer or User researcher [34,48].Increasing the customer role as direct source of information to the development team also reduces need for messengers but requires a change in organisational culture [34].If a project member is able to produce also the next output and it is easier to communicate, then the initial challenge of communication is circumvented.
4. Verifying transfer success: Designers should make sure that the concept in later stages is understood in implementation and the key vision based on the customer need is matched.One-off handovers of information should be avoided and a gradual transfer of knowledge favoured [34].The service design team could meet the development team in a short while after the initial Service Design Handover and then review their plans.The comments and the input with the accumulated knowledge from service design phase can find their target better when the ownership of the service concept is with the implementation team.Agile software development is driven by testing of increments.The method iteratively tests how well the market needs are met [41,48,61].That reduces the need to have a successful transfer of knowledge as the customer needs-and-wants can always be re-found from the customers directly.For organisational requirements and service means the information can also be iterated during the project and one-off transfers are not a deal breaker.

Limitations
According to the PRISMA statement [12], systematic literature reviews may have limitations due to publication or outcome reporting bias, evidence included in the review, and the review process itself.We address each of these limitations below.
Publication bias in literature reviews refers to a situation where the publications examined yield different results from the results of all the research that has been done in an area [77, p.1].This is a common bias in literature reviews, since no literature review can identify all relevant articles due to the high number of databases containing academic literature, with different options for search and in different data forms.In comparison, the Web of Science database gave a fraction of the results to SCOPUS.We chose SCOPUS as the database due to its coverage of relevant disciplines for this study and adequate means to search and organise the data.Also the chosen keywords introduce a publication bias, especially in cross-disciplinary reviews, where the relevant keywords may differ based on discipline.The chosen keywords in our cross-disciplinary study resulted from numerous trials of finding relevant literature.Since the original, limited set of keywords yielded few results, additional keywords were gradually added to expand the number of relevant works.The search phrase could still be expanded with additional keywords.The key in evaluating the effect of publication bias is to see if a larger set of publications would change the results.Future work should examine how new publications from other databases or with new keyword search might change the results.Outcome reporting bias refers to incomplete details of the review method in reporting.We mitigated this bias by following the PRISMA statement in reporting.
Evidence included in the review for each important outcome was addressed in this study by detailed reporting of the source articles for each result.This review did not, however, evaluate the validity of each method used in the analysed articles.For example we included one workshop call in the sample because it included some knowledge transfer challenges not mentioned in other publications.Finally, the review process itself was iterative, which PRISMA sees appropriate due to the nature of systematic reviews.This study did not use a systematic protocol for the iterative process of forming the final search phrase, which diminishes our chances to justify why each search term was included in or excluded from the phrase.The publication screening process in this study (Fig. 2) does follow the protocol of PRISMA statement, but the fact that only one author did the screening may have influenced the set of publications in the final corpus.
The readers should note a new analysis from 2022 of the limitations of the PRISMA statement [78], which may have had an influence on the results of this study.Other limitations include the delay from research to publication.The literature sample was collected early 2020 which is about 2 years before final publication of this article.

Conclusions
Service Design has entered companies to ensure a human-centred perspective from the beginning of new service development.While the service user's journey is in focus, service design studies also the needs of service providers and aims to create value for all involved stakeholders.The result of service design is a service concept, an idea of a service that may contain several subservices in the form of online services, face-toface services, and physical objects for different user groups among the stakeholders.Agile software development project can start only after a service concept passes a go-to-development gate.Several service design explorations may result in one service concept that adopts ideas from different exploration rounds, which means Agile UX practice may not receive the knowledge collected during fuzzy front end service design about users and service providers.We refer to this knowledge transfer as Service Design Handover.
The main objective of this systematic literature review was to understand information flow throughout the Service Creation Project with special attention on the Service Design Handover.The interplay between service design and UX design is a topical but understudied area of research, and this work is the first to examine the essential activity of knowledge transfer between the two practices.The findings provide both practical and scientific contributions.The contributions to practice include strategies for overcoming knowledge transfer challenges by improving communication quality, increasing communication amount, circumventing the need for communication, and verifying transfer success.The important boundary objects for knowledge transfer from the literature are service vision, product backlog, and concepts or prototypes.The main contributions to agile UX and knowledge transfer research are threefold.They include an extension to Eckert et al.'s [10] list of sources for knowledge transfer problems by four new items, an information flow framework for Service Creation Project (Fig. 6), and an initial framework for Service Design Handover to agile UX (Fig. 7).Our framework provides the first view to knowledge transfer throughout the whole process from service design to UX to implementation and to commercialisation.The uniqueness of the framework lies in the point of Service Design Handover, and in the boundary objects used there.These contributions pave the way for successful management of information flow throughout the Service Creation Project.
Future research should collect more empirical data of produced and transferred knowledge by studying real-life projects.Especially intriguing would be to find out how a service design team interacts with a different team of agile development and how knowledge produced in service design is utilised later.What practices improve knowledge transfer and what knowledge is utilised during the projects remain interesting research questions.The future research could examine the practical use of knowledge transfer strategies and their relative use in project contexts.Further analysis of work roles in current Service Creation Projects would clarify the needs for knowledge transfer.
Furthermore, for future research, the dynamics of information flow throughout a Service Creation Project need to be scrutinised with more empirical data.A longitudinal research approach can observe how teams transfer knowledge across project phases to other teams.Another interesting and less studied knowledge transfer context is between changing team members in a Service Creation Project team and their practices in knowledge handover (Table 1).

Fig. 3 .
Fig. 3. Overview of the process data analysis along horizontal project timeline.(For interpretation of the references to colour in this figure legend, the reader is referred to the web version of this article.)

Fig. 4 .
Fig. 4. Sample's scope in terms of Service Creation Project phases.

Fig. 6 .
Fig. 6.Framework of Service Creation Project information flow.

Fig. 7 .
Fig. 7. Initial framework for Service Design Handover to agile UX.

Table 1
Knowledge transfer context categorisation.