Journalist: Data journalism is not about asking questions to data. This is essential. If you don‘t have questions, the data will not answer. You will end up with a more colourful version of what the statistics office has published last year. So, the role of the journalist is to come up with project ideas. At the same time, she/he should be a good director of the process and understand - from experience or from talking to others who know - what it takes to get a data journalism project done. 

 

Developer: Developers in data-driven journalism do not write complete applications nor do they maintain them, at least for the majority of projects. Instead, the goal is to tame the data: Collect information, clean, combine and transform it into usable chunks. Most of that is one off, meaning that the next dataset you work on is very different from the one before. So, the level of automation and re-use is lower, at least in the current stage of data-driven journalism. 

 

There is one quality needed from developers working in data-journalism that is hard to find: The urge to tell a story. Often, at least from my experience, developers do not think like that. They care for code, for features, for maintainability and wish to avoid surprises. A coding surprise can take many forms: The application does not run. Or, even worse, the journalist all of sudden has very different demands, lot‘s of ideas for features, etc. Such approaches are signs of a journalist who does not think like a coder. And usually such behaviour turns coders off. It‘s like you started to build a small, but complete house - and all of sudden the project merges to become bigger, there are rooms to the building project, new doors, a garage - and, oh, the garden around it needs to taken care of. Software development is to a large part working into a black box. It takes time until you can see anything and considerable parts are often only joined in later stages. So, good management of features and the scope of the project are essential. 

 

Designers/Visualizers: The third person, that should be part of a data team is someone who can do magic to the look and feel. Colors, charts, layouts should be compelling, clear and usable. This is easier said than done. Outstanding design is important in data journalism to get from data to story. The best examples out there rely on design for presenting the idea for the most part. 

 

 

In a good journalist/developer/designer team, the scope of a given project is the key to get it done. You can not do everything at once. Focus, keep the focus, finish the first step and only then move to the next. Plus, aim to communicate the specific scope of a project at any time - if you start small and then the project grows and grows, you might be heading for disaster. 

 

One way to do this is by going step by step. First, you do a simple map with crimes commited in a region. No more than 100 data points. No fancy features. Publish that. 

 

Next, you use a better map. More features. Filters. Timeline. 200 datapoints. Publish. 

 

The point is that quite a few projects in data journalism can be re-used later. What you did on one topic might be very helpful for another. So, going step by step is the best way to explore that. Just avoid hoping to do big, big jumps. Go slow, move steady - this will get you results much more reliably than sudden sprints. 

 

 

At last, it is important to have a good understanding of border lines, where one project moves from simple to very complex. 

 

Below is a rough, overly simplifying table aiming to provide an overview of typical data-driven projects. If you talk about a project, try to decide whether it is a data story, a data interactive or a data app. 

 

The table above is helpful to define the scope of projects: Is this something we can do today? Will we need a week or more for that? How could we come up with an automated, initially more complex data app?

 

A data story would be an article, that is based on a data visualization - most of the text will reference the data points that are interesting. So, this is very close to typical journalism work, with an added layer of data. These stories though can ver very strong and telling, if you found the right data and a good way to visualize the context in a simple chart. 

 

Data interactives (there is no agreed name on this) would be bigger visualizations, overviews and analytics found often in the New York Times. There is a lot of work behind those and they are usually created by teams of two to four specialists, mixing know-how from journalism, design and coding in different degrees. 

 

Finally, a class that is potentially the most promising area into the future, would be Data Apps. Here real-time data intake, automation, personalization, and lot‘s of other qualities can be added. They take more time, but provide a potential for future income from journalism, too. 

 

What the table says as well is this: Yes, a typical data project takes more time than your typical article or report or video. But the usability of such projects - if they are good - is much higher and longer, too. This, by the way is a very important driver for future adoption of data-driven journalism in newsrooms.