Sie sind komplex, verästelt, mühsam und aufgeladen, anregend und intelligent – die Debatten, die unsere Leserinnen und Leser im Kommentarbereich von ZEIT ONLINE führen, bereichern die Diskussionskultur unserer Seite enorm – und fordern täglich bis zu acht Moderatorinnen und Moderatoren heraus. Von ihnen wird erwartet, in Sekundenschnelle zu entscheiden, ab wann Ironie verletzend wird, wann eine emotionale Äußerung zur unsachlichen Beleidigung wird und wie scharf der Ton in Threads werden kann, ohne dass die Diskussion kippt – und das in allen Themengebieten. Unabdingbar für diese Arbeit ist ein Moderationstool, das die Arbeit handhabbar macht. Zumal die Zahl der Kommentare stetig wächst.
Anfang des Jahres haben wir uns entschieden, die Administrationsoberfläche für die Moderation zu erneuern, damit sie schneller, genauer und gleichzeitig entspannter arbeiten können. Begonnen haben wir mit der Frage: Was wollen die Moderatoren? Mit einem Ideen-Workshop, der sich der Design-Thinking-Methoden bedient, näherten wir uns dem Thema.
Impact-Effort-Matrix
Zunächst haben wir die Abläufe der Moderation an einer Wand mit Post-its wie in einem Flowchart visualisiert. Was sind die einzelnen Arbeitsschritte der Moderation, welche Aktionen führen dazu, einen Kommentar zu sichten, ihn in seinem Kontext zu verstehen, ihn zu bearbeiten oder gar zu löschen? Mehrere Pain-Points konnten so identifiziert werden – Stellen, an denen die Arbeitsabläufe nicht reibungslos funktionieren oder unnötig kompliziert sind. In kleinen Gruppen suchten wir Ideen und Lösungen für diese schmerzenden Punkte. Die Lösungsideen ordneten wir in eine Impact-Effort-Matrix ein. Die Impact-Effort-Matrix ist eine 2×2-Matrix. Auf einer Achse gibt man den Grad der Auswirkungen an, auf der zweiten den Aufwand. Dadurch ergeben sich vier Quadranten: 1. Wenig Auswirkung, wenig Aufwand. 2. Wenig Auswirkung, viel Aufwand. 3. Große Auswirkung, wenig Aufwand. 4. Große Auswirkung, viel Aufwand. Am Ende erhält man eine erste Idee, welche Ideen und Funktionen man umsetzen sollte und welche eher nicht. Leider lagen fast alle Ideen und Funktionen im 4. Quadranten, im Bereich große Auswirkung, viel Aufwand. An dieser Stelle war klar: Wir können unser bestehendes System nicht durch ein paar einfache Maßnahmen so verbessern, dass wir unseren Moderatoren ein deutlich besseres Nutzungserlebnis bieten können. Wir brauchen ein neues System.
Jobs-to-be-done
Ein zweites Konzept, welches wir regelmäßig in der Entwicklungsredaktion anwenden, ist das Jobs-to-be-done-Framework. Die Idee dahinter: Ein Nutzer hat eine Aufgabe zu erledigen und als Produktentwickler müssen wir ihm diese Aufgabe möglichst einfach machen. Deshalb haben wir die einzelnen Jobs der Moderatoren definiert. Zum Beispiel: einen Kommentar sichten, einen Kommentar löschen, einen Kommentar bearbeiten, einen Nutzer sperren. Diese Jobs haben wir gewichtet und in eine Reihenfolge gebracht.
Mit der priorisierten Liste der Funktionen und der Moderatoren-Jobs haben wir in einem zweiten Workshop auf Papier die Informationsarchitektur gestaltet. Anforderung hier: die wichtigsten Informationen für den wichtigsten Job zuerst. Die Hypothese: Dadurch kann der Moderator die Informationen schneller erfassen. Die zweite Hypothese: Unnötig lange Klickwege und neues Laden einzelner Seiten rauben einen Großteil der Moderationszeit. Also sollten alle nötigen Informationen in einer Timeline verfügbar sein. Dabei sollte der Job, der die meiste Zeit verbraucht, am schnellsten zu erledigen sein. Nachdem wir verschiedene Ansätze gezeichnet hatten, haben wir erneut mit unseren Moderatoren gesprochen, um unsere Ideen mit der Arbeitsalltagsexpertise abzugleichen und uns für die Variante des Tools zu entscheiden, die Erfolg versprechend ist.
Nun begann die Designarbeit. Ausgangspunkt hier: Bootstrap. Gerade für Administrationsoberflächen enthält Bootstrap vielfach bewährte UX- und UI-Patterns. Trotzdem blieb die größte Herausforderung, wie wir so viele Informationen so geschickt unterbringen, dass die Nutzer alle wichtigen Informationen möglichst schnell erfassen können. Nach zwei Design-Iterationen, an deren Ende wir stets mit den Moderatoren über die neue Oberfläche gesprochen hatten, haben wir uns für einen High-Fidelity-Prototypen entschieden. Warum? Nur so konnten wir die beiden wichtigsten Hypothesen überprüfen: Neustrukturierung der Informationsarchitektur und Moderation in einer Timeline haben einen starken Effekt auf die Moderationsgeschwindigkeit.
Prototyp
Den High-Fidelity-Prototypen haben wir in der Entwicklungsredaktion in React mit Mock-Daten umgesetzt. Dafür mussten wir uns intensiv mit dem Konzept auseinandersetzen und es bis in das kleinste Detail verstehen lernen. Statische Screens überlassen Dinge der Vorstellung: Wie fühlt es sich an, von dieser Ansicht in die nächste zu wechseln? Auf welche Art und Weise verschwindet ein Kommentar beim Klick auf den Button? Wir mussten Antworten auf diese Fragen finden und konnten sie nicht auf später verschieben. Lösungsansätze konnten sofort von uns entwickelt und mit den Moderatoren in UX-Tests überprüft werden.
Außerdem konnten wir durch den Bau des Prototypen ein besseres Verständnis für die Herausforderungen der Programmierer entwickeln. So haben wir beispielsweise eine vorläufige Datenstruktur entwickelt, um unsere komponentenbasierte React-Applikation mit Dummy-Daten zu versorgen.
Nachdem wir alle Hypothesen überprüft hatten, haben wir ein kleines Team aus zwei Frontend- und zwei Backend-Entwicklern zusammengestellt. Um eine zuverlässige Kommunikation mit React zu ermöglichen, haben wir uns für das Schreiben einer Middleware entschieden, die zwischen unserem Community-Backend und React sitzt und die asynchrone Übermittlung von Daten sowie einen Parallelbetrieb des alten und des neuen Systems ermöglicht. Während das Team im zweiwöchigen Sprint-Rhythmus funktionierende Alpha-Software deployen konnte, haben wir weiter regelmäßig UX-Tests durchgeführt und konnten so sicherstellen, dass wir weiter auf dem richtigen Weg sind. Außerdem hatten wir so eine regelmäßige Abdeckung mit End-to-End-Tests.
Nach Erreichen des Minimal Viable Products sind wir in einen Parallelbetrieb eingestiegen. Täglich hat eine Moderatorin oder ein Moderator mehrere Stunden mit dem Tool gearbeitet. Stück für Stück haben wir so das gesamte Moderationsteam auf die neue Software geschult.
Von Milan Bargiel, Michael Schultheiß und Julia Meyer
Lesen Sie bei Digitale Leute mehr zum Thema Ideation bei ZEIT ONLINE und was eine Entwicklungsredaktion eigentlich ausmacht.