Standardisieren statt Zentralisieren
Service-Designmuster für Gemeinden im Vereinigten Königreich
von Lizzie Bruce und Sanjay Poyzer
Der Government Digital Service (GDS) ist die Leitstelle für Verwaltungsdigitalisierung im Vereinigten Königreich. Als Teil des Cabinet Office ist es unsere Aufgabe, die Beziehung zwischen Bürger/-innen und Staat zu transformieren. Obwohl wir ein zentraler Teil der Verwaltung sind, arbeiten wir nicht so, wie man es vielleicht erwartet: Überall sind Post-its, und wir werfen mit Wörtern wie ›digital‹ und ›agil‹ nur so um uns. Aber natürlich sind diese Schlagwörter und Neon-Notizzettel nur die Fassade. In Wirklichkeit helfen wir der Verwaltung, öffentliche Dienstleistungen zu verbessern. Dienstleistungen, die inklusiv, flexibel und nutzerzentriert gestaltet sind.
Die Verwaltung ist riesengroß und sehr alt
Im ganzen Vereinigten Königreich helfen 5,4 Millionen Mitarbeiter im öffentlichen Sektor, Dienstleistungen zu erbringen. Die Zahl wird etwas weniger imposant, wenn wir uns auf die Nationalregierung konzentrieren, also auf die Abteilungen, die Dienstleistungen und Strategien auf nationaler Ebene bereitstellen. Das sind nur etwa eine halbe Million Menschen. Als GDS vor 6 Jahren ins Leben gerufen wurde, haben wir uns überlegt, wie wir skalieren könnten, damit unsere Arbeit schnell große Wirkung zeigen kann. Jetzt gehören mehr als 800 Dienste zu GOV.UK, von denen viele Millionen Benutzer/-innen haben. Sie werden von agilen Serviceteams betrieben und kosten Millionen Pfund weniger als die analogen Servicevarianten.
Das fehlende Bindeglied sind die örtlichen Verwaltungen. Im Vereinigten Königreich werden lokale Dienstleistungen von 418 verschiedenen Gemeinden erbracht. Die benötigten Dienstleistungen sind von Region zu Region unterschiedlich, außerdem verfügen die Gemeinden über eigene Budgets, so dass es bisher nie eine landesweite Richtlinie für ihren Betrieb gab.
Bevor es das Internet gab, suchte man die örtlichen Dienstleister persönlich auf: mit einem Besuch im Rathaus, der Bibliothek oder etwas Ähnlichem. Das hat sich geändert. Die Leute erwarten, dass sie online mit der Verwaltung in Kontakt treten können. Das bedeutet, dass all die Gemeinden im ganzen Land immer und immer wieder dieselben digitalen Gestaltungsprobleme lösen — wieder und wieder und wieder …
Auf nationaler Ebene lösen wir häufig auftretende Problem genau einmal. Wir setzen gemeinsame Komponenten und Designmuster ein. Gemeinsame Komponenten sind Dienstleistungsbestandteile, die wir zentral aufbauen. GOV.UK Notify verschickt zum Beispiel SMS-Nachrichten und E-Mails, GOV.UK Pay ermöglicht Diensten, Zahlungen von Benutzer/-innen anzunehmen, und GOV.UK Verify bietet den Benutzer/-innen eine Möglichkeit, online ihre Identität nachzuweisen. Indem wir solche Dienstbestandteile zentral entwickeln, können wir Design- und Forschungszeit investieren, um dafür zu sorgen, dass sie für alle erdenklichen Dienstleistungen reibungslos funktionieren. Und Serviceteams können sich ganz darauf konzentrieren, ihre Dienste erfolgreich zu gestalten.
Designmuster sind nach einhelliger Meinung die optimale Lösung für Designprobleme: zum Beispiel Muster wie ›erst prüfen, dann anfangen‹ (›Check before you start‹). Statt die Benutzer/-innen zu zwingen, komplizierte Richtlinien zu Ansprüchen zu lesen, stellen wir am Anfang ein paar Fragen, um herauszufinden, ob die Dienstleistung zu den Benutzer/-innen passen, bevor es losgeht. Wir haben Muster wie diese, die von Hunderten Teams auf nationaler Ebene eingesetzt werden.
Wegbereiter
Dieses Jahr habe ich mich einem Team angeschlossen, das herausfinden will, wie Gemeinden Designmuster und Komponenten einsetzen könnten. Das war für uns neues Terrain, und so sind wir mutig geworden: wir haben das gesamte Konzept erweitert, ausgehend von Designmustern für nur einen kleinen Teil der Dienstleistung hin zum gesamten Prozess von Anfang bis Ende. Wir haben ›Designmuster für lokale Verwaltungen‹ entwickelt, ›local government service patterns‹. Wir sind davon ziemlich begeistert, denn das stellt eine große Veränderung für die potenzielle Arbeitsweise von Gemeinden dar — nicht nur im Vereinigten Königreich, sondern weltweit.
Die Idee dahinter: wenn man einen Parkausweis beantragt, die Müllabfuhr bestellt oder ähnliche alltägliche Dienste in Anspruch nimmt, sollte der Ablauf dafür im gesamten Vereinigten Königreich ähnlich ablaufen. Das Design ist nicht um seiner selbst willen standardisiert, sondern weil es die beste Methode ist, die Dienstleistung zu erbringen.
Das hört sich vernünftig an. Aber wenn ich eines im öffentlichen Dienst gelernt habe, dann, dass ›vernünftig‹ nicht ›einfach zu bewerkstelligen‹ bedeutet.
Mit den Bedürfnissen anfangen
Bei GDS starten alle Projekte mit einer Discovery-Phase. Sie dient der Feststellung des eigentlichen Problems. Wir betreiben Nutzungsforschung, um herauszufinden welche Bedürfnisse der Dienst zu erfüllen hat und führen eine kurze betriebswirtschaftliche Analyse durch, um zu verstehen was erreicht werden kann. Das Ziel ist zu einer fundierten Hypothese über die Eigenschaften des Dienstes zu gelangen, um diese wiederum mit Hilfe von Prototypen in einer Alpha-Phase zu testen.
Wir sind mit dieser Art des Arbeitens ziemlich vertraut, während das in den Gemeindeverwaltungen noch weniger üblich ist. Qualitative Forschung und Design sind für uns Bestandteil der Serviceerbringung, was sie zweifelsohne sind, doch gibt es ein Problem, wenn die Leistungserbringung ausgelagert ist. In der Vergangenheit wurde die Gestaltung und Entwicklung von Dienstleistungen separat von der Festlegung ihres Leistungsumfangs gehandhabt. Lediglich Letzteres wurde in der Verwaltung gemacht. In unserem Projekt bedeutete dies, dass die Gemeindeverwaltungen kaum Expertise und Erfahrung in Forschung oder Design hatten.
Als wir unser erstes Servicemuster für Gemeinden angingen, war uns klar wir mussten dies ändern. Es scheiterte nicht an der Bereitschaft der Servicemanager in den Gemeinden Forschung und Design zu betreiben, jedoch fehlte ihnen schlicht die Ausrüstung dafür. Daher schulten wir sie in Forschungsmethoden und ermutigten sie dazu, mit tatsächlichen Nutzer/-innen zu sprechen. Das Resultat? Unsere Gruppe von 17 Gemeinden hat über 150 Menschen interviewt. Ein Team bei GDS hat diese Forschung ausgewertet und auf Gemeinsamkeiten und Unterschiede hin untersucht. Letztlich stellten sich die Dienste der verschiedenen Regionen als sehr viel ähnlicher denn unterschiedlicher heraus. Das hatte zur Folge, dass wir die zusammengetragenen Forschungsergebnisse tatsächlich im Gestaltungsprozess der Dienste für alle Gemeinden verwenden konnten — mit einigen Variationen wo sie nötig waren.
Am Anfang der Alpha-Phase entwickelten wir einen digitalen Prototypen für die fiktive Gemeinde von Argleton. Nach einer Usability-Studie mit dieser Version ließen wir die Gemeinden die Prototypen auf ihr eigenes Design anpassen, so dass sie aussahen wie ihre existierenden Webseiten. Auch nahmen wir lokale Änderungen vor, die aufgrund von spezifischen Bestimmungen oder technischen Einschränkungen notwendig waren. So genehmigte beispielsweise eine Gemeindeverwaltung ihren Anwohnern lediglich einen einzigen Parkausweis. Andere Gemeinden stellten dagegen mehrere aus, wollten jedoch sicherstellen, dass die Nutzer/-innen auch wirklich die Besitzer/-innen der Autos waren für die sie die Genehmigungen beantragten. Und dort wurde es dann so richtig kompliziert …
Die Benutzer-innen sind Kolleg-innen, keine Kund-innen
Holen wir hier etwas weiter aus: Als wir anfangs diese Servicemuster entwarfen, schien die große Frage zu sein: ›Wie sollen wir die Leute dazu bringen, diese Muster zu benutzen?‹ Und schon waren wir in die Falle der Verkäufermentalität getappt!
Dieser Fehler wird in der Verwaltung sehr häufig gemacht, weil sie sehr groß ist (und hatte ich schon erwähnt, dass sie auch sehr alt ist?). Wir müssen also organisationsübergreifend arbeiten. In der Privatwirtschaft sind entweder externe Personen die Kunden-innen oder man selbst ist ihr Kunde. Das ist im Allgemeinen das Modell für die Beziehungen zwischen Organisationen, aber auf den öffentlichen Dienst kann man das so nicht übertragen. Organisationen des öffentlichen Dienstes kämpfen nicht um Marktanteile. Wir sind alle hier, um die Allgemeinheit zu dienen.
Und doch tappen wir in die Falle. Wir bauen etwas auf, und dann fragen wir uns, ob wir die Benutzer/-innen mit Zuckerbrot locken können oder sie doch eher mit der Peitsche zwingen müssen. Diese Herangehensweise ist grundlegend falsch.
Wie entgehen wir dieser Fehlannahme? Zunächst handelt es sich hier um eine Dienstleistung, das heißt wir müssen sie so entwerfen wie wir Dienstleistungen für Bürger/-innen entwerfen. Wir müssen fragen:
1. Was brauchen unsere Benutzer/-innen?
2. Was ist unser Ziel, und wie können wir es erreichen?
3. Was müssen Benutzer/-innen tun, damit wir dieses Ziel erreichen können?
Dank dieser Fragestellung wurde uns klar, dass wir die Benutzer/-innen von öffentlichen Dienstleistungsmustern wie Kollegen behandeln mussten, nicht wie Kunden. Das ist so, weil:
1. Unsere Benutzer/-innen müssen ihre öffentlichen Dienstleistungen entwerfen und erbringen.
2. Unser Ziel ist, dass die Dienstleistungen für die Benutzer/-innen gut funktionieren und gleichzeitig kostengünstig sind. Wir glauben, dass wir dieses Ziel mit gemeinsamen Komponenten und Mustern erreichen können.
3. Dieses Ziel wird erreichbar, wenn die Benutzer/-innen zu diesen Mustern und Komponenten beitragen. Das ist ein zentraler Punkt.
Die Bedürfnisse unserer Benutzer/-innen und unsere Ziele stimmen offensichtlich überein. Und das Wichtigste: wir gestalten nicht nur für unsere Benutzer/-innen, wir gestalten mit ihnen.
Im Laufe des Projektes kam uns diese Erkenntnis nicht als plötzliche Erleuchtung, sondern durch einen langsamen Prozess des Begreifens. Als wir mehr Rückmeldungen zur Durchführbarkeit dessen erhielten, was wir für die ideale Lösung hielten, merkten wir, dass wir uns die komplette Transformation dieser Dienste mit unterschiedlichen Anforderungen der Gemeinden zu einfach vorgestellt hatten. Ihre Bedürfnisse waren zwar ähnlich, doch hatten über Jahre etablierte Arbeitsweisen Einfluss auf weitere Dienste, was keinen Sinn für einige Gemeinden ergab.
Wenn die Muster funktionieren sollten, mussten die Verwaltungen in der Lage sein sie lokalisieren zu können. Das hieß für uns zunächst ihre jeweiligen Kontexte zu verstehen. Es wurde uns klar, dass wir Dienstleistungen ebenso wenig ›lieferten‹, wie ein Teammitglied seinem Team seine Mitarbeit ›abliefert‹. Muster brauchen einen Dialog mit tiefgehendem Respekt auf beiden Seiten. Unsere Rolle beim Entwurf dieser Muster war, den Wissensaustausch zwischen den örtlichen Verwaltungen zu unterstützen, so wie die Hauptaufgabe jedes Designers ›Facilitation‹, also die Unterstützung und Förderung von Prozessen ist.
Wir haben gelernt, dass man diese Prozesse nicht automatisieren kann. Wir konnten nicht einfach ein Online-Formular bauen, das man mit Forschungsergebnissen füttert, um dann automatisch eine Best-Practice-Dokumentation zu bekommen. Wir brauchen strukturierte, kritische Diskussion.
Die Zukunft ist kollaborativ
Das Konzept von Dienstleistungsmustern für Gemeinden ist noch recht neu. Wir haben genau zwei fertiggestellt, Parkausweise und Busfahrkarten für Senioren, und beide werden von einer Handvoll Verwaltungen eingesetzt. Die Muster werden frei zugänglich im Internet veröffentlicht, es kann also sein, dass sie noch weiter verbreitet sind.
Das Spannende ist aber, dass uns unsere Pilotgemeinden Rückmeldungen geben, während sie ihre Dienste entwickeln, sodass wir das Muster weiterentwickeln können. Sie benutzen außerdem unsere gemeinsamen Komponenten wie GOV.UK Verify zum Nachweisen ihrer Identität und gov.uk Pay zum Bezahlen, und weil dazu die technische Einbindung durch technische Schnittstellen wie apis nötig ist, reden wir miteinander auch darüber. Mit den Komponenten lernen wir — wieder — bei der Entwicklung nicht nur die Benutzer/-innen in den Mittelpunkt zu stellen, sondern mit ihnen zusammenzuarbeiten.
Die Verwaltung ist groß. Und sie ist alt. Aber sie reift zu einem außerordentlich agilen Team heran.
———
Lizzie Bruce ist Content Designerin beim Government Digital Service und arbeitet dort im GOV.UK Verify-Team. Zuvor arbeitete sie für die britische Post und direkt in Gemeinden.
Sanjay Poyzer arbeitet als Service Designer für den Government Digital Service des britischen Cabinet Office. Im letzten Jahr entwickelte er mit 17 Gemeinden neue Dienste.
