Data visualisation for policy research: what a designer decides before opening the software

The easiest mistake in this work is to skip that question, open a spreadsheet, and go straight to “what chart should we make?” I start a step earlier, with a more awkward question: does this need to be a chart at all?

On a recent report for the Chatham House Ukraine Forum, we sat down with the research team before anyone opened design software and worked through the findings with rough sketches on paper. Some clearly needed a visual to carry the argument. Others were stronger left as a single number in the text. A few gained nothing from being drawn at all, and we said so. That early sorting is a large part of the design work, even though none of it happens in software. A chart should do something the words cannot do as quickly or as clearly. If it is only there because the data exists, or because a page looks bare without it, it is not earning its place.

Deciding what the reader should take away

Once a chart has earned its place, the next question is almost this simple: what is the one thing the reader should walk away with?

This matters more in our sector than most, because the reader rarely has long. A journalist is pulling a single finding out for a story. A policymaker is scanning a briefing between meetings. Someone has seen the chart on social media or screenshots away from the report it came from. You are designing for a few seconds of attention, usually with none of the surrounding context to help you.

Most of that work is done by the title, and by the gap between labelling a chart and stating its finding. A title that names the subject leaves the reader to do the interpreting. A title that states what changed does the interpreting for them, and tells them why it is worth their time. I push for the second kind every time. If the finding sits plainly at the top, the reader knows what to look for as their eye moves through the chart, and you rarely need a dense legend or three lines of explanation to rescue a visual whose point is hard to find.

The visual itself can usually be simpler than people expect. Good data journalism gets its strength from knowing what to leave out: what to emphasise, what to cut, how to lead the eye with hierarchy, spacing and a direct label instead of a key. A complicated dataset does not need a complicated chart.

The biggest decision is whether you are making one chart or a system

There is one more decision that belongs firmly before the software, and it is the one people most often skip: are you designing a single chart, or a system that other people will run without you?

We encountered this question when we built a suite of Flourish templates for the Migration Policy Institute. MPI works with very large, multi-layered migration datasets, and the brief was not one polished chart but templates their own research team could populate, again and again, long after we had handed the work over.

Making the first example look good was the easy part. The real work was thinking about what would happen when the data changed — more years, new categories, a different number of series — and building templates that held their shape rather than falling apart. Looking at what the team has produced since, the system has held up, and to me that is a far better test of a template than how the launch-day example looked. Anyone can make the first chart sing. The harder question is whether the hundredth one still carries the same institutional rigour.

That project also gave me a clear example of where AI helps without taking over the thinking. The datasets were large enough that we used AI to analyse their underlying structure and test how the data might be reorganised to fit the templates. But we did not take that output and publish it. Once we understood the structure, MPI’s own data team rebuilt and checked the files themselves. The statistics were going into a live policy debate, and verification had to stay with the people who knew the data. That is roughly how I think about AI across this work: it can make parts of the process quicker, but it cannot decide what the finding is, whether it deserves a chart, or what the reader most needs to see.

What all of this has in common

Whether I am working on a single high-rigour policy paper or a template system a research team will run for years, I always come back to the same test. A visualisation should help someone understand something they would otherwise have missed, or grasp it faster than they would from the words alone.

Everything that decides whether a chart does that happens before the software is open: what relationship the data holds, whether it needs drawing at all, what the reader should take away, and who will run it next. The software carries those decisions out; it does not make them. The deciding is the design — the drawing is just the last step.

Got a data visualisation project in mind that you need a hand with? Drop us a line and we’d be happy to help: [email protected]