roguepenguin

The tools and discipline of data storytelling

Thu, 14 Feb 2019 02:26:00 +0000

When we start school we are given a pencil.

Over the next few years we learn to master this tool.

But this does not make us an artist or an author.

Mastery of a tool does not equate to mastery of a discipline.

The discipline of data storytelling

The same can be said about data storytelling. Software knowledge doesn’t always equate to knowledge of data storytelling (I define a data story simply as “a story supported by data”).

There are loads of data visualisation tools available today; many free to use, easy to access (browser-based), and with intuitive user interfaces. But data visualisation is just one part of data storytelling.

Data storytelling is usually made up of multiple data visualisations, connected through narrative.

Effective data storytelling requires tools capable of visualising data and communicating narrative.

A few data visualisation tools have evolved to enable better communication of the insights they visualise:

Yellowfin BI

Flourish

Most data visualisation tools don’t have an inbuilt data story canvas, but they do make it easy to embed their visuals elsewhere.

Therefore, the tools are not limiting our data storytelling ability. It’s awesome Yellowfin BI and Flourish have created environments where incorporating narrative is easier - and I hope more will follow their lead! But if we really wanted to hack it (or embed data visualisations elsewhere) we could. So why don’t we?

What is holding us back from telling good data stories is our ability to write them in the first place.

It's like we’ve been given fancy coloured pencils with little understanding of how to arrange what we draw with them...

When we start a job we are given a data visualisation tool.

Over the next few years we learn to master this tool.

But this does not make us a data storyteller.

Mastery of a tool does not equate to mastery of a discipline.

Experimenting with a different data visualisation tool

Fri, 04 Jan 2019 02:18:00 +0000

Adobe Illustrator is my preferred tool for data visualisation. The majority of my work focuses on data storytelling and this software works well in an area requiring very custom graphics. Experimenting with different tools is not something I do often - like many, I stick with what I know. But data visualisation tools have increased in both number and quality on what was available even a year ago. More tools are available for more effective data story visualisation.

Datawrapper has been on my radar to try for a while (mainly because Lisa Charlotte Rostwrites amazing data viz blogs about their product) but it's not something I've given myself time to try out. Therefore after reading the first #SWDChallenge of 2019, I had the perfect opportunity.

"I challenge you to try a new tool for visualizing data" - Storytelling with Data

My Datawrapper project

Instead of starting from scratch (sourcing the right data and designing the visualisation) which can take a while, I've used one of my existing graphs created in Adobe Illustrator, and attempted to recreate the same design using Datawrapper.

Original graph created using Adobe Illustrator

Graph recreated using Datawrapper

Differences in graphing software

Disclaimer: I haven't spent a lot of time learning Datawrapper. With the help of their tutorials and Google I've created the above graph. If I point out differences below that can be corrected please let me know - thank you!

Font

I used the basic (free) version of Datawrapper, allowing only one font choice. Font size and weight choice was also limited. The only font size I was able to change under the basic plan was the annotation. If I paid 499€/month to upgrade to their full solution I could have custom branded this graph.

Title

The original graph was part of a bigger infographic and its title placement was to the right of the graph. This was a purposeful design choice to decrease the proximity of the takeaway title to the data points it describes (the high proportion of female hatchlings).

Gestalt principle of proximity: the closer an object is to another, the closer their relationship.

In Datawrapper there was only one option of title placement I could find - at the top left. A design choice that makes sense for most graphs.

Background colour

The colour gradient in the original graph symbolises the nest temperature; warming from blue to red.

Although Datawrapper was able to seperate and shade areas of the background, I couldn't find a way to run an overall colour gradient through it.

Data points and legend

