A hospital redesigns its discharge process. Patients now leave faster, satisfaction scores climb, and the internal team celebrates a textbook service design win. Six months later, community nursing teams are overwhelmed. GPs report patients returning with complications that should have been caught in transition. Readmission rates creep upward. The discharge process works beautifully in isolation—and fails completely in context.

This pattern repeats across sectors. A municipal government streamlines its housing application portal, only to discover that the simplicity funnels applicants into a benefits system that can't absorb the volume. A bank redesigns onboarding for speed, inadvertently breaking the fraud detection workflows that downstream teams depend on. Each project delivered exactly what was scoped. Each project made the larger system worse.

The problem isn't bad design. It's bounded design. Most service design operates within project scopes that treat a single service as a discrete object—something with clear inputs, outputs, and boundaries that can be optimized independently. But services don't exist independently. They exist within ecosystems of interdependent actors, shared resources, and cascading effects. When we design as if the boundary of our project is the boundary of the system, we systematically produce interventions that solve local problems while generating systemic ones. Understanding why this happens—and what to do about it—requires a fundamental shift in how we frame the design challenge itself.

Herbert Simon described complex systems as hierarchies of nearly decomposable subsystems. The key word is nearly. Services within an ecosystem share users, data flows, regulatory constraints, and institutional dependencies. They also share something less visible: assumptions about each other's behavior. When one service changes how it operates, it violates assumptions that adjacent services were built on—often without anyone realizing those assumptions existed.

Consider a service ecosystem map for something as common as a patient journey through mental health care. The patient interacts with a GP, a referral system, a specialist assessment team, a therapy provider, a prescription service, and potentially crisis support. Each of these is often designed and managed by a different team, sometimes a different organization entirely. The patient experiences it as one continuous journey. The system treats it as six or seven discrete services, each with its own KPIs, budgets, and improvement roadmaps.

The interdependencies between these services fall into several categories. There are resource dependencies—where one service's output is another's input. There are temporal dependencies—where sequencing and timing matter. There are information dependencies—where services rely on shared data or signals. And there are normative dependencies—where shared standards, expectations, or cultural norms hold the ecosystem together in ways no specification document captures.

What makes ecosystem mapping genuinely difficult is that many of these interdependencies are latent. They don't show up in process diagrams or service blueprints because they operate through informal channels, workarounds, and institutional memory. A triage nurse who knows which referral pathways actually work. A case manager who calls ahead to smooth a handoff. These human adaptations are invisible infrastructure, and they're the first things disrupted when a single service is redesigned without ecosystem awareness.

The implication is straightforward but uncomfortable: you cannot fully understand a single service without understanding the ecosystem it operates within. A service blueprint that stops at organizational boundaries isn't wrong—it's incomplete in ways that become consequential at the moment of implementation.

Takeaway

Every service silently depends on assumptions about how adjacent services behave. When you redesign one service without surfacing those assumptions, you don't just risk side effects—you guarantee them.

The UK's Universal Credit program remains one of the most instructive examples of isolation failure at scale. The ambition was sound: replace six separate benefits with a single, simpler system. The service design for the application process was, by many accounts, well-executed for a digital government service. But the new system was designed with assumptions about claimants' digital literacy, banking access, and ability to manage monthly payments that didn't hold for the most vulnerable users. Adjacent services—food banks, housing associations, local councils—absorbed the consequences. The project succeeded on its own terms while destabilizing the ecosystem it depended on.

A less dramatic but equally revealing example comes from a European transport authority that redesigned its journey planning app. The new app was faster, cleaner, and better rated. But it directed users toward optimal routes that concentrated passenger load on specific connections, overwhelming those services during peak times. The app's design optimized individual journeys while degrading collective system performance. No one on the project team had modeled how individual route optimization would aggregate into network-level effects.

These cases share a common structure. A well-scoped project identifies a clear problem, designs an effective solution within its boundaries, and delivers measurable improvement on its own metrics. The failure is not within the project—it's between the project and the ecosystem. The metrics that matter most aren't captured because they belong to adjacent services, different departments, or different organizations entirely.

What's particularly insidious is that project-based evaluation reinforces the isolation. When the discharge redesign team reports faster discharge times, they're telling the truth. When the benefits platform reports successful digital applications, that's accurate too. The harm is distributed across actors who weren't in the room, measured by KPIs that belong to other teams, and experienced by users who have no mechanism to feed back that the system got worse even though the service got better.

This isn't a failure of competence. It's a structural consequence of how organizations commission, fund, and evaluate design work. Projects have scopes. Budgets have line items. Teams have mandates. Ecosystems have none of these things, which is precisely why they're so easy to ignore and so costly to neglect.

Takeaway

A service design project that meets every brief, hits every KPI, and delights every stakeholder in the room can still make the world worse for the people it was meant to help—because the damage shows up in someone else's metrics.

Acknowledging ecosystem complexity doesn't mean every project must redesign the entire system. That's neither practical nor desirable. The goal is to design within ecosystem awareness—maintaining actionable project boundaries while accounting for systemic interdependencies. Several methods make this feasible without turning every engagement into an unbounded research exercise.

Ecosystem scanning is a lightweight practice that maps adjacent services, shared users, and critical dependencies before design work begins. It doesn't require full systems analysis. It requires asking: what happens upstream of our service? What happens downstream? Who else touches our users before and after they reach us? What are we assuming about those touchpoints? Even a two-hour workshop with cross-service stakeholders can surface dependencies that would otherwise remain invisible until implementation.

Boundary negotiation is the practice of making project scope decisions explicit and revisable. Rather than treating the brief as a fixed frame, teams identify which ecosystem interactions they're choosing to include, which they're choosing to monitor, and which they're consciously setting aside. This doesn't expand the scope—it makes the scope honest. When you name what you're not designing for, you create accountability for revisiting those decisions as evidence emerges.

Systemic indicators complement project-level metrics by tracking effects beyond the service boundary. If you redesign hospital discharge, you also monitor community nursing capacity and readmission rates. If you redesign onboarding, you track downstream process completion, not just signup conversion. These indicators don't need to be owned by the project team, but they need to be visible to them. Dashboards that stop at the service boundary produce the same blindness that caused the problem.

The deeper shift is cultural rather than methodological. It requires organizations to value ecosystem stewardship alongside project delivery. It means commissioning work with ecosystem impact assessments built in, not bolted on. It means rewarding teams that identify systemic risks, even when those risks slow down delivery. None of this is exotic. It's the basic discipline of designing within a system rather than pretending the system doesn't exist.

Takeaway

You don't need to redesign the whole ecosystem to design responsibly within it. You need to see beyond your project boundary, name your assumptions about what lies outside it, and track whether those assumptions hold.

The instinct to bound a problem before solving it is sound. Without boundaries, design work becomes unfocused and undeliverable. But boundaries are analytical choices, not descriptions of reality. The service you're redesigning doesn't know it has a project scope. Neither do its users.

The shift from isolated service design to ecosystem-aware practice isn't about doing more—it's about seeing more. It means treating your project boundary as a lens, not a wall. It means building the habit of asking what your intervention assumes about everything it doesn't control.

Services are not objects. They're relationships embedded in systems of relationships. Design them accordingly, and you stand a chance of making things better not just within the frame of your project, but in the world your users actually inhabit.