Ich (UX Design), Head of Operations, zwei Entwickler
Situation
Laut den deutschen Informationsfreiheitsgesetzen hat jede Person einen Rechtsanspruch auf Zugang zu amtlichen Informationen. Die Online-Plattform FragDenStaat hilft Nutzenden dabei, diesen Anspruch wahrzunehmen. Über die Plattform können sie Anfragen an Behörden stellen und weiterverfolgen sowie die Antworten auf FragDenStaat öffentlich zugänglich machen. So entsteht ein immer weiter wachsendes Archiv behördlicher Informationen.
Ein Hindernis dabei: Wenn Behörden antworten, entsteht häufig ein Medienbruch. Sie schicken die Antwort nämlich nicht unbedingt per E-Mail, sondern oft per Briefpost. Damit auch diese Antworten ins FragDenStaat-Archiv gelangen, müssen die Anfragenden sie selbst scannen und an der richtigen Stelle hochladen. In der Praxis geschieht das jedoch häufig nicht. Dadurch gehen der Öffentlichkeit Informationen verloren, die eigentlich bereits herausgegeben wurden.
Task
Mehr Anfragende dazu bewegen, empfangene Briefe tatsächlich hochzuladen.
Action
Result: Drei Beispiele
Wir haben an mehreren Stellen angesetzt, um mehr Nutzende zum Hochladen der Behördenpost zu bewegen. In dieser Case Study konzentriere ich mich auf das Content Design und zeige drei Entscheidungen aus dem Formular, das Nutzende beim Upload ausfüllen müssen.
Fragen an den Kontext anpassen
Einige der Fragen im Formular hängen voneinander ab. Die Antwort auf eine Frage entscheidet manchmal darüber, wie die nächste Frage formuliert werden sollte oder welche Antwortoptionen überhaupt sinnvoll sind. Zum Beispiel:
Ich werde gebeten, das Ergebnis meiner Anfrage nach Erhalt der Post zu beschreiben. Hat eine Behörde mir die Post geschickt, kann sich das Ergebnis der Anfrage dadurch nicht zu „Anfrage zurückgezogen“ ändern. Denn die Behörde kann die Anfrage nicht zurückziehen, das kann ich nur selbst. Diese Antwortoption sollten wir also gar nicht anbieten.
In der alten Version des Flows sind jeweils mehrere Fragen oder Funktionen auf einer einzelnen Seite kombiniert. Dadurch werden Abhängigkeiten zwischen den Fragen nicht erfasst. Die Fragen sind dadurch für Nutzende teils schwierig zu beantworten und die Wahrscheinlichkeit von Eingabefehlern steigt.
In der neuen Version beantworten Nutzende pro Bildschirm nur eine Frage (one thing per page). So können wir die Formulierungen und Antwortoptionen an die bisherigen Antworten anpassen.
Ein Ausschnitt der dahinterliegenden Formular-Logik. Die Verzweigungen steuern, welche Folgefragen und Antwortoptionen angezeigt werden:
In den Usability-Tests kamen alle Nutzenden (Seitennotiz:
Das habe ich nicht gemessen. Ich lasse Teilnehmende lieber ausführlich ihre Gedanken beschreiben und hake nach. Das macht aussagekräftiges Messen von Time-on-Task unmöglich.
). Wenn sie zögerten, lag das fast immer an der Zusammenfassungs-Frage (unten in einem eigenen Abschnitt behandelt).
Mehrdeutige Begriffe vermeiden
Im alten Flow erhalten Nutzende nach dem Hochladen von Dokumenten die Option, diese Dokumente freizugeben. Der Begriff „freigeben“ wirft allerdings Fragen auf.
Was genau „freigeben“ bedeutet, ist kontextabhängig. Bei einer öffentlichen Anfrage bedeutet „freigeben“, dass die hochgeladenen Dokumente sofort mitveröffentlicht werden. Bei einer privaten Anfrage bedeutet „freigeben“ hingegen nur, dass die Dokumente der Anfrage hinzugefügt werden, ohne direkt öffentlich zu sein. Erst wenn die Anfrage später selbst auf öffentlich umgestellt wird, werden auch die Dokumente sichtbar.
Im Redesign habe ich auf das Wort „freigeben“ ganz verzichtet:
Im Usability-Test verstanden zwei von acht Teilnehmenden das Button-Label „Dokumente hinzufügen“ falsch. Sie dachten, dass man durch Tippen auf diesen Button weitere Dokumente scannen beziehungsweise hinzufügen könnte.
Im Nachhinein ist diese Interpretation nicht überraschend: Wenn Nutzende direkt erkennen können, was sie als nächstes tun sollen (hier: auf den Button tippen), ignorieren sie häufig den Rest des Screens. Hier bemerken sie also den Text weiter oben nicht („Diese Dokumente werden der Anfrage hinzugefügt“). Dadurch wird „Dokumente hinzufügen“ mehrdeutig. Bedeuten könnte es entweder „Weitere Dokumente hinzufügen“ oder „Diese Dokumente hinzufügen“.
Mit den Anpassungen aus der nächsten Iteration verschwand das Missverständnis in der zweiten Testrunde:
Eine unergiebige Frage streichen
Der alte Flow fordert Nutzende auf, den Inhalt der hochgeladenen Behördenpost zusammenzufassen. Die eingegebene Zusammenfassung erscheint dann auf der Anfrageseite. Spätere Besucher:innen können so direkt ablesen, welche Infos die Behörde geschickt hat, statt das mühsam aus dem Schriftverkehr rekonstruieren zu müssen.
Das Problem: Die erhofften Zusammenfassungen kommen über das Feld nicht zustande. Die meisten Nutzenden lassen es leer. Wer doch etwas einträgt, antwortet entweder zu vage („Anfrage wurde beantwortet“) oder zu viel (der gesamte per OCR ausgelesene Brieftext wird ins Feld kopiert).
Vor der ersten Iteration habe ich mir die Schwachstellen der bisherigen Fragestellung angeschaut:
Um klarer zu machen, welche Infos die Frage eigentlich verlangt, passe ich sie nun an den jeweiligen Punkt in der User Journey an. Je nach Situation wird zum Beispiel gefragt:
„Fassen Sie die erhaltenen Informationen in wenigen Worten zusammen oder kopieren Sie relevante Stellen aus dem PDF.“
„Fassen Sie zusammen, was die Behörde Ihnen mitgeteilt hat. Zum Beispiel: Mein Widerspruch wurde abgewiesen.“
„Was haben Sie der Behörde in diesem Brief mitgeteilt? Zum Beispiel: Widerspruch eingelegt.“
Im Test:
5 von 8 fassen nicht die erhaltenen Informationen zusammen. Stattdessen beschreiben sie den Anfragenverlauf („Ich habe einen Hygienekontrollbericht von XXX angefragt und erhalten“) oder die Behördenantwort („Mir wurden die Kontrollberichte übersendet“).
Auf Nachfrage: Die Option, den Inhalt des Dokuments zusammenzufassen, schließen die meisten bewusst aus, vor allem weil das zu aufwändig wäre. Es geht ja manchmal um viele Seiten, die sich nicht ohne Weiteres in wenigen Sätzen fassen lassen.
In keinem der beobachteten Fälle – online und im Test – liefert die Frage also brauchbare Information. Wie die Behörde reagiert hat, ist schon separat über den Status erfasst, und der per OCR ausgelesene Text liegt ebenfalls vor.
Zweite Iteration: Mein nächster Ansatz wäre gewesen, einige Beispielantworten zur Frage hinzuzufügen, um deutlicher zu machen, welche Art von Antwort erwartet wird:
Stattdessen haben wir uns entschieden, die Frage ganz zu entfernen, und zwar aus zwei Gründen:
Uns war wichtiger, den Prozess für Nutzende möglichst schnell und unkompliziert zu gestalten. Gerade dann, wenn die Frage korrekt verstanden wird, erfordert sie Mühe und kann dazu führen, dass einzelne Nutzende den Vorgang abbrechen („Dann lade ich das lieber später hoch, dafür muss ich mir erst eine Zusammenfassung überlegen.“).
Der Informationsverlust durch das Weglassen ist gering, da Nutzende aktuell vor allem Antworten eingeben, die schon anderweitig verfügbar sind.
Rückblickend
Ich schreibe diese Case Study nun fast drei Jahre nach dem Projekt. Rückblickend frage ich mich: Warum haben wir keinen stärkeren Schwerpunkt auf quantitative Daten gelegt? Es war schließlich das Ziel, mehr Uploads zu erreichen. Um die passenden Stellschrauben zu finden, bräuchten wir eigentlich Infos wie Drop-off-Points: Wo genau im Flow brechen Nutzende ab?
Aber dann erinnere ich mich wieder: Solch detaillierte Analytics zeichnet FragDenStaat nicht auf, aus Respekt vor der Privatsphäre der Nutzenden. Und bei welchen Anfragen ein Upload fehlt, lässt sich leider auch nicht auf anderem Wege rekonstruieren. Denn fehlt einfach nur eine Antwort, wissen wir ja nicht, was dahinter steckt: Es könnte ein Brief sein, der nicht hochgeladen wurde, oder ein anderer Grund – vielleicht hat die Behörde zum Beispiel nie geantwortet.
Was ich heute trotzdem anders machen würde: gemeinsam mit dem ganzen Team gründlicher brainstormen, ob es vielleicht doch Daten gibt, die indirekt ein paar Hinweise liefern könnten. Und für die qualitative Seite hätte ich gezielt nach regulären Nutzenden mit Upload-Erfahrung gesucht, nicht nur nach Power-Usern.
