Top to bottom or left to right? Logic model conventions January 8, 2009
Posted by Paul Duignan in : Communicating outcomes models, Doing evaluation more efficiently, DoView, Outcomes models, Using the approach , trackback
There are various conventions for visualizing logic models (or outcomes models as I call them to include the wide range of different models evaluators work with – program logics, logic models, outcomes hierarchies, theories of change, program theories, strategy maps, ends-means diagrams, results chains etc.)
I have put up a knol article in the Outcomes Theory Knowledge Base which talks about why I think there are advantages to a top to bottom rather than a left to right approach to drawing logic models. Of course, if you are in an organization where you are told to draw left to right logic models, then go for it and some people who use DoView software use it to draw left to right models. The article is here.
However, if you have the choice have a think about what is the best way to draw them. My reasoning is that a top to bottom model is superior because it lets you:
- Emphasizes the importance of high-level outcome(s) by putting them in the most prominent place on the page (at the top).
- Encourages ‘outcomes thinking’ by having the reader start with high-level outcomes and then move down to look at the steps which it is believed will lead to this outcome(s). This is the normal flow for the way a written page is read in most written languages. It is also consistent with the way in which it is recommended within outcomes theory that an outcomes model is built in practice – i.e. starting with a box at the top of a page and asking the question ‘what is it, at the highest level that we are trying to do here?’
- Works against just ‘program justification’ thinking in contrast to the more appropriate ‘outcomes thinking’. Program justification thinking only sets out a justification for a project rather than focusing on the outcomes that one is trying to achieve and working backwards from these to specific programs. The ‘outcomes thinking’ approach leaves open the possibility that one can consider that there may be more than one way (program, or intervention) through which an outcome can be achieved. ‘Outcomes thinking’ is the type of process that funders and other external stakeholders want program providers to have gone through in regard to the programs and interventions they are proposing. They do not just want them to think up some outcomes that justify their programs without carefully considering the alternatives.
- It conforms to some visual and language metaphors related to causality – ‘higher-level outcomes’, ‘top-level outcomes’, ‘raising ones vision’ and visual metaphors which often to put the most important items at the top of a visual representation.
- From a practical visualization perspective, it easily allows for navigation within diagrams which have more items at the bottom of the visualization than at the top. In general (although not necessarily always), there tend to be more items listed as one moves further down an outcomes model.
The problem with a left to right models is that they are usually drawn (and seem to work best) with outputs on the left-hand side and outcomes on the right. This means that the diagram tends to make the outputs the most prominent rather than an approach which is based on ‘outcomes thinking’ which, as in the top to bottom models makes the outcomes the most prominent part of the model (because they are at the top of the page). Interesting, I am having an exchange on the EVALTALK list at the moment in which someone who is into left to right models said that you need to get people to draw their models ‘backwards’. What he meant was that you need to get them to think from outcomes back to outputs. However, to my mind this reflects a problem with the visualization of a model from left to right on a page. If you use the convention of drawing models from top to bottom down a page then there is not need to get people to draw the ‘backwards’ you just start with an empty box in the middle of the page in which you get them to put the highest level outcome they can think of and the work down from there to get the steps which lead to it.
Examples of logic models visualized in the way suggested here can be found at OutcomesModel.org. If you have any comments regarding your thoughts or experience on the best format for outcomes models, post a comment.
Paul Duignan, PhD
Comments»
I think this is a focus on an extremely important topic. I have been developing graphic images for most of my career. I have tried since the beginning of PCs virtually every visualization/graphic software program and if nothing else, am an expert on the evolution of the software.
I agree completely with your preference for the top to botton approach. The reader of the model however tends to control your effectiveness in doing it that way because of their long reinforcement history of reading. I think there is a major difference in visualization and recognition patterns in users. Charts, exhibits and figures etc. I consider graphics and visualization I think of more as concept mapping of some sort.
I would encourage experimention with something like DoView because of the many uses that can be made of software that focuses so directly on outcomes.
Barry,
Can you elaborate on what you mean by ‘the major difference in visualization and recognition patterns in users’?
Nothing but opinion, but I think that visualization is dependent on a more fundamental pattern recognition ability. It is at a higher level of abstraction. In the same way that there has been a “pattern recognition” score on various psych tests, I think that visualization might be facilitated in those who have a higher level of pattern recongition to begin with.
I have always admired Edward Tufte of Yale and his several books on different aspects of visualization. He made it clear enough to me at least that much of visualization can be taught but you have to have to understand, imagine multivariate patterns to get there. I have had students who can learn concrete patterns in simple graphs but cannot “imagine” beyond that level to more integrated complex relationships. I do not mean to resurrect left – right brain issues, but some of this people have been extremely verbal, bright law students who could not begin to understand visualization. – B
Totally agree Barry, I have looked at Tufte’s good work also. It think that we are now entering a new age where visualization skills will become important because of the possibilities opened up by IT. Presumably some people will be naturals at it, others will be able to learn it and others will just not get it. I think that there is an issue about getting to understand visualization conventions.
One assumption is that anyone should be able to understand a visualization without knowing any conventions. This is a pretty hard ask. Another, more relaxed approach is to see it as a matter of developing a set of conventions in an area which are reasonably simple but which may require a little learning or getting use to. We do this all the time about other types of technical information (e.g. accounting systems) I don’t see why we should demand that visualizations don’t have any aspect of ‘conventions’ in them. Of course it is a matter of getting enough people to accept the conventions so that they become widespread.