Bei meinen Praktika in Datenredaktionen lerne ich nicht nur neue Kniffe und kann mich und meine Kenntnisse einbringen, ich erfahre auch jede Menge über die Arbeitsabläufe bei den verschiedenen Teams. Und die sind – genau wie die Zusammensetzung der Teams – teils sehr unterschiedlich. SRF Data arbeitet anders als das Interaktivteam der Berliner Morgenpost, das wiederum anders arbeitet als das Datenteam von Zeit online, bei dem ich derzeit hospitiere. Das fängt schon bei der Themenwahl, der Regelmäßigkeit von Konferenzen oder der Arbeitsteilung an. Mit einem detaillierten und allgemeingültigen Konzept, nachdem alle Datenredaktionen arbeiten, kann ich also noch nicht gerade dienen.

Eine Annäherung kann aber folgende Grafik bieten, mit der ich versucht habe, den Workflow des Interaktivteams der Berliner Morgenpost aufzuzeichnen.

workflowGrundsätzlich kann eine Datengeschichte auf zwei Arten anfangen: Man hat eine gute Idee oder eine These und besorgt sich Daten, um die Idee umzusetzen oder die These zu überprüfen. Oder man findet Daten oder bekommt welche zugespielt, und entwickelt daraufhin eine Idee oder eine These.

Wie rum auch immer, wichtig ist die Kommunikation im Team. Ich kenne das nur zu gut: Man entdeckt einen coolen Datensatz, hat eine super Idee und legt direkt los. Vielleicht ohne zu bemerken, dass die Daten für die Umsetzung der Idee nicht die Richtigen sind. Oder, dass das Ergebnis außer einen selbst niemanden interessieren wird. Im Dialog mit dem Team können solche Gedankenfehler schneller auffallen, die Projektidee verändert oder verworfen werden. Ein weiterer Vorteil: Gibt das Team grünes Licht, hat man dank der Diskussion bereits eine recht konkrete Vorstellung davon, was man machen will.

Das erleichtert den nächsten Schritt: Die Analyse. Statt die Zahlenberge vor sich hinzuschieben kann zielgerichtet genau das analysiert werden, was genauer betrachtet werden soll. Danach oder teilweise schon zeitgleich widmet sich der Designer der optischen Umsetzung des Projekts: Wie sollen die Ergebnisse präsentiert werden? Was für eine Visualisierungsform soll gewählt werden? Bei der Berliner Morgenpost geht dieser Schritt sogar so sehr ins Detail, dass der finale Designvorschlag wie ein Screenshot des danach realisierten Projekts aussieht. Jede Farbe, jedes Symbol, jede Interaktion wird vorher festgelegt und immer wieder mit dem Team durchgegangen, bis alles passt. Danach haucht ein Programmierer der Designvorlage Leben ein.

Spätestens nach der Analyse beginnt außerdem parallel zu Design und Programmierung ein ganz wichtiger Teil der datenjournalistischen Arbeit: Das klassische journalistische Handwerk. Können weitere Quellen die Ergebnisse aus der Datenanalyse bestätigen? Was sagen Experten und Akteure? Soll noch ein Video in den Artikel eingebunden werden und was soll alles im Text stehen?

Bei allen Arbeitsschritten kann es zum Verwerfen des Projekts oder einer Änderung des vorangegangenen Arbeitsschrittes kommen – in der Grafik gekennzeichnet durch die orangenen Pfeile. Stellt man bei der Datenanalyse Mängel in den Daten fest? Muss die Idee doch verworfen oder verändert werden, weil es neue Erkenntnisse aus dem Fact-Checking gibt? Lässt sich ein Design doch nicht so nutzerfreundlich umsetzen, wie gedacht oder passt die geplante Visualisierung einfach nicht zu den Analyseergebnissen?

Wenn alles passt, hat man am Ende seine Datengeschichte – in der Grafik gekennzeichnet durch das fabulöse Einhorn.