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’re encouraging 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 at nightingale@datavisualizationsociety.org.
Today’s submission comes from Shirley Wu, an award-winning software engineer specializing in data art and visualization and co-author of the book Data Sketches.
Do I have horror stories to share? Oh, definitely, quite a few! Although, I’m not sure the label “horror story” always fits—in many of these instances, I was working with clients that I liked (and some that I still work with today!) and we created something valuable, even if the process was rougher than I expected.
There are really only two projects that I beat myself up about for feeling unprofessional. The first is this:
Back in 2018, I took on a project for a newsroom where I wanted to use a library (Vue.js) that the client wasn’t sure their build process could support. The client was under an extremely tight timeline that I wasn’t confident I could meet—unless I worked in Vue.js. The client’s developer warned me that the project might not be able to deploy if I used Vue, but I felt so much pressure to meet the deadline that I couldn’t see an alternative. I worked around the clock to build that piece in 11 days. I was so proud of it! And then, come time to deploy, of course it didn’t work.
I’d started on that piece in October, delivered it in November, and in January we were still trying to figure out how to make it deploy. Eventually, the editor ghosted me. I had been paid for the piece itself, but I never got paid for all the hours spent troubleshooting—and saddest of all, the project I worked so hard on and was so proud of never got to see the light of day.
One of my biggest take-aways from that experience is to be considerate of the tech that my clients use. I shouldn’t have insisted on a library that their developer wasn’t sure they could support. That situation ended up teaching me a bit about client management, too: Don’t always cave to client pressure. It’s okay to push back against deadlines that are not technically feasible.
The second instance in which I felt unprofessional was a project with one of my long-term, repeat clients that dragged on for a year and a half, and I was never able to deliver. The client had a vague idea of what he wanted – an internal predictive modeling tool for helping make business decisions – but he didn’t have a super clear vision of what it should do. I presented 2-3 rounds of designs, but they were never quite what he wanted. I think the project ultimately stalled because neither of us were confident in the direction of the design. Eventually, because he’s a good client, we just moved on to a new project, and yet, for the longest time, I felt like I had lost his trust because I never delivered on that one.
In trying to figure out what went wrong, I’ve come to believe that the project was too far out of my comfort zone—it veered too far into data science and predictive modeling—and I wasn’t confident that I could do what he wanted. At the same time, the client didn’t have a clear vision to guide me. Since then, I’ve realized that I need two things from clients: I need the dataset upfront, and I need them to clearly articulate the goal of the project. They don’t need to have a vision for the design, but they do need to be able to articulate the business use case in 1-2 sentences—what do they want the project to accomplish? What questions do they want answered? What ideas do they want to communicate?
Another “learning opportunity” (I’m not going to call it a horror story because it’s a project I’m really proud of!) was for an art museum in Hong Kong. With this project, I was caught off-guard by cultural differences. Because I’m Chinese-American and the client spoke English, I didn’t expect there to be major cultural differences, but there were!
As it happened, after the visualization was complete, I had to write an artist statement. There was so much back-and-forth with the client over the statement – maybe 10 rounds of feedback over four months – that at one point, I began to wonder if I was writing the artist statement or if they were. In retrospect, their feedback definitely improved the statement, but it took a conversation with a friend to realize that the reason for all the back-and-forth was that words are taken very seriously in Hong Kong, much more seriously than they are in the U.S. The client simply didn’t want to have anyone misunderstand. This was a huge difference from when I wrote an artist statement for SFMOMA (the San Francisco Museum of Modern Art), and they accepted it without revision because it was intended to be written by me. Now, I can appreciate that my client in Hong Kong was just trying to protect themselves and to protect me. They were a great client overall and supportive of my work, and I recognize now that they were being thoughtful and sensitive to others. My take-away: Anticipate – and be open to – cultural differences.
And also: Trust the client’s domain expertise. I’m a software engineer, and I don’t know anything about the art world. The final artist statement is much stronger because of the client’s involvement. I should have trusted that they knew what they were doing. When I work with a client, one of the most important things to me is that they respect my domain expertise with data; I also need to respect their domain expertise. This doesn’t just mean their knowledge of a particular dataset or field—it also means their understanding of the process and the audience.
Recounting these stories comes with a lot of emotional baggage! These are all situations I still think about and ruminate on to this day; sharing them is kind of like therapy. And there are so, so many more beyond these three.
