Author: Lucy Clague, Independent Evaluation & Research Consultant
Theories of change are a familiar part of evaluation—but too often they’re created, signed off and set aside. This guest blog, by Lucy Clague, explores how to move beyond the diagram, using coding and iteration to turn your theory of change into a practical tool that actively shapes evaluation design, data collection and analysis.
Diagrams don’t evaluate themselves: making Theories of Change work harder
Let’s be honest—theories of change aren’t exactly glamorous. Most programmes have one, usually captured in a familiar diagram of boxes and arrows showing inputs, activities, outputs and outcomes (the logic model). That diagram is just a visual shorthand for the real work: the underlying story about how and why change is expected to happen. Too often, it’s created at the start, signed off by funders and then quietly filed away until the final report.
That’s a missed opportunity.
Think of the theory of change like a playlist. You’ve curated it carefully, thinking about the flow, the mix and what will land with your audience. But it only comes to life when it’s actively used. You might shuffle, skip or reorder tracks as you go, responding to what the evidence is telling you—just like tweaking a playlist based on the vibe in the room.
Over the years, working on large multi-strand programmes, I realised it’s one thing to have the familiar diagram, but another to actively use the theory of change behind it to guide evaluation design, research tools and analysis.
Coding: from theory to robust evidence
Every pathway in a theory of change is essentially a hypothesis: if we do X activity, then Y output should follow, which should lead to Z outcome. By introducing a simple coding system, I could link specific activities to outputs and outcomes in a way that made these assumptions testable.
Each code became a tag that tied a pathway directly to research questions, survey items, interview prompts and analysis frameworks.
Suddenly, the diagram stopped being just a picture. The theory of change became the backbone of the evaluation. I could trace evidence back to the pathways it was meant to test and see clearly which assumptions about change were holding up—or not.
Staying iterative
The other big win of coding is that it supports iteration. As evidence comes in, it’s straightforward to revisit the theory of change: do the pathways still make sense? Do some need refining or rethinking? The model can evolve alongside the programme—like reordering a playlist—always grounded in what the data is telling you.
And while the framework is useful, some insights will inevitably fall outside it. That’s fine—sometimes the surprises are the most valuable. The trick is balancing structure with openness: let your coding guide you but keep your eyes open for anything unexpected that adds insight.
Why it matters
This approach brings clarity—not just for me as an evaluator but for delivery teams and commissioners too. Everyone can see how the evidence links back to the change mechanisms, which makes discussions about what’s working, for whom and why much more productive.
It also shifts the questions we ask. Instead of simply “Did the programme work?” we can ask: “Which parts of the programme logic are supported by evidence and why?” That subtle shift makes evaluation more actionable and genuinely useful for improving practice.
Takeaways
- Treat the theory of change as a living tool, not just a diagram
- Code your pathways so research questions, data collection and analysis are aligned with programme logic
- Use evidence to refine the model iteratively
- Stay open to insights outside the framework—they often matter more than you expect
Theories of change and their diagrams might feel a little dry, but with coding, iteration and a bit of imagination—like curating a playlist—they can actually make evaluation more structured, rigorous and useful. And that’s something worth paying attention to.
