When data speaks, who is listening?

Perhaps a bit early for resolutions but I need to claim this one publicly so I am called to accountability. In the past, I have viewed data visualization as sketches for launching bigger and more granular data projects. Nothing wrong with this approach but I am now thinking the crumbled pages or archived visualizations--with a little more refinement--might be worthy of attention on their own.

My favorite leader in the data viz revolution has been The Financial Times. I will admit it here, dear reader. I subscribe solely for the charts and data.

I tend to work as a design thinker. I need something visual before I can articulate or refine a problem. Before I see or look for data (depending on my role) I sketch a quick graphic to seed an idea of what might be the best option for visualizing the data and communicating little arguments.

A visual drawing also helps to communicate to teams about the type of data needed to address the question posed, and the feasibility of the approach. For example, without geospatial data, mapping patterns according to geography are not possible (although existing limited geocodes can be enhanced with a little artful integration of Shapefiles for example).

Here is a snippet from a book on my shelf, Design Thinking: Understanding How Designers Think and Work, the bolded words in the original text read "designer(s)" I swapped them for data scientist(s).

​It works.

Experienced data scientists know that it is possible to go on almost forever gathering information and data about a data problem, but that they have to move on generating solution proposals, which in themselves begin to indicate what is relevant information.

In a data project it is often not all clear what the 'problem' is; it may have been loosely defined by the client, many constraints and criteria may be un-defined, and everyone involved in the project may know that goals may be re-defined during the project.

​In data, 'problems' are often defined only in relation to ideas for their 'solution', and data scientists do not typically proceed by first attempting to define their problems rigorously. Of course, this can mean that important information is overlooked, or is discovered only very late in the data process, causing disruption and delay."

We need to pause and define the problems--rigorously.

​I like how sketches can draw you in even in the absence of a shared language. I included the graphic below because I got lost in its simplicity and ability to communicate ideas and situations.

Andy Kriebel recreated the visual vocabulary wonderfully and artfully to be interactive.

Scroll below to interact with Visual Vocabulary!--Andy Kriebel

Attention, patience, and time is well spent when launching data projects. In prior years, many of us worked in silos while our clients kept a distance.

Let's be honest, nobody on the client side particularly cared how the sausage was made. Now it is all about collaboration.

​All the technical mumbo jumbo hangs silently in the air and you better be able to rein it in and communicate clearly--whether its statistical modeling, null hypothesis testing, or helping to refine the data question.

We are listening...