This guest post comes from Abby Henderson. Abby Henderson, MS, is a Project Manager at Veris Insights. Abby got her Master’s in Program Evaluation and Data Analytics from ASU in 2019, while working at the Center for Applied Behavioral Health Policy within the Watts College of Public Service and Community Solutions. In 2021, Abby joined the team at Veris Insights, where the focus is on bettering the world of work through providing first-class service and research on university recruiting and talent acquisition. In her free time, Abby loves to fall down internet rabbit holes about random topics, build slide decks no one ever sees, and take long walks around Phoenix with her dog. You can connect with her on LinkedIn or by sending an email to email@example.com.
We’ve all been on the receiving end of a long, boring, text-heavy report. It can be challenging to sit down and read, rarely translates insights into action, and is (for lack of a better word) boring. Well… I used to be an author of reports like that.
The Everything Report
At the start of my career, I thought the most important thing a report could convey was… well… everything. My thinking went something like this: “All of the background information, data, methods, and recommendations needed to be extensively covered. The more technical and academic the language, the better. If I can impress people with my language and expertise, they’ll be more likely to follow the recommendations I suggest.” However, that line of thinking functions under the assumption that people will read to the end of the report to get to those recommendations.
What I came to realize early on was that people, in fact, did not want to read through a long and technical report to get to the recommendations buried at the end. On top of that, spending so much time writing extensive reports was taking time away from strategic and creative thinking about what the data means. I had so little time left for that type of thinking that my recommendations were often vague, unhelpful, or lacking in creative thinking.
Introduction to Data Visualization
Cut to a session I attended hosted by the Arizona Evaluation Network and led by Deven Wisner and Nicole Huggett on data visualization. My brain lit up with curiosity and joy at the idea that data could be conveyed simply, succinctly, and visually. That session got me started on a new journey and led to me asking new questions.
Instead of asking, “How much information can I fit in this report? How technical can I make my language?” I was now asking questions like, “What is the purpose of this report? How do I hope these findings are used? How can I communicate that clearly, succinctly, and visually?”
The next thing I knew, I was enrolled in Report Redesign through Depict Data Studio and spending much of my free time thinking about data communication. More broadly, I was (and continue to be) interested in how we bridge the gap between technical expertise and lived experience, and how we communicate across that gap regardless of building a bridge.
Starting a New Conversation
I started to have conversations with my colleagues about how we could change our reporting. I started by suggesting we add more data visualizations and fewer tables.
When I met resistance to this idea, I started to produce two versions of our reports. One version included the tables we were accustomed to, and the second version included more elements of data visualization. Through providing both options, I was able to slowly garner traction and buy-in on including data visualizations.
The next proposal I made was to include infographics, one-pagers, or shorter summaries with our reports for individuals who may only be interested in the data from a high level. Again, I took on responsibility to demonstrate what I was envisioning and how I thought it could work. This meant taking on extra workload to create the products our leadership was accustomed to, as well as products I wanted us to explore. I brought up data visualization in meetings, attended webinars, and tried to increase the data literacy on my own team.
I was hopeful but hesitant during this timeframe. After all, change takes time, and change takes even more time when you’re suddenly grappling with a pandemic and an upending of our work lives as we previously knew them to be. In this new normal, I was suddenly surrounded by data visualization. The conversation shifted in the world around us, and therefore the conversation shifted in our office as well. There was no longer a question about the utility of data visualization in reports, as we were seeing firsthand how impactful a good visualization can be to convey a message.
The conversations about change continued, as I slowly began to notice how things were shifting in our offices. Suddenly, others on my team were hoping to collaborate on infographics. I was being asked to take on more projects, but each new project was a step in the right direction. We were no longer producing reports without visualizations, and we were starting to explore including one-pagers with our annual reports as a standard across projects.
Around this time, I ended up in a new position at a new company that uses data visualization as a bedrock of our work and didn’t get to see firsthand how the process in my previous office continued to change. However, I found out from colleagues that they now include an infographic or one-pager as a standard with all annual reports, are exploring ways to add more visual elements to quarterly reports, and are continuing to increase the internal skill around data visualization.
Here are three.
The most important lesson I learned in this process was one of patience. From the moment I made my first data viz, I wanted to change everything immediately. That was neither realistic nor feasible, and looking back I wish I had aimed for a slow burn to change our processes.
By deciding this was the hill I wanted to climb, I also had to be prepared to climb alone. Sometimes this included late nights in the office making two versions of the same report. Sometimes (often) this included frustration with my own lack of knowledge about data viz best practices. I had to trust that this process was worth the extra work. However, looking back, I wish I had had better boundaries around taking on extra workload to accomplish this change. Finding other champions on my team earlier on may have helped with that as well, as data visualizations are nearly always improved by collaborative brainstorming.
Here’s the thing: anytime you learn something new, you’ll make mistakes. I made plenty, both in my actual visualizations and in my attempts to create internal change in my organization. The goal is not to make zero mistakes, but to use your mistakes as a jumping off point for new learnings. Accepting that mistakes are part of any change process can provide grace from the start about the challenges you’ll encounter.
Leave a Reply