A logic model is a simple visual diagram showing how your nonprofit connects inputs, activities, outputs, and outcomes. Think of it as your theory of change in a single image, answering one question: if we do X, Y, and Z, then this change happens. The beauty of the format is that it forces clarity. You cannot hide vague thinking inside a logic model, because either the cause-and-effect chain makes sense or it does not, and the moment your work sits on one page in front of colleagues, the weak links become obvious to everyone in the room.

Why Logic Models Matter

Logic models are not academic exercises, and they are not paperwork you produce once for a funder and then file away. They are working tools, and they earn their place because a single page of connected boxes does several jobs at once that would otherwise take months of meetings. The first job is alignment. When your program staff, your executive director, and your board can all point at the same diagram and agree on what the organization is trying to do and why, a large category of internal friction simply disappears, because disagreements that used to surface as vague unease now surface as a specific argument about a specific box.

The second job is diagnostic. Laying out what you actually measure against what you claim to achieve almost always reveals a mismatch: what you thought you were measuring turns out not to match your actual outcomes. The third is explanatory. New staff, incoming board members, and funders understand your approach instantly when it is drawn rather than described, which saves you the ritual of explaining the organization from scratch to every new arrival. The fourth is strategic, because when you can see your entire theory on one page, decisions about where to spend the next dollar become clearer. The fifth is relational: potential partners can see exactly where collaboration makes sense, rather than guessing from your mission statement.

The Five-Box Logic Model

The standard format uses five boxes connected by arrows, and the most common mistake at this stage is overthinking it. Each box answers a different question, and the questions get harder as you move left to right. Inputs and activities describe what you control. Outputs describe what you produce. Outcomes describe what changes for the people you serve. Impact describes the lasting result that shows up long after your program has ended, often somewhere you cannot see. Keeping those distinctions clean is most of the work.

Two rules keep the boxes honest. First, be specific about inputs. Naming the actual size of your budget is useful; writing "significant resources" is not, because a vague input cannot be tested against the activity it is supposed to fund. Second, list your core activities rather than your peripheral ones. A logic model that catalogues everything anyone in the building does becomes a job description rather than a theory, and the arrows stop meaning anything. Outputs are countable and immediate; outcomes are the changes you seek. If you find yourself unable to tell which of the two a statement belongs to, ask whether it describes something you did or something that shifted in someone else.

The Cause-and-Effect Chain

The arrows connecting your boxes are not decoration; they are the argument. Read out loud, the logic model says: because we have these inputs, we can do these activities. Because we do these activities, we reach this many people. Because we reach them with this approach, they experience these outcomes. And because of these outcomes, they eventually achieve this impact. When the sentence sounds forced at any joint, you have found something worth discussing, and the discussion is more valuable than the diagram.

Each arrow must be defensible. If there is no reasonable path from an activity to the outcome sitting next to it, you have identified a gap in your theory, and that is exactly what you want to find. Teams often arrive at this moment expecting to feel embarrassed and instead feel relieved, because the gap explains something that has been bothering them for a year. A model with a visible weak link is more useful than a model whose links are all asserted with equal confidence and none of them examined.

Running a Logic Model Workshop

You can build a logic model with your team in a single two-hour session, provided the preparation is done and someone keeps time. The structure below runs in rounds, each with its own clock, because the alternative is that the group spends the whole session arguing about the wording of one activity and never reaches the outcomes at all. Assign a facilitator who is willing to say "we will come back to that" and mean it.

Before the Room Fills

Give yourself thirty minutes of preparation before the workshop. Invite five to ten people representing different parts of your organization: program staff, a board member, the executive director, and the finance person if that is possible. The mix matters more than the number, because a model built only by program staff will over-describe activities and under-describe resources, while one built only by leadership will miss what actually happens in the room with participants. Send everyone a simple one-page overview of what you are doing beforehand. No one should walk in cold.

The Rounds

Open with a ten-minute introduction. Explain the five boxes and show a simple example from another nonprofit in your sector, deliberately not your own organization yet, so the group learns the concept before it starts defending its own work. Then run the first round on inputs for fifteen minutes. On a large sheet of paper or a whiteboard, write "INPUTS" and brainstorm: budget, staff, partnerships, community relationships. Write everything down and do not edit yet, because premature editing kills the contributions of the quietest people in the room.

Round two covers activities and takes twenty minutes. Given those inputs, what do you do? What are your core programs and services? Push relentlessly for specificity here. "We run job training" is not specific enough to test; "we run a twelve-week digital marketing skills program taught by industry professionals" is something you can actually reason about. Round three, fifteen minutes, covers outputs: who do you serve, how many people participate in each activity, and what is the real reach? Then take a five-minute break, because the hardest round comes next and tired groups conflate outputs with outcomes.

Round four, twenty-five minutes, is outcomes, and it is the hardest part of the day. If your programs work as intended, what changes do participants experience? Not outputs, which only record that they showed up, but changes in their knowledge, skills, attitudes, behavior, or circumstances. The question that unsticks most groups is this one: six months after the program, what is different about participants? Answer it using data you already have or participant feedback rather than aspiration. Round five, fifteen minutes, covers impact. Fast forward two or five years. If your outcomes happen, what is the lasting result? This box is aspirational by nature and you will not have data for it yet, which is fine as long as everyone knows that is what they are looking at.

