Visualisations and the stories behind them

For me, the most important part of a visualisation isn’t the visualisation at all.  The most important part is the reaction it provokes, which should be equivalent to:

Oh yes, now I get it.

Actually, you often want things to continue on from this, so you get

Oh yes, now I get it.  Therefore …

The important things aren’t:

• Look how good I am at art.
• Look how clever I am to understand such a big and complicated thing.  Isn’t it big and complicated?  I’m so clever.
• Look how sharp my eyesight is and how fine my motor control is to produce something as detailed as this.
• Look how good a programmer I am to code something so flashy.
• Look how amazing my visualisation tool is – it has all these features!

Getting back to what it should be about – the core of it for me are the two pronouns and the ellipsis.

Oh yes, now I get it.  Therefore …

They are essentially variables, so I’ll make that explicit:

Oh yes, now X gets Y.  Therefore Z.

This is starting to look a lot like a user story to me.  To make that even more explicit:

As a role
I want to understand / know information
So that reason

The two versions are equivalent: X=role, Y=information, Z=reason.  For instance:

As a student
I want to know the entry criteria for universities offering a Physics degree
So that I can pick the correct qualifications to study before university.

As an operations manager for a web site
I want to know if any of my systems are about to degrade
So that I can keep the site performing well by taking preventative action in time.

So, before you pick up your crayons or open your editor to create a visualisation, please think about the user story behind it.  If you can’t think of a decent user story, then maybe you’re actually just exploring a bit of data or a new tool.  That’s OK, but knowing what you’re doing will help you do it well.

Or maybe your user story is actually too large to implement as a single visualisation.  It might be that the information needed is just too big and complicated, or that there’s more than one role involved and a single visualisation won’t work for all of them.  In which case, think about how you can break it up.

For instance, the user story might start as:

As a student
I want to know which universities would be a good place for me to study Physics
So that I can apply to the right one

The part that seems to make this large (and also hard to know when you’ve done enough) is the “good” in “good place”.  What defines good:

• What are the entry requirements and how likely am I to get in?
• How far away is it from home?
• How expensive is it to live there?
• How likely am I to have accommodation provided by the university?
• How many of the people there will be similar to me?
• What is the social life like?
• Etc.

Each of these could easily turn into its own visualisation, showing separate data and using different techniques.

The user story is a much better jumping off point than “We need a pie chart” or “I want something nice in D3” or “I wonder what’s in this data”.  Who are your users?  How good are their eyesight and motor skills?  How will they be seeing this – on a mobile or projected at a conference?  What kinds of thing are they used to that you can exploit?  What question or need of theirs am I trying to address – how similar or different things are, what relates to what etc.  Knowing all these kinds of thing will help you to be more effective.

If you’re coming to visualisation from the programming side then thinking about user stories behind visualisations might not be too hard, at least compared to people coming to visualisation from statistics or graphic design.  Regardless of your background I think that the important thing is still the user, and their story.