Last Updated May 28, 2026
Design thinking becomes more difficult, and more important, when it moves from bounded product or service problems into complex institutions. A design team working on a single interface can often identify users, test a prototype, and improve a workflow within a relatively contained environment. Institutions are different. They are made of rules, incentives, histories, budgets, authority structures, professional cultures, policies, technologies, data systems, legal obligations, public expectations, frontline improvisations, and informal norms that shape what can actually change.
Complex institutions include public agencies, universities, hospitals, courts, school systems, research institutions, foundations, international organizations, large nonprofits, regulatory bodies, civic infrastructure systems, and mature corporations. In these settings, design problems rarely belong to one team. They cross departments, professions, jurisdictions, technologies, funding streams, service channels, and layers of accountability. They affect people differently depending on their role: residents, patients, students, clients, frontline staff, managers, executives, regulators, funders, partners, advocates, researchers, and communities affected by institutional decisions.
Main Library
Publications
Article Map
Design Thinking
Related Topic
Institutions & Governance
Related Topic
Organizational Psychology
Related Topic
Risk & Resilience

For this reason, design thinking for complex institutions cannot be reduced to empathy interviews, workshops, journey maps, sticky notes, and prototypes. Those practices can help, but they are not enough. Institutional design requires systems thinking, governance analysis, stakeholder mapping, policy awareness, organizational psychology, implementation planning, data infrastructure, ethical review, and long-term learning. It must ask not only what people need, but what the institution is capable of changing, what it is incentivized to ignore, where authority sits, how decisions are made, and why previous reform efforts failed.
The central challenge is that complex institutions often generate the very problems they are trying to solve. A public agency may want to improve access while its eligibility rules create administrative burden. A hospital may want patient-centered care while scheduling, billing, staffing, documentation, and insurance systems fragment the patient experience. A university may promote interdisciplinary learning while departments, budgets, tenure structures, and curricular systems preserve silos. A nonprofit may value community participation while grant cycles and reporting requirements push it toward funder-defined metrics.
Design thinking can help complex institutions change, but only when it becomes institutionally literate. It must understand how formal rules interact with informal routines, how mission statements differ from incentives, how frontline workers repair broken systems, how marginalized groups experience institutional burden, and how implementation depends on governance. The goal is not simply to make institutional services more user-friendly. It is to help institutions become more responsive, accountable, adaptive, and capable of learning.
Design thinking for complex institutions connects directly to what design thinking is, human-centered problem solving, empathy and stakeholder research, problem framing, insight generation, prototyping, testing and validation, implementation and scaling, evaluation, learning, and outcome measurement, service design, design thinking and strategy, ethics, power, and inclusion, data systems and AI-assisted research, co-design and participatory design, public policy, and organizational innovation.
What Design Thinking for Complex Institutions Means
Design thinking for complex institutions is the application of human-centered, systems-aware, evidence-based, and governance-conscious design methods to organizations and public systems where problems are distributed across many actors, rules, technologies, incentives, histories, and forms of authority. It extends design thinking beyond individual user experience into institutional experience: how people encounter, navigate, depend on, resist, work within, and are shaped by institutions.
This form of design thinking does not abandon empathy, prototyping, or iteration. It places them inside a larger institutional analysis. Empathy must include people served by the institution and people working within it. Prototyping must include policies, workflows, decision rules, data systems, service channels, governance structures, and implementation responsibilities. Iteration must include feedback from frontline staff, affected communities, managers, legal teams, finance teams, technology teams, data owners, and accountability bodies.
| Traditional design-thinking focus | Institutional design-thinking focus |
|---|---|
| User pain points | Institutional burden, service failure, policy constraints, and uneven access. |
| Customer journey | Institutional journey across departments, rules, roles, channels, and decision systems. |
| Prototype | Service, policy, workflow, data, governance, and implementation prototype. |
| Usability | Access, legitimacy, accountability, burden reduction, trust, and institutional learning. |
| Stakeholder research | Multi-level research across users, staff, leaders, partners, regulators, and affected communities. |
| Iteration | Learning loops tied to governance, resources, authority, and long-term outcomes. |
| Scaling | Institutional absorption, capability building, policy alignment, and change governance. |
Complex institutions require design thinking to become more patient and more rigorous. A workshop may reveal a problem, but it rarely changes the authority structure that sustains it. A prototype may improve a touchpoint, but it may fail if the data system, staffing model, policy rule, or budget cycle cannot support it. A strategy may sound compelling, but it may be absorbed by routines that preserve the existing system.
Design thinking for complex institutions therefore asks: what must change in the institution for the design to become real?
Why Complex Institutions Need a Different Design Approach
Complex institutions are responsible for many problems that simple design methods cannot solve. A confusing public form may reflect legal requirements, risk management, outdated data infrastructure, staff capacity, and political distrust. A poor patient experience may reflect scheduling algorithms, insurance rules, clinical documentation, staffing ratios, departmental silos, and financial incentives. A weak student experience may reflect advising systems, curricular complexity, financial aid rules, housing, mental-health capacity, and departmental autonomy.
In these environments, design thinking must avoid superficial solutionism. Making a form clearer may help, but it may not reduce the underlying documentation burden. Creating a dashboard may improve visibility, but it may not change decision authority. Launching a pilot may demonstrate promise, but it may not survive procurement rules, union agreements, legal constraints, or budget cycles. Adding AI may accelerate research, but it may also amplify institutional bias if the data reflects historical exclusion.
| Institutional problem | Simple design response | Institutionally literate response |
|---|---|---|
| People cannot complete a service process. | Simplify the interface. | Examine eligibility rules, documentation requirements, service channels, support pathways, language access, and appeal rights. |
| Staff resist a new system. | Improve training and communication. | Analyze workload, trust, incentives, professional identity, staffing, decision rights, and hidden labor. |
| Departments do not collaborate. | Hold a cross-functional workshop. | Redesign governance, shared goals, funding, accountability, data access, and coordination routines. |
| Equity outcomes are weak. | Add diverse participants to research. | Study unequal burden, historical exclusion, disaggregated outcomes, power, accessibility, and institutional accountability. |
| A pilot works but does not scale. | Create a rollout plan. | Assess institutional absorption, capability gaps, resource commitments, policy alignment, and feedback governance. |
| Leaders lack visibility into problems. | Build a dashboard. | Connect metrics to qualitative evidence, decision rituals, accountability, and action authority. |
| AI is proposed as a solution. | Prototype an AI tool. | Ask whether the problem requires AI, what data it uses, who is harmed by errors, and what governance is required. |
Complex institutions need design thinking because institutional problems are experienced by people. But they need a different design approach because institutional problems are not solved by understanding experience alone. They are solved when experience, authority, policy, infrastructure, incentives, and learning systems are redesigned together.
The purpose of institutional design thinking is not to make institutions appear more innovative. It is to help institutions become more capable of serving the people and publics they exist to serve.
The Nature of Institutional Complexity
Institutional complexity arises when many interacting parts shape outcomes in ways no single actor fully controls. Institutions have formal rules, but they also have informal routines. They have official strategies, but they also have incentives. They have organizational charts, but actual work often flows through relationships, workarounds, legacy systems, professional judgment, and local adaptations.
Complex institutions are also layered across time. Current services reflect old policies, past crises, inherited technologies, accumulated exceptions, political compromises, professional norms, and prior reform efforts. A design team entering the system encounters not a blank slate, but a sedimented history of decisions. Many institutional problems are not the result of one bad design choice. They are the result of accumulated adaptations that made sense locally but created system-level burden.
| Source of complexity | How it appears | Design implication |
|---|---|---|
| Multiple missions | The institution must serve access, compliance, efficiency, equity, risk control, and accountability at once. | Design must surface trade-offs rather than pretending all goals align. |
| Layered authority | Decisions depend on managers, executives, boards, regulators, funders, professional groups, and external rules. | Design teams must map decision rights before proposing solutions. |
| Professional cultures | Different groups hold different values, evidence standards, languages, and responsibilities. | Design must translate across professional logics without flattening expertise. |
| Legacy systems | Old technology and data structures shape what is possible. | Prototypes must account for infrastructure and migration constraints. |
| Policy constraints | Rules, eligibility criteria, compliance requirements, and statutory obligations shape service design. | Design must distinguish what is legally fixed from what is locally interpreted. |
| Distributed burden | Efficiency in one unit may create labor elsewhere. | Design must measure total burden, including hidden work by users and staff. |
| Informal repair | Frontline staff create workarounds to make broken systems function. | Design must learn from repair work without exploiting it. |
| Political legitimacy | Institutional decisions may be contested by publics, communities, or stakeholders. | Design must include legitimacy, not only operational performance. |
This complexity does not make design impossible. It changes the unit of design. Instead of designing only a form, website, workflow, or product, teams must design relationships between rules, roles, tools, evidence, authority, and experience. The design object becomes the institutional system.
The first task is therefore diagnostic. What is the system actually doing? Whose work keeps it functioning? Where does burden accumulate? Which rules are real constraints, and which are habits disguised as rules? What does the institution measure? What does it ignore? Where can small changes unlock larger learning?
Institutional Problem Framing
Problem framing is especially consequential in complex institutions because the initial frame often reflects the institution’s own perspective. A university may frame the problem as student disengagement. Students may frame it as fragmented advising, financial stress, unclear requirements, and lack of belonging. A public agency may frame the problem as low compliance. Residents may frame it as confusing rules, fear of penalty, inaccessible language, and lack of trust. A hospital may frame the problem as missed appointments. Patients may frame it as scheduling barriers, transportation, caregiving, cost, and communication failures.
Institutional problem framing asks whether the problem has been named from the perspective of power or from the perspective of lived experience. It also asks whether the institution has framed symptoms as causes. Low participation, low completion, staff resistance, customer dissatisfaction, and weak adoption are often symptoms of deeper system design.
| Institution-centered frame | Possible deeper frame |
|---|---|
| Users do not complete the process. | The process imposes excessive documentation, uncertainty, language, time, or trust burden. |
| Staff are resistant to change. | The change increases workload, threatens professional identity, or lacks credible support. |
| Departments are not aligned. | Governance, incentives, funding, and accountability are fragmented. |
| People do not understand the policy. | The policy may be too complex, poorly justified, inaccessible, or inconsistently applied. |
| Innovation does not scale. | The institution lacks absorption capacity, implementation authority, and long-term ownership. |
| Data is not used in decisions. | Decision rituals, incentives, trust, and data governance do not support learning. |
| Communities lack trust. | The institution has a history of exclusion, broken promises, surveillance, or unequal treatment. |
Institutional framing should include at least four layers: lived experience, operational process, governance structure, and historical context. Lived experience shows how people encounter the system. Operational process shows how work actually happens. Governance shows who has authority to change conditions. Historical context explains why trust, burden, or resistance may exist.
A strong institutional design frame does not ask only “How might we improve this service?” It asks: “What institutional conditions produce this experience, and which of those conditions must change?”
Stakeholders, Roles, and Conflicting Accountabilities
Institutional design involves many stakeholders with legitimate but conflicting accountabilities. Frontline staff may be accountable for service delivery. Managers may be accountable for efficiency. Legal teams may be accountable for risk. Finance teams may be accountable for budget constraints. Data teams may be accountable for privacy and system integrity. Community members may be accountable to lived realities that the institution has historically ignored. Leaders may be accountable to boards, regulators, voters, funders, or markets.
Design thinking in this setting requires more than stakeholder mapping. It requires accountability mapping. Each stakeholder’s incentives, constraints, risks, decision rights, and success measures must be understood. Without this, design teams may mistake disagreement for resistance, when it may reflect real institutional tensions.
| Stakeholder group | Common accountability | Design risk if ignored |
|---|---|---|
| People served by the institution | Access, dignity, outcomes, clarity, safety, and fairness. | Solutions may improve internal metrics while preserving external burden. |
| Frontline staff | Real-time service delivery, exception handling, care, compliance, and repair. | Design may increase hidden labor or create unworkable processes. |
| Middle managers | Coordination, staffing, performance, and operational continuity. | Pilots may fail because ownership and capacity are unclear. |
| Executives | Strategy, budget, legitimacy, risk, and institutional reputation. | Design may remain tactical if strategic sponsorship is weak. |
| Legal and compliance teams | Rules, liability, rights, regulation, and procedural protection. | Design may be blocked if legal constraints are misunderstood. |
| Technology and data teams | Systems, security, privacy, interoperability, and technical feasibility. | Design may assume infrastructure that does not exist. |
| Community partners | Trust, lived expertise, advocacy, legitimacy, and accountability. | Participation may become symbolic if power is not shared. |
| Funders or oversight bodies | Performance, reporting, mission alignment, and stewardship. | Metrics may narrow the design problem to what is fundable or reportable. |
Conflicting accountabilities should not be hidden. They should be designed around. If a project requires frontline staff to absorb more work, the design must include staffing, training, tools, and workflow redesign. If a project requires legal interpretation, legal teams should be involved early. If the project affects marginalized communities, those communities should have influence over framing, evidence, and evaluation.
Institutional design thinking is strongest when it makes conflict visible before implementation. Conflict discovered early can become design intelligence. Conflict discovered late becomes failure.
Governance, Authority, and Decision Rights
Governance determines whether design work can actually change an institution. It defines who can approve, fund, stop, revise, scale, or maintain a design. Many institutional design efforts fail not because the ideas are weak, but because governance is unclear. Teams generate recommendations without knowing who owns the decision. Pilots succeed without a scaling authority. Research identifies systemic problems that no one has permission to address.
Design thinking for complex institutions should map decision rights as carefully as it maps user journeys. A design team should know which decisions are local, which require executive sponsorship, which are constrained by law, which depend on budget cycles, which require union or professional negotiation, which involve data governance, and which require public or community accountability.
| Governance question | Why it matters |
|---|---|
| Who owns the problem? | Institutional problems often cross units, so ownership may be fragmented or absent. |
| Who can approve the change? | Design recommendations fail when approval authority is unclear. |
| Who controls the budget? | Implementation requires resources, not only agreement. |
| Who controls the policy or rule? | Some design barriers are embedded in eligibility, compliance, or procedural requirements. |
| Who controls the data system? | Service and AI redesign often depend on data access, quality, security, and interoperability. |
| Who must be consulted? | Legitimacy may require staff, community, legal, regulatory, or stakeholder review. |
| Who can pause or stop the design? | Ethical governance requires authority to respond to harm or failure. |
| Who maintains the design after launch? | Institutional design fails when maintenance is not assigned and funded. |
Governance should also be designed for learning. Institutions often have approval processes but weak learning processes. They can launch programs, but they may not have strong mechanisms for asking whether a program is working, for whom, under what conditions, and with what unintended consequences. Design thinking can help build learning governance: review cycles, evidence thresholds, decision logs, escalation paths, public reporting, and adaptation rules.
Without governance, design thinking remains advisory. With governance, design thinking can become institutional capability.
Frontline Work, Hidden Labor, and Institutional Repair
Frontline workers often know more about institutional reality than formal process maps reveal. They see where policies fail, where data is wrong, where people are confused, where systems do not talk to each other, where exceptions occur, and where people need help that the official process does not provide. They often perform hidden repair work: calling another department, correcting records, explaining confusing rules, translating institutional language, finding workarounds, calming frustration, and protecting people from system failure.
Institutional design thinking must treat frontline knowledge as evidence. But it must also avoid exploiting frontline repair. If a design depends on staff goodwill, unpaid emotional labor, or constant workaround behavior, it is not a sustainable design. The goal is not to celebrate heroic staff who make broken systems work. The goal is to redesign the conditions that require heroism.
| Frontline signal | What it may indicate | Design response |
|---|---|---|
| Staff repeatedly explain the same rule. | The rule, message, or process is unclear. | Redesign language, timing, channel, eligibility explanation, or support pathway. |
| Staff keep manual spreadsheets outside the official system. | The official data system does not support actual work. | Study workflow needs, data structure, and system constraints. |
| Staff rely on informal contacts to solve cases. | Formal escalation and coordination channels are weak. | Design accountable handoffs and escalation routines. |
| Staff avoid using a required tool. | The tool may create workload, risk, duplication, or poor fit. | Evaluate tool usability, incentives, training, and workflow integration. |
| Staff absorb user anger or confusion. | The institution has shifted burden to frontline emotional labor. | Reduce upstream burden and create clearer recovery paths. |
| Staff create exceptions for vulnerable cases. | The formal process may be too rigid or inequitable. | Examine discretion, eligibility, due process, and support design. |
Frontline research should include observation, interviews, shadowing, workflow mapping, artifact review, service blueprinting, and repair mapping. It should ask what staff are officially supposed to do, what they actually do, what workarounds they use, what risks they carry, what tools fail them, and what they would change if authority and resources were available.
Good institutional design reduces hidden labor. It does not merely redistribute it.
Service Systems, Policy, and Backstage Infrastructure
Institutions deliver value through service systems. A service is not only a front-facing interaction. It is a chain of policies, roles, technologies, data flows, communications, facilities, documents, budgets, permissions, and handoffs. People experience the visible service, but the visible service is shaped by backstage infrastructure.
Service design becomes institutional design when it includes the backstage. A confusing message may originate from a legal template. A slow process may originate from staffing rules. A poor digital experience may originate from incompatible databases. A repeated documentation request may originate from risk policies. A lack of accessibility may originate from procurement standards. A failed handoff may originate from unclear responsibility between units.
| Service layer | Institutional design concern |
|---|---|
| Frontstage interaction | What people see, hear, read, submit, receive, and experience. |
| Backstage workflow | How staff process, interpret, escalate, approve, deny, and repair. |
| Policy layer | Rules, eligibility, rights, obligations, exceptions, and discretion. |
| Data layer | Records, identifiers, quality, sharing, privacy, interoperability, and reporting. |
| Technology layer | Systems, interfaces, automation, AI tools, security, and integration. |
| Governance layer | Decision rights, oversight, accountability, review, and escalation. |
| Resource layer | Budget, staffing, procurement, training, capacity, and maintenance. |
| Trust layer | Legitimacy, transparency, fairness, historical memory, and repair. |
Institutional service design should identify which layer is producing the problem. If the frontstage experience is poor because the policy is contradictory, interface design alone will not fix it. If staff cannot deliver a redesigned service because the staffing model is inadequate, training alone will not fix it. If people distrust the institution because of past harm, clearer messaging alone will not restore trust.
The service system is the design object. The visible touchpoint is only one part of it.
Data Systems and Institutional Learning
Data systems shape what institutions can see and learn. If an institution does not track who abandons a process, it may assume the process works. If it tracks completion but not burden, it may mistake persistence for good design. If it tracks average satisfaction but not group-level disparities, it may miss exclusion. If it tracks internal processing time but not user time, it may optimize institutional efficiency while shifting labor to the public.
Data systems are therefore not merely technical infrastructure. They are institutional sense-making systems. They define what becomes visible, what is counted, what is ignored, and what leaders are likely to act on. Design thinking for complex institutions must include data-system analysis because many institutional failures are maintained by measurement gaps.
| Data-system question | Design importance |
|---|---|
| What is measured? | Reveals what the institution values and manages. |
| What is not measured? | Reveals blind spots such as burden, exclusion, dignity, trust, or hidden labor. |
| Who is missing from the data? | Identifies non-users, abandoners, marginalized groups, and people outside tracked channels. |
| How is data categorized? | Shows whether institutional categories reflect lived realities or administrative convenience. |
| Who can access the data? | Determines whether evidence can inform decisions across units. |
| Who can challenge the data? | Protects against misclassification, error, and institutional overconfidence. |
| How are decisions linked to evidence? | Creates traceability between research, policy, design, implementation, and outcomes. |
| How is learning governed? | Ensures evidence leads to review, adaptation, and accountability. |
AI-assisted research increases the importance of data governance. Institutions may use AI to summarize feedback, classify cases, retrieve research, or support decision-making. But AI systems inherit the limitations of the data and institutions that produce them. If research repositories are incomplete, if metadata is weak, if consent is unclear, if minority signals are underrepresented, AI-assisted synthesis may produce confident but misleading findings.
Institutional learning requires more than dashboards. It requires evidence that is traceable, disaggregated, interpreted with context, connected to decisions, and reviewed through governance structures that can act.
Ethics, Public Value, and Unequal Burden
Institutions distribute burden and benefit. They decide who must wait, prove, explain, travel, appeal, comply, disclose, repeat, pay, translate, learn a system, or ask for help. They also decide who receives access, protection, recognition, investment, discretion, trust, and repair. Design thinking for complex institutions must therefore be ethical from the beginning, not only after a solution is proposed.
Public value matters even when the institution is not a government agency. Universities, hospitals, foundations, nonprofits, and large civic or technical systems all shape social goods. They affect knowledge, care, opportunity, safety, participation, legitimacy, and trust. A design that improves efficiency but increases exclusion is not a good institutional design. A design that reduces cost by shifting work to already-burdened people is not a neutral improvement.
| Ethical dimension | Institutional design question |
|---|---|
| Access | Who can actually use the service, process, or system? |
| Burden | Who must spend time, effort, money, emotion, documentation, or coordination to succeed? |
| Dignity | Does the institution treat people as capable, respected, and worthy of clear explanation? |
| Power | Who defines the problem, interprets evidence, and decides what changes? |
| Accountability | Can people challenge errors, appeal decisions, receive reasons, and obtain repair? |
| Equity | Do outcomes improve across groups, especially for those historically excluded or overburdened? |
| Transparency | Can people understand the process, decision rules, and consequences? |
| Public value | Does the design strengthen the institution’s legitimate purpose and social responsibility? |
Ethical institutional design requires disaggregated evidence. Average outcomes can hide severe harm. A redesigned service may improve completion overall while worsening access for disabled users, limited-English speakers, rural users, older adults, caregivers, low-income households, frontline staff, or people with low institutional trust. A new AI system may improve speed while increasing opacity and appeal burden.
Institutional design should therefore include burden audits, accessibility review, participatory interpretation, privacy review, public-value analysis, and repair pathways. The question is not only whether the institution works better. It is whether it works better without shifting harm elsewhere.
Prototyping Inside Institutions
Prototyping inside institutions is different from prototyping a product interface. Institutional prototypes may include service scripts, policy interpretations, workflow changes, decision rules, training routines, data-sharing agreements, governance meetings, escalation pathways, staffing models, dashboards, communication templates, access supports, or new forms of participation.
The purpose of institutional prototyping is to test whether a change can work inside real constraints. A prototype should test human desirability, operational feasibility, policy fit, technical feasibility, legal acceptability, ethical risk, frontline workload, data requirements, and governance readiness. A prototype that only tests user preference may miss the conditions that determine implementation.
| Prototype type | What it tests | Institutional risk |
|---|---|---|
| Service-script prototype | How staff explain a process, decision, or next step. | May fail if policy language, training, or staffing do not support it. |
| Workflow prototype | How work moves across roles and systems. | May shift burden to another team or create hidden labor. |
| Policy prototype | How a rule, eligibility interpretation, or exception pathway operates. | May require legal review, consistency, and due-process safeguards. |
| Data prototype | How evidence, records, or metrics are captured and used. | May create privacy, quality, interoperability, or governance problems. |
| Governance prototype | How decisions are reviewed, escalated, and adapted. | May lack authority, cadence, or ownership. |
| AI-assisted prototype | How AI supports research, triage, retrieval, or synthesis. | May create bias, opacity, surveillance, or overreliance. |
| Participation prototype | How affected groups shape interpretation or decisions. | May become symbolic if decision power is unchanged. |
Institutional prototypes should be explicit about risk and reversibility. Some prototypes can be low-risk experiments. Others affect access, rights, care, benefits, employment, privacy, or dignity. High-stakes prototypes need safeguards, consent, monitoring, escalation, and repair. In some cases, it may be unethical to prototype directly with affected people until safeguards are stronger.
The strongest institutional prototypes test the whole change ecology: the people, the process, the rule, the system, the data, the authority, and the learning loop.
Implementation, Scaling, and Institutional Absorption
Implementation is where many institutional design projects fail. A design may be desirable, evidence-based, and strategically aligned, yet still fail because the institution cannot absorb it. Absorption means the institution has the capacity, authority, resources, routines, data systems, skills, incentives, and governance needed to make the design part of normal operation.
Scaling is not merely expanding a successful pilot. It is changing the conditions under which the pilot worked. A pilot may depend on exceptional staff, temporary funding, special permissions, manual workarounds, or unusual executive attention. When scaled, those conditions disappear. The design must therefore be tested not only for effectiveness, but for institutional durability.
| Implementation factor | Failure mode if ignored | Design requirement |
|---|---|---|
| Ownership | No team is responsible after the pilot ends. | Assign durable operational and governance ownership. |
| Capacity | Staff cannot perform the new work at scale. | Plan staffing, training, tools, and workload redistribution. |
| Funding | The pilot relies on temporary resources. | Secure sustainable budget and maintenance commitments. |
| Policy fit | The design conflicts with formal rules or interpretations. | Align policy, procedure, legal review, and discretion. |
| Data infrastructure | The design requires data the institution cannot capture or share. | Build data governance, quality, access, and interoperability. |
| Incentives | Existing metrics reward old behavior. | Align performance measures with the intended change. |
| Culture | The design conflicts with professional identity or trust. | Use participation, explanation, leadership, and learning rituals. |
| Accountability | Harms or failures are not detected after launch. | Create monitoring, escalation, repair, and review mechanisms. |
Institutional absorption should be assessed before scale. A design is not ready to scale simply because users liked it or a pilot improved metrics. It is ready when the institution can deliver it reliably, fund it, govern it, monitor it, repair it, and adapt it.
Implementation is not the end of design. In complex institutions, implementation is design under real conditions.
Resistance, Incentives, and Organizational Culture
Institutional resistance is often treated as a communication problem. Leaders say people need to understand the change. Design teams say stakeholders need to be brought along. Sometimes that is true. But resistance can also be intelligent. People may resist because the change is under-resourced, poorly governed, misaligned with professional ethics, based on weak evidence, or likely to increase burden.
Design thinking should treat resistance as data. Who resists? What do they know? What risks do they see? What past failures shape their expectations? What incentives make the existing system rational? What losses does the change create? What forms of trust are missing?
| Resistance signal | Possible interpretation | Design response |
|---|---|---|
| Staff say the new process is unrealistic. | The design may not fit workload, staffing, tools, or timing. | Prototype with frontline staff and measure hidden labor. |
| Managers delay implementation. | Accountability, funding, or decision rights may be unclear. | Clarify governance, ownership, and resource commitments. |
| Legal or compliance teams raise concerns. | The design may affect rights, privacy, consistency, or due process. | Involve legal review early and distinguish fixed rules from interpretations. |
| Communities distrust the process. | Previous engagement may have been extractive or symbolic. | Build participation, reciprocity, transparency, and repair. |
| Technology teams push back. | The design may depend on fragile infrastructure or unrealistic integration. | Map technical dependencies and sequence implementation. |
| Executives lose interest. | The design may lack strategic alignment or visible accountability. | Connect evidence to institutional goals, risks, and governance rituals. |
Incentives are often stronger than intentions. If performance measures reward speed, staff will prioritize speed. If reporting requirements reward outputs, teams will optimize outputs. If budgets are siloed, collaboration will be difficult. If risk is punished but learning is not rewarded, people will avoid experimentation. Design thinking must therefore examine the incentive system surrounding the desired behavior.
Culture is not changed by slogans. It changes when routines, incentives, authority, evidence, and relationships change together.
Evaluation and Learning in Complex Institutions
Evaluation in complex institutions should measure more than whether a design launched or whether users were satisfied. It should ask whether the design reduced burden, improved access, strengthened trust, changed outcomes, supported staff, shifted incentives, improved accountability, and became part of institutional learning.
Because institutional systems are complex, evaluation should use multiple forms of evidence. Quantitative measures can show scale, distribution, timing, and outcome patterns. Qualitative research can explain lived experience, trust, meaning, and hidden burden. Frontline evidence can reveal implementation failure. Data-system evidence can show process flow and system reliability. Community review can test legitimacy. Governance records can show whether evidence changed decisions.
| Evaluation domain | Possible indicators |
|---|---|
| Access | Completion by channel, language, disability, geography, income, age, or support need. |
| Burden | Time, steps, documents, repeated contacts, cognitive load, emotional stress, and coordination work. |
| Service quality | Accuracy, timeliness, clarity, recovery, continuity, and handoff success. |
| Staff experience | Workload, autonomy, morale, training adequacy, hidden labor, and tool fit. |
| Equity | Disaggregated outcomes and burden across affected groups. |
| Trust and legitimacy | Perceived fairness, transparency, responsiveness, and willingness to reengage. |
| Implementation readiness | Ownership, funding, staffing, policy alignment, and data-system support. |
| Learning | Review cadence, decision changes, evidence updates, and adaptation after feedback. |
Evaluation should include stop, pivot, and scale criteria. Before implementation, the institution should define what evidence would justify expansion, what evidence would require redesign, and what evidence would require stopping. Without these thresholds, institutions often continue programs because they have already invested in them, not because they are working.
Learning must also be governed. Evidence should have a path to authority. If evaluation findings cannot change budgets, policies, staffing, technology, or leadership priorities, then evaluation becomes documentation rather than learning.
Critiques and Limits
Design thinking has limits in complex institutions. It cannot substitute for political will, legal reform, funding, labor rights, public accountability, democratic participation, or institutional courage. Some institutional problems are not design problems in the narrow sense. They are problems of power, resource distribution, law, ideology, or governance. Design methods can help reveal them, but they cannot solve them alone.
There is also a risk that institutions use design thinking to appear responsive without changing authority. Workshops can become rituals. Participation can become symbolic. Innovation labs can become isolated. Prototypes can become demonstrations that never alter core operations. Human-centered language can soften institutions without making them more accountable.
| Limit | What can go wrong | Responsible response |
|---|---|---|
| Design theater | Workshops create the appearance of change without shifting decisions. | Connect design work to governance, budget, authority, and implementation. |
| Participation washing | Stakeholders are consulted but cannot influence outcomes. | Name the level of participation honestly and document influence. |
| Innovation isolation | Design teams create promising pilots outside core institutional routines. | Design for absorption, ownership, policy fit, and operational capacity. |
| Method over power | Design methods are used to avoid confronting structural constraints. | Escalate issues that require law, funding, rights, or governance change. |
| Metric capture | Institutions optimize what is measurable while ignoring dignity or trust. | Use mixed methods and disaggregated evidence. |
| AI solutionism | AI is introduced to complex institutional problems before the human system is understood. | Assess whether AI is appropriate and govern data, bias, privacy, and accountability. |
| Overload | Teams try to redesign everything and lose focus. | Identify leverage points, sequence work, and match scope to authority. |
The answer is not to abandon design thinking. The answer is to practice it with institutional humility. Design teams must know when a problem can be prototyped, when it requires governance change, when it requires policy change, when it requires community authority, and when it should not be framed as a design challenge at all.
Design thinking becomes stronger when it recognizes its limits.
Cross-Pillar Connections
Design thinking for complex institutions connects several domains. Institutions and governance provide the language of authority, legitimacy, rules, accountability, and decision rights. Organizational psychology helps explain culture, identity, resistance, leadership, motivation, and group behavior. Risk and resilience help institutions understand uncertainty, failure modes, adaptation, and system stress. Data systems and analytics provide evidence infrastructure. AI systems introduce governance challenges around bias, privacy, automation, and accountability.
Service design connects institutional complexity to journeys, touchpoints, backstage workflows, and handoffs. Behavioral design helps explain friction, adoption, trust, and decision environments. Ethics and inclusion examine power, burden, dignity, accessibility, and public value. Public policy connects design to law, administrative burden, legitimacy, and collective responsibility.
| Related field | Contribution to institutional design thinking |
|---|---|
| Institutions & Governance | Authority, legitimacy, accountability, decision rights, public value, and institutional trust. |
| Organizational Psychology | Culture, leadership, motivation, resistance, identity, team dynamics, and change behavior. |
| Risk & Resilience | Failure modes, adaptation, stress testing, recovery, continuity, and uncertainty management. |
| Data Systems & Analytics | Measurement, dashboards, evidence pipelines, data quality, and learning infrastructure. |
| Artificial Intelligence Systems | Automation, decision support, research synthesis, bias risk, monitoring, and AI governance. |
| Service Design | Frontstage and backstage service systems, touchpoints, workflows, and recovery pathways. |
| Ethics, Power, and Inclusion | Burden, access, dignity, participation, accessibility, consent, and unequal consequences. |
| Public Policy | Rules, rights, administrative burden, policy implementation, and public accountability. |
The broader lesson is that complex institutional design is interdisciplinary. It cannot be owned by design alone. It requires collaboration among people who understand lived experience, operations, technology, law, finance, policy, ethics, data, governance, and implementation.
Design thinking is valuable in this environment because it can integrate these forms of knowledge around human consequences. But it must remain connected to institutional reality.
Mathematical Lens: Modeling Institutional Change Readiness
Institutional change readiness can be modeled as a weighted relationship between desirability, authority, capability, resources, policy fit, data readiness, trust, and governance. A simple readiness model might be:
R_i = w_dD_i + w_aA_i + w_cC_i + w_fF_i + w_pP_i + w_gG_i + w_tT_i – w_bB_i – w_kK_i
\]
Interpretation: Readiness for institutional design option \(i\) increases with desirability, authority, capability, funding, policy fit, governance, and trust, but decreases with burden and coordination complexity.
Institutional absorption can be modeled separately. A design may be promising but hard to absorb if it requires new capabilities, new data systems, new governance, or new staffing.
A_i = \alpha O_i + \beta S_i + \gamma M_i + \delta L_i + \theta Q_i
\]
Interpretation: Absorption depends on ownership, staffing, maintenance, learning routines, and quality of operational support.
Burden should also be modeled directly. Institutional improvements often look successful internally while shifting cost outward.
B_g = \lambda T_g + \mu C_g + \nu E_g + \rho D_g + \sigma U_g
\]
Interpretation: Burden for group \(g\) includes time, cognitive load, emotional stress, documentation, and uncertainty.
These models do not automate institutional judgment. They make assumptions visible. They help teams ask whether a design is desirable but unauthorizable, promising but underfunded, ethical but operationally unsupported, efficient internally but burdensome externally, or scalable only if governance changes first.
R Workflow: Institutional Complexity and Change Readiness
The R workflow below models institutional design options using change readiness, absorption capacity, burden reduction, governance strength, and implementation risk. It is intended as a decision-support example rather than an automated institutional decision model.
# Install packages if needed.
# install.packages(c("tidyverse", "scales"))
library(tidyverse)
library(scales)
institutional_options <- tibble(
option = c(
"Simplify eligibility pathway",
"Create assisted access model",
"Redesign cross-department handoffs",
"Build institutional learning dashboard",
"Prototype community accountability board",
"Modernize legacy case-management data",
"Redesign frontline escalation process",
"Create AI-assisted research synthesis workflow"
),
desirability = c(8.8, 9.0, 8.2, 7.6, 8.4, 7.8, 8.6, 7.4),
authority = c(6.4, 6.8, 5.8, 7.2, 5.4, 6.0, 7.0, 6.6),
capability = c(6.8, 6.4, 5.6, 7.0, 5.8, 5.2, 7.2, 6.2),
funding = c(6.6, 6.2, 5.8, 6.8, 5.4, 5.0, 6.6, 6.0),
policy_fit = c(6.0, 6.4, 6.8, 7.4, 5.8, 7.0, 7.2, 6.6),
governance_strength = c(6.2, 6.4, 5.6, 7.2, 5.8, 6.0, 7.0, 6.4),
trust_gain = c(8.2, 8.8, 7.6, 6.8, 9.0, 6.4, 7.8, 6.6),
burden_reduction = c(8.6, 8.4, 7.4, 6.2, 7.8, 6.8, 8.0, 6.4),
coordination_complexity = c(6.8, 7.2, 8.6, 6.4, 7.8, 8.8, 6.6, 7.4),
implementation_risk = c(5.8, 6.2, 7.4, 5.6, 6.8, 8.0, 5.4, 6.6)
)
scores <- institutional_options %>%
mutate(
change_readiness =
0.16 * desirability +
0.15 * authority +
0.14 * capability +
0.12 * funding +
0.12 * policy_fit +
0.13 * governance_strength +
0.10 * trust_gain +
0.08 * burden_reduction -
0.05 * coordination_complexity -
0.05 * implementation_risk,
absorption_capacity =
0.25 * authority +
0.25 * capability +
0.20 * funding +
0.15 * governance_strength +
0.15 * policy_fit,
public_value_priority =
0.30 * burden_reduction +
0.25 * trust_gain +
0.20 * desirability +
0.15 * policy_fit -
0.10 * implementation_risk,
sequencing_need =
0.35 * coordination_complexity +
0.30 * implementation_risk +
0.20 * (10 - authority) +
0.15 * (10 - capability),
recommended_action = case_when(
change_readiness >= 7.1 & absorption_capacity >= 6.6 ~ "scale_with_governance",
public_value_priority >= 7.2 & absorption_capacity < 6.4 ~ "prototype_then_build_capacity",
sequencing_need >= 7.0 ~ "sequence_after_governance_and_capability_work",
implementation_risk >= 7.4 ~ "risk_review_before_pilot",
TRUE ~ "pilot_with_learning_metrics"
)
) %>%
arrange(desc(change_readiness))
print(scores)
portfolio_summary <- scores %>%
group_by(recommended_action) %>%
summarize(
options = n(),
mean_readiness = mean(change_readiness),
mean_absorption = mean(absorption_capacity),
mean_public_value = mean(public_value_priority),
mean_sequencing_need = mean(sequencing_need),
.groups = "drop"
) %>%
arrange(desc(mean_public_value))
print(portfolio_summary)
ggplot(scores, aes(x = absorption_capacity, y = public_value_priority, size = burden_reduction, label = option)) +
geom_point(alpha = 0.75) +
geom_text(check_overlap = TRUE, vjust = -0.8, size = 3) +
labs(
title = "Institutional Design Portfolio: Absorption Capacity vs Public Value",
x = "Institutional absorption capacity",
y = "Public value priority",
size = "Burden reduction"
) +
theme_minimal(base_size = 12)
write_csv(scores, "institutional_design_option_scores.csv")
write_csv(portfolio_summary, "institutional_design_portfolio_summary.csv")
This workflow helps institutional teams distinguish options that are ready to scale from options that need governance, capacity, policy, or implementation work first. It also keeps public value and burden reduction visible alongside feasibility.
Python Workflow: Institutional Design Portfolio Simulation
The Python workflow below simulates institutional design portfolio uncertainty. It asks which options remain strong when scores for authority, capability, funding, governance, trust, burden reduction, coordination complexity, and implementation risk vary.
# Install packages if needed:
# pip install pandas numpy matplotlib scipy
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
options = pd.DataFrame({
"option": [
"Simplify eligibility pathway",
"Create assisted access model",
"Redesign cross-department handoffs",
"Build institutional learning dashboard",
"Prototype community accountability board",
"Modernize legacy case-management data",
"Redesign frontline escalation process",
"Create AI-assisted research synthesis workflow"
],
"desirability": [8.8, 9.0, 8.2, 7.6, 8.4, 7.8, 8.6, 7.4],
"authority": [6.4, 6.8, 5.8, 7.2, 5.4, 6.0, 7.0, 6.6],
"capability": [6.8, 6.4, 5.6, 7.0, 5.8, 5.2, 7.2, 6.2],
"funding": [6.6, 6.2, 5.8, 6.8, 5.4, 5.0, 6.6, 6.0],
"policy_fit": [6.0, 6.4, 6.8, 7.4, 5.8, 7.0, 7.2, 6.6],
"governance_strength": [6.2, 6.4, 5.6, 7.2, 5.8, 6.0, 7.0, 6.4],
"trust_gain": [8.2, 8.8, 7.6, 6.8, 9.0, 6.4, 7.8, 6.6],
"burden_reduction": [8.6, 8.4, 7.4, 6.2, 7.8, 6.8, 8.0, 6.4],
"coordination_complexity": [6.8, 7.2, 8.6, 6.4, 7.8, 8.8, 6.6, 7.4],
"implementation_risk": [5.8, 6.2, 7.4, 5.6, 6.8, 8.0, 5.4, 6.6]
})
def score_options(df):
result = df.copy()
result["change_readiness"] = (
0.16 * result["desirability"] +
0.15 * result["authority"] +
0.14 * result["capability"] +
0.12 * result["funding"] +
0.12 * result["policy_fit"] +
0.13 * result["governance_strength"] +
0.10 * result["trust_gain"] +
0.08 * result["burden_reduction"] -
0.05 * result["coordination_complexity"] -
0.05 * result["implementation_risk"]
)
result["absorption_capacity"] = (
0.25 * result["authority"] +
0.25 * result["capability"] +
0.20 * result["funding"] +
0.15 * result["governance_strength"] +
0.15 * result["policy_fit"]
)
result["public_value_priority"] = (
0.30 * result["burden_reduction"] +
0.25 * result["trust_gain"] +
0.20 * result["desirability"] +
0.15 * result["policy_fit"] -
0.10 * result["implementation_risk"]
)
result["sequencing_need"] = (
0.35 * result["coordination_complexity"] +
0.30 * result["implementation_risk"] +
0.20 * (10 - result["authority"]) +
0.15 * (10 - result["capability"])
)
result["portfolio_score"] = (
0.35 * result["change_readiness"] +
0.30 * result["public_value_priority"] +
0.20 * result["absorption_capacity"] -
0.15 * result["sequencing_need"]
)
result["recommended_action"] = np.select(
[
(result["change_readiness"] >= 7.1) & (result["absorption_capacity"] >= 6.6),
(result["public_value_priority"] >= 7.2) & (result["absorption_capacity"] < 6.4), result["sequencing_need"] >= 7.0,
result["implementation_risk"] >= 7.4
],
[
"scale_with_governance",
"prototype_then_build_capacity",
"sequence_after_governance_and_capability_work",
"risk_review_before_pilot"
],
default="pilot_with_learning_metrics"
)
return result.sort_values("portfolio_score", ascending=False)
baseline = score_options(options)
print("Baseline portfolio scores:")
print(baseline)
np.random.seed(42)
n_simulations = 10000
score_columns = [
"desirability",
"authority",
"capability",
"funding",
"policy_fit",
"governance_strength",
"trust_gain",
"burden_reduction",
"coordination_complexity",
"implementation_risk"
]
records = []
top_options = []
for simulation_id in range(n_simulations):
simulated = options.copy()
for col in score_columns:
simulated[col] = np.random.normal(
loc=options[col],
scale=0.55
).clip(1, 10)
scored = score_options(simulated).reset_index(drop=True)
top_options.append(scored.iloc[0]["option"])
for rank, row in scored.iterrows():
records.append({
"simulation_id": simulation_id,
"option": row["option"],
"change_readiness": row["change_readiness"],
"absorption_capacity": row["absorption_capacity"],
"public_value_priority": row["public_value_priority"],
"sequencing_need": row["sequencing_need"],
"portfolio_score": row["portfolio_score"],
"rank": rank + 1
})
simulation_df = pd.DataFrame(records)
winners = (
pd.Series(top_options)
.value_counts(normalize=True)
.rename("probability_top_portfolio_option")
.reset_index()
)
winners.columns = ["option", "probability_top_portfolio_option"]
winners["probability_top_portfolio_option"] *= 100
stability = (
simulation_df
.groupby("option")
.agg(
mean_change_readiness=("change_readiness", "mean"),
mean_absorption_capacity=("absorption_capacity", "mean"),
mean_public_value_priority=("public_value_priority", "mean"),
mean_sequencing_need=("sequencing_need", "mean"),
mean_portfolio_score=("portfolio_score", "mean"),
sd_portfolio_score=("portfolio_score", "std"),
median_rank=("rank", "median"),
mean_rank=("rank", "mean"),
best_rank=("rank", "min"),
worst_rank=("rank", "max")
)
.reset_index()
.sort_values(["median_rank", "mean_rank"])
)
print("\nProbability each option ranks first:")
print(winners)
print("\nPortfolio stability:")
print(stability)
plt.figure(figsize=(10, 6))
plt.bar(winners["option"], winners["probability_top_portfolio_option"])
plt.xticks(rotation=25, ha="right")
plt.ylabel("Probability of ranking first (%)")
plt.title("Institutional Design Portfolio Stability Under Uncertainty")
plt.tight_layout()
plt.show()
baseline.to_csv("institutional_design_baseline_scores.csv", index=False)
winners.to_csv("institutional_design_portfolio_winners.csv", index=False)
stability.to_csv("institutional_design_portfolio_stability.csv", index=False)
simulation_df.to_csv("institutional_design_simulation_records.csv", index=False)
This workflow helps teams avoid treating a single score as certainty. Complex institutions are uncertain environments. Simulation can reveal whether an option is robust, fragile, dependent on optimistic assumptions, or promising only after sequencing and capacity building.
GitHub Repository
The companion repository will provide a reproducible technical workspace for exploring the modeling, simulation, documentation, and implementation ideas associated with this article. The article folder is organized for multi-language institutional design, governance, implementation, service-system, and change-readiness workflows and includes folders for Python, R, Julia, C++, Fortran, C, Rust, Go, SQL, notebooks, documentation, raw data, processed data, and outputs.
Complete Code Repository
This repository folder contains companion materials for modeling institutional complexity, change readiness, governance strength, stakeholder burden, absorption capacity, implementation risk, service-system design, public value, institutional learning, and uncertainty across multiple technical environments.
The repository structure is designed to support reproducible institutional design analysis rather than isolated coding examples. The language-specific folders allow the same institutional-readiness, public-value, burden, governance, and implementation-risk logic to be explored across statistical, scientific, systems, and database workflows. The documentation and data folders help preserve assumptions, stakeholder definitions, governance criteria, implementation constraints, and validation protocols so that institutional design judgments remain traceable.
| Folder | Purpose |
|---|---|
python/ |
Institutional portfolio scoring, uncertainty simulation, implementation-risk analysis, absorption capacity modeling, and governance review workflows. |
r/ |
Institutional complexity scoring, public-value analysis, visualization, portfolio review, and change-readiness reporting. |
julia/ |
Numerical modeling and high-performance simulation for institutional change scenarios. |
cpp/, c/, rust/, go/ |
Systems-oriented command-line scoring tools, validation utilities, and reproducible implementation components. |
fortran/ |
Scientific-computing examples for numerical institutional-readiness modeling. |
sql/ |
Schemas for institutional options, governance criteria, stakeholders, implementation risks, evidence, and analytical queries. |
notebooks/ |
Exploratory analysis, teaching materials, institutional design demonstrations, and portfolio review workflows. |
docs/ |
Method notes, model cards, data dictionaries, reproducibility guidance, governance review, implementation protocols, and validation documentation. |
data/raw/ |
Original or synthetic source data used for institutional design examples. |
data/processed/ |
Cleaned, transformed, model-ready, or scored institutional design data outputs. |
outputs/ |
Generated figures, tables, reports, uncertainty results, portfolio diagnostics, and model outputs. |
Conclusion
Design thinking for complex institutions requires a larger imagination than design thinking for bounded products or services. It must account for rules, incentives, authority, professional cultures, policy constraints, data systems, frontline repair, public legitimacy, and long-term implementation. It must understand that institutional problems are experienced by people, but produced by systems.
The strongest institutional design work begins with human experience and then follows that experience into the institution. It asks where burden is created, where authority sits, where workarounds appear, where data is missing, where policies constrain action, where incentives preserve the current state, where trust has been damaged, and where governance must change. It treats frontline workers, affected communities, and institutional staff not as obstacles, but as sources of evidence about how the system actually functions.
Design thinking can help complex institutions become more responsive and accountable, but only if it resists design theater. Workshops are not enough. Pilots are not enough. Dashboards are not enough. Strategy language is not enough. Institutional design must connect research to authority, prototypes to implementation, evidence to governance, and learning to decision rights.
Complex institutions do not change because a better idea exists. They change when better ideas become supported by rules, resources, capabilities, relationships, and accountability. That is the work of institutional design thinking: to move from insight to institutional capacity, from participation to shared responsibility, from pilot to absorption, and from service improvement to public value.
Design thinking becomes serious inside complex institutions when it asks not only “What should we design?” but “What must this institution become in order to deliver what people need?”
Related articles
- What Is Design Thinking?
- Human-Centered Problem Solving
- Problem Framing in Design Thinking
- Insight Generation in Design Thinking
- Prototyping in Design Thinking
- Testing and Validation in Design Thinking
- Implementation and Scaling in Design Thinking
- Design Evaluation, Learning, and Outcome Measurement
- Service Design in Design Thinking
- Design Thinking and Strategy
- Ethics, Power, and Inclusion in Design Thinking
- Design Thinking, Data Systems, and AI-Assisted Research
- Co-Design and Participatory Design
- Design Thinking in Public Policy
- Design Thinking and Organizational Innovation
Further reading
- Meadows, D.H. (1999) Leverage Points: Places to Intervene in a System. Available at: https://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/.
- OECD (2017) Systems Approaches to Public Sector Challenges: Working with Change. Paris: OECD Publishing. Available at: https://www.oecd.org/en/publications/systems-approaches-to-public-sector-challenges_9789264279865-en.html.
- OECD Observatory of Public Sector Innovation (n.d.) Systems Approaches. Available at: https://oecd-opsi.org/work-areas/systems-approaches/.
- OECD Observatory of Public Sector Innovation (n.d.) Service Design. Available at: https://oecd-opsi.org/guide/service-design/.
- Ostrom, E. (2005) Understanding Institutional Diversity. Princeton: Princeton University Press. Available at: https://press.princeton.edu/books/paperback/9780691122380/understanding-institutional-diversity.
- Lipsky, M. (1980) Street-Level Bureaucracy: Dilemmas of the Individual in Public Services. New York: Russell Sage Foundation. Available at: https://www.russellsage.org/publications/street-level-bureaucracy.
- Pressman, J.L. and Wildavsky, A. (1973) Implementation: How Great Expectations in Washington Are Dashed in Oakland. Berkeley: University of California Press. Available at: https://www.ucpress.edu/book/9780520053311/implementation.
- Simon, H.A. (1996) The Sciences of the Artificial. 3rd edn. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262691918/the-sciences-of-the-artificial/.
- Weick, K.E. (1995) Sensemaking in Organizations. Thousand Oaks: SAGE. Available at: https://us.sagepub.com/en-us/nam/sensemaking-in-organizations/book4988.
- National Institute of Standards and Technology (2023) Artificial Intelligence Risk Management Framework (AI RMF 1.0). Available at: https://www.nist.gov/itl/ai-risk-management-framework.
References
- Meadows, D.H. (1999) Leverage Points: Places to Intervene in a System. Available at: https://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/.
- National Institute of Standards and Technology (2023) Artificial Intelligence Risk Management Framework (AI RMF 1.0). Available at: https://www.nist.gov/itl/ai-risk-management-framework.
- OECD (2017) Systems Approaches to Public Sector Challenges: Working with Change. Paris: OECD Publishing. Available at: https://www.oecd.org/en/publications/systems-approaches-to-public-sector-challenges_9789264279865-en.html.
- OECD Observatory of Public Sector Innovation (n.d.) Service Design. Available at: https://oecd-opsi.org/guide/service-design/.
- OECD Observatory of Public Sector Innovation (n.d.) Systems Approaches. Available at: https://oecd-opsi.org/work-areas/systems-approaches/.
- Ostrom, E. (2005) Understanding Institutional Diversity. Princeton: Princeton University Press. Available at: https://press.princeton.edu/books/paperback/9780691122380/understanding-institutional-diversity.
- Lipsky, M. (1980) Street-Level Bureaucracy: Dilemmas of the Individual in Public Services. New York: Russell Sage Foundation. Available at: https://www.russellsage.org/publications/street-level-bureaucracy.
- March, J.G. and Olsen, J.P. (1989) Rediscovering Institutions: The Organizational Basis of Politics. New York: Free Press. Available at: https://www.simonandschuster.com/books/Rediscovering-Institutions/James-G-March/9780029201151.
- Pressman, J.L. and Wildavsky, A. (1973) Implementation: How Great Expectations in Washington Are Dashed in Oakland. Berkeley: University of California Press. Available at: https://www.ucpress.edu/book/9780520053311/implementation.
- Simon, H.A. (1996) The Sciences of the Artificial. 3rd edn. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262691918/the-sciences-of-the-artificial/.
- Weick, K.E. (1995) Sensemaking in Organizations. Thousand Oaks: SAGE. Available at: https://us.sagepub.com/en-us/nam/sensemaking-in-organizations/book4988.
