Have you ever made an embarrassing mistake in a data visualization? Did you utterly fail to meet your client’s or boss’s vision? Did you proudly share a visualization only to be overwhelmed by critical feedback? Of course you have! We all have, whether we’re beginners or superstars. In this series, we encourage dataviz practitioners to share their own Horror Stories as a way of normalizing “failure” as part of professional development. Brave enough to share your personal tale of woe? Email us!
Some years ago, a data visualisation agency invited me to work on a project for a big client. The brief was to create an interactive visualisation tool for exploring experimental data, to be showcased at an industry event. The client was very protective of their data, and would only let us access it from their own computers. I had a bad feeling about the project from the start, but the agency was persuasive so I said yes anyway, naively asked for the dataset as an Excel file and trekked along to the client’s office in a bland English commuter town.
Some background: I started out in data visualisation as a researcher after doing a PhD in music. I’d spent most of my working life until that point doing academic research in the humanities, so in those early years, I was on the steepest part of the data skills learning curve. My qualitative research skills were fine, but my quantitative, data-handling skills were – how shall I put it? – godawful.
When I sat down at the terminal and opened the data file, I knew straight away I hadn’t a clue what I was doing. It was bazillions of rows long – opening it almost crashed the computer – and I didn’t understand how to handle it or what any of the variables meant. I was seriously out of my depth. I was working with a very competent designer, who was relying on me to come up with some insights and analysis that could be used to guide the visual approach. If only.
It was a very, very long three days I spent in those offices, pretending to do things to the data file while people breezed past, making excited comments about what we were working on. Mercifully, the client had also written up the study results in a technical document, and I was at least able to translate some of its terminology into plain English for the designer.
What did I learn from this? To always trust my gut feeling when deciding whether to take a project on. And, from that moment on, I put serious effort into learning R.
There’s a happy ending to the story. Someone else replaced me as data ‘analyst’ on the project, the designer did a fabulous job and the client was thrilled with the result. I take no credit for any of this.
Miriam Quick is a data journalist, researcher and author who explores novel ways of communicating data. She has written data stories for the BBC, worked as a researcher for Information is Beautiful and the New York Times and co-created artworks that represent data through images, sculpture and sound. Her first book, I am a book. I am a portal to the universe., co-authored with Stefanie Posavec, was published in September 2020.
