Here’s what I learned from writing, coding and designing my own longform data-driven feature story

“By any means necessary.” It’s a phrase that has taken new contexts throughout history, from first appearing in a play by Jean-Paul Sartre to showing up in speeches given by Malcolm X on the civil rights movement.

When this phrase came to me, it was in an altogether different context. Last September I walked onto the campus of Goldsmiths, University of London for my first day of a masters programme in Digital Journalism. Over the next year my classmates and I would be learning how to create immersive stories for the web using data visualisations, multimedia videos and web applications. Our computing professor told us that we would never go far wrong if we stuck with one principle:

By any means necessary.

The extended version? Start with where you want to end up, and then hack, test, experiment and code your way to get there (even if it gets messy). And that’s what we learned to do.

Three months ago I started the process of compiling everything I learned in my programme into a single story: a longform data-driven feature article, coded from scratch (no templates).

The end result came from hours of research, interviews, cleaning datasets, searching for d3.js examples, tearing out hair when code didn’t work, drinking liters of coffee and working many late nights.

My piece, The Network of a Lifetime, is a story about net neutrality changes in the U.S. and how these regulations affect the internet as consumers use it. I set out to create a story that included data analysis and visualisation throughout the piece, with scrolling being the main user interaction.

I wasn’t sure how to feel after I finished it: something I had worked so hard on, for so long, suddenly becoming “finished” and reaching an end.

Now, a few weeks later, the gravity of completing this large of a project has worn off. And I’d like to share some of the most important things I learned along the way. For this kind of project, newsrooms usually dedicate multiple people to the job: a journalist, a data journalist, a web developer, maybe a copy editor. This post is about what I learned through having to be all of those people at once.

Plan your planning ahead with a Master Plan

I knew that this project would require me to be doing lots of different things at once. Big projects have many stages and tasks — planning and organisation would be essential. So weeks before I even started writing or coding, I made myself a master plan. Here’s the sketch that served as my progress monitor for the project.

The left side lists tasks categorised into 4 types. The right side acts as a timeline of what tasks will be completed each week. The length of the bars represents the estimated amount of time a task will take. This allowed me to see the distribution of tasks across time.

I divided each task into a category and split them across the weeks I had left before the deadline. Then, at the beginning of each week I would see what I wanted to complete that week and what day I could work on it.

Obviously this didn’t always work out perfectly…some tasks ended up taking much longer than expected, while others were checked off by finding a quick solution online. But estimating the time each task would take was key to managing the project as a whole. If a certain task was taking much longer than the estimated time I set aside for it, a tough decision needed to be made: either stick it out or find an easier way of doing it.

Test early, test often

At the start of the project, this is roughly how I thought the process of creating the piece would look:


Alongside my Master Plan, this was how things were supposed to go. But in reality, there ended up being way more overlap than I expected. The news stops for no one. In my final week, I was still researching the latest articles to come out about net neutrality, which led to adding or removing certain paragraphs from the story. I was writing while coding, while creating data visualisations, while transcribing interviews, etc. It was messy, and nowhere close to as linear as the diagram above.

But more importantly, taking this approach put me in a tough spot in the last two weeks when testing my code. Since I left most of the coding towards the end, I found myself scrambling in the last few days to test my webpage on different devices and browsers.

This led to a huge headache getting the all the different graphics and data visualisations to look sharp on mobile devices. Looking back, I should have started testing my site as I built it, using different devices and starting from a mobile-layout first approach rather than adapting desktop to fit on mobile.

Always start with a mood board

Very early on in the project, I started to pull together a mood board of influences that would shape the look and feel of the page. This is a practice I learned from people working in creative design agencies. I pasted links and screenshots of my favourite interactive stories from publishers like NYT, FiveThirtyEight and Quartz to save some inspiration.

From this mood board, I formalised the influences to create rules that would be applied across the webpage. My mood board contained things like font options, a set color palette, stroke-weights, data visualisation examples to draw from and photography styles.

These presets also allowed me to start assigning meaning to my design choices. For example, since I had a set color palette, I could then define certain colors as accents in charts across the webpage or use a certain font only as annotations.

