Resource · Program evaluation

How to design a program evaluation logic model for a small nonprofit

Most small nonprofits first meet the logic model as a box on a grant application. Someone fills in the columns the night before the deadline, the funder accepts it, and nobody looks at it again until the next application.

That’s a waste of a useful tool. A good logic model is the clearest way to say what your program does, what you expect to change because of it, and how you’d know. Built well, it becomes the backbone of your evaluation, your reporting, and the conversation with your board about whether the work is working.

This guide walks through building one that a small team can maintain and actually use.

What a logic model is (and isn’t)

The W.K. Kellogg Foundation’s widely used guide defines a logic model as “a systematic and visual way to present and share your understanding of the relationships among the resources you have to operate your program, the activities you plan, and the changes or results you hope to achieve” (Kellogg Foundation Logic Model Development Guide). The CDC’s 2024 evaluation framework describes it the same way, as a picture of how a program’s activities connect to its intended outcomes, and treats it as a living document that changes as the program does (CDC Program Evaluation Framework, 2024).

A logic model is a statement of your program’s theory: if we do these things, then these changes should follow. It is not a work plan, a budget, or a promise that every outcome will happen. It’s a map you can test.

The five parts

The basic model reads left to right:

Inputs (resources). What you have to work with: staff, volunteers, funding, partners, space, and the trust you’ve built in the community.
Activities. What the program does with those resources: case management sessions, workshops, outreach, housing navigation, mentoring.
Outputs. The direct, countable products of those activities: sessions held, people served, referrals made, beds filled.
Outcomes. The changes in the people you serve, in their knowledge, skills, behavior, or circumstances. The Kellogg guide splits these into short-term and longer-term outcomes.
Impact. The broader change in the community or system the program contributes to over many years.

The most common mistake is stopping at outputs. “We served 240 people” describes effort, not change. Funders and boards increasingly ask the next question: what’s different for those 240 people? That’s the outcomes column, and it’s the one worth the most thought.

Build it from right to left

It feels natural to start with what you do. It works better to start with what you’re trying to change.

Start with the problem and the people. In one or two sentences, name who the program serves and what problem it addresses for them. Be specific: “adults leaving county jail without stable housing” is a program; “the community” is not.
Name the outcomes you’d be proud of. Ask staff: if this program works, what’s different for a participant after three months? After a year? Write those down as changes in the person, not as services delivered.
Work backward to activities. For each outcome, ask what the program does that should lead to it. If an outcome has no activity behind it, either add one or drop the outcome. If an activity supports no outcome, ask why you do it.
Fill in the outputs. For each activity, what would you count to show it happened at the level you planned?
List the inputs last. Now you know what the activities require, so you can see whether your resources match your ambitions.

Building in this order keeps the model honest. It stops the outcomes column from becoming a wish list that nothing in the program actually drives.

Make the arrows explicit

The arrows between columns are where the real thinking lives, and they’re usually left blank. Between each activity and outcome, write the assumption in plain words: mentoring by someone with lived experience builds trust, which makes participants more likely to stay engaged with services.

Those assumptions are what an evaluation actually tests. They also show you where the program depends on things outside its control, such as housing availability, a partner’s referral capacity, or policy changes. Name those as external factors. It protects the program when something outside its reach changes the results.

Keep it to one page

A logic model that needs three pages won’t get used. If yours is sprawling, you’re probably mixing several programs into one model or listing every task as an activity. Group activities into a handful of meaningful categories, and keep only the outcomes you’d actually measure.

Direct-service staff are the best test. If a case manager can look at the model and say “yes, that’s what we do and why,” it’s right. If they can’t find their work in it, it isn’t.

Turn the model into an evaluation

A logic model becomes useful for evaluation when each outcome is paired with a way to know whether it happened:

An indicator. What would you observe if the outcome occurred? “Housing stability” might become “participant in the same housing at 90 days.”
A data source. Where would that information come from: case notes, a short survey, a partner’s records, a follow-up call?
A timing. When would you collect it, and who is responsible?

Be realistic about what a small team can collect. Two or three well-measured outcomes, tracked consistently, will tell you more than ten indicators collected once and abandoned. Build collection into work staff already do, such as intake, case closure, and scheduled check-ins, rather than adding a separate data task.

The CDC framework’s steps are a useful check on the whole process: assess the context, describe the program, focus the evaluation questions and design, gather credible evidence, generate and support conclusions, and act on findings (CDC). The logic model is step two. Everything after it depends on getting that step right.

Common mistakes

Outputs dressed up as outcomes. “Participants complete the workshop” is an output. “Participants can create a monthly budget” is an outcome.
Outcomes nobody can measure. “Improved well-being” needs a definition and an indicator, or it will quietly drop out of every report.
A model built for the funder, not the program. If it only exists for a grant, it won’t match what staff do, and the evaluation built on it will measure the wrong things.
Never revisiting it. Programs change. Review the model at least once a year, and whenever you add a service, lose a partner, or learn that an assumption doesn’t hold.
Leaving out the people served. Participants often know which outcomes matter most and which are unrealistic. Ask them.

A practical first step

Pick one program. Get the program lead and two frontline staff in a room for an hour. Start with the outcomes column: ask what changes for participants when the program works. Then work backward. You’ll leave with a rough draft that’s already more useful than most grant-application logic models, and a clearer sense of what you’d need to measure to show it.

More guides →