How to Build a Logic Model That Actually Gets Used (Free Template Inside)

I've watched a lot of logic models get made. Usually it goes like this: a grant application asks for one, somebody stays up late filling in five boxes, it gets attached as an appendix, and nobody looks at it again until the next application.

That's a shame, because a good logic model is the single most useful page a program can have. It's the thing that keeps your narrative, your budget, your staff and your data pointed at the same goal. Let me show you how to build one that earns its keep.

What a logic model is, in plain English

A logic model is your program's if-then story, drawn on one page.

If we have these resources, then we can do these activities. If we do these activities, then we'll produce these outputs. If we produce these outputs, then these people will change in these ways. And if enough of that happens, our community will be different.

The W.K. Kellogg Foundation's Logic Model Development Guide, still the most used reference two decades after it came out, 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 to do, and the changes or results you hope to achieve" (quoted by United Way of Pierce County).

The five boxes

Kellogg splits the page into two halves: your planned work and your intended results (Kellogg Foundation guide).

Your planned work

1. Resources (inputs). The human, financial, organizational and community resources you can direct at the work. Staff, volunteers, funding, space, partners, devices, curriculum.
2. Activities. What the program does with those resources. Write these with verbs: teach, coach, distribute, refer, convene.

Your intended results

3. Outputs. The direct products of the activities, usually counts. Classes taught, people served, hours of coaching. These show you delivered the program at the "dose" you planned.
4. Outcomes. Changes in participants' knowledge, skills, attitudes, behavior, status or functioning. Split them into short-term, intermediate and long-term.
5. Impact. Change at the organization, community or system level that your program contributes to.

If outputs and outcomes still blur together for you, I wrote a whole post on outputs vs. outcomes. It's the single most common logic model mistake.

On timing: Kellogg's guide suggests short-term outcomes show up in about one to three years, long-term in four to six, and impact in seven to ten (Kellogg Foundation, Chapter 2). For a small program on a one-year grant, I translate that more practically: short-term means by the end of the program, intermediate means at a 60 to 90 day follow-up, long-term means a year or more out.

Build it backwards

Here's the move that changes everything. Don't start on the left with what you have. Start on the right with the change you want.

The Institute of Museum and Library Services calls this backward design: ask "what short, medium, and long-term outcomes do we want to see in our community?" first, then work out the inputs and outputs needed to get there (IMLS logic model guide).

Starting on the left gives you a list of everything you already do with "outcomes" stapled on. Starting on the right forces the question every funder is asking: is this the right work for the change you want?

The order I use with teams:

1. Impact. What's different in the community if this works? One sentence.
2. Long-term outcomes. What's different for participants a year or more out?
3. Intermediate outcomes. What has to change first, in behavior or status, for that to happen?
4. Short-term outcomes. What do people need to know, believe or be able to do first?
5. Activities. What will we do to cause those short-term changes?
6. Outputs. How will we count that the activities happened at the right scale?
7. Resources. What do we need to do all of that?

Then read it left to right out loud, saying "if... then..." between every box. Every place you stumble is an assumption you haven't said yet.

A worked example: a digital navigation program

Here's a full logic model for a made-up but realistic program: a library-based digital navigation program helping older adults get connected. If you don't know what digital navigators do, I explained the job here.

Notice a few things. The activities have verbs. The outputs are counts. The outcomes are all sentences about participants. And the impact box is humble: the program contributes to it, it doesn't claim to cause it single-handedly.

Write down your assumptions

Every arrow on a logic model is a bet. "If we give someone a laptop, then they'll use it" is a bet. Sometimes a bad one, if nobody showed them how, or the household has no internet.

Under the model, add two short lists:

• Assumptions. What has to be true for the arrows to work? "Low-cost internet plans remain available." "Participants have a safe place to keep a device."
• External factors. What outside forces could help or hurt? "The library branch closes for renovation." "A state program changes eligibility."

These are the most honest part of the page, and funders notice when they're there. They're also what you're really learning about when you evaluate.

A fill-in template you can copy

Paste this into a document and fill it in, right to left:

Program name: Who it serves: The problem, in one sentence:

Assumptions: External factors:

That's genuinely all it needs to be. The Kellogg guide's forms appendix has more elaborate blank templates if your funder wants their format (Kellogg Foundation guide).

Turn it into your measurement plan

Here's where most logic models die, and where yours is going to keep going. For every output and every outcome box, add four things:

Now your logic model isn't an appendix. It's the plan for what you'll collect, from whom and when. When report time comes, you're filling in a table you designed a year ago instead of digging through three spreadsheets. That's the whole philosophy behind Storyhouse: the plan, the questions and the records live together, so the report is a readout, not a rescue mission.

The mistakes I see most

• Outcomes written about the program. "Provide workshops" is an activity. "Participants can create a budget" is an outcome.
• Too many boxes. If you have 14 outcomes, you'll measure none of them well. Pick three to five.
• Claiming impact you can't show. "End poverty in South Seattle" is a mission. Put it in the impact box as a contribution, not a promise.
• No arrows. If you can't draw a line from an activity to an outcome, either the activity doesn't belong or an outcome is missing.
• Made once, never touched. Revisit it every six months. Programs change. The model should too.

Logic model vs. theory of change

You'll hear both terms. A theory of change explains why you believe change will happen: the research, the assumptions, the conditions. A logic model is the compact, operational version: what you do and what you expect to produce. Kellogg's guide treats the theory as the foundation and the logic model as the picture built on top of it (Kellogg Foundation guide). In practice, if your funder asks for one, they'll accept a clear version of either. Just make sure the two agree.

The U.S. Department of Education publishes a short job aid on developing logic models for its grants, with a glossary that's handy if your application uses federal terms (U.S. Department of Education).

The page that keeps everyone honest

When your logic model is good, your grant narrative writes itself, your budget lines up with your activities, your staff know why they're collecting what they're collecting, and your progress report has a structure before you start writing it.

One page. Built backwards. Read out loud. Measured on purpose. That's a logic model that gets used.