Review and Refine

Reserve the last fifteen minutes to look at the entire model as a whole rather than box by box. Does the story make sense when read start to finish? Are the arrows logical? Do the people in the room actually believe that if all these pieces happen, the impact will follow? Use the time to refine language and remove jargon, because a model full of internal shorthand cannot do the explanatory job it exists for. Ending the session with a model everyone can read aloud is worth more than ending with a model that is technically complete.

Common Mistakes in Logic Models

Confusing outputs and outcomes. "We serve 200 people" is an output. "Participants increase their skills by 30%" is an outcome. Your model should carry both, but the moment they mix, your measurement plan stops making sense, because you end up reporting attendance as though it were change.

Making it too complicated. Five boxes is the maximum. If you find yourself needing more, that is a signal that you are doing multiple distinct things, and the right response is to break the work into separate models rather than to widen the diagram until it becomes unreadable.

Using vague language. "Increase well-being" is too vague to guide anything. "Participants report 25% improvement in mental health scores" is specific enough to measure and to argue about. Funders need that specificity, and so does your own team, because vague outcomes are the ones nobody ever gets around to tracking.

Ignoring context. Logic models exist in a context. External factors such as the economy, policy changes, and community conditions affect your outcomes whether or not you acknowledge them, and a good model says so rather than implying that your activities operate in a vacuum.

Never updating it. Your organization changes, your programs evolve, and your logic model should too. Review it annually. It does not have to be perfect; it has to be true, and a model that describes the organization you used to be fails that test no matter how polished it looks.

From Logic Model to Strategy

A logic model is not your strategic plan, but it informs one, because it converts strategy questions from matters of opinion into matters of inspection. Once the model is clear, you can ask where your measurement is weakest, which tells you where to invest in data collection. You can ask which activities do not connect to any outcome, which raises the honest question of whether you should be doing them at all. You can ask where a gap in the chain might be filled by another organization, which turns partnership from a networking activity into a targeted search. And you can ask what needs investment, because an activity that is critical to the chain but chronically underfunded is a resource question, not a performance question.

The measurement question deserves particular attention, because logic models tend to expose that organizations count what is easy rather than what matters. Once you have a model in place, deepen your measurement approach with the qualitative side of the picture, covered in Qualitative Impact Data: Capturing Stories That Complement Numbers, so that the outcomes column is supported by more than headcounts.

Making It Visual

After your workshop, someone should clean the model up and make it visual. You do not need fancy design software; general-purpose design tools, drawing tools, or even presentation software will do the job, and the constraint of simple tools tends to keep the diagram simple too. The goal is an artifact you can reuse in staff onboarding documents, board presentations, grant proposals, strategic planning sessions, and community presentations, which is why legibility matters more than polish.

Once it is clean and visual, share it, reference it, and let it guide decisions. This is the step most organizations skip, and skipping it wastes the whole workshop. A logic model only matters if people actually use it, which in practice means it has to appear in the meetings where choices get made, not only in the folder where documents get stored.

The Messy Middle

After your workshop you may realize the model does not quite capture what you do. That is normal, and it is not a sign that the exercise failed. Messy models are real models; overly clean ones are usually oversimplified, having smoothed away the complications that make the work difficult in practice. Your model should spark conversation rather than end it, and a diagram that provokes an argument about what actually changes for participants has already paid for the two hours it took to build.

Treat it as a working document. Post it in the office where people walk past it. Ask for feedback from staff who were not in the room and from participants if you can. Refine it quarterly rather than waiting for a formal review cycle. After a few months of that, you will have something that genuinely represents your organization instead of something that represents one afternoon's discussion.

Anti-Patterns

Building the model alone at a desk. A logic model written by one person and circulated for comment collects polite agreement rather than real scrutiny, and it never produces the alignment that is a large part of the point. The value comes from five to ten people from different parts of the organization arguing in the same room.

Editing during the brainstorm. Cutting contributions during the inputs round saves a few minutes and costs you the resources nobody at the leadership table knew you had. Capture everything first; refine in the review round, which exists for exactly that purpose.

Writing the model for a grant application only. A model built to satisfy one funder's template gets tuned to that funder's language and is then unusable for onboarding, board discussion, or planning. Build the model for your organization first and adapt it for applications second.

Filling the impact box with data you do not have. Impact is long-term and often lies outside your direct reach, so treating it as a claim you can evidence today creates a promise your reporting cannot keep. Mark it as aspirational and let the outcomes column carry the evidential weight.

Declaring the model finished. Treating the workshop output as a final artifact guarantees it will be out of date before it is used, because programs evolve. A model that is never revisited quietly becomes fiction while remaining on the wall.

Practice Prompts