It’s important to note that this process happened before I started writing any code for the site. Once I did start coding, the CSS styling was easy to start applying since I had decided on it in the mood board already. It also ensured that my text, images and graphics were consistent across the whole story.

Sample screenshot of my mood board.

Be intentional with interactivity

The issue of interactivity is one that I went back-and-forth on for a long time. It’s an ongoing debate in news media, and particularly when it comes to data visualisaiton. But after reading up on what some of the smartest people in the field are saying, I decided to implement a minimalist approach to interactivity based on a mantra adopted by the FT’s Head of Interactive News Martin Stabe (though originally tweeted by Brian Boyer).

If a chart didn’t benefit from being interactive, I used Tableau to construct it and Adobe Illustrator to add annotations that tell the story. It may not be flashy, but it loads quickly, shows the data effectively and just plain gets the job done. The question for me became: how much does the user really benefit from being able to hover/click/zoom? If the answer is not much, I cut the interactive element.

That being said, not all of my charts were static. For example, I created a large scatter plot showing internet price and speed for 34 different countries. Interactivity seemed to make more sense here so that users could hover for the values of a country they were curious about. So I used d3.js for this one. But since the focus was on the values of the U.S. bubble, I added an annotation to show these.

Screen Shot 2017-07-28 at 11.21.31 AM.png
Screenshot of d3.js scatter plot. Full story here.

Archie Tse, graphics editor at the NYT, has a great quote on taking this approach of annotating the essential points in your data.

If you make a tooltip or rollover, assume no one will ever see it. – Archie Tse

If no one saw the exact values of the other bubbles, the chart would still get across my message.

The other form of interactivity I tried to implement was scrolling. Now, this wasn’t near the scale of the kinds of scrollable stories produced by folks like The Pudding or the NYT graphics team. But because users naturally will scroll down the page, I tried to use this as a way to transition between graphics and page elements.


Give opportunities for context and meaning

Because I was covering quite a technical topic, I knew that certain terms and topics would need explanations. But at the same time, I didn’t want to spend half my article explaining what terms like zero-rated services and content distribution networks meant.

I had to assume that some people would be familiar with the topic of net neutrality, while others were fresh to the debate. So I decided to draw on a recent tactic used by publishers to provide extra context throughout a story. A good example is the Washington Post’s ‘Knowledge Map’ feature, which highlights certain text that, when clicked, opens a box with relevant background information.

In my own piece, I took a similar approach by using a light highlight color for people, terms or issues that users may want a bit more information about. To distinguish this from regular links, I also added a small newspaper icon in the highlight as a way to signpost that this would display additional information within the webpage. And since I was using the Uikit framework for my site, I displayed these context boxes on the page through sliding off-canvas div.


Be ruthless with your preconceptions

Before I started this project, I had big plans for what the final story would look like. I bookmarked and saved amazing stories on the web that would be my benchmark. This would be the greatest, the best, the most amazing visual data story ever.

But here’s the reality: I’m not a developer by trade. I only started doing some light coding about a year-and-a-half ago. I’m not a designer either. I’m a data journalist with a couple key skills in my tool belt to create a visually impactful story. So I went full circle and came back to my course mantra:

By any means necessary.

As I started to build my story, I adjusted my aspirations to fit my timeline and abilities. This doesn’t mean I gave up when things got hard; I spent plenty of hours debugging and scouring Stack Overflow for solutions to my coding troubles. And sometimes I made major breakthroughs.

But other times, I had to be ruthless with myself and find a less “impressive” way to build something. I learned to challenge myself to learn new skills and languages, while also knowing when to throw in the towel and find a different way of accomplishing my goal. In the end, the story always has to take center stage over flashy technical elements.

This last point may be the most important takeaway I learned, but this post is by no means exhaustive. Throughout the process of creating this feature, I learned so much about time management, debugging code and writing a longform feature for the web.

But I know I’m not alone in this. Visual journalism and storytelling with data is on the rise in the media, and these skills are quickly moving from optional to recommended. I hope these lessons I learned while hacking my way to a digital feature story can help someone needing to do the same.

The Network of a Lifetime was created using the following tools/resources:

  • Uikit
  • ScrollMagic
  • jQuery
  • D3.js
  • C3.js
  • Tableau
  • Adobe Illustrator

Curious about more? Get in touch.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s