1. Introduction
Design methodology has traditionally prioritized simplification as a key principle. From the axiomatic design principle of minimizing information content (Reference SuhSuh, 1990) to the widespread “keep it simple” heuristic, the field treats simplicity as a marker of good design. This paradigm serves discrete product development well, where stable requirements, clear system boundaries, and predictable use contexts enable systematic problem decomposition (Reference SimonSimon, 1996; Reference Pahl and BeitzPahl & Beitz, 2007; Reference Ulrich, Eppinger and YangUlrich & Eppinger, 2020). However, as design challenges shift from fixed artifacts to evolving socio-technical systems where human organizations, institutional practices, and technical infrastructures continuously co-shape one another, the simplification imperative may be insufficient. Designers use several strategies to make design problems simpler to understand and address (e.g., working in teams, developing heuristics, drawing upon precedents). Reference DorstDorst (2020) posits that these strategies—and more generally, the current design paradigm—may “hit the ceiling” as it attempts to address increasingly complex problems.
Complex Socio-Technical Systems (CSTS) exhibit characteristics that fundamentally violate traditional design assumptions: multiple autonomous agents with partially conflicting objectives, emergent behaviors arising from nonlinear interactions, and adaptation in response to interventions that cannot be predicted from component-level analysis (Reference JonesJones, 2013; Reference Braithwaite, Churruca, Ellis, Long, Clay-Williams, Damen, Herkes, Pomare and LudlowBraithwaite et al., 2017; Reference de Weck, Roos and Mageede Weck et al., 2011). In such systems, complexity is not a design defect to be minimized but an intrinsic property of the system that requires explicit methodological accommodation. A central challenge for design research concerned with CSTS is how to develop systematic design approaches that work productively with complexity rather than attempting to eliminate it (Reference DorstDorst, 2020).
This challenge, while true across socio-technical challenge areas, is particularly acute in healthcare, where, despite substantial investments in electronic health records and quality improvement initiatives, coordination failures among multiple providers treating patients with chronic conditions result in fragmented care, duplicated testing, medication errors, and poor outcomes (Reference Clarkson, Bogle, Dean, Vickers, Morel, Tarassenko, Woodgate, Butterworth and MischkeClarkson et al., 2017). These failures persist because interventions address technical architecture while leaving underlying socio-organizational dynamics (e.g., professional boundaries and trust relationships) unmodeled and unaddressed. The gap reveals a key methodological limitation: current design approaches lack integrated frameworks for simultaneously engaging technical and social aspects across the entire design cycle, from problem scoping to implementation.
1.1. Limitations of current design approaches for complex systems
Existing design methodologies address different aspects of complexity but fall short of providing integrated approaches suited to CSTS design. In this section, we highlight several design approaches to illustrate the general areas in which a new design approach for complex systems is needed (Table 1).
Systematic product design methodologies provide rigorous processes for translating requirements into detailed product specifications through structured stages. The Germanic tradition, exemplified by Reference Pahl and BeitzPahl and Beitz (2007), emphasizes a systematic progression from requirements through conceptual to detail design, while foundational engineering design texts (Reference Dieter and SchmidtDieter & Schmidt, 2021) and product development frameworks (Reference Ulrich, Eppinger and YangUlrich & Eppinger, 2020) guide iterative cycles of needs identification, concept generation, and validation. These approaches excel for products with stable requirements and clear boundaries, but assume relatively static contexts of use, assumptions that CSTS fundamentally violates, where interventions co-evolve with the adaptive systems they target.
Model-Based Systems Engineering (MBSE) has advanced the modeling of large-scale technical systems substantially, enabling formal representation of system architecture, requirements traceability, and validation (Reference Madni and SieversMadni & Sievers, 2018). MBSE promotes models as the authoritative “single source of truth” for system definition. Yet this strength reveals a critical limitation: MBSE excels at capturing quantifiable technical relationships but struggles with qualitative, emergent socio-organizational dynamics that often determine real-world performance. This asymmetry leaves designers with partial representations of whole-system problems.
Human factors and ergonomics (HFE) has developed influential frameworks for socio-technical systems, analysis, and healthcare. The SEIPS model and its extensions (Reference Carayon, Schoofs Hundt, Karsh, Gurses, Alvarado, Smith and BrennanCarayon et al., 2006; Reference Holden, Carayon, Gurses, Hoonakker, Hundt, Ozok and Rivera-RodriguezHolden et al., 2013) provide a comprehensive work system analysis that considers persons, tasks, tools, technologies, organization, and environment. Other HFE approaches address the system design paradigm and human factors approaches to healthcare quality (Reference Karsh, Holden, Alper and OrKarsh et al., 2006; Reference Carayon, Wetterneck, Rivera-Rodriguez, Hundt, Hoonakker, Holden and GursesCarayon et al., 2014). These frameworks excel at analyzing existing systems to identify safety hazards, workload issues and socio-technical misalignment. However, they are primarily descriptive, providing a comprehensive model for understanding current work system components and their interactions, but limited guidance for how to systematically develop, validate, and implement new system configurations.
Quality improvement methodologies like Lean and Six Sigma bring data-driven process optimization but target symptoms rather than systemic causes, optimizing processes within existing structures without fundamentally reconceptualizing system architecture (Reference Braithwaite, Churruca, Long, Ellis and HerkesBraithwaite et al., 2018). Conversely, service design, systemic design, and broader design thinking approaches explicitly engage complexity through holistic, participatory methods (Reference Jones and MetcalfJones, 2014; Reference SevaldsonSevaldson, 2017; Reference BuchananBuchanan, 2019) but often lack the systematic progression from exploration through validated implementation required for CSTS.
Participatory and human-centered design approaches recognize that meaningful user involvement increases adoption and generates solutions better fitted to actual work practices (Reference Sanders and StappersSanders & Stappers, 2008; Reference Wacnik, Daly and VermaWacnik et al., 2025). However, participatory design has focused primarily on interface and service design, with limited integration into the structured system-level design processes (e.g., architectural modeling) that CSTS (e.g., healthcare) demand (Reference Maier, Oehmen and VermaasMaier et al., 2022). Reference Baxter and SommervilleBaxter and Sommerville (2011) argue that despite widespread recognition that socio-technical approaches produce more effective systems, such methods have seen limited integration into structured engineering design practice. This reinforces the need for frameworks that bridge these traditions.
Summarizes how current approaches lack sufficient aspects of complex system design
In comparing these design approaches discussed here, it is evident that we lack integrated design frameworks that simultaneously maintain systematic rigor (requirements management, architecture development, validation) while engaging socio-organizational complexity (stakeholder participation, cultural adaptation, emergent coordination) across the entire design cycle. Design for CSTS requires approaches that hold both technical and social dimensions in productive tension, and drive past the mere identification of problems towards the development and implementation of interventions to address such problems.
1.2. Healthcare as an exemplar of complex socio-technical system design
Healthcare exemplifies both the stakes and methodological challenges of CSTS design. Consider a patient with multiple chronic conditions (e.g., diabetes, heart failure, chronic kidney disease) who must navigate care across primary care physicians, endocrinologists, cardiologists, nephrologists, pharmacists, home health services, and insurance case managers. Each provider operates with distinct workflows, information systems, and organizational incentives. The resulting system exhibits defining characteristics of CSTS: feedback loops where medication prescribed by one specialist affects treatment plans of others, multiple stakeholders with partially conflicting objectives, and emergent behaviors such as coordination failures that no single actor intends but all collectively produce. Evidence of inadequate system design appears throughout chronic disease management (e.g., duplicated testing because results remain inaccessible across facilities, medication errors when specialists prescribe without visibility into complete drug regimens, or patients who become de facto care coordinators without adequate information infrastructure or clinical training) (Reference Clarkson, Bogle, Dean, Vickers, Morel, Tarassenko, Woodgate, Butterworth and MischkeClarkson et al., 2017).
Technical infrastructure is meant to tackle these challenges—electronic health records (EHR) aim for interoperability, patient portals provide access to information, and telehealth platforms support remote monitoring. However, multi-billion-dollar EHR implementations often fail to achieve the expected benefits (Reference Clarkson, Bogle, Dean, Vickers, Morel, Tarassenko, Woodgate, Butterworth and MischkeClarkson et al., 2017). The explanation lies not in technical deficiencies but in a mismatch between the technical architecture and the organizational workflows, communication norms, professional boundaries, and cultural practices that shape actual clinical work. This persistent gap demonstrates that healthcare’s challenges are fundamentally design challenges that current approaches do not adequately address.
1.3. Research contribution
This paper addresses the identified methodological gap by presenting an exploratory Design for Complexity Framework that synthesizes theoretical perspectives from complexity and systems science, design theory, and socio-technical systems theory into operational methods suited for regulated, high-stakes domains such as energy, education, and healthcare. Methodologically, the framework provides an integrated approach that spans problem scoping through implementation, maintaining systematic rigor while engaging socio-organizational complexity. Where existing methods address these dimensions in isolation, the framework integrates cross-disciplinary methods, holding them in productive tension throughout the design cycle. Theoretically, it responds to calls from Reference Clarkson, Bogle, Dean, Vickers, Morel, Tarassenko, Woodgate, Butterworth and MischkeClarkson et al. (2017), Reference DorstDorst (2020), and Reference Maier, Oehmen and VermaasMaier et al. (2022) to reimagine design approaches that embrace rather than attempt to simplify complexity, balancing systems-engineering rigor with human-centered adaptation and translating abstract principles into actionable methods. Moreover, the framework aims to equip designers with an approach to navigate the distinctive challenges of CSTS design to support iterative understanding and continual adaptation across evolving contexts. By presenting this theory-based framework, we invite discussion on its architecture and future application of its stages in practice, thus aiming to build towards a collective understanding of designing within complexity.
2. Theoretical foundations
The following section unpacks the theoretical bases that underpin the Design for Complexity Framework. Specifically, it traces how complexity and systems science inform holistic system understanding, how design theory provides structured progression from requirements to validation, and how socio-technical systems theory shapes the treatment of human-technical interdependence.
2.1. Systems and complexity science
Reference MeadowsMeadows (2008) describes foundational principles of systems behavior—namely, interconnections, feedback loops, and nonlinearity—that are directly relevant to understanding healthcare. Systems are defined not only by their individual elements but by the relationships among them. In healthcare, those relationships and information flows often influence outcomes as strongly as individual competencies. Feedback loops can amplify desirable behaviors, such as coordination, or, conversely, reinforce fragmentation. Nonlinear causality means that small design or policy changes can produce disproportionate effects depending on timing and context.
Healthcare is increasingly recognized as a complex system rather than a mechanistic collection of parts (Reference Plsek and GreenhalghPlsek & Greenhalgh, 2001; Reference Braithwaite, Churruca, Ellis, Long, Clay-Williams, Damen, Herkes, Pomare and LudlowBraithwaite et al., 2017), in which multiple interacting stakeholders (e.g., patients, clinicians, administrators, payers, and technologies) shape and reshape system behavior. These interdependencies generate patterns that cannot be understood or predicted by analyzing components in isolation. Healthcare is a wicked design domain (Reference Rittel and WebberRittel & Webber, 1973; Reference Braithwaite, Churruca, Ellis, Long, Clay-Williams, Damen, Herkes, Pomare and LudlowBraithwaite et al., 2017), characterized by complex and contested problems involving conflicting stakeholder values and evolving understandings that require reframing rather than direct solution (Reference DorstDorst, 2015).
Chronic-disease management illustrates this wickedness: priorities, boundaries, and problem definitions shift as interventions themselves reshape the system. Recognizing these dynamics, Reference Clarkson, Bogle, Dean, Vickers, Morel, Tarassenko, Woodgate, Butterworth and MischkeClarkson et al. (2017, Reference Clarkson, Dean, Ward, Komashie and Bashford2018) and Reference Maier, Oehmen and VermaasMaier et al. (2022) extend systems thinking into healthcare design, emphasizing that effective improvement requires viewing healthcare as an integrated socio-technical whole. Their work demonstrates that technical, organizational, and human factors must be addressed together, as optimizing one dimension in isolation often creates new risks elsewhere in the system.
Taken together, these insights highlight key implications for design methodology as applied to CSTS challenges, including healthcare design. Designing for CSTS demands extensive problem scoping before solution generation; mapping interconnections, feedback dynamics, and stakeholder perspectives to identify leverage points. As Reference Clarkson, Bogle, Dean, Vickers, Morel, Tarassenko, Woodgate, Butterworth and MischkeClarkson et al. (2017) caution, premature convergence on isolated fixes can optimize subsystems at the expense of overall system performance. Design for CSTS must therefore embed system analysis and stakeholder mapping as foundational activities preceding detailed design and implementation.
However, because complex systems continually evolve and generate behaviors that no component-level analysis can predict, thorough upfront scoping, while necessary, cannot yield a complete or stable problem definition. Rather than aiming to solve problems definitively, design for complexity is perhaps best suited to developing interventions that nudge the system toward transformation (Reference DorstDorst, 2020) and to continuing to assess how the system changes with each new intervention. A design methodology for CSTS must therefore support continual iteration and redefinition of the problem as interventions are developed and implemented.
2.2. Design theory for structured problem-solving
While systems science provides lenses for understanding complexity, design theory offers structured approaches for progressing systematically from needs to validated solutions. Gero’s Function-Behavior-Structure (FBS) ontology describes design as a set of transformation processes among three core concepts: functions representing intended purposes, behaviors describing what designs actually do, and structures defining the physical and organizational configurations that generate behaviors (Reference Gero and KannengiesserGero & Kannengiesser, 2004, Reference Gero and Kannengiesser2007).
The FBS framework conceptualizes design as movement through a state space where requirements map to functions, functions transform into expected behaviors, behaviors are realized through structural design, and structures are evaluated against requirements, with feedback loops enabling refinement. The Situated FBS extension (Reference Gero and KannengiesserGero & Kannengiesser, 2004) explicitly incorporates the ways environmental and social contexts transform design intent, making it particularly relevant for CSTS such as healthcare, where situated adaptation is required.
Traditional design processes emphasize iterative cycles of analysis, synthesis, and evaluation (Reference CrossCross, 2008). Structured methods such as the Design Structure Matrix (Reference StewardSteward, 1981) formalize how interdependent design variables require iteration planning to manage coupled dependencies. Analysis decomposes problems and develops an understanding of requirements, synthesis generates candidate solutions, and evaluation assesses solutions against criteria to identify gaps that motivate further iteration. In regulated domains such as medical device development, design control guidance prescribes systematic verification and validation within a structured waterfall-like process (FDA, 1997), emphasizing traceability and documentation.
However, such linear progression assumes requirements can be fully specified upfront and remain stable, assumptions that complex socio-technical systems violate. Design research methodology further emphasizes systematic inquiry combining prescriptive and descriptive approaches (Reference Blessing and ChakrabartiBlessing & Chakrabarti, 2009), and systematic application of these cycles, coupled with rigorous documentation, enables design teams to manage complexity while maintaining traceability (Reference Summers and ShahSummers & Shah, 2010).
Hence, design theory establishes that complex systems require systematic progression from requirements through architecture to validation, with explicit documentation of design rationale and iterative refinement based on evaluation feedback. The framework must provide structure for these cycles while acknowledging that, in CSTS, requirements emerge and evolve rather than being fully specifiable upfront. The challenge is maintaining systematic rigor without imposing premature closure, while also recognizing that in CSTS, design iteration does not end at deployment but continues as the system responds to interventions in ways that reshape the problem itself.
2.3. Socio-technical systems design
Socio-technical systems theory argues that effective system performance requires joint optimization of social and technical subsystems rather than technically optimizing first and expecting social elements to adapt (Reference Trist and BamforthTrist & Bamforth, 1951; Reference Emery, Trist, Churchman and VerhulstEmery & Trist, 1960). Technical systems enable certain behaviors and constrain others; social systems interpret, resist, or work around technical constraints based on local goals, knowledge, and relationships. Designing either in isolation produces insufficient outcomes.
Reference JonesJones (2013) argued that purely technical interventions in healthcare design often fail because they overlook how professional identities, power dynamics, trust relationships, and organizational cultures shape technology use. As seen in earlier examples such as EHR systems, even sophisticated innovations can undermine coordination when introduced without attention to social and organizational practices (Reference Wears and BergWears & Berg, 2005).
These failures highlight a deeper challenge: while our current design methodologies accurately model technical architectures, they often fail to capture the social dynamics that influence real-world performance in integrated structures. Technical systems can be modeled, simulated, and validated quantitatively, but social systems resist formalization. For example, we cannot easily model trust, cultural acceptance, or informal coordination with the same level of accuracy (Reference Madni and SieversMadni & Sievers, 2018), which raises the question: how can we design effectively when the social dimension lacks quantitative parameters?
Stakeholder participation helps address this limitation by treating participants as domain experts who hold tacit knowledge about how social systems function. Reference Sanders and StappersSanders and Stappers (2008) show that meaningful involvement throughout design increases acceptance, surfaces hidden constraints, and produces solutions better aligned with real work practices. Participatory design thus transforms stakeholders from objects of study into partners in knowledge creation. This in turn shifts the fundamental processes of socio-technical systems design: rather than designers attempting to bring together social and technical dimensions from an outside perspective, participatory design allows for designer-stakeholder teams to develop technical dimensions from a situated social perspective.
Overall, socio-technical systems theory emphasizes that human and organizational factors must be central during the design process, not after. Effective CSTS design requires ongoing stakeholder participation in shaping problem framing, architecture development, and implementation.
2.4. Synthesis: the need for an integrated framework
The theoretical traditions reviewed above each address critical but insufficient aspects of design for complexity. Systems science provides conceptual frameworks for understanding complexity but offers limited operational guidance for how to move from understanding to design. Design theory fills that gap with structured processes but assumes stable requirements and technical artifacts. Socio-technical systems theory emphasizes the joint optimization of human and technical systems altogether, yet lacks integration with a systematic design process.
A further gap cuts across all three: While participatory approaches and socio-technical theory emphasize stakeholder engagement and joint optimization, neither integrates quantitative system modeling into a structured design process, despite modeling’s capacity to reveal emergent behaviors. Adjacent work in participatory simulation (Reference Tako and KotiadisTako & Kotiadis, 2015) and group model building (Reference VennixVennix, 1996) demonstrates feasibility but focuses on modeling outcomes rather than on integrating the design process.
As documented in Section 1.1, these approaches address pieces in isolation. CSTS require an integrated design framework that: (1) maintains systematic rigor through staged progression with requirements traceability, (2) engages complexity through holistic system mapping, (3) integrates socio-technical considerations throughout, (4) incorporates stakeholder participation, and (5) balances structure with flexibility for local adaptation. The Design for Complexity Framework presented in Section 3 synthesizes these theoretical foundations into such an integrated approach.
3. Design for Complexity Framework
The Design for Complexity Framework (Figure 1) synthesizes the theoretical traditions from Section 2 into a seven-stage operational process that responds to the integration gap identified in Section 1: maintaining systematic design rigor while engaging socio-organizational complexity across the complete design cycle. The framework guides design practitioners across domains (e.g., engineers, researchers, healthcare organizational change agents) through three phases: gap identification and system understanding (Stages 1-2), design/modeling/iteration (Stages 3-6), and implementation and consolidation (Stage 7).
The framework’s distinct contribution lies in integrating adaptive iteration into a systematically structured process that maintains both technical rigor and continuous stakeholder participation. Rather than relying on a single methodological tradition, the framework draws on multiple approaches in combination. This reflects what Reference JacksonJackson (2019) terms methodological pluralism: the recognition that no single methodology is sufficient to address the complexity of wicked, socio-technical problems.
While designerly thinking emphasizes iteration (Reference CrossCross, 2008) and participatory design emphasizes stakeholder engagement (Reference Sanders and StappersSanders & Stappers, 2008), existing approaches tend to foreground one of these dimensions; there is comparatively less guidance on integrating both throughout the full design cycle, from problem scoping to implementation. The framework embeds iteration as an inherent property of Stages 3-6, where teams navigate fluidly among architectural design, modeling, and stakeholder refinement, guided by emerging insights. This accounts for the reality that, in complex socio-technical systems, problems and solutions co-evolve (Reference Dorst and CrossDorst & Cross, 2001), stakeholder understanding deepens through engagement with emerging designs, and organizational contexts shift over extended design processes.
The framework is design-led throughout: design methods structure activities at every stage. However, the degree to which early stages are also designer-led where designers drive analytical inquiry and synthesis, depends on the design context (Reference Wacnik, Daly and VermaWacnik et al., 2025). For example, in research-oriented applications, the designer’s analytical expertise may appropriately lead system study and confirmation, as their training (e.g., systematic inquiry and cross-domain synthesis) helps distinguish structural issues from surface-level symptoms and prevent premature problem anchoring around stakeholder-visible concerns. In contrast, in operational settings, such as system redesign, early stakeholder participation may be necessary to ensure ownership and equity.
In both cases, designers contribute ‘designerly ways of knowing’ (the unique, practical, and creative thinking methods designers use to understand and address complex, ill-defined problems) as a distinctive form of expertise within multidisciplinary teams (Reference CrossCross, 2006). As the process moves into iterative design and refinement (Stages 3-6), stakeholder participation becomes essential in both contexts, reflecting the principle that systems cannot be designed effectively without the knowledge of those who operate within them. Figure 1 illustrates this architecture with bidirectional arrows showing permissible transitions, particularly emphasizing the iterative nature of Stages 3-6.
3.1. Stage architecture: from understanding to implementation
3.1.1. Stages 1-2: understanding and confirming the system
The first two stages develop and validate a comprehensive understanding. Stage 1 (System Study) is exploratory, seeking to understand “what exists”. Designers map stakeholders and their relationships, trace how processes function in practice, and identify where system dynamics diverge from the intended design. They apply their analytical training to develop legible representations of a system that may not be intelligible to those operating within it. Stakeholder involvement at this stage varies with context, ranging from active participation in mapping workshops to validating designer-generated representations. The objective is a rich picture of system dynamics and an initial problem framing that is deliberately open to revision as understanding deepens.
Stage 2 (System Confirmation Analysis) deepens and tests this initial understanding. It uses additional data collection and analysis, such as diagnostic metrics or early simulation, to verify that the insights from Stage 1 accurately represent system behavior. Validation may range from expert elicitation and informed judgment—where the designer tests findings against domain experts’ tacit knowledge—to formal stakeholder member checking and collaborative data interpretation, depending on the project context. This confirmation step is essential in complex systems, where surface-level observations can be misleading and premature problem framing risks misdirecting subsequent design effort. Both stages produce problem statements grounded in literature and empirical investigation.
The Design for Complexity Framework
Seven-stage process organized across three phases, with iterative co-evolution (Stages 3–6) and monitoring-enabled re-entry (Stage 7). Brown arrows indicate iteration; dashed arrows show feedback enabling loop-back. Stakeholder participation intensifies from context-dependent (Phase 1) to essential co-design (Phase 2) to adoption monitoring (Phase 3).
3.1.2. Stages 3-6: iterative design, modeling, and refinement
These stages constitute the framework’s design and iteration space, operating as analysis-synthesis-evaluation cycles extended to accommodate socio-technical complexity. Stage 3 (System Architecture) conceptualizes high-level solution structures addressing confirmed problems. Designers generate and compare multiple conceptual alternatives, specifying how components are arranged, how they relate to one another, and how information flows between them without committing to detailed parameters. For example, this might take the form of a conceptual framework that maps relationships among different system elements. Each alternative is then assessed for feasibility across technical, organizational, and cultural dimensions. Design rationale is documented explicitly, as it becomes critical when later stages reveal the need to revisit architectural choices.
Stage 4 (System Modeling) translates conceptual architectures into testable forms through analytical models, simulations, or prototypes that predict system behavior under varied conditions. Modeling integrates quantitative approaches such as process simulation, system dynamics modeling, and network analysis with qualitative methods such as causal loop analysis and scenario walkthroughs. Reference Schünemann, Johanning, Herold and BrucknerSchünemann et al. (2024) demonstrate that quantitative and qualitative modeling capture complementary aspects of socio-technical system behavior, and that neither alone provides sufficient representation for design decisions. This leverages the representational rigor of MBSE while extending it to capture social and organizational interactions that traditional MBSE overlooks.
Stage 5 (System Refinement) marks a deliberate shift: while earlier stages may draw primarily on the designer’s analytical expertise (depending on context), Stage 5 requires stakeholder engagement to address the epistemic question that analytical methods alone cannot answer: does this representation accurately capture our lived experience of the system’s function? Reference VennixVennix (1996) demonstrates that when stakeholders engage directly with system representations through structured facilitation, the process builds shared understanding and commitment to resulting decisions.
The core activity is a structured walkthrough, which may take the form of a facilitated session in which the design team presents the system model, and stakeholders verify it against lived experience. This collaborative validation surfaces tacit knowledge that analytical inquiry alone cannot access and builds the shared understanding necessary for effective co-design. The objective is a stakeholder-validated system model that reflects both analytical findings and practitioner knowledge, with identified leverage points for intervention.
Stage 6 (Intervention Design) shifts stakeholder participation fully to co-creation. At this point, stakeholders and designers share a validated model of how the system currently works. Using that model as a shared canvas, they jointly propose changes and trace them through the system — if we change this, what happens there? Does this create a new problem somewhere else? This is where the framework moves from understanding the system to actually designing change within it.
The framework does not prescribe specific intervention methods. Rather, Stage 6 provides what intervention design requires but rarely has: a validated system representation and a collaborative process that grounds proposed changes in system-level reasoning rather than isolated problem-solving. This operationalizes the principle of socio-technical systems theory, which holds that effective performance requires joint optimization rather than technical optimization followed by social adaptation (Reference Trist and BamforthTrist & Bamforth, 1951).
Both Stages 5 and 6 are analytically distinct but iteratively coupled, reflecting problem-solution co-evolution. This concept, as Reference CrillyCrilly (2021) traces across multiple design traditions, describes how problem understanding and solution development mutually shape one another through iterative engagement (Reference Dorst and CrossDorst & Cross, 2001). Progression from Stage 5 to Stage 6 occurs when stakeholders confirm the model reflects their operational reality. However, Stage 6 activities frequently reveal inadequacies, unmapped mechanisms, effects that contradict stakeholder experience, or missing feedback loops, triggering a return to earlier stages for revision. The framework maintains analytical separation while recognizing iterative coupling, offering both conceptual clarity and practical flexibility.
More broadly, the iterative character of Stages 3–6 represents the framework’s departure from conventional processes. Reference StewardSteward (1981) demonstrates that systems design inherently involves interdependent variables requiring iteration; in CSTS, this coupling extends beyond technical parameters to social and organizational dimensions. Modeling may reveal architectural inadequacies (return to Stage 3), stakeholder validation may surface gaps in requirements (return to Stage 2), and intervention co-design may identify fundamentally different architectural alternatives (return to Stage 3). Understanding emerges through this iterative engagement rather than being fully specifiable a priori.
3.1.3. Stage 7: consolidation and deployment
Stage 7 translates validated designs that resulted from the outputs of preceding stages into system-level design artifacts. This could be documented protocols, decision-support tools, training programs, or policy recommendations, depending on the design context. Equally important is establishing the monitoring infrastructure necessary for ongoing adaptation. This stage is not an endpoint: Reference Chambers, Glasgow and StangeChambers, Glasgow, and Stange (2013) argue that interventions in complex systems must be continuously adapted as contexts evolve, rather than rigidly maintained in their original form.
Stage 7 embodies this dynamic sustainability concept: it uses monitoring mechanisms like performance thresholds, environmental changes, and stakeholder concerns to set clear re-entry criteria that prompt a return to earlier stages. This positions the framework as ongoing design infrastructure rather than a one-time process, reflecting the continuous adaptation necessary in complex socio-technical systems.
3.2. Application: chronic disease care coordination
To illustrate the framework in a realistic setting, consider a design team tasked with improving care coordination for chronic diseases in a regional health system. Fragmented care across multiple providers leads to duplicate testing, medication discrepancies, and preventable readmissions, yet many interventions show inconsistent effects because they target isolated components rather than the system (Reference JooJoo, 2023; Reference Duan-Porter, Ullman and MajeskiDuan-Porter et al., 2022). The framework structures this as a socio-technical design problem.
Stages 1–2 map the system before proposing solutions. In Stage 1, the team uses participatory workshops to map how coordination happens, identifying informal workarounds and suspected failure points. The team discovers that responsibility is unclear at care transitions and that patients often coordinate their own care. Stage 2 tests these observations against hard data (e.g., readmission rates and medication error reports) and confirms that coordination failures cluster at transitions where no single role is responsible.
Stages 3–6 organize non-linear design iteration. Stage 3 develops a coordination architecture: Who is responsible? How does information flow? Is coordination centralized or distributed? Stage 4 tests these choices by modeling real scenarios. For example, how many handoffs a typical patient experiences each week, and whether medication reconciliation (the process of creating and comparing a complete list of all the patient’s medications to avoid errors) can be completed at each transition when staff is short.
Stage 5 brings frontline clinicians and patients in to check these models against their actual experience. In Stage 6, patient representatives may reveal that a centralized coordinator will not work because their care spans many disconnected sites. This sends the team back to Stage 3 to rethink the architecture, not just adjust details, illustrating problem–solution co-evolution in which designing the intervention transforms understanding of the problem itself.
Stage 7 consolidates the validated design into concrete outputs: protocols that assign clear responsibility at every transition, training for handoff procedures, and EHR tools that alert staff when medication reconciliation is incomplete. The team also defines monitoring triggers—such as shifts in the patient population or changes in reimbursement rules—that signal when to revisit earlier stages, replacing reactive fixes with structured adaptation.
4. Discussion, limitations, and future work
The Design for Complexity Framework advances a structured yet adaptive approach for designing complex socio-technical systems. Its distinct contribution lies in systematically integrating systems science, design theory, and socio-technical principles into a unified seven-stage process that maintains both technical rigor and stakeholder engagement across the complete design cycle, an integration that existing approaches provide individually but not in combination. Unlike existing approaches that address these elements separately, this framework recognizes that understanding and intervention develop together in complex systems.
Although healthcare served as the primary example, the framework’s logic applies wherever human and technical systems co-evolve. Future research should test the framework through implementation case studies across domains, examining how practitioners navigate the stage structure, where iteration occurs, and whether this integration yields outcomes different from those of conventional approaches. The authors are currently applying the framework to design a curricula complexity quantification tool, providing an initial empirical test of its staged structure.
While the framework emphasizes stakeholder participation, the degree and form vary with design context, as discussed in Section 3. The framework provides a structured progression in which designers select appropriate methods based on domain and context, rather than prescribing specific tools for each stage. Ultimately, this theoretically based framework represents an initial step toward design methodologies that treat complexity not as an obstacle to be reduced but as a condition to be designed within.
Open access
