Writing in Code
I found Fathom through a data visualization course at college that was taught by a statistics professor, so my first exposure to information design was through the lens of statistical analysis. I spent most of my time in that class making sure the data was not misrepresented, and working through particularly challenging pieces of code. The more complicated the analysis or the code, the better I felt about the project, and I wanted that complexity to show in my end product. If the code worked and did something cool, then I was happy.

Contrary to what Twitter suggests, I learned more this summer than just how to use a hammer drill. A couple weeks ago, I showed James some slides from a presentation of my work this summer. One of his initial comments was, “This needs some design love.” I had sort of known that, but it hadn't felt like a priority to me. I was just trying to produce the necessary content clearly. For James, design is an integral part of any work. As a newbie to design thinking, this was one of the moments that started changing how I evaluate my work.

A comparison of my slide on the right to James's more elegant version on the left.

When I started work at Fathom in June, I was immediately struck by how different the work flow is from the environments I was used to. Instead of focusing on the technical or analytical side of information design, the big questions were always design ones: Who is the audience? What are they most interested in? How can this tool be more intuitive for them to explore? And most importantly, what is the story in the data? I had never thought about conveying data as storytelling before. Handling data was always fairly black and white to me; you look for an answer in the form of evidence to prove your hypothesis true or false. Information design at Fathom isn't like that. The process obviously still involves rigorous exploration and analysis of the data, but it's focused on allowing humans to navigate the data with ease.

Thinking of information design as storytelling was huge for me. I was originally drawn to computer science because it felt similar to creative writing; it's the same sort of creation, just writing in a different language. Code produces apps in the same way that sentences conjure images. I have often thought that I should apply the same rigorous logic used in coding to writing essays, and now I am realizing that the creativity and insight involved with writing should also transfer to my code. Just as nobody wants to read a book with non-stop action and no plot, nobody gets anything out of a bouncy technicolor bar chart.

Growing up, my English teachers told me not to use contractions in my writing, so I was surprised when my English professor last semester went through my first short story and contracted words wherever appropriate. I had been blinded by what I thought was a “rule,” when in reality the lack of contractions sounded unnatural for the characters and was distracting from the story. Similarly, I realized that my instincts to follow statistical “rules” would overwhelm many users with distracting or unnecessary information, instead of empowering them to explore.

In school, my computer science classes are focused on code. The work we submit is source code, and evaluations are based more on how that code is written than on what it produces. Entrenched in the source code, the focus is on theory and algorithms. At Fathom it's not enough to stop there. Code is a tool to create, but particularly cool or complex code should not be driving the process. The driving force is the vision of the end product, an insightful tool.