Solid points in the original graph represent a higher proportion of female hatchlings and the more subdued outlined points representing a higher proportion of males (the graph takeaway title was related to the female hatchlings so I've made these stand out more).

While it was possible to outline the points in Datawrapper, the outline didn't appear in the legend making the white point disappear (as below).

I've shaded these points with a light grey in the final graph so it is visible in the legend.

Axes

I like to have as few unnecessary lines in my graphs as possible as they can add to the clutter. By shading the background of this graph, the border is already outlined so I don't need the axis lines.

In Datawrapper I couldn't find a way to remove my axis lines without losing my axis labels (as below) - even though it's okay for a scatter plot axis to not start at zero 😉

It's easy to customise the graph size in Datawrapper but not the canvas size. Axis labels were always inside the graphing area (as below), so I couldn't accommodate labels and annotations outside of this.

I like to include units in my axis whenever possible as this helps to decrease the cognitive load on a reader if they have to search out the measurement or scale.

After various attempts at Googling number formats, I couldn't find a way to include the temperature unit (°C) in each axis value so had to settle for incorporating it into the axis label.

I'll use Datawrapper again

Datawrapper doesn't have the flexibility of a graphic design software such as Adobe Illustrator but I was pleasantly surprised by how much it could be customised - something really important for the data storytelling I do. I turned off tool tips for this graph but it's also a function I can see using for more interactive/explorative data stories.

You can find out more about Datawrapper on their website: www.datawrapper.de

If you're interested in data visualisation I'd recommend taking part in this month's #SWDChallenge - whatever your professional role. It's easy to get wrapped up in learning an organisation's tool of choice, without looking up to see what else is out there.

How to uncover a data story

Thu, 13 Dec 2018 01:51:00 +0000

The role of Data Storyteller often falls on the person already knee-deep (or even completely submerged) in data. They have cleaned it, transformed it, explored it, visualised it, analysed it, modelled it, and now they have to use it to ‘tell a story’.

But to raise one’s head out of the detail of data, with the intention of focusing on just one of the many possible narratives, can be a very hard thing to do. Sometimes the deeper an understanding of a topic, the harder it is to tell just one story. One will try and incorporate as much information as possible, creating a very jumbled and often non-existent ‘story’.

I’ve seen this. I’ve done this. And from all of my learnings, I've developed my way of uncovering a story (or at least the elements of a good story) amongst the data noise.

You can download my “Uncovering a Data Story template” .

How I’ve used this template

Credit to my father-in-law, we were having a conversation about an article he read on the Green Sea turtles living near Australia. It claimed a changing climate was causing the animal’s own biology to threaten their existence. [Turtles have temperature-dependent sex determination, which means as their nest temperatures increase so does the proportion of female hatchlings. Increasing global temperatures has resulted in less and less males].

I knew there was a data story in here somewhere, so I read a lot of scientific papers to try and uncover it. But after following many information rabbit holes (some which lead as far as other species) I used the template (completed below*) to highlight only what I needed to craft a narrative.

* the original template had far more scribbles!

Character: Who will the story focus most on? This can be your business, a customer group, a product, a country, or an animal (in this case).

Event: What happened to the character (the Green Sea turtle) to make their story worth telling now? Most business stories are built around a character change or a difference between characters. Focusing on a single event will help to keep the resulting narrative concise and compelling.

Event period: If an event has occurred, it’s occurred over a certain period of time. This could anything from billions of years to milliseconds, depending on the event affecting the character.

State before/after: Data is helpful here to describe the character’s state. Ideally, you want to include information showing the change in the character as a result of the event.

Impact: What kind of an impact does the event have on the character? The more impact the event has (positive or negative), the more powerful the story could be.

Reason: Why did the event happen? Sometimes this can’t be explained, which is okay if the narrative states this.

Reaction: Is there anything that could be done in the future to continue a positive impact or reverse a negative impact? This may or may not be able to be told from a data level.

Background: This section involves an understanding of the audience you’re attempting to communicate with. What is their current level of understanding of the topic and what other information do they need to know to be able to understand the character or event? In the Green Sea turtle example, a reader first needs to know turtles have temperature-dependent sex determination and what this phenomena actually is.

Here is the resulting high-level narrative based on the above completed template:

“The sex of a baby green turtle is determined by the temperature of the nest it develops in. But a warming climate is altering this temperature-dependent sex determination process. Therefore, there is an immediate need for nest management strategies to avoid a green turtle population collapse.”

Any data not supporting this narrative, is not included in the final graphic. You may find as you start to fill out the template you have enough information for multiple stories, so fill out more than one copy of the template and tell the stories separately.

The final graphic produced from the Green Sea turtle template and narrative example can be seen here.

Designing graphs from an element level

Tue, 23 Oct 2018 22:33:22 +0000

Choosing the right graph type is an important part of any data visualisation project, with each graph usually following its own set of design rules. But the majority of graph types use only one or two basic design elements to display data. By understanding best practice visualisation of these elements, graphs can always be designed correctly.

Graph type can be simplified.

Many tools exist to help make the right graph choice when visualising data. Most approach the decision from the perspective of the data format. Data with a trend over time could be best visualised in a line graph, where part-to-whole data would be more effective as a bar or pie. Graph type is an important decision but too often the right graph choices are still visualised wrong.

“All graph axes should start at zero”. This is a statement I hear debated a lot. To set the record straight, this is wrong. Not all graph types require their axes to start at zero. But how do you know what rules to follow for what graphs?

Each graph type has best practice design rules, and learning these will enable you to visualise them correctly. But many of these design rules are repeated for multiple graph types because graph type can be broken down and simplified further.

Graphs can be designed from an element level.

The majority of graph types use one or two basic graph elements to visualise data: area and/or point.

These are not to be confused with design principles (such as Gestalt) which will help to add order and reduce graph clutter.

Graph elements

If your graphed data is shaded, you’re using area to visualise it. If your graphed data is plotted, you’re visualising it using point (or position). For some graph types, you’ll have to do both. Understanding graph design at an element level will enable you to correctly create most graphs.

Visualising Area

Graph types using only area to display data include Proportional Area, Waffle, and Tree graphs.

Area displays data differences through relative size. When visualising data using area, there must be a zero baseline. Without a zero baseline the area used to represent data is incorrect and deceiving to the viewer.

Visualising Point (or position)

Graph types using only point (or position) to display data include Scatter, Line, and Bump graphs.

Point displays data differences through relative position, rather than size (see area). Because of this, graph axes don’t have to start at zero.

Some graph types connect their points with lines e.g. Line and Connected Scatter graphs. Lines are not graph elements, they provide a connection between points (an application of the Gestalt principle - Connectedness). Cole Nussbaumer Knaflic offers great advice on when to apply this: “the lines that connect the points need to make sense”. Line graphs are good for visualising time series data, and for most people it makes sense to connect the points.

When displaying data using point, all points should be the same size. If they aren’t a uniform size, area is also being used to visualise data (such as a Bubble graph). In the case of the Line graph, points are often smaller than the lines used to connect them.

Visualising both Area and Point

The majority of common graphs combine area and point to display data. These include Bar, Area, Bubble, and Pie graphs.

Graphs with area and point elements compare data using both relative size and position. It’s important to understand where in the graph each element is used, to visualise it correctly.

Area can be measured from horizontal, central, or vertical baselines. Zero baselines will differ between graph types.

Points can be plotted on vertical, horizontal or circular scales. Axes direction will differ between graph types.

Understanding graph element design will improve your data visualisation.

Applying visualisation rules to graph elements will help you design any type of graph correctly.

For example:

Bar graphs have an area element so they must have a zero baseline, so as to not distort this element.

Line graphs don’t have an area element (only point), so they don’t have to start at zero because they are visualising relative position.

Bubble graphs have area and point elements. In this case, the area's zero baseline is central to each circle, therefore the point axis doesn’t have to start at zero.

When choosing a graph type, remember: area and point differences are not perceived by people with equal success.

“Our ability to perceive differences in 2-D areas hasn’t evolved to the same level of accuracy as our perception of differences in 2-D position, perhaps because it was more important for survival that our ancestors could detect the exact location of the sabre-toothed tiger, rather than its exact size” – Stephen Frew

Tell me a data story.

Mon, 10 Sep 2018 03:11:00 +0000

Sounds simple enough...

But there are two parts to this request: the writing of the story, followed by its telling.

To tell a data story, you have to write it first - unless you were born with the innate ability of story creation on the fly, and eat data for breakfast (but even then you’ll want to allow time for quality checks...).

You can read more about what a data story is (and isn’t) here.

The September #SWDChallenge: makeover this graph.

Each month, Storytelling with Data sets a data visualisation challenge and one word in particular stood out to me this month - storytelling.

“Consider the following visual. Your challenge this month is to improve it utilizing data visualization and storytelling best practices.” – Elizabeth Ricks.

I chose to focus my efforts on uncovering a story in the above graphs - both in its writing and telling.

Writing the data story.

A good way to find a data story is to start questioning the holes – find the information gaps the graphs don’t explain.

How much money are we talking about?What proportion of global GDP is this?Why are Europe and Asia Pacific showing almost an inverse change, while the others remain fairly constant?What drove the increase for Asia Pacific?

Answering some of these questions helped create a narrative for the series of events in my story. Here is the narrative I wrote for the above graphs:

Travel and tourism generated $7.6 trillion dollars globally in 2016. This was 10% of the world’s total GDP. Asia Pacific made the biggest contribution with 31%. But years earlier, Europe was the leading travel market - in 2000, Europe was responsible for over a third of global travel and tourism GDP. Over the next 16 years, driven by a strengthening economy in the Asia Pacific region, Asia Pacific surpassed Europe as the global leader in GDP contribution from travel and tourism.

Important to note: I wrote the data story before visualising anything.

Telling the data story.

Once a narrative has been written, there are many ways it could be told. For this particular data story, I chose to animate it using Adobe After Effects.

A data narrative will naturally lend itself for the visualisation of certain parts. Below is my draft (pen and paper) visualisation of the above narrative:

Narrative: "Travel and tourism generated $7.6 trillion dollars globally in 2016."

Visual: A growing bar chart.

Narrative: "This was 10% of the world’s total GDP."

Visual: A globe enclosed by a donut chart.

Narrative: "Asia Pacific made the biggest contribution with 31%."

Visual: A map highlighting Asia Pacific with a stacked dot plot showing global GDP contribution.

Narrative: "But years earlier, Europe was the leading travel market - in 2000, Europe was responsible for over a third of global travel and tourism GDP."

Visual: A map highlighting Europe and a stacked dot plot showing the global GDP contribution (dots animate to change position). The year winds back to show previous time period.

Narrative: "Over the next 16 years, driven by a strengthening economy in the Asia Pacific region, Asia Pacific surpassed Europe as the global leader in GDP contribution from travel and tourism."

Visual: Connecting lines between the 2000 and 2016 dot plots create a slope graph.

You can see the final (no-frills) animation here.

Tell me a data story.

Putting effort into the data story process will make your data communications more effective.

Find out what your data does not explain. You will have to look elsewhere for answers but this will help to find your narrative.Write the narrative. Use words only - no pictures.Tell the story. Visualise your data.

Data stories: the glue of the Analytics Cycle.

Tue, 04 Sep 2018 02:58:00 +0000

Anyone working in analytics will be familiar with the Analytics Cycle, in some shape or form. It’s an Analyst’s version of the Scientific Method (perhaps even, justification of the term “data science”).

The Analytics Cycle outlines the high-level process followed by Analysts to uncover data insights and ultimately add business value.

A traditional Analytics Cycle

Ask: Consider the business problem the project is attempting to solve.

Prepare: Decide what data sources are suitable and prepare the tables for analysis.

...

And yes, this bit takes ages 🤯

...

Explore: Understand the data and the subject it represents (customers, products etc.).

Model: Calculate further insight with advanced statistics and computing power.

Act: Apply the insight to a business process.

Evaluate: Understand how your insight-driven action performed.

Simple right... but is this real life?

For a business looking to harness analytics, the steps in this cycle have almost become a check list. But modelling is the exception, not the rule. Many actions can be taken from insight uncovered during exploratory analysis.

A more realistic Analytics Cycle

A business is more likely to go through the below Analytics Cycle (even in an ideal world).

Modelling should never be undertaken if there is not a clear use case for the output.

Modelling is a nice to have (if required) but in many cases not necessary to answer the initial business question.

Sharing insight makes the Analytics Cycle go round.

There are at least two moments in the Analytics Cycle when insight should be shared with the wider business.

After exploring, and before acting.

Regardless of if any future modelling will occur, exploratory insight should be shared with the business. This allows those with more knowledge on the subject (as opposed to data on the subject) to confirm or question its representation. It is better to pick up discrepancies at this point, than incorporate these into a model.

Insight uncovered through exploratory analysis could also be actioned by the business, without the need for a model.

After evaluating, and before asking.

Incorporating insight into existing business process is the usual application of it, but if we don’t measure and learn from this we are doomed to repeat the same mistakes. Understanding how effective (or not) a change has been, helps generate new questions for the next analytics cycle.

Kick it old school.

Distributing data to business users without real-world (or better yet, “their-world”) context, will not inspire them to act. Your pile of sundry facts is not motivation for someone to invest time on a data project, where the value is not clearly obvious. This barrier for engagement creates a huge gap in your analytics cycle.

But humans are evolutionary hard-wired for narrative. Data stories, when used as tools for communication, help bridge the business-analytics “engagement gap”. They paint a bigger picture and evoke an empathy for what the numbers actually represent.

Data stories are an effective way to engage internal business users with analytics.

Avoid the modelling silo.

One of the biggest traps an analytics team can fall into is the modelling silo. This occurs when analytics is practised with no input from the rest of the business. This is an expensive use of resources and can be dangerous if any output is ever actioned (although most of the time it isn’t).

The output of analytics is information that may enhance a business.

But analytics should not operate in silo.

So share the insight you find… and tell a data story.

Myth busting the "data story"

Wed, 29 Aug 2018 04:39:14 +0000

What is a data story?

There are lots of terms thrown around the analytics industry (artificial intelligence, machine learning, data science, etc.) and we often tend to over-complicate their meaning. But one of these “buzz words” is near and dear to my heart, so I feel the need to defend its honour… or at least properly define it.

The data story.

A “data story” is a story supported by data. It’s not rocket (or data) science…

It is simply a narrative, written with data as supporting evidence.

For example:

"Churn is a problem for our business and churn rates have been increasing steadily over the last 18 months. But regional analysis shows areas with the highest churn rates also have the largest competitor activity. Therefore, if we target specific regions with offers more in-line with other providers, this could help to retain customers."

What is not a data story?

The lure of a buzz word… I’m pretty sure the number of Analysts declined at the same rate as the number of Data Scientists increased (disclaimer: I haven’t looked for data to back this up). Regardless of your job title, unless you do something to grow your skill set you are still only capable of doing the same thing.

As more people adopt a term it morphs into something else entirely, so I’m setting the record straight on the term “data story”, by explaining what it’s not:

A visualisation

Data visualisation can be an effective way to tell a data story (see below) but it relies on the story having been written first. If you are calling every data visualisation a data story - please stop. Some visualisation techniques (especially those based around design principles) lend themselves to enhance data storytelling, but these do not apply to all forms of data visualisation.

Data visualisations are not data stories.

A random statistic

Putting a number on a page (or in an email, or on a billboard) is not a data story. It is a statistic, usually a really big statistic and probably a statistic presented to the high visual standard of a graphic designer.

Statistics are not data stories.

Data science

Data science is a behaviour. It’s the technical practice/process followed to uncover data insights and ultimately add business value.

Data science is not a data story.

How do I write a data story?

If you take one thing from this blog post, let it be this:

Data is not the story – it just helps to support a bigger message.

A good data story will be written with a purpose (knowledge of the action it is trying to create), it will target a specific audience, and communicate a message (through narrative and supporting metrics). Data stories are so much bigger than the metrics that help support them.

You can download my Data Story canvas here. Techniques to complete each section of the Data Story canvas are covered in Rogue Penguin's Data Story workshops.

How do I tell a data story?

Only after a data story is written can it be told, and there are many ways to do this.

Verbal

From the camp fires of our ancestors, this is perhaps the most common form of storytelling. Their stories served as instructions, warnings, and inspiration – all purposes still relevant today.

Visual

Written words, images and graphs can all be used to aid in telling a data story.

There are many different data visualisation tools but not all graphs/charts/dashboards created in them are appropriate for storytelling. Visual data storytelling relies less on the software and more on the storyteller. The book “Storytelling with Data” by Cole Nussbaumer Knaflic is a great starting resource.

Both verbal and visual

Combining verbal and visual methods of storytelling covers multiple communication preferences. Presentations are a great format for storytellers. An audience can hear a story and have it supported further with visuals.

I’m sure this definition of “data story” will continue to evolve as the industry matures - and that’s exciting! I hope the term doesn't get defined so broadly though, that its meaning is lost.

Graph makeover

Fri, 06 Jul 2018 03:46:33 +0000

The #SWDChallenge this month was a graph makeover - simply turn any existing graph into a better one.

Something I do for fun (acknowledgment of my data viz obsession!) is collect graphs I think could be presented better differently.

The graph I picked for this challenge is one on my local council’s website. It shows how Wellington City Council allocate rate payments across their service areas.

Before: graph to makeover

Source: Wellington City Council website

Here were some of my initial comments:

What do the colours mean? Is green conservation?Radial bar - is it a pie, is it a bar? 🤔The bars are hard to compare.Per $100 isn’t that relatable as rate payments are much higher than this (I realise this could also be read as percent though).There is no order to the bar arrangement, apart from colour (but no legend to identify what this represents).The big icon circles make the bar length deceiving.

I felt I needed to understand the topic more so poked around the Council website and followed up with a few questions (thank you, Heather for replying to my seemingly random tweets!).

I want to emphasise the resulting visualisation is in no way a reflection of WCC endorsement. I have personally made over their graph for learning/demonstrative purposes.

Here are the changes I made, and my reasoning behind them:

Lose the overall circle.

Radial bar graphs make it very hard to compare variables. Anyone using this type of graph should try to apply some order to the positioning of the bars e.g. to reflect value or time etc.

Lose the icons.

Icons are great to increase engagement of a data visualisation but too many can add clutter to a piece. These circular icons also deceivingly add to the area of each bar.

Group the bars.

For me there are too many bars at the same level of visual hieracy. My brain desperately wants to apply more Gestalt principles to create some order.

I’ve used the priority areas below (detailed on another page of the Council website) to help categorise the bars:

The priority area colour scheme has also been applied where possible. Anything not covered by these categories I’ve grouped into General Council Operations. Disclaimer: I’m not sure if the Council would find this correct!

Rank the bars.

Ranking bars from highest to lowest removes some of the cognitive load on the viewer and helps increase the visual order of the graph.

Make the dollars more relatable.

Anyone who pays rates knows the amount is likely to be a lot more than $100. Instead of using a ‘per $100 of total rates’ measurement I’ve gone with the average rate payment. It’s still only an average, but a more relatable figure with less calculation required by the viewer.

Add in Goods and Services Tax.

From the perspective of the rate payer, their total payment (including tax) is the amount they pay in rates. If you’re showing the true allocation of a rate payment I think GST should be included.

After: graph made over

I've kept a lot of WCC branding elements but added more alignment, grouping and a different view of the data.

If you're looking for a way to improve your data viz skills, I think makeovers are a great way to do this. Sometimes just listing out the elements you think don't work (and why!) is a quick and easy way to train your design eye.

Thanks, Wellington City Council for starting off this data viz 💛🖤

Response from Wellington City Council:

A personal data viz development challenge

Wed, 20 Jun 2018 08:28:00 +0000

As someone who is lucky enough to specialise in communicating technical information 😍, data visualisation is a big part of my professional life. But all those NDAs make it hard to share a lot of this work with the world. Therefore, at the beginning of the year I set myself a 'resolution' (something I don’t do often) to create more personally-driven data visualisations.

But where to start?!

In January as if in answer to this question, Storytelling with Data launched #SWDChallenge - a monthly data visualisation challenge. A different visual framework is proposed each month but participants are given the freedom of choice around tool and data.

The digital community is amazingly supportive (just type #SWDChallenge into Twitter!) with lots of minds thinking differently about the same challenge.

If you’re looking to improve your data visualisation skills (or those of your team) I highly recommend participating in the #SWDChallenge.

I'm 6 data visualisations complete, 6 to go!

You can check out my visualisations to date 👉 here.

The end of traffic light dashboards

Mon, 23 Apr 2018 08:10:00 +0000

The psychology of colour is fixed in us from an early age and businesses have a long-standing obsession with traffic light inspired data visualization. But how effective are these red-green dashboards when viewed by someone who can’t differentiate between these colours?

Data visualization good practice should include accessibility of design.

The reason traffic lights are red and green

Red has long been used to signal danger, but why? Red has the longest wavelength of any colour on the visible spectrum, which means it can be seen from a greater distance than other colours. This is perfect for a driver who needs as much notice as possible to stop.

Image: Red has a longer wavelength than any other colour on the visible spectrum.

Green is located on the opposite side of the colour wheel to red. Used together they show the most contrast between each other than if they were paired with other colours. Green has a mid-length wavelength on the visible spectrum so can also be seen from a relative distance.

Image: Red and green are located opposite each other on the colour wheel.

Using this logic it makes sense to design a traffic signalling system using these colours. But, what about the 5% of the population who can’t differentiate between red and green?

Colour blindness

Colour blindness affects approximately 1 in 12 males and 1 in 200 females. Chances are you know a few people who have a colour vision deficiency (CVD). The high contrast seen between red and green with normal vision is not present for someone with the most common type of CVD, as they are unable to differentiate between these two colours.

Image: How red and green can be viewed by different people.

How to make data visualizations accessible for CVD

Colouring a data visualization should always be done strategically – leave the rainbows in the sky! Colour is one of the most powerful preattentive attributes when used correctly. A data visualization can still benefit from the psychology of red (stop) and green (go) but only if you understand clearly the message you want to communicate.

For example, the two graphs below show the same data but their narratives are very different. The graphs wouldn’t be used together but at the discretion of the report writer, depending on what they wanted to communicate.

Image: Graphs showing elements of positive or negative storytelling.

Tip: Red and green are fine to use independently of each other. The CVD problem occurs when the colours are used together as the only way to understand data.

If you must use red and green together

Ideally, I wouldn’t recommend using red and green together but there will always be situations when you can’t avoid it. We can learn from the reasons traffic lights still work and apply these to our data visualizations.

1. Relative position

There is a consistent order to the position of the red, yellow, and green lights (depending on where in the world you are). This way of reading traffic lights is not as intuitive as colour differences and may require a slightly longer reaction time, especially at night.

Image: Different traffic light layouts around the world.

Tip: Try to not make colour the only way you differentiate between data points. Position, shape, and size are all good design principles to use in addition to colour, for your chart to be accessible to most audiences.

Image: A traffic light in Canada with specially shaped lights helps assist people with CVD.

Tip: I like to design data viz prototypes in greyscale only. If it works in black and white, it will also work in colour - which can be added later.

2. Shade of green

Traffic light green isn’t actually green-green (or grass-green). Its wavelength pulls it slightly towards the yellow or blue (depending on where in the world you are) parts of the visible spectrum. This doesn’t give it a lot of difference for someone with CVD but makes it slightly more accessible.

Tip: Try to push your ‘green’ to more yellow-green or blue-green parts of the colour wheel (remember painting as a kid... blue and yellow make green!).

Image: Adding blue or yellow to your green will make it more accessible when used alongside red.

Tip: If you’re working with RGB values, increasing the ‘G’ value of your green will lighten and intensify your colour. This can give enough contrast against a duller red for CVD viewers. Be careful when printing as high ‘G’ values won’t be viewed the same on paper as on screen.

Image: Increasing the 'G' RGB value of your green will make it more accessible when used alongside red.

Tip: This website created by Susie Lu and Elijah Meeks is a great tool to check how your colours are viewed by someone with CVD.

Change your thinking on data visualization design

Many fields are designing for accessibility but I feel the business data visualization world is slow to respond to this.

If you are responsible for communicating with data please be aware of the people who don’t view the world the same way you do.

Not all Data Viz needs to tell a story

Tue, 26 Sep 2017 20:28:00 +0000

Data viz can have a bad rep.

Sometimes this is justified – it’s just badly done. But there are times when the type of data viz is wrong for the objective it’s trying to achieve. Understanding the purpose and audience of your data viz is key to its success.

Data viz can be exploratory (used to explore data) or explanatory (used to explain data).

An amazing example of a recent exploratory data viz is Chris McDowall’s interactive NZ election vote map. Users have the power to navigate and seek answers to their own questions. The data is presented without bias - it is there to explore.

Exploratory data visualisations don’t tell stories, they enable them be found and written.

However, if a user is uninterested in exploring, their usual response is… “so what”? This question is a sign they want to be told a data story.

Explanatory data visualisations tell stories.

So next time ask yourself, is your data viz here to explore or to explain?

How to write a Data Story

Mon, 28 Aug 2017 22:22:00 +0000

Click here to download the PDF version.

What is Data Storytelling?

Sun, 06 Aug 2017 22:14:00 +0000

The concept of storytelling has become a popular tool for business users. Combine it with the word ‘data’, and it becomes even more appealing. The problem, like many buzz words, is the term has reached a tipping point of use, where it no longer holds value.

We’re all familiar with what it means to tell a story – we hear stories every day in our conversations with each other. A story is essentially a series of events (however small). To tell a story, is to communicate this series of events in some way.

Digital platforms play a role in modern storytelling – Facebook, Instagram and Snapchat all give users the opportunity to create and share their own story. The events captured by this media may not always be interesting, but then we don’t always tell interesting stories…

So what is storytelling, in a data context?

Data storytelling, uses data to help support the communication of a series of events.

Businesses are good at using data to describe a single event, usually because the data in question is a tracked metric. Where businesses need help, is joining the dots between events, to create a series of events – or a story.

Focusing on why an event happens, helps connect it with other events. Using data to support the occurrence of these events, creates a data story.

A good data story always has a point, or an audience take away - you've connected a series of events and supported these using data... so what? What do you want your audience to do or know? Data stories should start here!

If you aren't clear on a key take away, you will fail in telling your story well.

Storytelling is a skill. Storytellers who include too many irrelevant details, generally lose their audience before getting to their point (if they’re even aware of what this is).

Good data storytellers have identified their key message, include only event data to help convey this, and understand the best way to communicate with their specific audience.

The overlooked Data Storytelling skill

Fri, 21 Apr 2017 03:21:00 +0000

As Analysts, we’re good at presenting information the way we would like to receive it – multi-dimensional and detailed. The interest we have for our chosen topic drives us to leave no stone unturned in our analysis. This makes us great Analysts. Our attention to detail also compels us with the need to present findings from every angle.

As Business Users, we want to receive information we can action. Our customers, people and bottom line are what’s important. Analytics is great, but only if a subsequent process change impacts our business. We don’t need (or desire) to know how insight is generated, just what we’re going to do to leverage it.

So, how do Analysts communicate insight effectively enough, for a business user to then create change?

Data Storytelling is a method to emotionally connect analytics with business users.

Data Storytelling directs the focus of a specific audience away from the noise of data, to a purpose relevant to them.

To enable a business user to engage with analytics, an Analyst needs to connect to the motivation of the business user. For this reason, empathy is a vital skill in data storytelling.

“You never learn anything without there being an emotional connection” – Gordon Poad.

One piece of analysis can uncover multiple data stories. The role of a storyteller is to find one to resonate with their audience. Each story begins with a narration, which is then told - usually with the use of technology.

Data stories can be written, by anyone, using just a pen and paper.

Data Science vs. Machine Learning

Tue, 21 Mar 2017 02:13:00 +0000

There’s a lot of talk today of data science and machine learning. Like any buzzwords, their meaning is muddied as we try to include more of the work we do in their definitions (everyone wants to be a Data Scientist, right?).

Data science, also known as data-driven science, is the process of gaining business insights from data. It is not a tool, but a behaviour. The role of a Data Scientist encompasses business strategy, hypothesis generation, data wrangling, analysis, modelling and insight communication (often in the form of data visualisation).

Machine learning is a data science technique. It describes a type of modelling, similar to statistical modelling, with the aim of finding hidden patterns in large data sets. Statistical modelling techniques are often described as a type of machine learning as, over time, the disciplines have merged and overlap more of each other

Statistics holds assumptions to infer events.

Machine learning uses data to predict them.

There are two main types of machine learning:

Supervised learning techniques (also known as predictive or directed) are used when you know what you are trying to predict (your modelling target) – customer churn for example. These models analyse historical data to identify variables that will help to predict your target in future data. Businesses have been building these types of models for decades, with common modelling techniques including classification and regression.

Unsupervised learning techniques (also known as descriptive or undirected) are used when you don’t know what you are trying to predict – product recommendations for example. The modelling (such as clustering or feature extraction) is nothing new, but the volume of data these models are exposed to has led to the hype around this type of machine learning.

Some things to watch out for when using machine learning:

Not all models work for all business problems. Many machine learning models are black boxes. You put data in and you get an answer out, but you are unable to understand what influenced the output. The model may be more accurate than traditional statistical approaches, but it’s a process you can’t explain to the business.

Machine learning is not magic. It is a set of tools you can use to help solve a problem. There will always be some sort of human judgement as part of the machine learning process.

Machine learning can be bias. Models that learn from data showing prejudice will have this bias built into their output. There are many ethical questions that will need to be considered in a future of machine learning.

Does your business need data science and machine learning?

In regards to data science – yes, absolutely. All companies can benefit from using parts of the data science process to help drive their business. Regardless of the amount of data a business collects, putting structure around how this data is used will lead to insight.

Machine learning isn’t for everyone.

To build a machine learning model you generally need lots of data and that data needs to be clean. Once built, there also needs to be a way to operationalise the model (that is, it needs to run in-database).

Businesses are quick to jump to more advanced machine learning solutions before mastering the data science basics. The solution should always be what’s best for the business problem. Sometimes, understanding and applying a data science approach is enough to generate great results.

The First 3 Months of a Startup

Wed, 25 Jan 2017 02:06:00 +0000

It's a startup world! But, do you know where to begin...?

For anyone thinking of making the jump to self-employment, here are some recommendations from my experience during the first 3 months of Rogue Penguin.

Build a network of incredible people

I couldn’t imagine starting a business without first establishing a solid connection network. My network was the difference between Rogue Penguin flying or struggling to get off the ground. These people provided support, advice, introductions and (importantly) work – they were (and still are) my biggest advocates. Thank you!

Get a good Accountant

If there’s a business process that makes me feel (more) like a fish out of water, it’s the accounts. Early on, this is something I knew I would need help with. I met a great accountant at a networking event a few months before starting the business (not thinking I would ever need their services) – thanks again network! I’m now a Xero user but leave most of the heavy lifting to the experts.

Understand your rate

It’s one of the most nerve racking questions to answer when first starting out – what do you charge? It brings into focus too many self-doubting questions. I got some unexpected help with this in one of my first contracts. I proposed an hourly rate to a potential client and their counter offer was 20% higher, as I was “underselling myself”. I will be forever grateful to this person for (literally) helping me to value myself.

Tell people what you’re doing

If you’re self-employed, no one is better at selling what you do than you. Tell everyone, regardless of whether you think they will use what you’re offering. It’s good practice for working out your elevator pitch.

Cover yourself

Insurance may be a set-and-forget purchase but take the time to look into it. Professional Indemnity, Public Liability, Income Protection – these are all things that should at least be considered, after talking to a professional.

Healthy body, healthy mind - able to work

I have never valued the ergonomic setup of (most) corporate offices as much as I do now. My work involves me travelling between client offices with a laptop, or working after hours from home – on a laptop. It took 2 months before my neck gave up. I was off work for a week, at regular physiotherapy for 6 weeks and have never been in that much pain. One gym membership, a personal trainer and a big screen later… I’m choosing to invest in prevention rather than treatment.

Prepare for things outside of your control

What would you do if you couldn’t access your computer, or files, or colleagues, or office? Many companies were forced to answer this question after November’s earthquake – and are still reeling from it. The importance of being able to work remotely, even if you don’t, has never been so important. Thanks to file sharing apps like Dropbox and collaboration tools like Real Time Board, this is getting easier.

Narrow your personal scope

Starting out, I was open to anything – mainly due to professional interest but also being terrified about not getting any other work. This constant saying ‘yes’ meant I was over committed and, at times, doing work that did little to inspire me. Had I not given it a go though, I would have missed out on discovering the work that I now jump out of bed for. Narrowing down the work you love, also involves identifying the work you don’t.

The Unconscious Bias of Infographics

Sat, 08 Oct 2016 02:59:00 +0000

Graphics are an effective way to visually communicate information. Certain icons are chosen over others as they have the power to instantly make a story understandable. It’s not surprising then, that particular images have been used to portray specific data.

For example, this is an image that is easily recognised anywhere in the world:

If particular colours are added, the meaning is even more intuitive:

The woman and man icons, created at the beginning of the last century, are common ways to visually represent gender. They are intuitive (there is no language or literacy barrier) and therefore are now seen everywhere.

But are they still relevant?

Data visualisation should be without prejudice, letting data tell its own version of the truth. Can this happen if the icons used are filled with their own discrimination?

Why can’t a man wear a dress? Why can’t a woman wear blue?

Today's world should not still be using fashion to define gender.

So what are some alternative ways to visually represent gender?

Chromosomes

The DNA level leaves little room for social influence. These visuals can often be confused with each other though, depending on the background of the audience.

Symbols

The use of symbols to differentiate between genders is centuries old. They are still used today in various industries, including the study of genetics.

Appearance

Representing a gender by a certain appearance is where society begins to have an impact. I’m not a fan of this method but it is effective in communication.

Objects

Objects can play on the difference in anatomy between genders. These are not always instantly recognised and only appropriate for certain audiences.

Words

Being obvious and spelling out a gender is an effective way to differentiate between them. This does rely on the audience understanding a specific language.

Acceptance of the right to choose the gender you identify with, is only increasing - and I hope it continues to. Visual communicators need to ensure that their work doesn’t hinder this movement.

I love the message the team at It Was Never A Dress is spreading. They are redefining the message:

Visual communicators need to adapt to represent the society they are communicating to.

Are you aware of the unconscious bias in your visual communication?

Why I'm starting my own business

Sun, 14 Aug 2016 03:50:00 +0000

Last week I leaped off the cliff I’d been dancing on the edge of for so long.

I left my permanent job to start my own business.

My resignation letter went something along the lines of:

Dear , It’s not you. It’s me. I need to let you know that my last day will be . I still love you but I’m really looking for a more open relationship. I hope that we’re still able to stay friends and hang out in the future - maybe just not as often. You’ll find me running my company of one, and hopefully not too lonely… Kat.

Then the rollercoaster pulled away from the platform.

But I’m not an adrenaline junkie, so why am I willingly lining up for this ride?

These are my 3 main reasons for going rogue:

My career clock ticked. I never grew up wanting my own business. The thought didn't cross my mind until about 3 years ago, where it was more an amorphous daydream than any real plan. Either way, something stuck. Over the past year I’ve met some incredibly kick-ass women doing their own thing (looking at you Shadoe, Sam and Kat!). Amazing women like them are laying the path for others to follow. For that, I’m grateful.

I believe there’s a gap. Companies aren’t lacking data. They usually aren't lacking reports either. What they struggle to do is use the insight they generate. There are multiple reasons the return on data insight can be lower than expected. Resources are usually spent on insight production (expensive software, model creation, monthly reporting) - all important elements of a data-driven business. Rarely is the same amount of focus given to how insight will be operationalised (stakeholder management, hypothesis generation, experiment design, testing). The low number of businesses being driven by their data is not due to their lack of analytics; they are simply missing the data translating skills to use it.

I have more to give. I find some roles today are almost self-limiting. Their scope is restricted to a task or deliverable, with little overlap for something seemingly unrelated. This may be great for a business (having someone so specialised), but for many employees their skill sets are more diverse than those detailed in a single position description. We keep trying to box what can’t be boxed, into smaller and smaller boxes. So I’m re-writing my role, based on all that I have to offer.

It’s for these reasons (and more), that Rogue Penguin was born.

Supporting companies to generate, communicate and action insight.

You're So Vain, You Probably Think That Metric Is About You

Sat, 16 Jul 2016 08:32:22 +0000

It wasn’t until recently I realised the extent of the vanity metrics problem. Sucked in by their shininess, I had blindly played a role in their endorsement.

I’ve read (and produced) many reports that were praised for being interesting. Interesting but not actionable. And I fear this is the norm we’ve created. It’s acceptable to produce a huge amount of numbers on a regular basis. So much so that we now need to automate the process.

“The key to actionable metrics is having as few as possible.” – Eric Ries.

If you have a piece of data on which you can’t act, it’s a vanity metric. A good example - the number of visits a website gets a day. Doubling this number probably isn’t going to change the way you’re running your business. The metric doesn’t shed any light on who’s visiting, what they’re looking at, if they’re subscribing, if they’re buying or why they’re leaving.

The metrics that should matter to you will enable you to change your behaviour by helping you to pick a course of action.

It took working for a startup to break the hold vanity metrics had on me. Corporates may have the resource to track numbers for fun, but startups need to defend their every dollar. Their chosen metrics are reflections of the business levers they’re trying to optimise.

Here are a few ways to open you eyes to vanity metrics:

Have an influence. Metrics measure effects. They will help you to monitor the things that you’re capable of influencing. A business needs to not only understand what their metrics represent, but the behaviours that influence them. A metric of importance, that you can’t influence, needs more analysis to be understood.

Be open to change. If the metrics you track aren’t changing, then neither is your business. A business’ metrics should be a reflection of their focus. Metrics require monitoring, discussing and, at times, changing. As a business grows, signups and brand awareness (priority one in the early stages) may be replaced with some sort of revenue goal; with a focus on different metrics.

Know where you’re going. Metrics enable you to track progress towards a specific goal – big or small. If you can’t picture the end game, a metric’s value is worthless. Setting a target (and experimenting with the levers that influence it) will help you define what success looks like.

Less is more. ‘Data Visualisation’ has been an industry buzz term for a while, with many new software vendors in the market. Their tools provide businesses with the opportunity to track everything, when that’s the last thing they should be doing. With reporting automation becoming mainstream, understanding why you’re tracking specific metrics is a key to being a data-driven business.

Metrics reflect operation. They need to be understood and agreed on by more than those who track them. The process around using insight is just as important as the process that produces it.

What It Means To Be Data-Driven

Sat, 16 Jul 2016 08:23:57 +0000

If your weather app showed a 60% chance of rain, you would probably reach for a jacket before leaving the house. This new information would influence your behaviour. In a business-context, although a much bigger scale, the concept remains the same – a choice is made to do something (or not) on learning certain information. This is nothing new; businesses have been doing this for years... so, why is being data-driven the 'it' thing to do today?

The trouble now is there’s too much data. Businesses not only have to create unique activities, they also need to identify relevant data prior to traditional activity planning. And the hard work doesn’t end with a successful launch; measuring the right post-campaign information should be more than a glowing afterthought. To validate the right data was used to drive an activity, the right (and probably different) data will need to be measured afterwards.

And this end-to-end process is today’s definition of being data-driven – the scope has changed.

A data-driven business does more with it’s data than produce good insight. Generating insight starts with the need for an answer to a specific question. Data is not magic; it does not speak to people. Ask it a question and it will volunteer an answer. Being data-driven begins with an action, based on this answer. Data-driven companies operationalise their insight.

When a business pours their blood, sweat, tears (and money) into an activity, the results need to be definitively measured. The key to improving a business process is dependent on their understanding of how to influence the cause and effect. Investment in future changes, as a result of input from a data/insight feedback loop, is an enabler for any data-driven process.

It is not the sole responsibility of an Analyst to make a business data-driven.

“An intelligent organisation is not about the ‘cleverness’ of one analytics team but the insightful nature of the entire business” - Pearl Zhu.

Not everyone needs to know how data is processed, or how insight is created, but a collective understanding of how to operationalise the learnings – that’s what builds a true data-driven business.

How to make an Infographic

Thu, 19 May 2016 08:34:00 +0000

Infographics are a fun and unique way to visualise your data, but how do you make one? Here are a few things that I consider when building my infographics:

1. Who is the audience?

The first step in their creation, is to characterise the audience for the visualisation. The viewer’s requirements of the infographic will determine the type of design required – data-driven graphic design or data-driven art. Does the audience need to understand the underlying data in detail, or just the big picture?

2. What is the story?

You then need to uncover the story the data has to tell. Analytics may be required at this stage to help mine deeper into the data and highlight the real message.

3. What metrics can you use to tell the story?

When the story is revealed, the metrics need to be chosen that will best portray that message. Is only one metric required to support the message or are there multiple metrics that combine to tell the story? Are these metrics made up of multiple categories or are they dependent on a higher hierarchical metric?

4. What will it look like?

Only when you know all this information can you begin to think about the design. There are many things that are restrictive in the design of an infographic. Does it have to fit into specific dimensions? Will it be viewed on a computer screen or a large poster? Does it have to be branded? Does the data require referencing?

Developing unique design concepts, which will work with the data, can be challenging. It helps to surround yourself with collaborative, creative people that enhance the generation of your inspiration and ideas.

5. Construction

Only now, that you know who you're presenting to, the story you’re telling, the metrics you’re using to tell the story, and how you want the graphic to look; do you begin construction.

Our infographics are built using Adobe products; Illustrator, InDesign and Photoshop. With more and more online tools available to create infographics, the skill lies in the ability to tell the right story and present it in a unique way.

Click here to check out some of Rogue Penguin's infographics.