In Defense of Simplicity, A Data Visualization Journey

The last 8–9 years of my career have been focused on Data Visualization, which has given me plenty of time to develop a philosophy or two about my approach to this field. I say two, but I really mean about half a dozen of semi-distraught career-crisis generating moments (that lasted weeks or months) questioning what it is I want out of this field, whether what I am doing is the “right thing” and whether I should be doing something else.

Given Elijah Meeks’ thoughtful article about why Data Visualization practitioners are leaving their jobs, I thought it might be worthwhile to share my path, because the philosophy I landed on (cleverly masked as “simple” in the title of this post) is the one I’ve felt the best about in years.

The Awakening

Always be learning (source)

First came the realization that Data Visualization was a field. Surprising as it may seem, but we are not born with this knowledge nor did anyone teach me about it without my asking. What followed was a few years of just trying-to-keep-up. Learning the math, learning the different types of visualizations out there, etc. I had no voice of my own, I really just tried to figure out what was what, how to build it and how to do a good job. I did a lot of bad jobs. Lots of prototypes were thrown away and I was really hurt about it because I didn’t have a sense yet of how to evaluate “good” in this field. It was also a while ago, so the base of examples out there was a lot smaller. I picked Amanda Cox as my career hero and charted on.

The Wanna-Be Data Artist

The struggle is real (source)

Choosing a set of incredibly talented people as my role models was both inspiring and demoralizing at the same time. I had just gotten my bearings around HOW to do this stuff and these folks were leaps and bounds better than me at coming up with creative ways to express data. I was just getting to the point of being able to choose the right methods and building them. I dabbled in some side projects trying to make some creative data interpretations, making things out of data that didn’t really demonstrate anything and just generally pushing myself to try and bring a little bit of art-something-something to my practice. I wouldn’t call these efforts successful though, because I never quite seemed to land on anything that resonated with me. Somehow, none of those things generated any kinds of feelings from the people I showed things to. They might have enjoyed them, but that was about it. I was unsatisfied because I still didn’t know WHY I was doing it.

INTERMISSION

BRB DataVis (source)

Tired of my lack of progress and still lacking of voice, I decided to take a break from Data Visualization and just get better at working on web applications. They were all the rage at the time (remember when Backbone.js came out!?) and I was excited to make things that lived and were performant on the web.

Hellloooooooo Data Journalism

I LUV DATA JOURNALISM (source)

I was lucky to stumble into a contract with the Guardian Newspaper in London as one of my first projects at Bocoup. Suddenly I was working with an excellent set of data visualizers on some really meaningful stories. We were collaborating with the Global Development Desk which both had interesting stories to tell AND a great mission of bringing to light important stories that might not get enough coverage otherwise. Before I knew it, I had to think about how to weave my visualizations together; what the glue was. There was a higher purpose to putting them together in a way that was meaningful and spoke to a wide range of people (news consumers.) It was a humbling experience, and it taught me a ton. It taught me to iterate on designs fast, to throw things away, to make reusable components, to be able to code fast, and that story was king. I’m proud of the work we made, but I had a lingering feeling that maybe there was something we didn’t get to. There were a few quips/anecdotes in the data that were REALLY strong, but the exploratory interactives we made took a while to get to them, or required user interaction (hey, remember steppers?!) that we weren’t sure users were making. I was concerned that the approach we took wasn’t the best, but I had no idea what the best would be (because I am not a journalist).

The Age of Tool Making

Tools are important (source)

As I was trying to figure out how I did or didn’t fit into this world of journalism, I saw very quickly that lots of things were missing: tight deadlines required some reusability or compromises I didn’t like making and growing types and sizes of data allowed for more complex analysis, the skills for which were not necessarily in most newsrooms. Being at Bocoup and generally a problem solver, it was a lot easier to dive into this world of trying to build tools and resources for my colleagues in journalism than to try and become a journalist. I still admire them from afar while trying to steal their tricks.

By this point, I was definitely a news junkie. I was enjoying the golden-age of interactive graphics spawned by the New York Times and the like, and I was piping them to my parents who are also politically engaged. A funny thing happened though — they didn’t stick. My parents didn’t get them. Now, you can chuck this to my parents being old, but my mom is a music teacher who spent her life reading music notation I can’t even parse, and my dad is a mechanic who knows how to fix incredible machines from schematic diagrams from the 80s. And still, they just didn’t like these interactives and they just kept asking me “what does it mean?”. At some point, I started taking screenshots and just sending long explanations, then skipping the screenshots all together and just focusing on the conversations. At that point I realized, I don’t want to make things that most people can’t get. As much as I love them, my fellow practitioners, are not my primary audience.

Data and Design Unseat Eye Candy

Data IS beautiful (source)

The previous experience led me pretty quickly to realizing two things:

  1. If people want a story, give them a story. Don’t waste their time trying to get to it.
  2. If people have a problem they want to solve, make the easiest thing you can to help them solve that problem.

These two principles meant a few things.

  1. First, I had to get better at data analysis. Showing single value counts and medians and means wasn’t actually solving anyone’s problems most of the time. That one statistics class I took in college (delivered entirely over powerpoint and about coin flips) wasn’t cutting it. I dug into the world now called Data Science to learn all about the ways I can find answers in data. I’m still learning a lot, and I’m lucky to have Jim Vallandingham around to help me learn.
  2. For me to learn how to make things users can use and understand, I had to start thinking about perception, psychology and the user experience people have when interacting with whatever I make. A lot of what I learned didn’t support the desire to make complicated intricate visualizations. We all know making a hairball network diagram generally isn’t helpful — well, so far science agrees.

I started learning a lot more about human perception from excellent books such as Colin Ware’s Information Visualization: Perception for Design. At the time, I also met Lane Harrison, whose work on perception in data visualization has been practice-changing (how many times this week can I cite this paper?!). I also started working with the very excellent designers at Bocoup, like Jess Klein, who started reminding me that usability and usefulness is king. What was the point of making interfaces most people couldn’t understand or know how to use? So what if it was novel? If it didn’t make sense to most people, then I really didn’t solve anyone’s problem.

Problem Solving (aka Current Philosophy)

Bridge crossing at its best (source)

These days, I’ve relaxed the demands I put on myself around the visual wow-ness of my work. Sure, it’s really wonderful to have recognition from my peers in the industry, but it’s actually even more wonderful to build a really simple tool for small clinic practitioners to track their patient experience data in a digital way for the first time; to show and explain to them a box plot and suddenly see them make use of it. A box plot is never going to win awards, but a well crafted tool that is simple to use is going to make someone’s life better, or at least a little easier.

Sometimes these tools use simple charts, sometimes we come up with something more intricate and complex. Sometimes we have too much data and we need to reduce it to something consumable, or represent it in some way that can be filtered through interaction. Whatever the case is, I have a giant bag of tools I’ve acquired that I use to make things that are simple for people.

And no, I have yet to make something my parents understand. #lifegoals.