Das GovTech TestLAB – unser Experimentierraum zum Testen von digitalen Tools und Produkten für die Verwaltungsdigitalisierung – wurde kürzlich im CityLAB-Blog vorgestellt. Zeit der Frage nachzugehen: Wie kann die Berliner Verwaltung sicherstellen, dass ein digitales Tool wirklich hilft – und nicht nur für mehr Wellengang im Arbeitsalltag sorgt?
Testen in vier Etappen – Kurs setzen, Segel hissen, Crew motivieren und Logbuch schreiben
Im TestLAB nehmen Verwaltungsmitarbeitende digitale Tools unter die Lupe. In praxisnahen Workshops prüfen und bewerten sie und finden gemeinsam heraus, welche Technik einen Mehrwert stiftet. Gleichzeitig lernen sie Methoden kennen, um künftig selbstständig zu testen und zu bewerten.Grundsätzlich orientieren wir uns im Testlabor an einzelnen Methoden aus unserem Handbuch für öffentliches Gestalten.
- Jeder Test folgt einer klaren Struktur – quasi wie eine Seefahrt mit vier Etappen: Use Cases identifizieren und Problemverständnis schärfen
- Produkttest durch Demo und Selbsterfahrung
- Produktbewertung und Evaluation
- Fazit und „Bonusmaterial”
So können neue Produkte erprobt werden, ohne sofort beschafft zu werden. Gleichzeitig entsteht Raum für Austausch: Häufig sitzen Verwaltungsmitarbeitende aus verschiedenen Bereichen im gleichen Boot – mit ähnlichen Hürden und Herausforderungen.
Durch diesen Erfahrungsaustausch lassen sich im Nachgang idealerweise Synergien finden und Kräfte bündeln. Der Umfang und Aufbau eines Tests oder einer Testreihe hängen jeweils von der Komplexität des zu testenden Produktes ab. Wie viel Vorwissen wird zur Nutzung benötigt? Müssen vorher bestimmte Daten gesammelt und eingespeist werden? Abhängig davon gestalten sich die Workshops und Formate, die von 60 Minuten über Testzeiträume von mehreren Wochen reichen können.
Unabhängig von der Länge eines Formats, ist jeder Test mit einer Seefahrt vergleichbar, die die oben genannten vier Stationen beinhaltet. Die vier Etappen – Kursbestimmung (Use Cases), erste Probefahrten (Demo & Selbsttest), Zwischenbilanz (Evaluation) und gemeinsames Logbuchlesen (Fazit) – bilden die Route. Hierbei helfen die zur Verfügung gestellten Kriterien (in Form von Kompass, Radar oder Checkliste) die Tools oder einzelne Funktionen des Produkts zu bewerten. Am Ende der Reise (am Ende des Testzeitraums) kommen die Seefahrer:innen am Lagerfeuer zusammen, erzählen sich, was sie erlebt haben und reflektieren gemeinsam die Brauchbarkeit der Werkzeuge.
Beispielhafte Fahrt: openDesk mit dem ITDZ Berlin
Eine solche “Abenteuerreise auf hoher See” durften wir gemeinsam mit dem ITDZ Berlin und Mitarbeitenden der Berliner Verwaltung beim Test des Open Source-Arbeitsplatzes openDesk durchführen. Die Teilnehmenden wurden auf eine zweiwöchige Erkundungsfahrt geschickt, bei der sie die Anwendung in ihren Teams ausprobiert und kollaborativ in ihren Projekten zusammengearbeitet haben. Die unterschiedlichen Produktfeatures wurden durch einzelne Inseln abgebildet, die nacheinander bereist wurden. Für jeden ausgefüllten Logbucheintrag (jede Bewertung) wurden Punkte gesammelt – eine spielerische Incentivierung, die sehr gut ankam.
Wie navigieren wir von der Problemwahrnehmung zum Produkttest?
Alle Formate sind methodisch so aufgebaut, dass die Teilnehmenden im ersten Schritt ihre Herausforderungen sammeln und diskutieren. Es gilt zuerst zu verstehen, an welcher Stelle genau die Probleme liegen und zu erkennen, ob sie (ausschließlich) technischer Natur sind. Mit Hilfe von Service Design-Methoden, befähigen wir die Teilnehmenden eine nutzendenzentrierte Erfassung der alltäglichen Probleme zu zeichnen, indem realistische Use Cases und Nutzungsszenarien erstellt werden – anstelle von einer bloßen Auflistung von Anforderungen. Die Persona-Methode kann dabei unterstützen die Bedarfe der Zielgruppen und der Nutzenden besser zu visualisieren. Dabei können sich die Verwaltungsmitarbeitenden, die bei einem Workshopformat vor Ort sind und ihre Use Cases mitgebracht haben, idealerweise in die Zielgruppe hineinversetzen und als Advokat:innen für die fiktiven Personas agieren.
Optional lässt sich noch tiefer einsteigen: Mit Hilfe der Methode Baumanalyse aus dem Handbuch Öffentliches Gestalten wird eine Herausforderung tiefergehend betrachtet und in die Bereiche „Ursache“ und „Effekte“ unterteilt. Sie kann dabei helfen ein größeres Problem in kleinere Teilaspekte zu unterteilen, die entweder das Problem verursachen oder sich als Auswirkung des Problems äußern. Durch die Art der Fragestellung wird eine Herausforderung greifbarer und der Umfang der verschiedenen Ausprägungen klarer. Ein Produkttest könnte anschließend z.B. ergeben, dass ein Problem nicht vollumfänglich gelöst werden kann, aber auf bestimmte Teilaspekte einzahlt wird und das Tool dennoch zu einer Verbesserung beiträgt.
Als Beispiel für ein zentrales Problem in der Baumanalyse, könnte man “Langsame Digitalisierungsfortschritte” nennen, das auf unterschiedliche Ursachen zurückzuführen ist: Zum einen mangelt es an personellen und technischen Ressourcen, zum anderen sind Entscheidungsprozesse komplex und es gibt rechtliche Unsicherheiten. Beide Aspekte haben wiederum andere Ursachen – Ursachen zweiter Ordnung. Komplexe Entscheidungsprozesse entstehen gegebenenfalls durch komplexe Gesetze und einer bestimmten Arbeitskultur. Andererseits führt das zentrale Problem auf der Effekt-Seite dann z.B. zu Unzufriedenheit bei Bürger:innen, Standortnachteilen für die Wirtschaft, hohem Ressourcenaufwand der Verwaltung und verpasste Effizienzgewinne durch digitale Lösungen.
Das Gedankenspiel zeigt, dass sowohl Ursachen als auch Effekte auf verschiedenen Ebenen stattfinden. Die Methode hilft dabei ein komplexes Problem granularer zu strukturieren. Oft kann eine digitale Anwendung nicht das zentrale Problem lösen, aber auf eine Ursache der ersten oder zweiten Ordnung einzahlen und damit an einem kleinen Zahnrad das Gesamtgefüge verbessern.
Bei kleineren, klar fokussierten Lösungsansätzen ist eine solche ausführliche Voranalyse weniger wichtig und wir fahren direkt fort.
Ein Produkttest findet idealerweise in realitätsnahen Bedingungen statt: vor Ort mit einem passenden Endgerät wie Laptop oder Smartphone, auf dem die Anwendung genutzt wird. Handelt es sich um kostenpflichtige Produkte, beschaffen wir Testlizenzen. Bei Open Source-Produkten können wir, je nach Größenordnung, auch Testinstanzen aufsetzen.
Nachdem das Produkt ausprobiert wurde, bekommen die Teilnehmenden ein digitales oder analoges Template, das ihnen bei der Bewertung und Evaluation hilft. Diese Vorlage wird je nach Produkt angepasst, beinhaltet aber stets folgende Aspekte oder Fragen:
- Problempassung: Konnte die Anwendung zur Verbesserung des im initial beschriebenen Use Case beitragen? Oder ggf. auf einen der Teilaspekte (Ursache und Effekt) einzahlen?
- Nutzendenfreundlichkeit: Wie gut ist die Bedienbarkeit (Usability) des Produktes? Mit Hilfe eines Radardiagramms werden verschiedene Aspekte der User Experience (Nutzendenerfahrung) abgefragt und bewertet. Die einzelnen Kriterien beinhalten unter Anderem:
- Ist die Sprache in der Anwendung verständlich?
- Ist die Navigation einfach und klar?
- Ist die Bedienung selbsterklärend?
- Ist das Design mit Farben und Icons konsequent gestaltet?
- Macht die Nutzung Spaß und stellt eine positive Erfahrung dar?
Auf einem digitalen Whiteboard können die Testteilnehmenden ihre Punkte auf der Skala platzieren: umso weiter Außen die Punkte im Diagramm verortete sind, desto mehr stimmen die Teilnehmenden der Aussage zu.
Als letztes werden im Plenum die Ergebnisse zusammengetragen: Konnten die zu Beginn aufgestellten Herausforderungen der verschiedenen Teams adressiert und adäquat gelöst werden? Wenn nicht vollständig, dann zu Teilen? War die Bedienbarkeit des Tools intuitiv und leicht zu erlernen, sodass auch andere Personen in ähnlichen Positionen schnell davon profitieren könnten? Und wie ist der Gesamteindruck bezüglich der Lösung? An dieser Stelle lässt sich auch die Frage diskutieren, ob das Produkt einen weiteren spannenden Mehrwert, also „Bonusmaterial“ bietet, das unter Umständen vor dem Test nicht ersichtlich war oder nicht unbedingt eine Lösung des initialen Problems darstellt und dennoch eine Erleichterung in einem anderen Feld bieten könnte. In einer offenen und moderierten Gruppendiskussion wird über den Gesamteindruck reflektiert und über die Ergebnisse aus dem Test gesprochen, die dann bei einer denkbaren Ausschreibung des Produktes als Basis dienen könnten oder eben eine informierte Haltung darstellen, ein Produkt nicht weiter in Betracht zu ziehen.
Und was sagt die Verwaltung?
Das Feedback der Verwaltungsmitarbeitenden zum Format fällt sehr positiv aus, da sie durch das Testlabor die Möglichkeit haben ein Tool unverbindlich auszuprobieren und Vor- und Nachteile einer innovativen Lösung abwägen können, ohne dass sie die „Katze im Sack“ kaufen.
“Das zweistündige Workshopformat hat total gut funktioniert und wir hatten sowohl genug Zeit zum Testen, als auch zum Austausch. Das Tool selbst auszuprobieren hat für große Learnings gesorgt.”
Im besten Fall gewinnen die Teilnehmenden Klarheit über ihre Herausforderungen, lernen neue Navigationsinstrumente zur Produktbewertung kennen und erkennen, welche Bedingungen erfüllt sein müssen, damit ein Tool den Verwaltungstanker auch wirklich auf Kurs bringt. Unser Ziel: Die Verwaltung darin zu bestärken, auch mal neue Gewässer zu erkunden – mit Mut zu innovativen Lösungen.
Du kennst ein Tool, das wir gemeinsam testen sollten? Oder arbeitest Du in der Berliner Verwaltung und suchst eine passende Lösung? Melde dich gern per Mail oder Telefon – wir stechen gemeinsam in See!
