1. Introduction
As products become more complex and globalization increases, distributed product development (DPD) has become standard practice (Reference DührDühr, 2023; Reference Dumitrescu, Albers, Riedel, Stark and GausemeierDumitrescu et al., 2021; Reference GaulGaul, 2001). DPD teams are often intercultural, need to rely on digital collaboration tools, and work asynchronously (Reference Albers, Duehr, Zech and RappAlbers et al., 2022; Reference Kern and LindemannKern, 2016). While such settings offer diverse team members and creative potential, they also introduce communication issues, problems with information and communication technology (ICT) incomprehensibility, and reduced trust (Reference Bouncken, Brem and KrausBouncken et al., 2016; Reference IvanovIvanov, 2017; Reference Nicklas, Michalides, Gadzo and KochNicklas et al., 2023).
Creativity, creating novel and useful ideas (Reference SteinStein, 1953) is affected by intercultural dynamics and the distributed setting (Reference Brucks and LevavBrucks & Levav, 2022; Reference Gong, Nanjappan, Lee, Soomro and GeorgievGong et al., 2023; Reference Steinhauser and KittováSteinhauser & Kittová, 2018). Cultural diversity can improve creativity for developing products with high innovative potential, but can also cause misunderstandings, especially around hierarchy and communication norms (Reference Bastian, Kassem, Kempf and AlbersBastian, Kassem, et al., 2023; Reference Taras, Baack, Caprar, Jimenez and FroeseTaras et al., 2021). In such contexts, supporting creativity requires structured, culture-sensitive methods to push the teams to their full potential.
To address this issue, two methods have been developed: the Cultural Synergy Spectrum (CSS) Method and the Guideline. Both aim to support culture-sensitive creative problem-solving in distributed settings, but differ in structure and application depth (Reference Albers, Bastian and MartensAlbers et al., Submitted for Publication 2025; Reference Bastian, Cadavid Restrepo, Willerscheid and AlbersBastian, Cadavid Restrepo, et al., 2025). Despite their potential, it remains challenging to select the appropriate method since real-world industry teams are new to the methods (Reference Albers, Reiß, Bursac, Urbanec and LüdckeAlbers et al., 2014; Reference Braun and LindemannBraun & Lindemann, 2003; Reference Gericke, Eckert and StaceyGericke et al., 2017). The effort for understanding and applying a method in practice is high (Reference Albers, Braun, Heimicke, Richter, Henning and MoellerAlbers et al., 2011), which can lead to frustration and, therefore, low acceptance for methods (Reference Braun and LindemannBraun & Lindemann, 2003). Developers tend to rely on known methods, not open to trying new methods that are potentially better-suited (Reference Albers, Reiß, Bursac, Urbanec and LüdckeAlbers et al., 2014).
This contribution aims to develop a Decision Tool that enables fast and informed method selection between CSS and the Guideline. Based on the Design Research Methodology (DRM) by Reference Blessing and ChakrabartiBlessing and Chakrabarti (2009), the research can be allocated to four stages: literature-based analysis (RC), requirement derivation (DS I), tool development (PS), and initial validation in an academic context (DS II).
2. State of the research
2.1. Creativity in intercultural and distributed product development teams
DPD is characterized by spatial, temporal, and organizational separation (Reference Albers, Duehr, Zech and RappAlbers et al., 2022). Early definitions emphasized task allocation, but modern considerations emphasize collaboration across geographic boundaries (Reference Kern and LindemannKern, 2016). These distributed settings use ICT, and teams often collaborate synchronously and asynchronously. While offering access to various knowledge, different cultural perspectives, market proximity, and time-zone advantage, they also introduce new challenges in communication and coordination (Reference Bouncken, Brem and KrausBouncken et al., 2016; Reference IvanovIvanov, 2017; Reference Nicklas, Michalides, Gadzo and KochNicklas et al., 2023). Tool incompatibility and weak interpersonal bonds may reduce trust and performance (Reference DührDühr, 2023; Reference SchmalzlSchmalzl, 2004; Reference StöckertStöckert, 2011).
Intercultural team settings can enhance the creativity required to develop solutions with high innovative potential (Reference Bastian, Wasserbäch and AlbersBastian, Wasserbäch, & Albers, 2023; Reference GaulGaul, 2001; Reference IvanovIvanov, 2017). However, these settings can also lead to barriers such as language issues, misunderstandings, especially around hierarchy and communication norms (Reference Bastian, Kassem, Kempf and AlbersBastian, Kassem, et al., 2023; Reference Taras, Baack, Caprar, Jimenez and FroeseTaras et al., 2021).
Although technical tools for distributed work are well established, culture-sensitive methodological support remains limited. Intercultural competence is essential for harnessing the advantages of cultural diversity to enhance creativity and problem-solving (Reference Bastian, Wasserbäch and AlbersBastian, Wasserbäch, & Albers, 2023; Reference Jones, Chirino Chace and WrightJones et al., 2020). Reference HofstedeHofstede’s (1980) cultural dimensions help to describe and understand the differences: Power Distance, Individualism vs. Collectivism, Masculinity (now Motivation towards achievement and success (Hofstede Insights, 2024)), Uncertainty Avoidance, Long-Term Orientation, and Indulgence. For instance, German teams often feel comfortable with flat hierarchies and autonomy, while Indian teams often feel comfortable with stronger hierarchical and collective norms (Hofstede Insights, 2024). Such potential differences need to be acknowledged to prevent miscommunication.
Creativity can be understood as generating novel and useful ideas (Reference SteinStein, 1953). However, distributed settings make creative problem-solving challenging. Virtual environments can limit spontaneous interactions and hinder group ideation (Reference Brucks and LevavBrucks & Levav, 2022). The absence of non-verbal cues makes misunderstandings more frequent (Reference Brucks and LevavBrucks & Levav, 2022). Creativity in these settings is influenced by factors spanning team, organisation, individual, leadership, technology, time, and culture. Hofstede’s dimensions also relate to creativity. High Power Distance can suppress unconventional ideas due to hierarchical pressure (Reference Gong, Nanjappan, Lee, Soomro and GeorgievGong et al., 2023; Reference Nakata and SivakumarNakata & Sivakumar, 1996), while Long-Term Orientation correlates positively with creative problem-solving (Reference Steinhauser and KittováSteinhauser & Kittová, 2018). Other dimensions show mixed effects. Overall, supporting creativity in distributed teams requires an understanding of cultural influences and their impact on collaboration.
Creativity is based on the interaction of knowledge, skills, and motivation (Reference Kurtzberg and AmabileKurtzberg & Amabile, 2001). In technical contexts, creativity additionally requires experience and domain-specific expertise, which complement the general prerequisites of motivation and imagination relevant to creativity across all contexts (Reference Albers, Bastian, Düser, Völk and KüblerAlbers et al., 2025). Especially for complex creative problem-solving, like in the product development process, methods are required to assist the creative process (Reference Bullinger, Wörner, Prieto and BürgelBullinger et al., 1998; Reference Kyle´n and ShaniKyle´n & Shani, 2002). The following section explores such methodological support.
2.2. Support through the cultural synergy spectrum (CSS) method and the guideline
In response to the increasing complexity and globalization of product development, methods offer support by providing structure and reproducibility across intercultural and distributed teams (Reference Albers, Braun, Heimicke, Richter, Henning and MoellerAlbers et al., 2011; Reference Henning and MoellerHenning & Moeller, 2011). According to the Association of German Engineers in their guideline VDI 2221, a method is a systematic sequence of activities to achieve a defined objective (Verein Deutscher Ingenieure, 2019). Particularly in intercultural teams, methods help to stabilize collaboration, foster knowledge transfer, and enable creativity by assisting in overcoming communication barriers and unstructured ideation (Reference Bastian, Kassem, Kempf and AlbersBastian, Kassem, et al., 2023; Reference Blessing and ChakrabartiBlessing & Chakrabarti, 2009; Reference Hartstang and HeldHartstang & Held, 2024; Verein Deutscher Ingenieure, 2019). Although creativity is recognised as an essential competency in engineering, systematic approaches to support it in intercultural, distributed teams are not common. To address this gap, two methods have been developed to provide structured yet adjustable support for distributed teams for culture-sensitive problem-solving.
The Cultural Synergy Spectrum (CSS) Method (Reference Bastian, Cadavid Restrepo, Willerscheid and AlbersBastian, Cadavid Restrepo, et al., 2025) improves cultural understanding and assists with creative problem-solving. It comprises five phases: silent brainstorming using the Nominal Group Technique (Reference Delbecq and van de VenDelbecq & van de Ven, 1971), discussion of cultural backgrounds, theoretical input based on e.g. (Reference HofstedeHofstede, 1980), an embedded creativity session, and structured reflection. The method is implemented via a digital Miro board and supported by a moderator. The application takes approximately 95–120 minutes, excluding the creativity session. Initial validation across academic settings and an engineering team in China confirmed its effectiveness in enhancing intercultural awareness and creative outcomes (Reference Bastian, Cadavid Restrepo, Willerscheid and AlbersBastian, Cadavid Restrepo, et al., 2025; Reference Bastian, Deisenrieder and AlbersBastian, Deisenrieder, & Albers, 2025; Reference Bastian, Luo, Xia and AlbersBastian, Luo, et al., 2025).
The Guideline Method (Reference Albers, Bastian, Düser, Völk and KüblerAlbers et al., Submitted for Publication 2025) supports practical implementation in industrial environments while also improving cultural understanding and assisting with creative problem-solving. It consists of five phases: optional cultural onboarding, team alignment, creativity and idea selection, solution detailing, and optional reflection. The method is implemented using a PowerPoint click-through. It is designed for intuitive, independent use and typically takes around 100 minutes to complete. Further validation was conducted in a company setting (Reference Albers, Bastian and MartensAlbers et al., Submitted for Publication 2025).
While both methods aim to foster creativity in intercultural and distributed development teams, their application depends on the collaboration context and required depth of cultural integration. Table 1 shows the comparison of the two methods side by side.
Comparison of the CSS Method and the Guideline Method
The pure existence of methods does not automatically lead to their appropriate use in practice (Reference Gericke, Eckert and StaceyGericke et al., 2017). The difficulties with method selection in practice are explained in the following section to explain why the decision tool is needed to select the appropriate method, also for the Guideline and the CSS Method.
2.3. Difficulties with selecting appropriate methods
Despite the existence of many methods, selecting the appropriate one in different phases of the product development process remains challenging. One reason for this is that methods from academia are often presented with little detail and with an unclear scope, intended use, and expected outcomes (Reference Gericke, Eckert and StaceyGericke et al., 2017). This results in the effort for understanding and applying a method in practice being high (Reference Albers, Braun, Heimicke, Richter, Henning and MoellerAlbers et al., 2011). This can lead to frustration and, therefore, to low acceptance of methods (Reference Braun and LindemannBraun & Lindemann, 2003). Reference Albers, Reiß, Bursac, Urbanec and LüdckeAlbers et al. (2014) claim that developers tend to rely on known methods, not open to trying new, potentially better-suited methods. Enhancing method usability through well-designed support materials, e.g., templates, worksheets, digital tools, or visual summaries, is one step to facilitating practical application and promoting broader, more efficient method adoption (Reference Braun and LindemannBraun & Lindemann, 2003).
To comply with the requirements of practice, a tool needs to be developed to assist with an informed decision between the two introduced support methods for culture-sensitive problem solving in distributed teams.
3. Research methodology
The goal of this contribution is to develop a support that enables an easy and fast decision between the CSS Method and the Guideline, without prior method knowledge.
To achieve this goal, the following research question has been derived.
RQ:
How should a support system be designed to help users make informed, fast decisions between CSS and the Guideline, considering the specific situation and team context?
The research approach is based on the Design Research Methodology (DRM) by Reference Blessing and ChakrabartiBlessing and Chakrabarti (2009). Figure 1 shows the research approach, including the methods used, the stages of the approach, and the expected outcomes.
Research approach including methods, DRM stages, and results
Research Clarification (RC): Through a literature analysis, a research gap is identified, and the research goal and questions are derived. This establishes the conceptual basis.
Descriptive Study I (DS I): A deeper understanding of the problem is formed, providing a basis for requirements and possible solutions. For this, the identified needs from the literature were translated into requirements for the support and the System of Objectives. The elements of the SoO were then verified in an expert discussion.
Prescriptive Study (PS): Based on findings from the DS I, the development of the Decision Tool is performed. The SoO Elements were operationalized as a basis for the functionality of the support. The CSS and Guideline are compared to get the decision factors for the tool. The result is the first version of the Decision Tool ready for practical application and evaluation, which is already planned with industry experts.
Descriptive Study II (DS II): This stage focuses on evaluating the Decision Tool, differentiated in support performance, applicability, and success contribution. This was achieved through an initial validation of the Decision Tool in an academic setting, with method and product development experts.
Structured feedback from the expert round was collected, analysed, and improvements for the Decision Tool were derived.
4. Results
Based on findings from the literature review, initial elements of the System of Objectives (SoO) of the Decision Tool were derived to enable fast, situation-specific, and independent decision support. According to Reference LohmeyerLohmeyer (2013), a SoO comprises all explicit objectives, including their dependencies and boundary conditions. These initial objectives were developed by extracting the research gap, needs, and requirements from the literature and thematically sorting them within the DS I. Afterwards, these topics were further researched and translated into actionable targets. Due to their novelty, all objectives needed to be validated. This was achieved through two individual expert discussions. Two practitioners, experienced in intercultural and distributed product development from different corporate settings, evaluated the objectives in terms of relevance, clarity, and feasibility. Key criteria such as logic, clarity, and unambiguity were emphasized and reflected in the refined objectives. Following Reference Albers, Matros, Behrendt and JetzingerAlbers et al. (2015), the objectives count as validated, since all three aspects, objectification (structuring objectives), evaluation (assessment by practitioners), and verification (expert confirmation) were followed. Afterwards, the objectives were categorized following the evaluation types defined by Reference Blessing and ChakrabartiBlessing and Chakrabarti (2009). The final Decision Tool SoO includes seven Elements, shown in Table 2.
Elements of the decision tool SoO
DT = Decision Tool, SC = Success Evaluation, SP = Support Evaluation, AP = Application Evaluation
After the initial application of the Decision Tool, additional feedback was collected. As a result, a new objective (DT-SP3) was added, and another (DT-SP2) was extended to emphasize traceability and transparency.
This forms the basis for the development of the Decision Tool in the PS, where the Elements of the SoO are operationalized into concrete structural and functional elements.
Each SoO Element was translated into design features:
-
• A guided decision logic (DT-SC1)
-
• Multi-criteria selection reflecting relevant factors (DT-SP1)
-
• A transparent recommendation (DT-SP2)
-
• A method comparison (DT-SP3)
-
• A standalone PowerPoint interface with embedded instructions (DT-AP1, DT-AP2)
-
• A lean and fast process with not too many necessary decision questions (DT-AP3)
The method selection logic was derived from a structured comparison of the two support methods. Key differentiators were translated into decision criteria. Examples are cultural theory depth, moderator availability, creativity method integration, flexibility, time, format, and target team context. These criteria form the basis for the tool’s structure and enable context-sensitive recommendations. For example, if low experience or limited time is indicated, the Guideline is suggested; if deep cultural reflection is needed, the CSS is recommended.
As a structural basis, a decision tree (Figure 2) is developed showing the key differences and deciding questions in the identified logical order. Users begin by identifying their primary goal: either culture-sensitive problem solving or deep cultural understanding. Follow-up questions assess moderator availability and, if needed, the additional factors. These factors are weighted (team: x4, experience: x3, time: x2), and the support method with the highest calculated score is recommended. Depending on the answers, either the Guideline or the CSS Method is recommended, which is displayed through color coding in the decision tree (blue = Guideline, green = CSS Method). When applying the decision tool, the user is guided through the questions one by one and does not need to comprehend the decision tree all at once.
Decision tree for a situation- and team-specific recommendation of the CSS or the guideline
The tool is implemented as a PowerPoint-based click-through. This makes it accessible without specific software or method knowledge, and using a minimalistic and intuitive design. Users are guided through a short sequence of decision slides, each presenting a clear choice. No prior method knowledge is assumed, but users are expected to reflect on their specific team setting and project environment. The tool concludes with a slide stating the recommended method. The tool was internally verified for coherence and completeness by mapping it back to the SoO before being applied in a first validation round. Figure 3 shows an example slide using presentation mode in PowerPoint.
Example slide of the decision tool in presentation mode in the PowerPoint
5. Initial validation
An initial validation round was conducted to assess the functionality and user perception of the developed Decision Tool as part of the DSI. This evaluation aimed to explore the tool’s usability, applicability, and alignment with its intended support functions in a controlled expert setting.
The validation took place during a virtual research colloquium within the institute’s Design Methods and Design Management group, involving eight research associates with expertise in innovation management, design methods, knowledge management, and systems engineering. The participants were asked to independently test a PowerPoint-based version of the tool while adopting the perspective of a team lead in a distributed, intercultural product development setting. Structured feedback was collected on a color-coded Miro board, followed by a discussion to enable a thorough qualitative analysis.
The findings showed that the overall structure and interaction logic of the tool were positively received, while room for improvement was identified. A more straightforward introduction is required to improve transparency concerning the decision rationale and better traceability of the decision logic. Users expressed a desire for a decision tree overview, a possibility to compare the two underlying support methods, and more explicit explanations to feel more confident in using the Decision Tool independently.
Based on this feedback, improvements were implemented without altering the core decision logic. An expanded introduction, rationale for recommendations, the option to view a method comparison, improved terminology, and integration of a visual decision tree were included. Additionally, a new element, DT-SP3, was added to the SoO to reflect the need for a method comparison. At the same time, DT-SP2 was improved to emphasize transparency and traceability since it previously did not fully reflect the users’ needs.
In summary, the validation confirmed the Decision Tool’s usability and relevance while highlighting necessary enhancements to support the user´s understanding and trust better. These insights build the basis for the first iteration of improvements of the System of Objectives, ensuring a more robust and user-oriented tool for future application, as well as improvements on the Decision Tool itself.
6. Discussion
As outlined in Section 2.3, the selection of appropriate methods in product development is often hindered by insufficient methodological transparency, unclear scope of application, and high cognitive effort required for understanding and implementation. These challenges frequently result in low acceptance and reliance on familiar methods rather than using the better-suited alternatives. The development of the Decision Tool in this contribution directly addresses these issues by supporting an informed and structured choice between the guideline and the Cultural Synergy Spectrum (CSS) method. By providing clear decision criteria and guidance, the tool aims to ensure that the typical shortcomings associated with method selection, like ambiguity, high entry barriers, and lack of contextual fit, do not apply to the guideline and CSS. In this way, the Decision Tool serves as a mediating artifact that enhances method usability, reduces frustration, and increases the likelihood of appropriate and effective method adoption for these two methods in practice.
The expert validation confirmed the Decision Tool’s usability and relevance, while several limitations need to be acknowledged. The evaluation took place in an academic setting and did not involve participants who themselves currently face the need to decide between the two methods. This limits the applicability of the findings to broader or industry contexts. To ensure the design’s practical applicability, this study’s next step was already planned in an industry setting. Industry experts might have difficulties getting started with a theoretical tool and with the integration into daily work processes. The participants were method experts; therefore, their feedback was focused on usability rather than the daily-life integration of the tool.
Participants highlighted the tool’s clarity and ease of use, but also noted a lack of introductory context and explanation of the final recommendation. These insights led to refinements such as a more detailed introduction, a rationale for decisions, and a comparison of methods. The fast application versus informed decision-making was seen as the core design difficulty.
The researcher’s presence may have further influenced the user experience. To assess the tool further, broader testing in real-world teams that need to be supported concerning culture-sensitive problem solving, in an autonomous setting, is required.
7. Conclusion and outlook
The overall functionality and relevance of the Decision Tool’s concept and structure confirm the significant parts of the objectives in the design process. However, it also revealed limitations in assisting the user, transparency of the decision logic, and, with that, trust in the tool’s recommendations. With this feedback in mind, an updated version that enhances these elements was designed, while retaining the core selection logic. The major limitation was that the application was set in a research environment rather than in a real-world team setting, which needs to be addressed in the next step.
The updated Decision Tool requires validation through the application in the entire Systematic, along with the method it suggests.
Open access