• Take your organization's most established program and write out the five boxes for it in one sitting, without consulting anyone. Then read the chain aloud as a "because" sentence and mark every joint that sounds forced.
• Pull the last report you sent a funder and sort every figure in it into "output" or "outcome." Note how many fall into each column, and what that ratio implies about what you currently measure.
• Draft the one-page pre-read you would send to workshop participants. Test it on a colleague who was not involved and see whether they arrive understanding what the session is for.
• Write the outcomes box using only the question "six months after the program, what is different about participants?" and using only data or participant feedback you already hold. Leave blank anything you cannot support.
• Take one activity that appears in your model and trace it forward. If you cannot reach an outcome in one defensible step, write down what would have to be true for the connection to hold.
• Draft a context note listing the external factors, such as economic conditions or policy changes, that would most affect your outcomes, and decide whether it belongs alongside your model.

Reflection Exercise

Sit with your current model, or your first draft of one, and ask which arrow you believe least. Most teams know the answer immediately and have been avoiding it, usually because the weak arrow sits under a program that is popular, well funded, or personally important to someone senior. Write down what evidence would change your mind about that arrow in either direction, and what it would take to gather it.

Then ask the harder version of the question about your own role. If the model shows an activity that does not connect to any outcome, what would it cost the organization, politically and financially, to stop doing it? If the answer is that nobody could raise the question safely, the obstacle is not measurement but governance, and the model has just told you something more useful than any dashboard would.

Glossary

• Logic model: A simple visual diagram showing how an organization connects inputs, activities, outputs, and outcomes, usually in five boxes joined by arrows.
• Theory of change: The underlying argument that if you do X, Y, and Z, a particular change happens. A logic model is that theory expressed as a single image.
• Inputs: The resources available to you, including staff, funding, volunteers, partnerships, facilities, and curriculum.
• Activities: What you do with your inputs, such as teaching classes, providing counseling, distributing food, hosting workshops, or running support groups.
• Outputs: Countable, immediate measures of who you reach and in what numbers.
• Outcomes: The short-term changes participants experience as a direct result of your activities, in knowledge, skills, attitudes, behavior, or circumstances.
• Impact: The lasting, long-term change that follows from your outcomes, often occurring outside your direct reach.
• Context box: An optional addition noting external factors such as policy, the economy, or community conditions that affect the model.
• Gap in the theory: A point where no reasonable path connects an activity to the outcome next to it, revealed by testing each arrow.

Related Lessons

• Impact Measurement for Beginners: Start Here
• Qualitative Impact Data: Capturing Stories That Complement Numbers
• Outcome Tracking Dashboards: What to Measure and How to Display It
• Participatory Evaluation: Involving Your Community in Measuring Impact
• The Annual Impact Report: Design, Content, and Distribution Guide

Closing

The reason logic models keep surviving fashions in evaluation is that they are cheap, fast, and impossible to fake. Two hours, a whiteboard, and the right mix of people produce a document that tells you where your theory is strong, where it is guesswork, and where you are measuring the wrong thing entirely. Nothing about the format is clever; the discipline comes from being made to write down, in front of colleagues, the chain of reasoning that usually stays implicit.

What you do afterward decides whether it was worth the time. Clean it up, put it where people can see it, use it when you argue about budgets and programs, and revise it as the organization changes. A model that lives on the wall and shapes decisions is doing its job; one that is technically elegant and filed away is not, however good it looked on the day you drew it.

Key Takeaways

• A logic model is your theory of change in a single image, connecting inputs, activities, outputs, and outcomes to a long-term impact.
• The format forces clarity because vague thinking cannot survive being drawn as a chain of defensible arrows.
• Five boxes is the maximum. If you need more, you are describing multiple programs and should build separate models.
• Outputs record what you did and how many you reached; outcomes record what changed in participants. Keeping them separate is the single most consequential discipline in the exercise.
• A two-hour workshop with five to ten people from different parts of the organization, run in timed rounds, is enough to produce a working draft.
• Gaps you find between activities and outcomes are the point of the exercise, not a failure of it.
• Vague language, ignored context, and models that are never updated are the recurring failure modes.
• The model only creates value once it is visual, shared, and used in the meetings where decisions actually get made.

Frequently Asked Questions

Do we need a different logic model for each program? Maybe. If your programs are totally separate with different outcomes, then yes. If they are interconnected or serve the same population with different services, one organization-wide model might work. Start with one master model, and if it gets too complicated, break it into program-specific models.

What if our activities do not clearly lead to outcomes? That is the insight you wanted, and the gap tells you something. Maybe your theory of change needs rethinking, maybe you need a different activity, or maybe the activity is right but you are measuring the wrong outcome. Use it as a chance to strengthen your program design.

Should we include external factors? Some organizations add a "context" box on the side noting external factors such as policy, the economy, and community conditions that affect the model. This is helpful if those factors significantly influence your outcomes. Otherwise, keep the core model simple.

How often should we update our logic model? Review it annually, or whenever your organization makes major changes. You do not need to rebuild it from scratch. Usually minor tweaks to language or outcomes are sufficient, and major overhauls are rare unless your mission fundamentally shifts.

Can we use a logic model for a new program we are launching? Absolutely, and this is an ideal use. Build the logic model before you launch, because it forces you to clarify what you expect to happen. Then use it to guide measurement and evaluation from day one.