1. Introduction
Behavioural design is an important, emerging area of research and practice, which has demonstrated significant results in fields ranging from well-being and health (Voorheis et al. Reference Voorheis, Zhao, Kuluski, Pham, Scott, Sztur, Khanna, Ibrahim and Petch2022) to security and sustainability (Niedderer, Clune & Ludden Reference Niedderer, Clune and Ludden2017). These results are achieved via interventions that ethically shape positive behaviour change (Tromp & Hekkert Reference Tromp, Hekkert, Lim, Niedderer, Redström, Stolterman and Valtonen2014), developed through processes that combine aspects of design and behavioural science (Khadilkar & Cash Reference Khadilkar and Cash2020). However, while numerous process models have been proposed, current practice is replete with accounts of unexpected outcomes and tensions at the interface between design and behavioural concerns (Hagger & Weed Reference Hagger and Weed2019; Voorheis et al. Reference Voorheis, Zhao, Kuluski, Pham, Scott, Sztur, Khanna, Ibrahim and Petch2022; Bay Brix Nielsen, Cash & Daalhuizen Reference Bay Brix Nielsen, Cash and Daalhuizen2024). This points to an urgent need to better understand how interventions emerge from behavioural design processes.
In this context, behaviour change is realised through the development, delivery, maintenance and iteration of interventions, which embody behaviour change mechanisms (Michie, Atkins & West Reference Michie, Atkins and West2015; Schmidt Reference Schmidt2024). Here, embodiments are physical or digital artefacts that can range from individual interfaces, apps or products to whole services, systems or environments (Table 15.2 in Clune & Lockton Reference Clune, Lockton, Niedderer, Clune and Ludden2017). In contrast, behaviour change mechanisms (henceforth, we will use the terms ‘behaviour change mechanisms’ and ‘mechanisms’ interchangeably, depending on the context of use) are conceptual behavioural principles that can vary in their underlying premises, scope and complexity (e.g., see discussion on strategies like eco-feedback or behavioural steering in Lilley Reference Lilley2009; theory informed behaviour change techniques in Michie et al. Reference Michie, Richardson, Johnston, Abraham, Francis, Hardeman, Eccles, Cane and Wood2013; or use of dual system theory for behaviour change in Thaler & Sunstein Reference Thaler and Sunstein2008). The relationship between these two constructs is complex because embodiments can support multiple mechanisms and mechanisms can be translated into multiple embodiments. Therefore, their combination forms a central tenet of behavioural design processes (Cash et al. Reference Cash, Valles Gamundi, Echstrom and Daalhuizen2022). Yet this relationship also appears to be at the root of many of the challenges identified in current research and practice (Voorheis et al. Reference Voorheis, Zhao, Kuluski, Pham, Scott, Sztur, Khanna, Ibrahim and Petch2022; Bay Brix Nielsen et al. Reference Bay Brix Nielsen, Cash and Daalhuizen2024). This is despite recent advances in, for example, mapping of mechanisms and embodiments as part of Behaviour Change Intervention Ontology project (Michie et al. Reference Michie, Thomas, Mac Aonghusa, West, Johnston, Kelly, Shawe-Taylor, Hastings, Bonin and O’Mara-Eves2020). Thus, it remains unclear how the relationship between embodiments and mechanisms should be understood or fostered during the behavioural design process itself. Hence, we formulate the Research Question (RQ): How do behaviour change mechanisms and their embodiments emerge and relate to each other during behavioural design processes?
To answer this question, we analyse processes from 11 real-world projects through a co-evolutionary lens. Co-evolution provides a basic framework for capturing reciprocal influence between elements in a design process (Maher, Poon & Boulanger Reference Maher, Poon, Boulanger, Gero and Sudweeks1996; Crilly Reference Crilly2021). Therefore, we take the basic idea of co-evolutionary, reciprocal influence as a starting point for examining the interaction between behaviour change mechanisms and embodiments. Further, while co-evolution is generally associated with the thinking of designers (Smulders, Dorst & Reyman Reference Smulders, Dorst, Reyman, Norell Bergendahl, Grimheden, Leifer, Skogstad and Lindemann2009), various authors have demonstrated its utility at a range of scales (Maher & Tang Reference Maher and Tang2003; Wiltschnig, Christensen & Ball Reference Wiltschnig, Christensen and Ball2013; Crilly & Moroşanu Firth Reference Crilly and Moroşanu Firth2019). Hence, we use it to map task-to-task scale interactions across whole behavioural design processes. These two points of departure (reciprocal influence at the whole process scale) make co-evolution ideal for exploring our RQ and a foundation for theory development in this area.
2. Conceptual background
Before we can answer our RQ, it is necessary to understand what distinguishes behavioural design processes and how a co-evolutionary lens might be applied in this context.
2.1. Distinguishing behavioural design
Behavioural design can be distinguished from other design approaches by two main characteristics that emphasise the importance of its process. First, behavioural design processes are explicitly formulated with respect to behaviour change as the thing being designed (Khadilkar & Cash Reference Khadilkar and Cash2020). Here, designers aim to realise positive new situations by scaffolding the reduction, change in or adoption of new behaviours via intermediary interventions (e.g., creating an app. to increase exercise behaviour to minimise the negative effects of a sedentary lifestyle). There is no fixed, intervention-related framing, start or end point. For example, to increase exercise behaviour, the mechanism of ‘provide feedback’ might be embodied in a pedometer, an app., a training programme or a mix of all three. Rather, development flexibly draws together behaviour change mechanisms and their embodiments to support the realisation of the new situation (Michie et al. Reference Michie, Atkins and West2015; Bay Brix Nielsen et al. Reference Bay Brix Nielsen, Cash and Daalhuizen2024). Thus, while behavioural design projects can posteriori look like, for example, user experience or product design due to the embodiments used, this is not the case a priori or during the process.
Second, behavioural design processes bring two core values additional to typical design approaches: (i) grounding in behavioural theory and (ii) explicability. Here, designers integrate behavioural theory (of various sorts) and understanding of design. This creates a situation where it is insufficient to deliver an intervention that works within a general frame, as in most design approaches (e.g., approaches like human-centred design or product design do not demand use of specific theory as a basis for ideation; Roozenburg & Eekels Reference Roozenburg and Eekels1995; Giacomin Reference Giacomin2014; Human Centered Design Toolkit 2015). Behavioural designers must provide an explanation – grounded in theoretical and empirical insights – for the mechanisms and embodiments that make up interventions as well as how these have emerged from the design process (Taylor et al. Reference Taylor, Bury, Campling, Carter, Garfied, Newbould and Rennie2006; Michie & West Reference Michie and West2013). This then needs to be anchored by evidence for intervention effectiveness (at least in the short term) (Nielsen, Cash & Daalhuizen Reference Nielsen, Cash, Daalhuizen, Marjanović, Štorga, Škec, Bojčetić and Pavković2018; Cash et al. Reference Cash, Khadilkar, Jensen, Dusterdich and Mugge2020).
Bringing these characteristics together, it becomes clear that while all types of design deal with the relationship between behaviour and artefact in some form, behavioural design reflects a distinct paradigm in the treatment of this relationship in its design process (Schmidt Reference Schmidt, Boess, Cheung and Cain2020).
2.2. Behavioural design processes
Behavioural design, as characterised in Section 2.1, faces the fundamental challenge that while mechanisms draw on behavioural theory, embodiments can be anything from user interfaces to media campaigns or policy, as well as combinations of these, and might also change over time (refer to Table 15.2 in Clune & Lockton Reference Clune, Lockton, Niedderer, Clune and Ludden2017). Further, as noted in the introduction, the relationship between these two constructs is complex and interdependent. For example, multiple authors identify the prevalence of unexpected effects and uncertainty around the precise evidence for mechanisms and embodiments (Hagger et al. Reference Hagger, Moyers, McAnally and McKinley2020; Cao, Cao & Sutherland Reference Cao, Cao and Sutherland2025) as well as the need for iteration in context (Baxter et al. Reference Baxter, Mandeno, Aunger and Brial2025). Hence, there is a need to manage both aspects and their interaction during behavioural design processes.
Yet multiple authors highlight the difficulties of effectively integrating the approaches needed to deal with both behavioural science-based mechanisms and design-based embodiments, due to differences in logic and thinking about iteration (Aunger & Curtis Reference Aunger and Curtis2016; Schmidt Reference Schmidt, Boess, Cheung and Cain2020; Cash et al. Reference Cash, Valles Gamundi, Echstrom and Daalhuizen2022; Voorheis et al. Reference Voorheis, Zhao, Kuluski, Pham, Scott, Sztur, Khanna, Ibrahim and Petch2022). Bay Brix Nielsen et al. (Reference Bay Brix Nielsen, Cash and Daalhuizen2024) explain how mechanism-focused approaches are typically characterised by deductive/inductive logic, where processes are more linear. In contrast, embodiments-focused approaches typically emphasise abductive logic where processes are more iterative. Current, dominant process models, such as those from the OECD (2019) and Michie et al. (Reference Michie, Atkins and West2015), respond to this through early concretisation of the problem definition as a basis for fitting behaviour change mechanisms, which can then be used to determine embodiments in a constrained design step (Lockton, Harrison & Stanton Reference Lockton, Harrison and Stanton2010; Bohlen et al. Reference Bohlen, Michie, de Bruin, Rothman, Kelly, Groarke, Carey, Hale and Johnston2020). More generally, almost all current process models recognise some form of iteration. Yet how it is treated varies significantly, without a clear grounding in process theory. For example, iteration ranges from within stage, as in Aunger & Curtis (Reference Aunger and Curtis2016), to between stages, as in Fogg (Reference Fogg2009, p. 6), to between whole projects, as suggested by the OECD (2019) and Michie et al. (Reference Michie, Atkins and West2015). Hence, it remains unclear how the link between behaviour changes mechanisms, primarily rooted in behavioural science, and embodiments, primarily rooted in design, should be understood and managed. This points to an urgent need for focused investigation and theory development around the reciprocal influence between mechanisms and embodiments in behavioural design.
2.3. Co-evolution as a process lens
The dominant lens for describing reciprocal influence between two (or more) elements of a design process is co-evolution (Smulders et al. Reference Smulders, Dorst, Reyman, Norell Bergendahl, Grimheden, Leifer, Skogstad and Lindemann2009; Dorst Reference Dorst2019; Crilly Reference Crilly2021). Co-evolution has been used to examine interactions between an array of different process-related concepts, including idea generation (Dorst & Cross Reference Dorst and Cross2001); analysis, synthesis and evaluation activities (Martinec et al. Reference Martinec, Škec, Perišić and Štorga2020); uncertainty perception (Cash, Gonçalves & Dorst Reference Cash, Gonçalves and Dorst2023); and others (Wiltschnig et al. Reference Wiltschnig, Christensen and Ball2013). Further, while co-evolution typically refers to the interaction between problem space and solution space, Maher & Tang (Reference Maher and Tang2003) highlight how it can accommodate problem and solution spaces within ‘two or more’ conceptually different spaces, and Crilly & Moroşanu Firth (Reference Crilly and Moroşanu Firth2019) specifically extend it to business-related spaces. Hence, co-evolution provides a flexible conceptual basis for examining reciprocal influence between different elements of the design process.
Co-evolution has also proven a useful lens for characterising design processes across a range of scales and contexts. For example, Martinec et al. (Reference Martinec, Škec, Perišić and Štorga2020) used protocol analysis of specific design sessions in an experimental context, while Wiltschnig et al. (Reference Wiltschnig, Christensen and Ball2013) also used protocol analysis, but from weekly meetings distributed over a duration of 5 months as a team developed a new product feature. At a larger scale again, Crilly & Moroşanu Firth (Reference Crilly and Moroşanu Firth2019) compare co-evolution across whole projects using project milestones, documentation and interviews with the lead designer. Finally, Dorst (Reference Dorst2019) compared co-evolution across multiple projects using secondary data and overall descriptions of problem-solution transitions. As such, the investigation of co-evolution has been operationalised in terms ranging from moment-by-moment shifts in individual attention in a specific design session to post-hoc characterisation of shifts in task-to-task focus during a team’s design project. While this diversity of application can lead to ambiguity in what exactly is being captured by co-evolutionary descriptions (Cash et al. Reference Cash, Gonçalves and Dorst2023), it can also lend a degree of continuity to the conceptualisation of a basic aspect of design, that is, reciprocal influence between elements in a design process (Crilly Reference Crilly2021). Hence, co-evolution offers the potential for connecting insights garnered from behavioural design processes with extant research on design processes more generally.
2.4. Conceptual framework
Based on these theoretical foundations, we use co-evolution to explore how behaviour change mechanisms and their embodiments emerge and relate to each other during behavioural design processes. To do this, we decompose the overall design space as illustrated in Figure 1. Here, we operationalise the team-level focus of each task with respect to behaviour, that is, mechanisms or embodiments spaces, each of which is further sub-divided into problem or solution spaces, following a similar logic to Crilly & Moroşanu Firth (Reference Crilly and Moroşanu Firth2019). Task-by-task progression within or across the mechanisms/embodiments spaces in Figure 1 can then be mapped across the behavioural design process. Here, the focus of a task is represented by a dot and the subsequent progression of the process to the next task by an arrow. To differentiate progression within mechanisms and embodiments spaces versus between these spaces, we refer to progression within a mechanisms or embodiments space as a ‘move’ (depicted by a straight arrow) and progression between mechanisms or embodiments spaces as a ‘jump’ (depicted by a curved arrow). This provides a basis for conceptualising progression based on the direct influence of one task on the next, following typical co-evolutionary logic (Dorst & Cross Reference Dorst and Cross2001). Further, it also provides a framework for distinguishing iteration in comparison to current literature (see Section 2.2). For example, the dominant logic of Michie et al.’s (Reference Michie, Atkins and West2015) process is illustrated in Figure 1, where iteration is either implicitly treated within each space or at the level of the whole project. In Figure 1 and all subsequent process figures, moves and jumps progress over time and are ‘stacked’ vertically to aid readability. Hence, sequential arrows always depict progression over time, regardless of the arrow’s direction (left to right or right to left).
Basic conceptualisation of the behavioural design space through a co-evolutionary lens.
3. Methodology
Given our RQ, we adopt a theory-building, multi-case study approach for three main reasons. First, co-evolutionary development in behavioural design has not been previously explored or theorised, creating a need for in-depth insight in this context (Colquitt & Zapata-Phelan Reference Colquitt and Zapata-Phelan2007; Eisenhardt & Graebner Reference Eisenhardt and Graebner2007; Yin Reference Yin2014). Second, behavioural design produces a range of interventions across a variety of application domains, and hence a multi-case approach is needed to distil underlying, cross-cutting insights (Yin Reference Yin2014, p. 4). Third, case studies have formed the basis for prior work on co-evolutionary processes at the whole process scale (Crilly & Moroşanu Firth Reference Crilly and Moroşanu Firth2019), providing a reference point for our investigation. In this approach, we focus on developing analytical generalisability, that is, abstraction of theoretical insights from the specific case data (Robson & McCartan Reference Robson and McCartan2011), and follow practices for qualitative case research (Gibbert, Ruigrok & Wicki Reference Gibbert, Ruigrok and Wicki2008). This methodology is well suited to interdisciplinary challenges of design science where methods, tools and perspectives need to be aligned (Papalambros Reference Papalambros2015).
3.1. Case selection
Cases were considered at the project level and were selected based on two theoretical and one practical criteria to ensure methodological rigour (Yin Reference Yin2014). First, the project must have an active or overt aim of changing behaviour and be explicitly recognised as behavioural design by the participants (Tromp, Hekkert & Verbeek Reference Tromp, Hekkert and Verbeek2011; Niedderer et al. Reference Niedderer, Clune and Ludden2017). This was based on the features of behavioural design processes and their intended outcomes, irrespective of the specific interventions delivered at project completion (see Section 2.1). Second, the project should cover a complete expert-led design process, that is, from the overall aim to testing (Cash, Hartlev & Durazo Reference Cash, Hartlev and Durazo2017). This was based on our scale of investigation and allowed for a maturation of the relationship between behaviour change mechanisms and embodiments (see Section 2.4). Third, there should be good data access to critical decision-makers, such as project managers, designers and behavioural analysts, as well as supporting secondary data sufficient to establish and then triangulate (Yin Reference Yin2014) team-level progression in task-to-task focus across a whole design process.
To understand expert practice, all cases were drawn from successful behavioural design consultancies with more than 5 years of experience in Denmark. These consultancies specialised in behavioural design and constituted leaders in their field nationally, while Denmark is generally considered an international leader in this area. As such, the sample of companies can be considered to provide insight into leading, expert practice within a mature context.
The consultancies were requested to provide a list of possible projects that they considered behavioural design, along with a brief description of the process, aims and outcomes. This allowed for a nested approach to case selection to build external validity (Gibbert et al. Reference Gibbert, Ruigrok and Wicki2008). We selected 11 project cases from the four companies operating during 2018–2020 when the interviews were conducted, hence allowing for concurrent and retrospective data collection across our sample. The selected cases reflected varied behavioural problems (Michie et al. Reference Michie, Atkins and West2015) as they spread across application domains, commercial focus and company context. Further, interventions ranged from systems of products to individual products or other embodiments, and in application areas ranging from health to safety. In all 11 cases, designers dealt with multiple behaviours. This diversity helped us in extracting cross-cutting insights and hence supported our analytical generalisation approach (Robson & McCartan Reference Robson and McCartan2011). Overall, four projects focused on the social context dealing with behaviours in public places, like airports; two focussed on industrial contexts that dealt with behaviours in private professional organisations; two focussed on personal contexts relating to behaviours in private settings, and three cases had multiple contexts. Finally, 10 out of 11 cases were initiated with at least one evident problematic behaviour or target behaviour linked to the context in which the behaviour was happening. An overview of cases is provided in Table 1.
Overview of cases
Table 1. Long description
The table is organized into five columns: Case, Project type, Team/participants, Domain/context, and Deliverables and evaluation.
Company 1: Consultancy in business management and design.
- Case 1: Design of online expense system. Team includes project lead, designer, and I T engineer. Context is industrial. Deliverables include online forms and A/B testing.
- Case 2: Design of online job-logging system. Team includes project lead B and designer A. Context is social. Deliverables include online forms and A/B testing.
Company 2: Consultancy in technology development.
- Case 3: Medication system design. Team includes project lead/designer, designer, and I T engineers 1 and 2. Context is social (old age homes). Deliverables include an intelligent pillbox and monitoring system.
- Case 4: Children saving system design. Team includes project lead/designer, designer, and I T engineer. Context is personal. Deliverables include an intelligent piggybank.
- Case 5: Patient training system design. Team includes manager, project lead/designer, designer C, and I T engineer. Context is social. Deliverables include a belt with sensors.
Company 3: Consultancy specializing in behavior change.
- Case 6: Online safety communications. Team includes project manager/designer, survey designer, and research assistant. Context is mixed. Deliverables include informational materials and survey data.
- Case 7: Home C O sub 2 management. Team includes project manager/designer and designer. Context is personal. Deliverables include C O sub 2 measurement service and lamps.
- Case 8: Home safety system. Team includes project manager/designer, designer, product engineer, and research assistant. Context is mixed. Deliverables include a safety kit.
- Case 9: Train station wayfinding. Team includes project lead/designer, designer, survey designer, and research assistant. Context is social. Deliverables include physical signage.
Company 4: Consultancy with a specialized behavior change division.
- Case 10: Safety monitoring system. Team includes project lead/designer, designer, and 3 research assistants. Context is industrial. Deliverables include training programs and work protocols.
- Case 11: Digital I T system. Team includes project lead/designer, change lead, and 3 in co-team. Context is mixed. Deliverables include a behavior change process model.
3.2. Data collection
Within each case, we followed Crilly & Moroşanu Firth (Reference Crilly and Moroşanu Firth2019) in drawing data from multiple, concurrent and retrospective sources, including project milestones, documentation and interviews with the main designers in each project. This allowed for data saturation and triangulation both within and across cases (Yin Reference Yin2014, pp. 56–61). Primary data were collected in the form of 24 semi-structured interviews and observations in the case companies.
A semi-structured interview guide based on our conceptual framework was used to conduct the interviews and ensure the internal validity of our collected data (Gibbert et al. Reference Gibbert, Ruigrok and Wicki2008). Interview questions dealt with three main topics: (i) the behaviour being addressed, (ii) the outcomes of the design process and (iii) the design process itself. The questions related to each topic are outlined in Table 2. Follow-up questions and elaboration were used to ensure the elements of our conceptual framework were fully explored across the whole design process in each case.
Sample interview questions
Table 2. Long description
The table consists of two columns: Topic and Example questions.
Row 1: Topic is Behaviour being addressed. Questions include: Can you talk me through the behaviour you worked on in this project? What were its characteristics and range of behaviour? How general was the behaviour and demographic? What were the causes of this behaviour? Why do you think users behave in this way? How did you arrive at the target behaviour?
Row 2: Topic is Outcomes. Questions include: How did the intervention get the person from current behaviour to target behaviour? What other interventions did you consider during development? How did you evaluate the success of the project?
Row 3: Topic is Design process. Questions include: How did these considerations inform your project formulation? Did you make a brief, if so what did it include? Can you sketch a project timeline and talk me through the process from idea to final solution? Do you differentiate projects with respect to the target behaviour? If so, how? How did you set up the project and team organisation? How did you keep track of the project? How did you evaluate your ideas during the design process? Can you talk me through the major iterations in the project process?
The first author conducted face-to-face interviews with the key decision-makers in each project team. All the interviews were audio recorded with the prior consent of the participants. The interviews lasted for approximately 1 hour. Each case had multiple interviewees, with the aim of reaching saturation (Guest, Bunce & Johnson Reference Guest, Bunce and Johnson2006), that is, further questioning did not reveal any new information. Due to the small size of the involved teams (typically only two or three designers/analysts), in most cases, the whole team was interviewed. After explaining the involved behaviours and resultant interventions, each interviewee was asked to elaborate on the design process using process diagrams and sketches. During the interviews, these process diagrams worked as a reference to discuss the process-related aspects and link this back to the mechanisms and embodiments. Secondary data were collected via internal reports, project briefs, presentation decks, final project reports, blogs and so forth. This allowed us to map the progression across spaces (Figure 1) during the whole process in each case based on triangulation of concurrent and retrospective data from multiple sources.
3.3. Data analysis
Transcriptions of the audio recordings were used as the basis for thematic analysis, supplemented by the secondary data. First, open coding was used to understand the overall behavioural design process undertaken in each case. This covered both the practical details and the conceptual aspects, such as the nature of the behavioural design problem and reasoning of the design team (Neuman Reference Neuman2011, p. 511). This was also used to check that the processes aligned with the criteria for behavioural design, irrespective of the interventions being developed, as discussed in Section 2.1. At this point, initial findings were presented back to the design lead for each case in the form of verbal data summaries and initial process sketches. This served to confirm our basic interpretation of each case, the accuracy of process characterisation, and the overall assessment of the project and its outcomes. As we had worked closely with all companies before data collection, we were well positioned to interpret the interview data; hence, no major challenges emerged at this point. This helped to increase the validity of our basic findings as a foundation for theory development (Miles, Huberman & Saldaña Reference Miles, Huberman and Saldaña2014, ch. 11).
Second, with the veracity of our characterisations validated, we then conducted iterative axial coding, where cases were contrasted to develop abstract, cross-cutting themes (Neuman Reference Neuman2011, pp. 512–513). The authors ensured conceptual validity by moving between the data and the literature in an iterative process (Miles et al. Reference Miles, Huberman and Saldaña2014, ch. 4). We then used temporal bracketing to divide the continuous overview of the cases into multiple discrete periods so that we could trace progression within and between spaces (Langley Reference Langley1999). For each case, we developed process maps to help visualise progression and form a basis for refining our insights in process terms. Here, we identified co-evolutionary influences by identifying specific descriptions of problems and solutions and their progression in the timeline using quotes as well as secondary documents and the process maps, for example, the Designer in Case 1 stated that: ‘it was not initiated from a behavioural perspective’. The description of the problems and solutions was sufficient to assign them to either to mechanisms space or to embodiments space, for example, the Designer in Case 1 stated that: ‘then we used some UX …when we made the new [intervention], which was a web-based form’. However, we also identified when and how mechanisms influenced embodiments and vice versa, for example, the Lead Designer in Case 7 stated that: ‘we ended up with these four [interventions], “information, [and] habit” from the pilot; and then “nudging and feedback”, because that was feasible’. This resulted in the identification of co-evolutionary progressions within and between mechanisms and embodiments spaces, following the logic outlined in Figure 1.
Finally, we compared our findings with prior co-evolutionary studies and theorising to draw out the distinctive nuances of the themes emerging from our data (Langley Reference Langley1999). We aimed to extract theoretically relevant patterns from across cases, and hence mitigate the impact of variation and possible confounds associated with the individual cases themselves. Specifically, this analysis step allowed us to check for and eliminate the possibility of confounding process patterns at the company or project level linked to project teams or constraints. Here, all companies showed variations in the level of temporal and budgetary constraint, with no clear patterns emerging in relation to our extracted themes. Hence, while further research is needed to examine contextual interactions with project processes and outcomes, for the purposes of this research, they were not analytically significant. This process concluded when we reach analytical saturation, that is, the iterative comparison of cases did not reveal new co-evolutionary patterns and results served only to further detail first-order findings associated with already established themes (Miles et al. Reference Miles, Huberman and Saldaña2014, ch. 4).
4. Findings
Considering our cases at the most basic level, we found that all cases followed typical behavioural design steps in identifying a problematic behaviour and then working towards its resolution based on a combination of empirical and theoretical insights. A typical set of steps was: (i) identification and definition of the initial problematic behaviour or need; (ii) analysis and mapping of the problematic behaviour; (iii) development of a problem/target behaviour specification; (iv) identification of behaviour change mechanisms and proposal of embodiments; (v) iterative testing and development of prototype embodiments to identify barriers and effects; and (vi) communication and launch. This sequence of steps was reflected in our concurrent observations and discussions with design teams, as well as in secondary data and retrospective process sketches developed in the interviews. For example, the Project Manager and Designer for Case 7 stated: ‘it consists of every part of the behavioural design process… it has desk research… expert interview. It has investigations into people’s perception of the problem. It has intervention design, test of intervention design, second round of intervention design based on the pilot of the first round experiences, and then a larger randomized control trial’. Similarly, the Lead Designer for Case 1 stated that: ‘we did the project proposal [where] we had already laid out the method for the research… then we did interviews. I also did a behavioural assessment of all the information and a process mapping’. Further, secondary data revealed how two of the case companies employed an explicit ‘process template’ across projects, and presentation slide decks used in multiple cases included overviews of process steps as well as references to behavioural and behavioural design research.
While not revealing new insights, these data provide important confirmation of our research framing. Specifically, they confirm the behavioural design nature of our cases (Section 2.1), following identified precepts of behavioural design (Michie et al. Reference Michie, Atkins and West2015; Khadilkar & Cash Reference Khadilkar and Cash2020; Schmidt Reference Schmidt, Boess, Cheung and Cain2020), as well as process steps and methods (Aunger & Curtis Reference Aunger and Curtis2016; Cash et al. Reference Cash, Hartlev and Durazo2017; Voorheis et al. Reference Voorheis, Zhao, Kuluski, Pham, Scott, Sztur, Khanna, Ibrahim and Petch2022). Further, all cases displayed two-way interactions between behaviour change mechanisms and their embodiments. Thus, these data provide a solid basis for further theory development in the behavioural design context.
4.1. Non-linear development of behaviour change mechanisms and their embodiments
The first theme to emerge was iteration between design of the behaviour change mechanisms and their associated embodiments.
Unsurprisingly, the mechanisms formed the primary focus of the design work and were associated with steps dealing with the specifics of the behavioural problem and its cognitive or behavioural solution. This is illustrated by Lead Designer in Case 11: ‘everything that we do for designing interventions has to be with an understanding of, how this one person is functioning? what drives this person’s behaviour? what’s this person’s logic?’. Steps dealing with the behavioural problem were concerned with understanding and mapping the cognitive and behavioural mechanisms involved in the behaviour. For example, the Project Manager and Designer in Case 7 elaborated the behavioural nature of the design problem as: ‘we identified eight themes for why this behaviour [the target behaviour] wasn’t taking place. One is that, people don’t perceive it to be a problem, [the cause of the problem] is still abstract’. Similarly, steps dealing with behavioural solutions focused on the identification and integration of generic cognitive or behaviour change mechanisms, such as feedback, priming or reducing cognitive load. The Lead Designer in Case 1 explained a possible behavioural solution as: ‘Making the user think as little as possible, not make them understand rationally what you have to do [but] just intuitively see what you have to search’. In all cases, multiple mechanisms were proposed and combined in the final solutions.
However, the design of the mechanisms did not progress linearly, to then be ‘frozen’ and used as a basis for embodiment selection, as is typically suggested in current, behavioural design process models (Section 2.2). Rather, we found that much of the design of the mechanisms was guided by the design of the embodiments. This is illustrated by the Lead Designer in Case 3: ‘So you took the old behaviour into the new digital product, we also proposed that you could [achieve a desired behaviour] by [an additional feature on new product]’. Here, the design team responded to insights directly associated with the embodiment and associated implications for implementation of the solutions (e.g., through products, systems and other means). This included identification of additional mechanisms as well as fine-tuning, modification or removal of initial mechanisms. Hence, the designers were prompted to revisit the mechanisms space in relation to the embodiments space. The Project Manager and Designer in Case 7 stated: ‘This was a habit-forming intervention based on the psychology around implementation intentions. Participants were sent an information leaflet on the intervention and then they were given a sticker and a small schedule that they had to fill out’. In this case, the designer was not only thinking about the initial intervention and associated behaviour change but also ongoing continuation of behaviour via habit formation. Overall, there was a consistent pattern where the design team worked through two distinct areas within the mechanisms space: one related to the initial mechanisms and the other related to the mechanisms revealed by or made necessary for the success of the embodiments, that is, embodiments-related mechanisms. In the earlier example of a pedometer, it must be accepted/purchased, properly used/charged/upgraded and carefully discarded. These are linked with the characteristics of the embodiment and introduce embodiments-related mechanisms. These are influenced by the functions, aesthetics, colour, finish and ergonomics of the embodiment, as well as aspects of behavioural theory. For example, technology acceptance theory is associated with acceptance of technology and is based on the ‘Theory of planned behaviour’ (Ajzen Reference Ajzen2005), while diffusion theory introduces multiple factors, such as perceived criticality of need or complexity (Rogers Reference Rogers1983), all of which are behavioural in nature.
The interaction between the spaces is further reflected by secondary case data, with multiple cases generating three distinct sets of specifications related to: (i) the initial mechanisms via a behavioural specification, (ii) the embodiments via a technical specification of the intervention and (iii) the embodiments-related mechanisms via a revised overall specification. This led to significant non-linearity in the observed cases, with jumps between the embodiments space and the mechanisms space in both directions; with this latter space having a clear distinction between the initial mechanisms and the embodiments-related mechanisms. For example, the Project Manager and Designer in Case 7 reflected on how they had to update the mechanisms in light of embodiment considerations: ‘[in] the [intervention] we have an SMS component that people said, it was really good idea, but nobody actually used that system. So we found out that we needed to do something else with it’. This is exemplified by the process in Case 7, as illustrated in Figure 2b. Here, the mechanisms are established, an initial embodiment is proposed, the mechanisms are revisited considering this embodiment proposal and then a final embodiment is delivered. Similarly, Case 1 began with an existing embodiment, prompting an immediate shift in focus to the relevant mechanisms. This triggered the development of a new embodiment, which, in turn, prompted an iteration of the mechanisms, followed by finalisation of the embodiment, as shown in Figure 2a.
Distinction between mechanism and embodiment-focused tasks in (a) Case 1 and (b) Case 7.
While prior work has identified the need for both mechanism and embodiment development, the dominant framing in the literature is linear and mechanisms focused (e.g., the eight-stage process by Michie et al. Reference Michie, Atkins and West2015; see Section 2.2). Current process models suggest developing and ‘freezing’ the mechanisms before embodiment selection and/or development (Michie et al. Reference Michie, Atkins and West2015). Here, the need for iteration is sometimes included within stages, but not typically across stages. Hence, current process descriptions either exclude or limit the potential for jumps between the mechanisms and embodiments spaces, depicting linearity. Yet our results suggest that the expert process breaks this linearity. Specifically, embodiment design provides inputs that result in the addition and/or modification of the initial mechanisms, leading to multiple additional jumps from mechanisms to embodiments to embodiments-related mechanisms and so on. Critically, it was these jumps that allowed the observed teams to deliver solutions that leveraged both spaces, and incorporated both design and behavioural science insights. However, while this emphasises the need to reconsider typical assumptions about the linearity of behavioural design processes, it falls short of explaining how non-linearity should be understood in this context.
4.2. Co-evolution of behaviour change mechanisms and their embodiments
To understand the observed non-linearity outlined in the prior section, our second theme elucidates a complex set of co-evolutionary relationships underpinning the behavioural design process. Here, we found that our observed cases involved three interconnected yet distinct, co-evolutionary processes: (i) co-evolution within the mechanisms space, (ii) co-evolution within the embodiments space and (iii) co-evolution at a higher level between spaces.
Comparing processes across the cases revealed that there was cross-cutting interaction based on co-evolutionary developments in mechanisms space triggering development in the embodiments-related mechanisms space and vice versa. We denote this in Figure 3 by differentiating the development of the embodiment in relation to the initial mechanisms from the start of the project and the embodiments-related mechanisms derived in response to initial embodiment prototypes or test implementations. The Project Manager and Lead Designer in Case 7 highlighted this bridge between the mechanisms and embodiments spaces: ‘we had a behavioural barrier mapping [mechanisms problem]… and then that’s what led to the intervention design [embodiment solution], and in the intervention design, it’s worth saying, there’s always a pragmatic consideration when you create interventions [embodiment problem]’ (see Figure 3b). Conversely, the Lead Designer in Case 3 highlighted how development of the embodiments triggered new understanding of mechanisms: ‘asking the people that are actually supposed to use it [embodiment concept] in practice [embodiment solution] actually made us realize that this will never work [in terms of behaviour; mechanisms problem]’. Similarly, the introduction of embodiments also changes the original behaviour, which impacts the mechanisms space; as explained by the Lead Designer in Case 1: ‘after the implementation [of an embodiment solution] we also had to consider what new behaviours do we need to take into consideration for the users [mechanism problem]’ (see Figure 3a). Co-evolution was further illustrated by the Project Manager and Lead Designer in Case 9 as: ‘you jump back and forth many, many times, because you learn things and you figure out, this barrier to the behaviour is really big, maybe we can develop a solution to it. “No we can’t, because it costs a lot of money” and you have to walk back and forth’. Thus, co-evolution within each space (mechanisms and embodiments) is also shaped by co-evolution between them.
Co-evolution between mechanisms and embodiments in (a) Case 1 and (b) Case 7.
Figure 3 provides two examples of how this nested co-evolutionary process progressed, with illustrative data and quotes from Cases 1 and 7. Here, the co-evolutionary framing highlights an important distinction between Case 1 (Figure 3a) and Case 7 (Figure 3b). In Figure 3, the dark orange quotes are related to the mechanisms space, the dark blue quotes are related to the embodiments space and the black quotes are related to the need for jumping between the spaces. Specifically, Case 7 started with a behavioural problem independent of any existing embodiments, driving the development of multiple new embodiments solutions, which subsequently produced an array of new behaviours resulting in further evolution of the mechanisms space. In contrast, Case 1 started with a specific problem related to an existing embodiment. This was then traced to several behaviours independent of the embodiment, resulting in the proposition of a totally new embodiment solution better matching the identified mechanisms problem. In both cases, co-evolution within the mechanisms or embodiments spaces prompted major re-frames in the other space, which helps explain how a single behavioural design process can trigger the development of multiple embodiments, as in Case 7. However, this posed specific and significant challenges to the design teams, as explained by the Lead Designer in Case 7: ‘the behavioural component in your intervention targets the barriers that you identified. Once we have the skeleton around a concept we can prototype that, but it’s really hard to leap from, “here’s a [behavioural] problem [and] here’s a way [an embodiment] that we can actually solve it!”’. Thus, the multiple interacting co-evolutionary processes help us to capture how mechanisms and embodiments mutually influence each other.
While prior work has suggested that iteration might be an important avenue of investigation for the refinement of behavioural design processes (Schmidt Reference Schmidt, Boess, Cheung and Cain2020; Bay Brix Nielsen et al. Reference Bay Brix Nielsen, Cash and Daalhuizen2024), what form this might take has remained ambiguous. Our results decompose these iteration issues and demonstrate why it is important to not only iterate within individual spaces (as is currently the case in most behavioural design literature (Cash et al. Reference Cash, Hartlev and Durazo2017; Bay Brix Nielsen et al. Reference Bay Brix Nielsen, Cash and Daalhuizen2024)) but also to facilitate iteration between them. Specifically, the mechanisms succeed – or fail – through their embodiment, and embodiments succeed only if the embodiments-related mechanisms ensure that the intervention is successfully accepted, used, maintained/serviced and discarded (see Figure 3). The Project Lead and Lead Designer in Case 5 highlighted this as: ‘if a company comes to us… what they’re looking for is not necessarily the product, but the results that the product will give them, and I think having this structure of a behavioural design approach, heightens the chance of that happening… I know that the first thing you do is do the technical approach… instead of looking at what is the problem actually… so let’s look at the design outcome and design behaviour’. Critically, our results illustrate how expert behavioural designers foster co-evolutionary alignment between mechanisms and embodiments spaces to create satisfying pairings of problem and solution spaces at the overall intervention level. This significantly recontextualises the discussion of behavioural design processes as it concretises the process-based linkages between mechanisms and embodiments.
4.3. Co-evolution and emergent synergy
Finally, relating our findings back to our RQ and building on our second theme, our third theme illustrates how co-evolution contributes to the development of process synergy between mechanisms and their embodiments. Here, we operationalise process synergy as the extent of linkage between spaces. This is primarily based on: (i) the overall number of jumps between spaces, (ii) the number of jumps specifically from embodiments to mechanisms space, depicting updating of the mechanisms space in relation to insights associated with the embodiment and its implementation, and (iii) the number of jumps specifically from embodiments-related mechanisms to embodiments space, depicting the degree to which updated mechanisms are brought back into the embodiments. All of these jumps reflect deviations from the prevailing notion of linearity, with a single jump from mechanisms to embodiments space (Figure 1). Importantly, process synergy reflects the degree of alignment between mechanisms and embodiments in the design process, with the assumption that greater alignment will lead to better outcomes in the long term because possible confounding effects from one space or the other can be accounted for in the final intervention. However, this link between process and outcomes cannot be established concretely in our data and rests on the widely accepted logic of the need for alignment between spaces found in the broader literature (Dorst & Cross Reference Dorst and Cross2001; Crilly Reference Crilly2021). Hence, we conceptualise process synergy as an explicitly process-related success construct at this stage.
While some process synergy was observed in all cases, contrasts here revealed several additional insights towards its extent. Specifically, Cases 2, 3, 5, 6, 7, 8 and 9, in Figure 4a, started with a problem not associated with any specific embodiment, while Cases 1, 4, 10 and 11, in Figure 4b, started with a specific embodiment, which was then translated into the mechanisms space. Decomposing the behaviour-initiated projects (Figure 4a), Cases 3, 5 and 7 highlight at least 2 jumps between mechanisms and embodiments, and 1 jump between embodiments-related mechanisms and the embodiments (for 3 total, as in Figure 4a), supporting strong alignment between the spaces in the final intervention. The Project Lead and Designer of Case 5 discussed the outcomes of the project as: ‘we did this context study and from that we created prototypes, [then we did] ideation again, and then prototypes and testing. The major reason for not being successful lay in the motivation for using it… these workshops with the patients… changed our perspective’.
(a) Group 1 – Mechanisms-initiated projects, (b) Group 2 – Embodiments-initiated projects.
In contrast, Cases 2, 6 and 8 had just one jump between mechanisms and embodiments. The cases had no reported (embodiments to mechanisms) jumps as they were more open-ended, with interventions comprising multiple elements, including educational and social components, for which iteration was less feasible within the project’s constraints. The reasons for the limited iteration in Case 2 were elaborated by the Project Lead as: ‘[it is] all part of being a consultant, you come up with what you think is great idea! and then the client says, “Oh thanks! thanks a lot, we’ll do it ourselves or something, that’s just life”’. Here, instead of continued development, there was typically a plan in place for subsequent co-evolutionary refinement via post-project monitoring and iteration depending on the observed embodiments-related mechanisms.
A similar pattern was observed in the embodiments-initiated projects (Figure 4b). Here, Cases 1, 4 and 10 involved 4 jumps between mechanisms and embodiment, as well as at least one jump between embodiments-related mechanisms and embodiments. The Lead Designer of Case 10 elaborated how the project resulted in multiple interventions: ‘we went through everything [behavioural data] and we found that the [current embodiment] was… [communicated using language inappropriate to the audience] so communications changed [Intervention 01]. We then tried to decrease the current [problematic] behaviour, minimise it by making it difficult [Intervention 02], and then we focused on driving the behaviour in very small steps, so instead of introducing the entire system we introduced one critical part, so we worked a lot with feedback loops [Intervention 03]’. Here, the secondary data show that the design team went through at least six different jumps between embodiments-related mechanisms and embodiments.
However, exceptions to this pattern were observed in Cases 9 (Figure 4a) and 11 (Figure 4b), where only two jumps between mechanisms and embodiments occurred. Here, Case 11 co-evolved only in terms of the embodiments-related mechanisms and embodiments. Interestingly, both Case 9 and 11 involved complex systems and multiple mechanisms across a large set of people. Lead Designer in Case 11 elaborated the significance of this on the project as: ‘after we had done our insights study, because there were a lot of behaviours, we believed we didn’t have budget to solve all of it… with a lot of things that we hadn’t thought about with the [main project of which this project was a sub-project], and a lot of things that [client] hadn’t thought about as they decided on this very vague description of an [overall embodiment system as the starting point for the project] that would solve their issues’. These issues resulted in fewer co-evolutionary moves and jumps, resulting in lower process synergy.
By contrasting results across cases, it becomes clear that the extent of co-evolution within and between spaces contributed process synergy, which could broadly be linked to perceptions of better understanding and formulation of final interventions by the design team. Cases 1, 3, 4, 5, 7 and 10 all have significant iteration, dependent on the designers’ understanding of the multiple barriers to the mechanisms and the proposed mechanism solutions. Here, co-evolutionary jumps between mechanisms and embodiments both helped improve initial ideas and developed newer, different ideas. The Lead Designer in Case 3 highlighted this as: ‘All of the times that we have decided, we need to discard that completely and start over… the [embodiment] had to change because we incorporated the behavioural practice of the [stakeholder]. We got insights on their practice that says, “minor detail, this will never happen, so you need to do this instead”’. In addition, process synergy was also linked to refinement of the embodiments, with multiple cases in Figure 4 iterating their embodiments with respect to insights from testing and subsequent updating of requirements derived from embodiments-related mechanisms. Further, where this was not possible within the constraints of the project timeline, the extent of co-evolution was typically planned for the post-project context. In large part, this reflects the expertise of the consultancies in dealing with factors outside their control associated with the embodiments and their implementation, and hence planning how to account for embodiments-related mechanisms via post-project monitoring and adjustment, that is, aiming to develop process synergy even after project completion. Hence, process synergy contributed to the refinement of understanding in both mechanisms and embodiments spaces as well as alignment between them, with logical implications for the overall coherence of the final intervention.
These results strongly emphasise the importance of reciprocal reframing between the mechanisms and embodiments spaces, as well as the significance of substantive iteration between and within stages of the behavioural design process. Critically, the effects of initially identified mechanisms could only be fully understood once embodied, and hence iterative refinement of embodiments-related mechanisms was essential to delivery of the final intervention. This contrasts with the de-prioritisation of embodiment as a finishing step with limited recourse for iteration of mechanisms, as depicted by, for example, the behaviour change wheel (Michie et al. Reference Michie, Atkins and West2015). This was reflected by repositioning of embodiment within the behavioural design process to account for jumps between spaces and iteration in light of embodiments-related mechanisms. This significantly extends current behavioural design thinking in that it elucidates the contrast between effective, expert practice and current process prescriptions. Specifically, most current process models forward a selection-based approach to identifying mechanisms, which then determine the selection of embodiments (Bhamra, Lilley & Tang Reference Bhamra, Lilley and Tang2011; Michie et al. Reference Michie, Atkins and West2015). Yet our results highlight how this relationship should be understood as reciprocal, with mechanisms and embodiments exerting mutual influence on each other. Therefore, this relationship cannot be resolved via linear steps but rather requires iteration to gradually align the interacting spaces from Figure 1.
5. Discussion
In contrasting the processes observed in our 11 cases, we identified several notable features that significantly advance understanding of the behavioural design process. First, we characterise co-evolutionary development within both the mechanisms and embodiments spaces. This significantly elaborates prior research, which typically focuses on development in the mechanisms space and leaves embodiment largely implicit (Lockton et al. Reference Lockton, Harrison and Stanton2010; Michie et al. Reference Michie, Richardson, Johnston, Abraham, Francis, Hardeman, Eccles, Cane and Wood2013).
Second, we identify co-evolutionary development between the mechanisms and embodiments spaces, with the emergence of embodiments-related mechanisms as an important consideration. This contrasts with the dominant view in current behavioural design research and prescription, suggesting a more linear and direct transition from mechanisms to embodiments spaces (Datta & Mullainathan Reference Datta and Mullainathan2014; Michie et al. Reference Michie, Atkins and West2015).
Third, we identify process synergy: the extent of co-evolution between mechanisms and embodiments spaces, as an important factor shaping understanding and coherence of the final intervention. In our results, projects with greater process synergy (i.e., multiple jumps between mechanisms and embodiments spaces) achieved greater alignment between behavioural and artefact-related considerations and were better able to account for embodiment and implementation-related factors in the final intervention.
Figure 5 illustrates these findings and serves as a point of comparison to our initial conceptual framework (Section 2.4) as well as typical descriptions of influence between mechanisms and embodiments in current behavioural design processes prescriptions. Hence, the recognition of co-evolution at multiple levels in behavioural design, as well as its salience in fostering process synergy constitutes important advances in this context.
Illustration of co-evolution in behavioural design, denoting co-evolution within the embodiments and mechanisms spaces as well as co-evolution between spaces at a higher abstraction level denoted here as the intervention problem/solution spaces in recognition that it links mechanisms and embodiment understanding.
5.1. Implications for behavioural design
The understanding illustrated in Figure 5 provides the basis for two major implications for behavioural design process prescriptions (Section 2). First, current process research and prescriptions in behavioural design provide essential steps but do not typically explain how to manage the iterative interaction between behaviour change mechanisms and embodiments (Section 2.1). Our results highlight how expert practitioners enable iterative, reciprocal influence both between mechanisms and embodiments spaces as well as within each space (Figure 5). Within spaces, this allows them to align and iterate on specific aspects of the design task, for example, by ensuring that their selection of behaviour change mechanisms aligns with their developing understanding of the mechanisms space or – in the embodiments space – by aligning their selection of technology with that found feasible, viable and desirable by the involved stakeholders. Between spaces, reciprocal influence is an essential driver of refinement and alignment, ensuring that behaviour change mechanisms are appropriate not only to the core behavioural problem but also to any aspects introduced by the embodiments, that is, embodiments-related mechanisms. Jumps between initial mechanisms, embodiments and embodiments-related mechanisms together support delivery of a cohesive intervention. This challenges prior understanding, where such iteration and alignment is typically not discussed, the process is formulated as largely linear (Francis et al. Reference Francis, Stockton, Eccles, Johnston, Cuthbertson, Grimshaw, Hyde, Tinmouth and Stanworth2009; Bhamra et al. Reference Bhamra, Lilley and Tang2011; Michie et al. Reference Michie, Atkins and West2015), iteration is left unstructured (e.g., as in Fogg’s eight-step process (2009a)) or iteration is offloaded to a meta-cycle, where a new project is formed based on feedback from a launched intervention (Michie et al. Reference Michie, Atkins and West2015; OECD 2017). Hence, we highlight the need for alternative formulations of behavioural design process models that can better account for iteration at multiple levels. This leads to our first proposition.
Proposition 1: Effective behavioural design processes enable for reciprocal, co-evolutionary influence within and between mechanisms and embodiments spaces.
Our findings also draw a direct connection between the extent of co-evolution and understanding and cohesion of the intervention, based on process synergy. Prior work has focused primarily on conceptualisation of behavioural and behaviour change theory and the specific work needed to deliver relevant theory-based interventions defined primarily with respect to their initial mechanisms (Michie et al. Reference Michie, Johnston, Francis, Hardeman and Eccles2008). In contrast, our work highlights the importance of process-focused theory that connects how behavioural design is done to the viability of the delivered interventions and the degree to which they leverage the full available design space (i.e., both mechanisms and embodiments spaces and their interactions). For example, Cash & Joo (Reference Cash and Joo2026) elucidate how specific theory, and associated process management, is needed to help mediate interactions between mechanisms and embodiments-related design work. Notably, this calls into question the typical formulation of a single one-way transition between the mechanisms and embodiments spaces found in most behavioural design literature (Section 2). However, further research is needed to better understand how process structures such as process synergy impact not just the delivered intervention but its ultimate performance in context. This leads to our second proposition.
Proposition 2a and 2b: Increased process synergy in the form of greater reciprocal, co-evolutionary influence (2a) within and (2b) between mechanisms and embodiments spaces will increase understanding and cohesion of delivered behavioural interventions.
Second, prior work has typically focused on early concretisation of the problem definition, hence making it unclear how iteration can be accommodated (Section 2.1). Our findings offer specific insight into this disconnect by highlighting the higher-level co-evolution between intervention-level spaces illustrated in Figure 5. Specifically, we found two and sometimes more jumps between the lower-level mechanisms and embodiments spaces associated with feedback regarding (i) how the initial mechanisms space can be translated into an embodiment and (ii) how the mechanisms space should be iterated based on feedback in relation embodiments-related mechanisms (Figure 4). Typically, this second mode happened at least once, but in some projects, it occurred multiple times as different embodiment approaches were tested and iterated, necessitating refinement of the mechanisms space (e.g., Cases 3, 7 and 10). Here, iteration was typically triggered by additional behavioural insights associated with the testing of intervention prototypes or the introduction of additional behavioural concerns associated with intervention uptake and use, based on expert review, user feedback or test implementation. While all cases included at least one iterative jump to allow for embodiments-related mechanisms, further jumps were sometimes necessary when significant issues emerged in the embodiments space. For example, in some cases the initial embodiment was found to need complete revision (as in Case 5), need additional elements (as in Case 3) or require ongoing processes to support uptake and use (as in Case 10). These changes were significant enough to require iteration of the mechanisms space. However, teams also needed to make explicit choices about how to manage this in context. For example, in Case 10 the team pivoted towards a more service-like formulation to allow for ongoing updates, while the team in Case 5 extended their process to allow for additional testing. Yet such changes or extensions were not always possible. For example, when constrained by time or budget, some interventions were delivered with the caveat that further work might be needed (as in Case 11). In these cases, teams typically provided information on how ongoing work might be handled and additional iterations incorporated into the post-project timeframe. Therefore, even when not possible within the constraints of the project timeline, all cases took care to provide for at least one and often two or more major iterations between embodiments and mechanisms spaces, with the general acknowledgement that these were essential for the ultimate success of intervention implementation in context. Literature on co-evolution in design also associates such interactions with the work of experienced designers and draws a link between this and better quality designs (Dorst & Cross Reference Dorst and Cross2001; Kavakli & Gero Reference Kavakli and Gero2002). This suggests an alternative structure to the typical single jump between mechanisms and embodiments spaces, where, at minimum, an iteration is needed in the mechanisms space for each major development or reframing of the embodiments space. This forms the basis for our third proposition.
Proposition 3: At minimum, reciprocal, co-evolutionary influence between mechanisms and embodiments spaces is necessary with respect to the initial mechanisms and the embodiments-related mechanisms.
Our findings (Figure 5 and propositions) thus help close the gap in understanding associated with the interface between the development of behaviour change mechanisms and their embodiments (Section 2).
5.2. Wider implications for design theory
Our findings also reveal the need for further development of co-evolutionary theory in order to link process structures and outcomes. Specifically, Proposition 2 highlights a link between process structure and understanding of the final intervention. This points to the need for future research to better conceptualise this process structure/output link and, for example, answer questions such as what might constitute too much or too little co-evolution, how co-evolutionary structures relate to specific types of development in the related spaces (linked to Proposition 3) and how this understanding might feed into efforts to model design processes (Fernandes et al. Reference Fernandes, Henriques, Silva and Pimentel2017). This aligns with general calls to better understand underpinning design processes and mindsets (Lavrsen, Carbon & Daalhuizen Reference Lavrsen, Carbon and Daalhuizen2024). Further, we note that it was necessary to introduce additional visual elements in our explanations of co-evolutionary moves reflecting the extent of moves (move versus jump) and complexity in the interaction and organisation of spaces (e.g., see Figure 4). Thus, while our work does not directly focus on extending a general understanding of co-evolution, our findings hold several significant implications for further work in this area and contribute to the ongoing debate regarding how co-evolution can be developed and visualised (Crilly Reference Crilly2021; Gero, Kannengiesser & Crilly Reference Gero, Kannengiesser and Crilly2022; Cash et al. Reference Cash, Gonçalves and Dorst2023).
5.3. Implications for behavioural design practice and education
In terms of practice, the distinction between development of mechanisms and embodiments spaces allows for greater clarity in process planning and management. First, Proposition 1 highlights the need to allow for co-evolution of mechanisms and embodiments spaces even when applying more linear process models (see Section 2). Specifically, behavioural design teams should make iteration an explicit, rather than tacit, part of their process. Key here is the recognition that changes in one space impact the other and need to then be accounted for. For example, if new mechanisms are identified as part of a research step, this should trigger iteration of the embodiment to examine how these might be practically integrated; might they simply be added to the existing embodiment (e.g., an additional function in an app) or might they require wider changes (e.g., shifting from an app. to an app. coupled with a product and communication campaign)? Similarly, changes to the embodiments should trigger iteration of the mechanisms. For example, shifting from an app. to an app. coupled with a product will introduce additional considerations around uptake, use and disposal of the product element that are distinct from an app. integrated within an existing device. Hence, significant changes in either space should trigger iteration.
Second, Propositions 2 and 3 reveal the need for at least one iteration, but with processes benefiting from more than one where possible within the constraints of time and budget. Critical here is that no matter what embodiment emerges, it will introduce new and/or significantly re-contextualise the initially identified mechanisms. At minimum there will be ancillary embodiments-related mechanisms around uptake, upkeep and end-of-life, which are typically intervention specific (e.g., an app. will require users to download and update it, as well as take on management of their own change process once the app. becomes unsupported or out of date on the relevant platform). Beyond these, all of our cases identified additional mechanisms either being enabled or directly triggered by their chosen embodiments and hence needed to revisit their initial conceptual models or selected mechanisms with these in mind. It is beyond the scope of this work to address every possible trigger for such iteration, or how this should be managed within the wider constraints of a project (indeed such issues are addressed in the design process and project management literatures). However, it is essential that teams organise their work such that iteration can be incorporated within the process and at minimum allow time to account for embodiments-related mechanisms and the potential need to revisit research insights or carry out additional work to understand embodiments-related uptake and use concerns.
In terms of education, our findings provide a basis for educators to explain the interaction between previously disparate yet complementary process models, such as those by Michie et al. (Reference Michie, Atkins and West2015) and Fogg (Reference Fogg2009b). This allows for a more consistent, theory-based explanation of the functioning, progression and critical dependencies of the behavioural design process. We highlight the need to further develop education around process skills in behavioural design to complement the extensive bodies of work focused on understanding behavioural problems and solutions (Michie et al. Reference Michie, Atkins and West2015).
6. Conclusions
This research set out to answer the RQ: How do behaviour change mechanisms and their embodiments emerge and relate to each other during behavioural design processes? We address this question by developing an elaborated understanding of co-evolutionary development associated with distinct co-evolution within the mechanisms and embodiments spaces, as well as between them (Figure 5). This allowed us to develop several propositional insights regarding the relationship between co-evolutionary process structures, conceptualised as process synergy and the development of behavioural design interventions. This has implications for behavioural design process theory and prescriptions, as well as highlighting areas of potential future work in more general discussions of co-evolution in design. In particular, not all possible co-evolutionary patterns were observed in our data, suggesting the need to further investigate the significance of specific co-evolutionary structures or sequences – especially across levels of analysis – as well as degrees of co-evolution and direction of the process. Thus, our work highlights the need for further research on process structure in behavioural design in order to complement ongoing work on behavioural problem/solution understanding.
Open access
