Wie sich das im Alltag auswirkt, habe ich als Mitgründer von Aivot erfahren. Wir sind mit einem ersten Prototyp unserer Verwaltungssoftware gestartet und haben daraus Schritt für Schritt ein Produkt und ein Unternehmen aufgebaut. Wie viel Zeit und Kapazität wir in die Weiterentwicklung investieren konnten, hing dabei auch davon ab, was die Software bereits erwirtschaftete. Mit wachsenden Einnahmen entstand nach und nach mehr Spielraum für die nächsten Schritte. Unser Jubiläum nehme ich zum Anlass, auf diesen Weg zurückzublicken und darüber nachzudenken, was Gründen im Public Sector besonders macht und welche Herausforderungen damit verbunden sind.

Aus einem Formularwerkzeug wurde eine Plattform

Die Idee für Aivot entstand aus der Verwaltungspraxis meiner heutigen Kollegen und Mitgründer. Sie kannten Medienbrüche, doppelte Arbeit und unnötig komplizierte Abläufe aus dem eigenen Behördenalltag. Ich selbst hatte bis dahin mit Verwaltung eigentlich noch gar nichts am Hut. Mein Blick auf diese Probleme kam anfangs von außen. Gemeinsam wollten wir die Abläufe mit Köpfchen einfacher machen. Das steckt auch in unserem Namen: Aivot ist Finnisch und bedeutet Gehirn.

Unser erster Prototyp trug noch keinen Produktnamen und konzentrierte sich auf Online-Formulare. Aus ihm wurde später Gover, und aus dem Formularwerkzeug entwickelte sich schrittweise eine Plattform für durchgängige Verwaltungsprozesse. Künftig trägt sie den Namen Prosuna.

Wir konnten diesen Weg gehen, weil im Team Softwareentwicklung, UI/UX, Konzeption, Projektmanagement und Verwaltungserfahrung zusammenkamen. Trotzdem hatten wir uns damit ein deutlich größeres Feld vorgenommen, als uns am Anfang vermutlich bewusst war. Eine solche Plattform reicht über einen einzelnen Arbeitsschritt hinaus. Sie trifft auf Fachrecht, Datenmodelle, Rollen und Rechte, Schnittstellen, Barrierefreiheit, Datenschutz, IT-Sicherheit, Betrieb und die tägliche Arbeit in der Sachbearbeitung.

Jedes dieser Themen erhöht den Prüf- und Abstimmungsbedarf und erweitert den Kreis der Menschen, die einer Einführung zustimmen müssen. Der Nutzen lässt sich nicht allein an einer gelungenen Oberfläche zeigen. Die Plattform muss sich auch dort bewähren, wo Daten weitergegeben, Sonderfälle bearbeitet, Entscheidungen dokumentiert und Systeme langfristig betrieben werden.

Die Breite hat einen fachlichen Grund. Medienbrüche verschwinden selten, wenn nur ein einzelner Schritt eine bessere Oberfläche bekommt. Wer einen Verwaltungsprozess spürbar entlasten will, muss über das Absenden eines Online-Formulars hinausdenken. Für uns bedeutet dieser Anspruch, dass wir lernen müssen, wie Fachlichkeit, Organisation und Technik in der Verwaltung tatsächlich zusammenwirken.

Der erste Auftrag braucht einen Vertrauensvorschuss

Eine Verwaltung muss vor einer Einführung auch einschätzen, ob sie sich im laufenden Betrieb auf den Anbieter verlassen kann. Wer steht für die Lösung ein, wenn nach dem Go-live etwas nicht funktioniert? Und kann das Unternehmen die Betreuung und Weiterentwicklung langfristig bewältigen?

Für ein junges Unternehmen entsteht daraus eine schwierige Schleife. Verwaltungen wünschen sich Erfahrung und belastbare Referenzen. Beides entsteht jedoch erst durch den Einsatz der eigenen Lösung. Wer noch am Anfang steht, muss also Vertrauen aufbauen, bevor er in größerem Umfang zeigen kann, dass dieses Vertrauen gerechtfertigt ist.

Das ist nicht einfach Ausdruck einer langsamen Verwaltung. Es geht um öffentliche Mittel, sensible Daten, rechtlich gebundene Entscheidungen und Leistungen, auf die Menschen angewiesen sind. Die Vorsicht hat also einen nachvollziehbaren Grund. Für Gründer:innen passt dadurch das gewohnte Bild vom Aufbau eines jungen Softwareunternehmens aber nur bedingt. Produkt, Marktzugang und Unternehmen können nicht sauber nacheinander reifen. Sie sind gleichzeitig voneinander abhängig.

Vertrauen entsteht in diesem Markt vor allem durch verlässliche Arbeit, verständliche Dokumentation und Gespräche, in denen auch Grenzen benannt werden. Betriebsmodelle, Sicherheitskonzepte und erreichbare Ansprechpartner:innen gehören deshalb zum Produktversprechen eines Softwareanbieters.

Das verändert auch den Vertrieb. Bei uns fühlt er sich selten wie der eine überzeugende Pitch an. Häufiger besteht er aus kleinen Belegen dafür, dass wir Zusagen einhalten, Fragen nachvollziehbar beantworten und auch nach dem Vertragsabschluss Verantwortung übernehmen. Eine erfolgreiche Einführung kann für ein junges Unternehmen deshalb weit über den unmittelbaren Umsatz hinaus wichtig sein: Sie macht die eigene Verlässlichkeit für andere sichtbar.

Auch Quelloffenheit ist für uns Teil dieser Verlässlichkeit. Sie gibt einer Verwaltung noch keine Garantie für guten Betrieb oder gute Zusammenarbeit. Sie schafft aber prüfbare Grundlagen und hält langfristig Optionen offen. Das ist ein wichtiger Teil der digitalen Souveränität, die wir mit Aivot unterstützen wollen.

Bootstrapping trifft auf einen langsamen Markt

Diese Verlässlichkeit aufzubauen, kostet schon vor dem ersten Auftrag Zeit. Produktentwicklung, Kundentermine und die vielen kleinen Aufgaben eines jungen Unternehmens konkurrieren dabei um dieselben begrenzten Kapazitäten. Mit jeder Einführung wurde unser Produkt belastbarer und unsere Perspektive verlässlicher.

Bootstrapped zu bleiben, war für uns nicht nur eine finanzielle Entscheidung. Wir wollten unabhängig von den großen Anbietern bleiben, deren Trägheit aus unserer Sicht dazu beigetragen hat, dass sich viele Probleme der Verwaltungsdigitalisierung bis heute halten. Gerade diese Trägheit war einer der Gründe für unsere Gründung: Wir wollten in diesem Bereich selbst etwas bewegen. Die Richtung unseres Produkts sollte deshalb unter unserer Kontrolle bleiben.

Dieser Weg band die Entwicklung des Unternehmens unmittelbar an das, was wir bereits erwirtschaften konnten. Produkt und Unternehmen mussten in einem gemeinsamen Tempo wachsen. Zusätzliche Kapazität brauchte eine finanzielle Grundlage. Jede Zusage band spürbar Zeit, und Grundlagenarbeit ließ sich nicht unbegrenzt vorfinanzieren.

In einem Markt mit langen Vertriebs- und Beschaffungswegen wird dieser Zusammenhang besonders herausfordern. Zwischen einem guten Gespräch und einer tatsächlichen Beauftragung können viele Monate liegen. Das Produkt muss trotzdem weiterentwickelt, der Betrieb vorbereitet und das vorhandene Team finanziert werden. Wer bootstrapped gründet, kann diese Zeit nicht einfach mit mehr Personal überbrücken.

Diese Monate bestehen zudem aus Arbeit. Ausschreibungsunterlagen müssen geprüft, Nachweise zusammengestellt, Angebote kalkuliert und technische Rückfragen beantwortet werden. Vieles davon fällt an, bevor feststeht, ob daraus überhaupt ein Auftrag wird. In einem kleinen Team fehlt diese Zeit an anderer Stelle, etwa bei der Weiterentwicklung oder der Betreuung bestehender Kunden.

Der KOINNO-Vergabereport 2025 gibt einen Hinweis darauf, wie stark diese Vorarbeit ins Gewicht fällt: 80 Prozent der Befragten mit Ausschreibungserfahrung bewerten den Aufwand einer Angebotsabgabe für öffentliche Aufträge als höher als den Vertriebs- und Angebotsaufwand bei anderen Kunden. An der Befragung nahmen insgesamt 62 Personen beziehungsweise Unternehmen teil, überwiegend aus länger bestehenden Unternehmen. Das ist in der Menge nicht repräsentativ, entspricht aber meiner eigenen Wahrnehmung und Erfahrung.

Für ein bootstrapped Unternehmen gehört deshalb auch die Auswahl der verfolgten Aufträge zur Produktstrategie. Passt der Bedarf zur eigenen Lösung? Steht der Aufwand für das Angebot in einem vertretbaren Verhältnis zur möglichen Beauftragung? Und welche Arbeit bleibt dafür liegen? Selbst eine fachlich interessante Gelegenheit kann zu viel Kapazität binden. Ein voller Kalender mit aussichtsreichen Gesprächen finanziert noch keine zusätzliche Stelle.

Ich möchte daraus keine Heldengeschichte über langsames Wachstum machen. Bootstrapping kann Kräfte aufzehren und Optionen begrenzen. Mehr Kapital hätte manche Entwicklung beschleunigt. Das ist nicht automatisch die bessere oder moralischere Gründungsform. Für uns hat sich dieser Weg richtig angefühlt, weil Produkt und Unternehmen so miteinander wachsen konnten.

Die Richtung des Produkts braucht auch ein Nein

Ohne Wagniskapital zu arbeiten, gibt uns die Freiheit, über unsere Richtung selbst zu entscheiden. Damit ist die Frage nach Unabhängigkeit allerdings nicht erledigt. Wer seine Weiterentwicklung aus Kundeneinnahmen finanziert, muss sich auch mit dem Einfluss einzelner Kundenwünsche auseinandersetzen. Besonders dann, wenn nur wenige Aufträge einen großen Teil der laufenden Kosten decken, kann eine zusätzliche Anforderung erhebliches Gewicht bekommen.

Bei einer breiten Plattform ist die Grenze nicht immer offensichtlich. Der Einsatz bei einzelnen Verwaltungen liefert das Wissen, das für ein gutes Produkt nötig ist, bringt aber auch spezielle Anforderungen mit. Wir mussten früh unterscheiden: Welche Anpassung verbessert das Produkt für viele Verwaltungen, und welche würde uns dauerhaft in eine Sonderlösung führen? Unser Geschäftsmodell ist deshalb kein klassisches Projektgeschäft. Im Mittelpunkt steht Prosuna als eigenständiges Produkt, das wir kontinuierlich weiterentwickeln.

So haben wir beispielsweise spezialisierte Funktionen für das Fördermittelmanagement bewusst abgelehnt, die ausschließlich in diesem Bereich zum Einsatz gekommen wären. Fachlich liegt das nah genug an Verwaltungsprozessen, um zunächst wie eine plausible Erweiterung zu wirken. Damit hätten wir aber dauerhaft zusätzliche Fachlogik pflegen müssen, die anderen Verwaltungsprozessen nicht zugutegekommen wäre. Wir wollten eine Plattform für durchgängige Verwaltungsprozesse bauen. Solche bereichsspezifischen Erweiterungen hätten uns von dieser Vision entfernt.

Die Schwierigkeit liegt für mich gerade darin, dass eine solche Anfrage durchaus sinnvoll sein kann. Ein nachvollziehbarer Bedarf verpflichtet uns trotzdem nicht dazu, ihn mit unserem Produkt abzudecken. Mit jeder Erweiterung übernehmen wir Verantwortung für ihre Pflege und Weiterentwicklung. Diese Arbeit bleibt, auch wenn der ursprüngliche Anlass längst nicht mehr gegeben ist. Unsere Unabhängigkeit zeigt sich deshalb auch darin, eine Richtung ablehnen zu können, die nicht zu dem passt, was wir langfristig tragen und vertreten wollen.

Ein enger Zuschnitt kann den Einstieg erleichtern

Wie weit man sich mit einem Produkt vorwagt, prägt auch den Weg zum ersten Einsatz. Im GovTech-Markt, also dem Markt für digitale Produkte und Dienstleistungen für Staat und Verwaltung, gibt es reichlich Angebote, die bei klar begrenzten Aufgaben ansetzen. Gerade bei neuen KI-Lösungen sieht man Angebote, die eine Recherche unterstützen, Dokumente zusammenfassen oder Texte formulieren. Ihr Nutzen lässt sich schnell erklären und oft ebenso schnell ausprobieren.

Für die Produktentwicklung liegt darin auch der Gedanke eines Minimum Viable Product, kurz MVP: eine erste, bewusst begrenzte Version, mit der ein Team früh prüfen kann, ob seine Annahmen über das Problem und den Nutzen der Lösung stimmen. Je enger die zu prüfende Aufgabe umrissen ist, desto gezielter lässt sich diese Version entwickeln und auswerten. Gerade beim Bootstrapping ist es hilfreich, grundlegende Annahmen prüfen zu können, bevor zu viel Entwicklungszeit in eine Richtung geflossen ist. Ein Produkt mit wenigen Funktionen ist aber nicht automatisch ein MVP. Es kann sich längst im Alltag bewährt haben und bewusst auf eine einzelne Aufgabe beschränkt bleiben.

Ein solches Produkt kann auch mit wenigen Funktionen im Verwaltungsalltag viel bewirken. Sind damit weniger Schnittstellen, beteiligte Rollen und Eingriffe in bestehende Abläufe verbunden, kann das die Hürden für Beschaffung und Einführung senken. Eine Verwaltung kann mit einem begrenzten Anwendungsfall beginnen und Erfahrungen sammeln. Trägt die Lösung nicht, lässt sie sich unter diesen Bedingungen vergleichsweise schnell austauschen.

Entscheidend ist allerdings, worauf das Produkt zugreift und was es beeinflusst. Auch ein Werkzeug mit wenigen Funktionen kann sensible Daten verarbeiten oder in rechtlich relevante Entscheidungen eingreifen. Die Zahl der Funktionen allein sagt deshalb wenig über den Prüfbedarf aus. Der Vorteil entsteht dort, wo sich eine Aufgabe tatsächlich mit überschaubaren Abhängigkeiten lösen lässt.

Wenige Abhängigkeiten können zugleich den Wechsel zu einem anderen Angebot erleichtern. Hängt das gesamte Geschäft an diesem einen Anwendungsfall, trifft dessen Austauschbarkeit das Unternehmen entsprechend stark.

Für solche Anbieter kann Diversifizierung deshalb wichtig sein: weitere passende Anwendungsfälle erschließen oder ergänzende Produkte entwickeln, damit die Einnahmen auf mehreren Angeboten beruhen. So hängt die Zukunft des Unternehmens weniger davon ab, ob es bei einer einzelnen Aufgabe dauerhaft die bevorzugte Lösung bleibt. Fachlich angrenzende Angebote ermöglichen es dabei, vorhandenes Wissen und Technik weiterzuverwenden. Auch bei diesem Weg stellt sich also die Frage, welche Erweiterungen zum Unternehmen passen und welche es zu weit von seiner Richtung entfernen würden.

Manchmal bin ich auf diesen „einfacheren“ Einstieg ein wenig neidisch. Die Aufgabe, den Nutzen schnell verständlich und überprüfbar zu machen, haben wir mit einer breiten Plattform allerdings genauso.

Der erste Prozess muss im Alltag etwas beweisen

Eine ganze Plattform auf einmal einzuführen, würde einer Verwaltung viele Entscheidungen gleichzeitig abverlangen. Für uns stellt sich deshalb die Frage, mit welchem Prozess sie die Zusammenarbeit und das Produkt sinnvoll kennenlernen kann. Der erste Einsatz muss eine reale Aufgabe lösen und dabei so überschaubar bleiben, dass Fragen und Probleme zeitnah geklärt werden können.

Beim Onboarding setzen wir deshalb nach Möglichkeit zuerst einen kleinen Verwaltungsprozess um, der ohne externe Datenquellen oder Schnittstellen auskommt. Zuständigkeiten und Erfolgskriterien klären wir früh. So hängt der Beginn nicht bereits davon ab, dass mehrere andere Systeme angebunden werden. Die Beteiligten können sich zunächst mit dem Ablauf und ihrer Arbeit in der Plattform vertraut machen.

Für mich sollte sich an diesem Prozess bereits zeigen, ob die Lösung im Alltag funktioniert. Finden Sachbearbeiter:innen die Informationen, die sie für die Bearbeitung benötigen? Ist erkennbar, wo eine Rückfrage offen ist und wer als Nächstes handeln muss? Kommt ein Vorgang zu einem fachlich sinnvollen Abschluss? Ein erfolgreich abgesendetes Formular allein würde den Anspruch an unsere Plattform noch nicht prüfen.

Die bewusste Begrenzung lässt aber Fragen offen. Ein Prozess ohne externe Schnittstellen sagt noch wenig darüber aus, wie gut die spätere Anbindung eines Fachverfahrens gelingt. Das sollte bei der Bewertung des ersten Einsatzes sichtbar bleiben. Sonst wird aus einem gelungenen kleinen Schritt eine Sicherheit abgeleitet, die der Versuch gar nicht liefern konnte.

Darauf baut für mich agile Entwicklung in Behördenprojekten auf: Erfahrungen aus einem überschaubaren Einsatz verändern die nächste Entscheidung. Manche Abläufe müssen angepasst, manche Annahmen erneut geprüft werden, bevor weitere Prozesse oder Schnittstellen hinzukommen. Der Einstieg wird damit zu einem Teil der Produktentwicklung und liefert der Verwaltung eine konkrete Grundlage, um über das weitere Vorgehen zu entscheiden.

Ein erfolgreicher Pilot braucht eine Anschlussentscheidung

Auch wenn sich dieser erste Prozess bewährt, bleibt die Frage, wie es nach einer Pilotphase weitergeht. Die OECD beschreibt den Übergang vom Pilot zur breiteren Einführung als eigene Herausforderung: Finanzierung und Beschaffung müssen dafür ebenso gesichert werden wie die Kapazitäten für Einführung und langfristige Betreuung. Ein funktionierender Versuch löst diese Fragen nicht wie von Geisterhand.

Deshalb sollte bereits vor dem Start besprochen werden, woran sich der Nutzen zeigen soll, wer anschließend über das weitere Vorgehen entscheidet und aus welchem Budget ein dauerhafter Betrieb finanziert werden könnte. Der mögliche Beschaffungsweg gehört ebenfalls dazu. Das ist keine Zusage für einen Folgeauftrag und darf einen fairen Wettbewerb nicht vorwegnehmen. Es schafft aber Klarheit darüber, welche Voraussetzungen für eine Fortsetzung noch fehlen.

Für ein bootstrapped Unternehmen ist dieser Unterschied wesentlich. Auch ein Pilot bindet Entwicklungszeit und erfordert Abstimmung sowie Betreuung. Sein Lerngewinn lässt sich nicht unbegrenzt gegen eine unklare wirtschaftliche Perspektive aufrechnen. Ein sinnvoller Pilot darf mit der Erkenntnis enden, dass die Lösung nicht passt. Wenn sie sich bewährt, sollte dagegen jemand eine begründete Anschlussentscheidung treffen können. Sonst bleibt wertvolle Arbeit im Versuch stecken und geht verloren.

Bei der nächsten Verwaltung muss etwas leichter werden

Wenn aus dem ersten Einsatz ein dauerhafter Betrieb wird, ist bereits viel erreicht. Für ein Produktunternehmen stellt sich dann die nächste Frage: Wie viel von dieser Arbeit hilft auch bei der Einführung in einer anderen Verwaltung? Eine erfolgreiche Installation belegt zunächst, dass die Lösung unter bestimmten Bedingungen funktioniert.

Wenn jede Verwaltung umfangreiche neue Sonderentwicklung benötigt, wächst mit jedem Auftrag auch die dauerhaft zu betreuende Vielfalt. Der gemeinsame Produktkern hilft dann wirtschaftlich nur begrenzt. Konfigurierbare Abläufe, wiederverwendbare Schnittstellen und verständliche Betriebsdokumentation können dagegen dazu beitragen, dass eine weitere Einführung weniger individuelle Arbeit erfordert. Auch Schulungsmaterial muss nicht jedes Mal von vorn entstehen.

Das bedeutet nicht, dass alle Verwaltungen gleich arbeiten sollten. Unterschiede im Fachrecht, in Zuständigkeiten oder in der vorhandenen IT verschwinden durch ein gemeinsames Produkt nicht. Es kommt darauf an, welche Unterschiede sich durch Konfiguration abbilden lassen und wo tatsächlich neue Entwicklung nötig ist. Gerade deshalb sind offene Standards für ein kleines Softwareunternehmen auch eine wirtschaftliche Frage: Jede wiederverwendbare Anbindung kann Aufwand bei späteren Einführungen vermeiden.

Für unseren Weg lässt sich daraus ein weiterer Maßstab ableiten. Fortschritt wäre, wenn eine Einführung Erfahrungen liefert, die die nächste einfacher machen. Sonst binden zusätzliche Kunden immer mehr von der Zeit, die eigentlich für die Weiterentwicklung des gemeinsamen Produkts gebraucht wird.

Beschaffung kann den Zugang mitgestalten

Auch eine gut übertragbare Lösung muss bei der nächsten Verwaltung wieder einen Weg in die Beschaffung finden. Hier liegt ein Teil der Verantwortung bei den öffentlichen Auftraggebern. Wenn der erste Austausch erst mit einer weitgehend festgelegten Leistungsbeschreibung beginnt, bleibt wenig Raum, andere Lösungswege kennenzulernen.

Im Anwendungsbereich der Vergabeverordnung sind Markterkundungen vor einem Vergabeverfahren ausdrücklich vorgesehen. Sie erlauben Auftraggebern, sich vorab mit dem Angebot des Marktes zu befassen und Unternehmen über ihre Pläne und Anforderungen zu informieren. Ein solcher Austausch ist noch keine Beauftragung. Er kann aber helfen, einen Bedarf so zu beschreiben, dass auch eine andere als die bisher bekannte Lösung infrage kommt.

Auch bei den Nachweisen gibt es Vorgaben, die den Zugang offenhalten sollen. Nach § 122 GWB müssen Eignungskriterien und geforderte Nachweise zum Auftrag und seinem Wert in einem angemessenen Verhältnis stehen. Die Vergabeverordnung nennt bei geeigneten Referenzen ausdrücklich öffentliche oder private Auftraggeber. Eine Referenz muss also nicht allein deshalb ungeeignet sein, weil sie aus der Privatwirtschaft stammt – ihre fachliche Eignung für den konkreten Auftrag bleibt zu beurteilen.

Für mich folgt daraus eine praktische Frage: Welche Erfahrung und welche Nachweise braucht es wirklich, um diesen Auftrag verantwortbar zu vergeben? Anforderungen sollten am tatsächlichen Risiko ansetzen. Ein begrenzter Einstieg bietet die Möglichkeit, den Umfang der Aufgabe und die dafür nötige Absicherung gemeinsam überschaubar zu halten. So können junge Anbieter zeigen, was sie leisten, und Verwaltungen gewinnen eine belastbarere Grundlage für ihre Entscheidung.

Über unsere Mitgliedschaften im Bitkom und in der GovTech Allianz setzen wir uns auch über die Arbeit an unserer Plattform hinaus für bessere Rahmenbedingungen ein, damit Innovationen im Public Sector schneller in die Praxis kommen.

Lange Wege sind keine Entschuldigung

Solche Rahmenbedingungen können den Marktzugang erleichtern. Sie nehmen uns die eigenen Entscheidungen aber nicht ab. Wer im Public Sector gründet, braucht Geduld für Vertrauen, Referenzen und formale Verfahren. Die langen Zyklen des Marktes dürfen trotzdem keine Ausrede dafür werden, Produktfragen jahrelang offenzuhalten.

Nicht jede Verzögerung kommt von außen. Wir haben uns bewusst für eine breite Aufgabe entschieden und ihre Größe am Anfang nicht in jeder Konsequenz verstanden. Unsere Verantwortung besteht darin, diese Aufgabe in beherrschbare Schritte zu übersetzen, klare Prioritäten zu setzen und nur das zu versprechen, was wir anschließend zuverlässig betreiben können.

Für Ende 2026 planen wir mit dem Major Release von Prosuna auf Version 5 einen besonderen Meilenstein. Nach zwei intensiven Jahren der Weiterentwicklung soll Prosuna damit endlich die Plattform sein, die wir uns beim ersten Prototyp vorgestellt haben: eine quelloffene Lösung, die Verwaltungsprozesse durchgängig abbildet, statt nur ihr digitales Eingangstor bereitzustellen. Version 5 beendet diese Entwicklung nicht. Sie schafft die Grundlage für die nächsten Schritte und für neue Anforderungen, die erst im Einsatz sichtbar werden.

Auf das, was unser Team unter diesen Bedingungen aufgebaut hat, bin ich sehr stolz. Ebenso dankbar bin ich allen, die unsere Idee mitgetragen und gemeinsam mit uns daran gearbeitet haben, in der Verwaltung etwas zu bewegen, auch wenn der Weg dorthin nicht immer der kürzeste war und weiterhin ist.

Mit der Zeit ist mir klarer geworden, dass wir mit jedem Auftrag auch darüber entscheiden, welche Arbeit wir uns für die kommenden Jahre vornehmen. Ein guter nächster Schritt muss zur Verwaltung passen, die ihn mit uns geht, und das gemeinsame Produkt voranbringen. Manchmal heißt das, eine Einführung kleiner anzulegen. Manchmal heißt es, eine Weiterentwicklung abzulehnen. Geduld mit dem Markt gehört dazu. Die Richtung unseres Unternehmens und dessen Lösungen müssen wir trotzdem selbst bestimmen.

Dann wird schnell nach der einen Ursache gesucht: zu wenig Geld, zu alte Systeme, zu viel Föderalismus, zu komplizierte Vergabe, zu wenig Mut oder schlechte Software. An all dem kann etwas dran sein. In der Praxis ist das Problem meistens weniger eindeutig.

Meist gelten mehrere Dinge zu früh als geklärt. Ein alter Prozess wird online nachgebaut, eine fachliche Entscheidung bleibt offen, die reale Nutzung kommt zu spät ins Spiel. Der Go-live gilt als Erfolg, obwohl nach dem Start die Verantwortung für Weiterentwicklung fehlt.

Weil die Probleme an unterschiedlichen Stellen entstehen, gibt es auch mehrere Ansatzpunkte. Projekte werden besser, wenn sie früh konkrete Fragen stellen: Was soll für Bürger:innen einfacher werden? Welche Arbeit soll in der Sachbearbeitung wirklich wegfallen? Welche Daten müssen nicht erneut abgefragt werden? Wer lernt nach dem Go-live aus der Nutzung weiter?

Für mich liegt darin der praktische Kern. Verwaltungsdigitalisierung muss nicht perfekt sein. Ihr Anspruch muss aber über einen digitalen Eingang für alte Abläufe hinausgehen.

Online sein ist noch kein Nutzen

Die Verwaltung hat in den letzten Jahren spürbar aufgeholt. Es gibt mehr Online-Anträge, mehr Portale, mehr digitale Zugänge und mehr technische Grundlagen. Das ist ein Fortschritt. Wer einmal gesehen hat, wie aufwendig es ist, eine Leistung über mehrere Verwaltungsebenen, beteiligte Stellen, Fachverfahren und Rechtsgrundlagen hinweg digital anzubieten, weiß: Schon digitale Verfügbarkeit ist oft kein Selbstläufer.

Für einen guten Verwaltungsdienst genügt sie trotzdem nicht.

Der eGovernment MONITOR 2025 zeigt diese Lücke ziemlich deutlich. Nur 33 Prozent der Befragten in Deutschland geben dort großes oder sehr großes Vertrauen in den Staat an. Für 51 Prozent sind mangelhafte oder fehlende digitale Angebote ein Grund, an Modernität und Leistungsfähigkeit des Staates zu zweifeln.

Besonders interessant finde ich die drei Hebel, die die Studie für mehr Zufriedenheit und Vertrauen nennt: Leistungen unkompliziert finden, digital eingereichte Anträge schneller bearbeiten und unnötige doppelte Dateneingaben vermeiden.

Die Erwartungen sind erstaunlich bodenständig. Menschen wollen finden, was sie brauchen, Angaben nicht mehrfach machen und merken, dass der digitale Weg auch die Bearbeitung beschleunigt.

Daran lässt sich der Nutzen messen. Ein Formular im Browser ist zunächst nur ein neuer Eingangskanal. Ob daraus ein guter digitaler Verwaltungsdienst wird, hängt davon ab, was davor, darin und danach passiert.

Findet jemand die richtige Leistung? Werden unnötige Fragen vermieden? Kommen Daten strukturiert dort an, wo sie gebraucht werden? Wird der Antrag schneller bearbeitet? Bekommt die antragstellende Person eine brauchbare Rückmeldung? Entsteht in der Sachbearbeitung weniger Arbeit oder nur andere Arbeit?

Bleiben diese Fragen offen, liegt das Problem nicht unbedingt in der Software. Meist wurde schlichtweg zu eng definiert, was besser werden soll.

Software kann keine ungeklärten Entscheidungen ersetzen

Eine Benutzeroberfläche kann sehr schnell so wirken, als sei ein Prozess schon verstanden.

Die Schritte sind angeordnet, Felder haben Namen, ein Upload-Bereich ist eingeplant, am Ende gibt es einen Absenden-Button. Das sieht nach Klarheit aus. In Wirklichkeit kann darunter noch sehr viel offen sein: Welche Angaben sind wirklich nötig? Welche Nachweise dürfen wegfallen? Welche Behörde prüft was? Was passiert mit dem Antrag nach dem Absenden?

Software erzeugt dann keine Klarheit. Sie macht nur sichtbar, wo sie fehlt.

Ein Pflichtfeld ist nicht einfach ein Feld. Es ist eine Entscheidung darüber, welche Information zwingend gebraucht wird. Ein Upload-Schritt entscheidet mit darüber, ob ein Nachweis wirklich erforderlich ist oder ob die Verwaltung ihn anders beschaffen könnte. Ein Status im Verfahren legt fest, welche Rückmeldung Bürger:innen bekommen und welche Fachlogik dahintersteht. Selbst ein Buttontext kann die Frage aufwerfen, ob ein Prozess aus Nutzerperspektive überhaupt verständlich gedacht wurde.

Wenn solche Entscheidungen ungeklärt bleiben, übernimmt die Software sie nicht klug. Sie bildet die Unklarheit ab: Ein kompliziertes Papierformular wird zum komplizierten Online-Formular, eine unklare Zuständigkeit zur unverständlichen Portalseite. Der interne Medienbruch lebt als PDF weiter, das digital eingereicht und analog verarbeitet wird.

Das ist aus Sicht einzelner Projekte oft nachvollziehbar. Niemand baut absichtlich schlechte Prozesse. Häufig stehen Teams unter Zeitdruck, müssen rechtliche Anforderungen erfüllen, haben begrenzten Zugang zu Fachverfahren oder arbeiten mit Vorgaben, die lange vor dem digitalen Dienst entstanden sind. In der Verwaltung kommt hinzu, dass viele Beteiligte mitreden müssen: Bund, Länder, Kommunen, Fachbereiche, IT-Dienstleister, Datenschutz, Vergabe, Betrieb. Alle haben gute Gründe für ihre Sicht.

Verwaltungsdigitalisierung braucht deshalb mehr als Umsetzungskompetenz. Die zuständigen Stellen müssen fachliche Entscheidungen treffen dürfen.

Wer darf einen Prozess vereinfachen? Wer entscheidet, ob ein Nachweis wirklich nötig ist? Wer übernimmt Verantwortung, wenn ein Formular anders fragt als das alte Papier? Wer kann sagen: Diese Daten liegen bereits vor, wir sollten sie nicht noch einmal abfragen? Wer darf nach dem Go-live Prioritäten ändern, wenn Nutzungsdaten oder Supportfälle zeigen, dass etwas nicht funktioniert?

Ohne diese Klärung landet organisatorische Unklarheit schnell in der Software. Dann sieht ein Projekt nach Fortschritt aus, obwohl die eigentliche Arbeit nur in eine Benutzeroberfläche verschoben wurde.

Alte Prozesse sind überraschend langlebig

Eine der hartnäckigsten Fehlannahmen in der Digitalisierung lautet: Wenn ein Prozess online ist, ist er modernisiert. Doch ein alter Prozess kann im Browser durchaus alt bleiben.

Man sieht das zum Beispiel an Formularen, die exakt der Logik des Papierwegs folgen: erst die persönlichen Daten, dann eine Reihe fachlicher Kategorien, dann Nachweise, dann eine Erklärung, dann Absenden. Das kann in manchen Fällen richtig sein. Häufig ist es aber nur die naheliegendste Übersetzung. Man nimmt das, was existiert, und baut es nach.

Das Problem ist nicht, dass bestehende Prozesse automatisch schlecht wären. Verwaltung arbeitet nicht ohne Grund mit Nachweisen, Fristen, klar benannten Stellen und dokumentierten Entscheidungen. Der Punkt ist ein anderer: Ein digitaler Prozess sollte nicht unbesehen übernehmen, was nur deshalb existiert, weil Papier, Aktenwege oder alte Fachverfahren es einmal erzwungen haben.

Der Digitalcheck setzt früher an. Er ist ein Prüf- und Unterstützungsansatz der Bundesregierung, mit dem neue Regelungsvorhaben auf Digitaltauglichkeit geprüft werden sollen. Vereinfacht gesagt: Schon beim Formulieren von Gesetzen und Verordnungen soll auffallen, ob ein Verfahren später durchgängig digital, verständlich und ohne unnötige Medienbrüche umgesetzt werden kann.

Wenn ein Gesetz persönliche Vorsprache, Schriftform, bestimmte Dokumente oder unnötig kleinteilige Nachweise verlangt, kann ein gutes Interface später vieles abfedern, aber nicht alles lösen. Manche digitale Hürde wird nicht im Projekt geboren, sondern im Regeltext.

Die Verantwortung beginnt damit schon vor der Softwareentwicklung. Regeln, Daten, Bearbeitungswege und Betriebsverantwortung müssen so gestaltet sein, dass eine sinnvolle digitale Umsetzung überhaupt möglich wird.

Das Onlinezugangsgesetz hat in Deutschland lange vor allem den Druck erhöht, Verwaltungsleistungen elektronisch anzubieten. Dieser Druck war wichtig. Ohne ihn wären viele Angebote vermutlich noch später entstanden. Gleichzeitig hat er eine Logik verstärkt, in der Verfügbarkeit leicht mit Wirkung verwechselt wird.

Seit der OZG-Änderung 2024 ist in § 7 OZG Nutzerfreundlichkeit ausdrücklich genannt. Bund und Länder sollen einfache und intuitive Bedienbarkeit sicherstellen; Nutzer sollen in die Entwicklung neuer elektronischer Angebote einbezogen werden. Damit wird Nutzbarkeit zum ausdrücklichen Maßstab. Online allein reicht nicht.

Die schwierigste Schnittstelle ist selten technisch

Wenn ein Digitalprojekt schwierig wird, fällt irgendwann fast immer das Wort Schnittstelle. Meist ist damit eine technische Verbindung gemeint: zwischen Onlinedienst und Fachverfahren, zwischen Portal und Nutzerkonto, zwischen Register und Antrag, zwischen Bezahldienst und Buchungssystem.

Die technischen Verbindungen verdienen Aufmerksamkeit. Die anspruchsvollste Schnittstelle verläuft in vielen Projekten jedoch zwischen Fachlichkeit und Umsetzung.

Ein Fachbereich weiß, welche Rechtsgrundlagen gelten, welche Sonderfälle kritisch sind und welche Fehler später echte Folgen haben. Die technische Seite weiß, wie Daten modelliert, Benutzeroberflächen gebaut, APIs angebunden und Systeme betrieben werden. Dazwischen liegt Übersetzungsarbeit, und dort entsteht oft Reibung.

Was meint ein Begriff im Gesetz, und was soll im Formular stehen? Welche Angabe ist fachlich zwingend, und welche ist nur historisch gewachsen? Welche Daten müssen Menschen selbst liefern, welche können übernommen werden, und welche dürfen aus Datenschutzgründen gerade nicht automatisch fließen? Was heißt „eingegangen“ im Status: technisch übertragen, formal vollständig oder fachlich prüfbar?

Was nach Detailarbeit klingt, bestimmt später, ob ein Online-Dienst entlastet oder neue Nacharbeit erzeugt.

Ich habe in Projekten oft erlebt, dass diese Übersetzungsarbeit unterschätzt wird. Man geht davon aus, dass Fachlichkeit schon irgendwie in Anforderungen landet und Anforderungen schon irgendwie in Software. In der Praxis braucht es mehr Sorgfalt. Gute Verwaltungsdigitalisierung muss Begriffe, Datenfelder, Prozessschritte, fachliche Verantwortlichkeiten und Rückmeldungen so klären, dass sie korrekt und praktisch nutzbar sind.

Offene Standards sind darum mehr als ein technisches Randthema. Sie schaffen eine gemeinsame Sprache für Daten und Schnittstellen. Mehr zu diesem Thema findet sich in meinem Beitrag Offene Standards: Die gemeinsame Sprache digitaler Verwaltung. Ohne gemeinsame Begriffe und verlässliche Datenmodelle landet die Komplexität bei den Menschen im Prozess.

Dann muss eine Sachbearbeiterin interpretieren, was ein System nicht sauber ausdrückt. Oder ein Bürger muss eine Angabe erneut machen, weil sie zwar irgendwo digital vorhanden ist, aber nicht sinnvoll weiterverarbeitet werden kann. Oder ein Antrag kommt zwar online an, muss aber manuell sortiert, geprüft und übertragen werden.

Das ist dann nicht mehr nur ein technisches Integrationsproblem. Es ist ein Qualitätsproblem des ganzen digitalen Dienstes.

Die reale Nutzung kommt oft zu spät ins Spiel

Ein Verwaltungsprozess kann intern logisch wirken und für Bürger:innen trotzdem schwer verständlich sein. Das ist kein Widerspruch. Es sind einfach unterschiedliche Perspektiven.

Die Verwaltung denkt in Leistungen, zuständigen Behörden, Rechtsgrundlagen und Nachweisen. Bürger:innen denken in Lebenssituationen: Ich bin umgezogen. Mein Kind wurde geboren. Ich brauche eine Genehmigung. Ich habe einen Bescheid bekommen. Ich muss etwas nachweisen. In dieser Situation ist es wenig hilfreich, wenn ein Portal formal korrekt, aber aus Nutzersicht schwer auffindbar oder unverständlich ist.

Nutzerzentrierung bringt diese Perspektiven früh zusammen. Bürger:innen sollen dabei nicht jede konkrete Lösung vorgeben. Entscheidend ist, echte Nutzungssituationen zu verstehen und die Lösung daran zu prüfen: Finden Menschen den richtigen Einstieg? Verstehen sie die Fragen? Können sie Fehler korrigieren? Entlastet der digitale Weg auch die Sachbearbeitung?

Die DIN SPEC 66336 zum Servicestandard beschreibt Qualitätsanforderungen für Onlineservices und Portale der öffentlichen Verwaltung. Sie betrachtet den Lebenszyklus eines digitalen Produkts über die Gestaltung hinaus: Nutzendenanalyse, Bedarfs- und Prozessanalyse, Rollen und Verantwortung, offene Standards, Datenschutz, Sicherheit, Betrieb, Support, Evaluation und Weiterentwicklung.

Für die Arbeit im Projekt heißt das: Gute Verwaltungsdigitalisierung braucht Kontakt mit realen Nutzungssituationen, solange noch etwas veränderbar ist.

Ein Nutzendentest am Ende ist besser als gar keiner. Aber wenn die zentralen Entscheidungen dann schon gefallen sind, wird er schnell zur Dekoration. Dann darf vielleicht noch ein Hilfetext angepasst werden, aber die unverständliche Prozesslogik bleibt. Die Reihenfolge der Schritte bleibt. Die Nachweispflicht bleibt. Die fehlende Statusmeldung bleibt. Das Projekt hat dann zwar Feedback eingesammelt, aber nicht wirklich daraus gelernt.

Der Beitrag Nutzerzentrierung beginnt mit Misstrauen gegenüber der eigenen Idee vertieft diesen Punkt: Gute Ideen müssen an echter Nutzung geprüft werden, bevor sie sich zu richtig anfühlen. Für Verwaltungsleistungen gilt das besonders, weil Menschen sich den Anbieter nicht aussuchen können. Wenn ein staatlicher Dienst schlecht nutzbar ist, entsteht nicht nur Frust über eine Website. Es entsteht Frust über die Verwaltung selbst.

Die ID-Wallet ist dafür ein gutes Beispiel, aber nicht nur als Panne. Die App sollte 2021 digitale Nachweise wie den digitalen Führerschein auf dem Smartphone nutzbar machen. Kurz nach dem Start wurde sie nach Sicherheitskritik, technischen Problemen und Lastspitzen wieder aus den App-Stores genommen. Gleichzeitig zeigte der Start, wie groß der Bedarf nach digitalen Identitäten ist. Laut damaliger Einordnung griffen deutlich mehr Menschen auf das System zu als erwartet. Nicht der Bedarf war das Problem, sondern das fehlende Zusammenspiel von technischer Reife, Sicherheit, Vertrauen und Produktrealität.

Das ist eine unbequeme Lehre: Eine grundsätzlich richtige strategische Ausrichtung kann trotzdem falsch umgesetzt werden. Gerade bei zentralen digitalen Infrastrukturen reicht es nicht, etwas öffentlichkeitswirksam live zu setzen. Eine solche Infrastruktur muss belastbar genug sein, um Vertrauen zu verdienen.

Gute Beispiele wirken oft weniger spektakulär

Wenn über digitale Verwaltung gesprochen wird, landen oft dieselben Beispiele auf dem Tisch: Estland, Dänemark und manchmal auch einzelne deutsche Dienste wie ElterngeldDigital.

Ich finde diese Beispiele hilfreich, solange man sie nicht als einfache Blaupause behandelt. Dänemark ist dabei kein zufälliger Name: Im UN E-Government Survey 2024 lag das Land nach Angaben der dänischen Digitalisierungsagentur zum vierten Mal in Folge an der Spitze. Der Blick sollte aber nicht beim Ranking oder der übersichtlichen Oberfläche von borger.dk stehen bleiben.

Hinter solchen Angeboten stecken über Jahre gewachsene Entscheidungen: digitale Identität, Register, gemeinsame Infrastruktur, klare Portale, rechtliche Grundlagen, Wiederverwendung, Betrieb und eine andere Erwartung daran, wie Verwaltung digital funktioniert.

Man kann das nicht einfach nach Deutschland kopieren. Deutschland ist föderal, groß, historisch anders gewachsen und organisatorisch komplexer. Diese Unterschiede sind real. Sie dürfen aber auch nicht zur Ausrede werden.

Von solchen Beispielen lässt sich weniger die konkrete Oberfläche als die Denkrichtung übernehmen. Gute digitale Verwaltung orientiert sich an den Situationen der Menschen statt nur an internen Behördenstrukturen. Sie nutzt vorhandene Daten sinnvoll, denkt den Prozess bis zur Entscheidung, Rückmeldung oder Leistung und behandelt digitale Dienste als dauerhaft gepflegte Produkte.

Auch in Deutschland gibt es dafür Ansätze. ElterngeldDigital ist nicht deshalb interessant, weil dort jedes Problem gelöst wäre. Interessant ist die Grundhaltung: eine komplexe Lebenssituation digital zugänglicher machen, Informationen verständlicher aufbereiten und den Antrag nicht nur als PDF-Ersatz denken. Solche Dienste zeigen, dass gute Verwaltungsdigitalisierung möglich ist, wenn Fachlichkeit, Nutzerführung und Umsetzung enger zusammenarbeiten.

Man sollte daraus keine Erfolgsgeschichte mit Schleife machen. Jeder Dienst hat Grenzen. Gute Beispiele sind selten perfekt, aber lernfähig.

Der Go-live ist der erste Realitätskontakt

Viele Digitalprojekte richten ihre Energie auf den Go-live. Das ist verständlich. Der Starttermin ist sichtbar, politisch relevant, vertraglich wichtig und organisatorisch oft hart erkämpft. Irgendwann soll das Ding raus.

Nur ist der Go-live nicht der Moment, in dem Digitalisierung fertig ist. Er ist der Moment, in dem sie zum ersten Mal wirklich mit dem Alltag kollidiert.

Dann zeigt sich der Alltag: Fragen landen beim Support, Nachweise werden missverstanden, Menschen brechen den Vorgang ab. Fälle passen nicht ins Standardmuster, Daten fehlen im Fachverfahren und manche Dokumente passen nicht zur digitalen Kommunikation. Einige Mitarbeiter:innen haben plötzlich mehr statt weniger Arbeit.

In einer klassischen Projektlogik wirken solche Beobachtungen schnell wie Mängel oder Störungen. In einer guten Produktlogik bestimmen sie die nächsten Prioritäten.

Das ist für die Verwaltung besonders wichtig, weil digitale Leistungen lange leben. Rechtsgrundlagen und Fachverfahren ändern sich, Sicherheitsanforderungen steigen. Bürger:innen gewöhnen sich an bessere digitale Dienste und erwarten mehr. Mitarbeitende entwickeln Workarounds, wenn ein System nicht zum Alltag passt. Ohne laufende Verantwortung kommt ein digitaler Dienst schnell in die Jahre.

Der Servicestandard benennt Betrieb, Support, Evaluation und Weiterentwicklung nicht zufällig als Qualitätsanforderungen. Dort entscheidet sich, ob ein Dienst dauerhaft trägt. Ein Wartungskontingent und ein Ticketsystem reichen nach dem Start nicht aus. Es braucht Menschen, die fachlich und technisch verantwortlich bleiben, Nutzungsdaten anschauen, Supportmuster ernst nehmen, Prioritäten setzen und Veränderungen beauftragen können.

Das ist einer der Gründe, warum ich Verwaltungsdigitalisierung eher als Produktarbeit verstehe als als reine Projektabwicklung. Ein Projekt kann liefern. Ein Produkt jedoch muss wirken.

Mein weiterführender Artikel Agile Entwicklung für Behördenprojekte: Wenn Verwaltung lernen darf greift diese Logik aus Sicht der Arbeitsweise auf: Agile Arbeit in der Verwaltung bedeutet nicht, Regeln zu ignorieren. Sie bedeutet, neue Erkenntnisse geordnet in die weitere Arbeit einfließen zu lassen.

Außerhalb der Verwaltung sieht man übrigens ein ähnliches Muster. Die Boston Consulting Group hat in einer Untersuchung zu digitaler Transformation beschrieben, dass nur etwa 30 Prozent der untersuchten Transformationen ihre Ziele erreichten und nachhaltige Veränderung erzeugten. Erfolgreicher wurden Vorhaben dort, wo Strategie, Führung, gute Teams, agile Steuerung, Fortschrittsmessung sowie Technik- und Datenbasis zusammenkamen. Das ist keine Verwaltungsstudie, weist aber in dieselbe Richtung: Nachhaltige Veränderung braucht das Zusammenspiel von Organisation, Technik und Lernen.

Digitalisierung muss für beide Seiten entlasten

Ein digitaler Verwaltungsdienst hat mindestens zwei Nutzergruppen: die Menschen, die eine Leistung beantragen oder Informationen brauchen, und die Menschen, die den Vorgang bearbeiten. Wenn nur eine Seite betrachtet wird, entsteht schnell eine Schieflage.

Ein Online-Antrag kann für Bürger:innen komfortabler sein und gleichzeitig in der Sachbearbeitung mehr Aufwand erzeugen, wenn Daten unstrukturiert ankommen, Nachweise falsch benannt sind oder Rückfragen nicht sauber im System landen. Umgekehrt kann ein Fachverfahren intern effizient sein und Bürger:innen trotzdem mit schwer verständlichen Fragen, unklaren Statusmeldungen oder unnötigen Wiederholungen belasten.

Gute Verwaltungsdigitalisierung muss beides sehen.

In Projekten konkurriert dieser Anspruch mit knapper Zeit und unterschiedlichen Bedürfnissen. Bürger:innen sind oft nur punktuell erreichbar, Sachbearbeiter:innen haben wenig Zeit, Fachbereiche stehen unter Druck und IT-Dienstleister brauchen klare Anforderungen. Dazwischen soll ein Prozess entstehen, der rechtlich korrekt, technisch stabil, barrierefrei, sicher, verständlich und betreibbar ist.

Gerade deshalb helfen konkrete Nutzungssituationen mehr als abstrakte Diskussionen über Modernisierung. Eine alleinerziehende Mutter, die abends am Smartphone einen Antrag ausfüllt. Ein Unternehmer, der nicht weiß, welche Erlaubnis für seinen Fall gilt. Eine Sachbearbeiterin, die täglich zehn digitale Anträge öffnen muss, aber jedes Mal dieselben Angaben ins Fachverfahren überträgt. Ein Mensch mit Screenreader, der an einem nicht sauber beschrifteten Uploadfeld scheitert.

Solche Situationen erden die Diskussion. Sie machen sichtbar, ob Digitalisierung wirklich Arbeit reduziert oder nur verlagert.

Ich würde den Erfolg eines digitalen Verwaltungsdienstes deshalb nicht zuerst daran messen, ob er modern aussieht. Ich würde fragen:

• Werden Bürger:innen sicherer durch den Vorgang geführt?
• Fallen Rückfragen, Nachforderungen oder doppelte Eingaben weg?
• Kommen Daten strukturiert und verständlich in der Sachbearbeitung an?
• Wird der Status des Verfahrens nachvollziehbarer?
• Können Menschen den Dienst auch mit Einschränkungen, auf kleinen Bildschirmen oder unter Zeitdruck nutzen?
• Gibt es nach dem Start jemanden, der Verbesserungen fachlich priorisieren und beauftragen darf?

Diese Fragen verschieben den Maßstab von sichtbarer Modernisierung zu spürbarer Entlastung im Alltag.

Was Projekte konkret anders machen können

Aus den wiederkehrenden Problemen ergeben sich für mich sechs praktische Konsequenzen.

1. Nicht mit der Benutzeroberfläche beginnen. Sie ist wichtig, aber sie darf nicht die erste und einzige Verständigung über den Prozess sein. Vorher müssen Problem, Nutzergruppen, Ist-Prozess, Soll-Prozess, Daten, Nachweise, beteiligte Stellen und Betriebsverantwortung sauber genug verstanden sein.

2. Alte Anforderungen nicht automatisch übernehmen. Wenn ein Papierprozess eine bestimmte Angabe verlangt, heißt das noch nicht, dass sie im digitalen Prozess genauso abgefragt werden muss. Manche Fragen bleiben nötig. Andere sind Gewohnheit. Wieder andere lassen sich durch vorhandene Daten, bessere Vorprüfung oder klarere Prozesslogik vermeiden.

3. Fachlichkeit und Technik früh zusammenbringen. Die Fachseite muss zwischen Anforderungsübergabe und Abnahme beteiligt bleiben. Die technische Seite braucht mehr als eine Liste von Feldern. Gute Lösungen entstehen dort, wo beide Seiten gemeinsam verstehen, welche Wirkung ein Prozess haben soll.

4. Nutzer:innen und Sachbearbeiter:innen nicht erst am Ende fragen. Ein früher Prototyp, der an einer unklaren Frage scheitert, spart später viel Arbeit. Ein Test mit Sachbearbeiter:innen kann zeigen, ob ein digitaler Antrag intern wirklich entlastet. Das ist kein Luxus, sondern Risikoreduzierung.

5. Den Go-live nicht als Ende planen. Ein digitaler Dienst braucht von Anfang an Budget und Verantwortung für Betrieb, Support, Messung und Weiterentwicklung. Sonst entstehen Angebote, die schnell veralten oder nie ihre eigentliche Wirkung entfalten.

6. Souveränität und Offenheit mitdenken. Datenexporte, offene Standards, nachvollziehbare Schnittstellen und dokumentierte Architektur sind keine Nebensachen. Sie entscheiden darüber, ob ein Dienst später angepasst, integriert oder weiterentwickelt werden kann. Digitale Souveränität ist eine Frage der Optionen beschreibt denselben Punkt aus Infrastrukturperspektive: Handlungsfähig bleibt, wer nicht jede spätere Entscheidung verbaut.

In der Summe geht es um saubere Produktarbeit, die vor dem Go-live beginnt und danach weitergeht.

Weniger Versprechen, mehr Wirkung

Ich bin vorsichtig geworden mit großen Digitalisierungsversprechen. Das ist kein Pessimismus. Digitale Verwaltung kann enorm viel verbessern: Wartezeiten und doppelte Angaben reduzieren, Leistungen besser auffindbar machen, Rückmeldungen beschleunigen, manuelle Übertragung vermeiden und Barrierefreiheit sowie Transparenz erhöhen.

Aber diese Wirkung entsteht nicht automatisch, nur weil eine Leistung online steht.

Verwaltungsdigitalisierung verfehlt ihr Versprechen, wenn alte Probleme lediglich in neue Software umziehen: Fachliche Verantwortung bleibt ungeklärt, Technik und Fachlichkeit finden nicht zusammen, Bürger:innen und Sachbearbeiter:innen werden zu spät einbezogen. Nach dem Go-live fühlt sich niemand mehr wirklich zuständig.

Sie wird besser, wenn sie als dauerhafte Arbeit an einem öffentlichen Dienst verstanden wird und nicht als einmalige Lieferung. Das ist mühsamer, aber ehrlicher. Diese Arbeit zwingt dazu, Wirkung zu definieren, Annahmen zu prüfen, Betrieb mitzudenken und aus Nutzung zu lernen.

Gute Verwaltungsdigitalisierung ist deshalb oft weniger spektakulär, als wir hoffen. Sie zeigt sich darin, dass jemand eine Leistung schneller findet, ein Formular eine schwierige Frage verständlich macht, eine Sachbearbeiterin weniger nachtragen muss oder ein Status Klarheit schafft. Und darin, dass ein Dienst auch nach zwei Jahren noch gepflegt wird.

Das sind keine Nebensachen. An ihnen merken Menschen, ob der Staat digital nur präsent ist oder tatsächlich besser funktioniert.

Ich meine mit Agilität hier kein festes Methodenpaket. Agile Entwicklung heißt in diesem Kontext: eine digitale Lösung in überschaubaren Schritten bauen, Annahmen früh prüfen und Erkenntnisse einarbeiten, solange Änderungen noch möglich sind. Nicht erst am Ende, wenn der Dienst eigentlich fertig sein soll.

Gerade in der Verwaltung ist das anspruchsvoll. Ein Antrag soll nicht heute so und morgen anders bearbeitet werden. Entscheidungen müssen begründbar sein, Verfahren prüfbar, Zuständigkeiten klar. Verwaltung braucht Stabilität. Gleichzeitig entstehen digitale Verwaltungsleistungen fast immer unter Unsicherheit: Wie läuft der Prozess wirklich? Welche Daten liegen bereits vor? Welche Sonderfälle sind relevant? Was entlastet Bürger:innen und Sachbearbeiter:innen tatsächlich?

Der Denkfehler beginnt dort, wo Stabilität und Lernfähigkeit gegeneinander ausgespielt werden. Gute agile Arbeit stellt nicht alles zur Disposition. Sie klärt, was feststehen muss und wo ein Projekt lernen darf: Ziele, Zuständigkeiten, rechtliche Anforderungen und Entscheidungswege brauchen Verlässlichkeit. Die konkrete Lösung muss sich an der Wirklichkeit messen lassen.

Das ist nüchterner als die üblichen Agilitätsversprechen und genau deshalb für Behördenprojekte belastbarer. Ein paar Rituale aus der Softwarewelt machen Verwaltung noch nicht lernfähig. Dafür muss sie neue Erkenntnisse aufnehmen dürfen und weiterhin nachvollziehbar entscheiden.

Agil heißt nicht, Regeln zu ignorieren

Ein häufiger Einwand gegen agile Entwicklung in Behördenprojekten ist schnell erzählt: Verwaltung könne das nicht. Zu viele Regeln, zu viele Zuständigkeiten, zu viel Dokumentation, zu wenig Spielraum.

Ich finde diesen Einwand nicht falsch. Er ist nur unvollständig.

Eine Behörde kann nicht so arbeiten wie ein kleines Produktteam in einem Start-up. Sie ist an Haushaltsrecht, Vergaberecht, Datenschutz, Barrierefreiheit, Aktenführung, politische Beschlüsse und Fachgesetze gebunden. Diese Bindungen sind kein Betriebsunfall, sondern Teil ihrer Aufgabe. Verwaltung darf nicht nach Gefühl entscheiden. Sie muss nachvollziehbar, gerecht und prüfbar handeln.

Agilität wird dort problematisch, wo sie so tut, als seien diese Anforderungen nur störende Altlasten. Dann entsteht das schlechte Bild, das viele Menschen in Verwaltungen völlig zu Recht skeptisch macht: bunte Klebezettel, neue Begriffe, aber am Ende mehr Abstimmungsaufwand und weniger Klarheit.

Gute agile Arbeit in Behördenprojekten schafft früher Ordnung. Ein Projektteam hält Annahmen fest, macht offene Punkte sichtbar und prüft regelmäßig, ob die Lösung noch zum Problem passt. Ein gut gepflegtes Backlog ist keine wilde Wunschliste, sondern ein Arbeitsinstrument, mit dem fachliche, technische und organisatorische Entscheidungen nachvollziehbar werden.

Der Perspektivwechsel liegt in einer anderen Art von Verbindlichkeit. Ein Projekt behauptet nicht, heute schon alles zu wissen. Verbindlich sind das gemeinsame Problemverständnis, die Entscheidungswege und der Umgang mit neuen Erkenntnissen.

Lernen muss Folgen haben

Damit dieses Lernen mehr ist als ein gutes Gefühl, muss es Folgen haben dürfen. Zeigt ein Nutzendentest, dass ein Nachweis regelmäßig fehlt oder ein Begriff missverstanden wird, darf die Erkenntnis nicht bei einem Ticket mit niedriger Priorität enden. Reviews und Retrospektiven sind nur hilfreich, wenn daraus Entscheidungen entstehen.

Die entscheidende Frage ist: Darf das Projekt während der Umsetzung klüger werden? Wenn die Antwort nein lautet, helfen auch Sprints, Boards und Backlogs nur begrenzt.

In echten Verwaltungsprojekten liegen viele Risiken nicht in der Programmierung selbst. Sie liegen in Annahmen über den Ablauf: Wer darf entscheiden? Welche Daten liegen schon vor? Welcher Nachweis ist wirklich nötig? Was passiert mit Fällen, die nicht ins Standardmuster passen? Typisch sind Nachweise, die in der Leistungsbeschreibung selbstverständlich wirken, aber im Alltag schwer auffindbar sind: eine alte Bescheidkopie, ein bestimmtes Aktenzeichen, eine Vollmacht oder die richtige Arbeitgeberbescheinigung. Solche Fragen lassen sich vorbereiten, aber selten vollständig am Anfang beantworten. Manche Dinge versteht man erst, wenn Menschen mit einem Prototyp arbeiten oder Testdaten durch einen Prozess laufen.

Das ist kein Versagen der Planung. Es ist der Regelfall komplexer Softwareentwicklung. Mehr Vorab-Dokumentation beseitigt diese Unsicherheit nicht; sie verschiebt sie nur in ein sauber formatiertes Dokument.

Digitale Verwaltungsleistungen sind keine abgeschlossenen Projekte

Ein ähnliches Problem entsteht, wenn digitale Verwaltungsleistungen wie Projekte organisiert werden, obwohl sie eigentlich Produkte sind.

Ein Projekt hat ein Startdatum, ein Budget, einen Umfang und irgendwann eine Abnahme. Ein Online-Dienst passt schlecht in diese Logik. Er lebt weiter. Rechtsgrundlagen und Schnittstellen ändern sich, Nutzer:innen melden Probleme, Sicherheitsanforderungen steigen. Manchmal stellt sich erst nach dem Go-live heraus, dass eine Funktion zwar formal korrekt ist, aber im Alltag nicht gut genug funktioniert.

Der Produktmanagement-Ansatz der FITKO beschreibt IT-Planungsratsprodukte ausdrücklich als dauerhafte Lösungen für konkrete Probleme, nützlich für Bürger:innen, Verwaltungsmitarbeitende, Unternehmen und andere staatliche Stellen. Damit verschiebt sich der Blick von der Lieferung zur dauerhaften Verantwortung für eine Lösung.

Dort liegt in der Praxis oft der Engpass. Nach dem ersten Release gibt es vielleicht noch ein Restbudget, ein Wartungskontingent und ein Ticketsystem. Aber wer beobachtet, ob der Dienst tatsächlich genutzt wird? Wer priorisiert Verbesserungen? Wer entscheidet, ob ein umständlicher Nachweisschritt vereinfacht werden kann?

Wenn dafür niemand zuständig ist, entsteht schnell eine digitale Fassade. Vorne sieht es modern aus, hinten bleibt der alte Alltag: Ausdrucke, manuelle Nachfragen, Excel-Listen, E-Mails mit Anhängen, Sonderfälle auf Zuruf.

Agile Entwicklung hilft nur, wenn Menschen das Produkt fachlich und technisch steuern dürfen. Ohne diese Verantwortung ist ein Backlog bloß eine sortierte Warteliste. Ein Release bleibt dabei ein Zwischenstand, kein Schlusspunkt.

Nutzerzentrierung ist kein Bauchgefühl

Damit Produktverantwortung nicht abstrakt bleibt, braucht sie Kontakt zum Alltag. Nutzerzentrierung heißt dabei nicht, dass Bürger:innen oder Sachbearbeiter:innen sich einfach wünschen dürfen, was gebaut wird. Fachrecht, Datenschutz und Haushaltslogik bleiben relevant. Aber man muss genau hinschauen, an welcher Stelle Menschen hängen bleiben: beim Begriff, beim Nachweis, beim Login, bei einer Frist oder bei einer Frage, die nur aus Verwaltungssicht eindeutig ist.

Das beginnt selten beim hübscheren Formular. Wenn Bürger:innen in einem Online-Antrag regelmäßig an derselben Stelle abbrechen, kann das an schlechtem Design liegen. Es kann aber auch bedeuten, dass ein Begriff aus dem Fachrecht unverständlich ist, dass ein Nachweis nicht verfügbar ist oder dass der Prozess eine Lebenssituation falsch voraussetzt. Wenn Sachbearbeiter:innen eingehende Anträge ständig nachbearbeiten müssen, ist das nicht nur ein internes Komfortproblem. Es sagt etwas darüber aus, ob der digitale Dienst seine Arbeit macht.

Das OZG formuliert in § 7 mittlerweile klar, dass Nutzerfreundlichkeit und einfache Bedienbarkeit sicherzustellen sind und Nutzende in die Entwicklung neuer elektronischer Angebote einbezogen werden sollen.

Auch der Servicestandard und die zugrunde liegende DIN SPEC 66336 gehen weiter als ein Methodenhinweis. Seit Oktober 2025 verweist auch die OZSV in § 2 bei Qualitätsanforderungen an neue oder grundlegend überarbeitete Systeme auf diese DIN SPEC.

Für die Praxis folgt daraus: Komplexe Onlineservices brauchen früh Kontakt zur Realität. Ein Nutzendentest ist ein fachlicher Realitätsabgleich. Verstehen Menschen, was sie tun müssen? Kommen sie an die nötigen Informationen? Entlastet der Dienst auch die Verwaltung oder verschiebt er nur Arbeit von einem Schreibtisch auf einen anderen?

Der eGovernment MONITOR 2025 zeigt, dass viele Menschen Behördenkontakte weiterhin als anstrengend erleben und digitale Angebote oft nicht die erwartete Entlastung bringen. Das deckt sich mit dem, was man in Projekten immer wieder sieht: Online verfügbar ist nicht automatisch gut digitalisiert.

Beschaffung muss Unsicherheit aushalten

An dieser Stelle kommt die Beschaffung ins Spiel. Und ja, sie macht agile Behördenprojekte anspruchsvoller.

Öffentliche Auftraggeber müssen Leistungen beschreiben, Angebote vergleichbar machen, Vergaben dokumentieren und Entscheidungen prüffest treffen. Schwierig wird es, wenn daraus der Anspruch entsteht, ein komplexes Softwareprodukt vor der Umsetzung vollständig zu kennen.

Dann entstehen umfangreiche Leistungsbeschreibungen, die an entscheidenden Stellen trotzdem vage bleiben. Man beschreibt Funktionen, bevor das Problem verstanden ist. Beide Seiten bekommen einen Vertrag, der Sicherheit verspricht und Veränderung teuer macht.

Agile Beschaffung heißt nicht, ohne Ziel einzukaufen. Beschrieben werden müssen Ziel, Zusammenarbeit und Entscheidungslogik. Nicht jede fachliche Erkenntnis kann schon im Vergabetext stehen.

Dafür gibt es in der öffentlichen IT-Beschaffung Anknüpfungspunkte. Die UfAB ist als Praxisleitfaden für IT-Beschaffungen darauf ausgelegt, Ausschreibungen strukturiert, nachvollziehbar und bedarfsgerecht vorzubereiten. Bei IT-Verträgen bieten die EVB-IT standardisierte Muster. Die 2026 überarbeiteten EVB-IT-Muster berücksichtigen Open Source deutlich stärker und erleichtern neue Softwareprojekte, die nachnutzbar veröffentlicht werden können, etwa über openCode.

Standardisierte Muster ersetzen kein Produktmanagement. Zugleich ist der Rechts- und Beschaffungsrahmen nicht automatisch die größte Hürde. Häufig liegt das Problem darin, dass Fachbereich, Vergabestelle, IT, Datenschutz, Betrieb und externe Umsetzung zu spät über die Art der Zusammenarbeit sprechen.

Ich würde deshalb früher über Arbeitsweise sprechen als über Features: Wer darf priorisieren? Wann wird eine Erkenntnis verbindlich? Wer sagt Nein, wenn ein alter Prozess nur digital nachgebaut wird? Und wie bleiben Datenschutz, Barrierefreiheit und IT-Sicherheit laufend beteiligt?

Weil diese Absprachen Verantwortung sichtbar machen, werden sie leicht vertagt.

Nach dem Go-live zählt der Alltag

Viele Projekte investieren viel Energie in die Zeit vor dem öffentlichen Start. Verständlich. Der Go-live ist sichtbar, politisch relevant und organisatorisch aufgeladen. Danach soll endlich Ruhe einkehren. Nur ist digitale Verwaltung selten ruhig.

Im Betrieb sieht man, wie ein Dienst wirklich funktioniert. Welche Fragen landen beim Support? Wo brechen Menschen den Vorgang ab? Welche Angaben werden falsch verstanden? Wo entstehen neue Belastungen in der Sachbearbeitung?

In klassischen Projektlogiken wirken solche Erkenntnisse schnell wie Mängel. In einer produktorientierten Logik liefern sie die Grundlage für die nächste Verbesserung. Nicht angenehm, aber wertvoll.

Für Sachbearbeiter:innen ist das besonders wichtig. Wenn ein Online-Dienst nur den Eingang digitalisiert, aber die interne Bearbeitung komplizierter macht, ist wenig gewonnen. Dann entstehen neue Rückfragen, Medienbrüche und Workarounds. Und diese Workarounds sind oft unangenehm langlebig.

Agile Entwicklung muss deshalb beide Seiten ernst nehmen: die Menschen, die eine Leistung beantragen, und die Menschen, die sie bearbeiten. Ein guter Verwaltungsdienst endet nicht beim Formular im Browser. Er verbindet Rechtsgrundlage, Prozess, Daten, Fachverfahren, Kommunikation und Betrieb.

Hier wird Agilität konkret: Probleme früh erkennen und klären, wer daraus welche Entscheidung ableiten muss.

Wenn Verwaltung lernen darf

Agile Entwicklung hilft Behördenprojekten, wenn sie Verantwortung sichtbar macht. Ein Methodenset, das nur über die alte Projektlogik gelegt wird, genügt dafür nicht, und schwierige Entscheidungen verschwinden dadurch ebenfalls nicht. Wer Agilität als Garantie für schnellere, günstigere und unkompliziertere Projekte verkauft, verspricht zu viel.

Agile Entwicklung in der Verwaltung braucht klare Zuständigkeiten, saubere Dokumentation und Respekt vor rechtlichen Anforderungen. Die Beschaffung muss die Zusammenarbeit verlässlich rahmen, ohne jedes Detail vorzugeben. Hinzu kommen Produktverantwortung über den Go-live hinaus, echte Tests mit Bürger:innen und Verwaltungsmitarbeitenden sowie die Bereitschaft, Erkenntnisse nicht als Störung zu behandeln.

Kulturell ist das vermutlich der schwierigste Punkt. Verwaltung ist darauf trainiert, Fehler zu vermeiden. Agile Arbeit macht falsche Annahmen früher sichtbar. Ihre Korrektur kann unangenehm sein, ist an einem Prototyp aber deutlich günstiger als nach zwei Jahren Umsetzung, wenn Verträge, Erwartungen und politische Kommunikation schon festgefahren sind.

Für mich liegt darin der Wert agiler Entwicklung: Sie hilft Behördenprojekten, Annahmen zu prüfen, Erkenntnisse aufzunehmen und Verantwortung für die nächste Entscheidung zu übernehmen, obwohl sich nicht alles im Voraus planen lässt.

Am Anfang geht es um Funktionen, Fristen, Schnittstellen, Datenschutz, Budget, vielleicht noch um den Betrieb. Alles berechtigt. Die Möglichkeit eines späteren Wechsels läuft eher unter ferner liefen. Irgendwann wird sie konkret: Kann die Organisation den Anbieter wechseln? Kommt sie sauber an ihre Daten? Versteht sie die eigene Betriebsumgebung noch? Könnte ein anderer Dienstleister übernehmen, ohne erst monatelang Detektivarbeit leisten zu müssen?

Ich habe gerade in der Arbeit mit Verwaltungen erlebt, dass solche Fragen schnell wie Luxus wirken. Man will ja erst einmal etwas ans Laufen bekommen. Den Druck kenne ich gut: Anforderungen sind hoch, Ressourcen knapp, Erwartungen von außen oft ungeduldig. Was kurzfristig nach Zusatzaufwand aussieht, entscheidet jedoch mit darüber, ob Digitalisierung langfristig entlastet oder eine neue Form von Abhängigkeit schafft.

Der Begriff digitale Souveränität ist inzwischen so aufgeladen, dass er manchmal mehr verdeckt als erklärt. Für mich wird er brauchbar, wenn man ihn als praktische Fähigkeit versteht: Eine Organisation muss auch dann noch handlungsfähig bleiben, wenn sich Preise, Anbieter, Gesetze, Sicherheitsanforderungen oder eigene Ziele ändern.

Souveränität ist nicht dasselbe wie Eigenbetrieb

Digitale Souveränität verlangt nicht, dass jede Kommune, jedes Ministerium oder jedes Unternehmen seine komplette Infrastruktur selbst betreibt. Das wäre in vielen Fällen weder wirtschaftlich noch fachlich sinnvoll. Eine schlecht dokumentierte Serverlandschaft im eigenen Keller kann genauso abhängig machen wie eine proprietäre Cloud-Plattform.

Auch eine Cloud ist nicht automatisch das Problem. Managed Services können Sicherheit erhöhen, den Betrieb professionalisieren und Teams entlasten. Für Teams, die nicht selbst rund um die Uhr Infrastruktur betreiben können, ist das ein realer Vorteil.

Wichtiger als vollständiger Besitz ist die Frage, ob eine Organisation noch steuern kann. Kann sie technische und vertragliche Zusagen prüfen, Daten in brauchbaren Formaten herausbekommen und Komponenten austauschen? Weiß sie, welche Teile sie bewusst auslagert und welche Verantwortung trotzdem bei ihr bleibt?

Der nüchterne Maßstab dafür ist Steuerbarkeit, nicht maximale Autarkie.

Was unter der Oberfläche lange nachwirkt

Viele Digitalprojekte werden zuerst über ihre sichtbaren Oberflächen beurteilt. Kommen Menschen ans Ziel? Ist der Prozess verständlich? Funktioniert der Dienst im Alltag?

Doch die Entscheidungen unterhalb der Oberfläche wirken länger nach: Identitätsmanagement, Datenhaltung, Schnittstellen, Protokollierung, Deployment, Monitoring, Backups, Rechtekonzepte, Schlüsselverwaltung, Mandantenfähigkeit und Exportformate.

Auf dieser Ebene entsteht später Beweglichkeit oder geht verloren. Ist ein zentrales System über dokumentierte Schnittstellen angebunden, lässt sich eher etwas austauschen. Sind Geschäftslogik, Datenhaltung und Benutzerverwaltung eng an eine bestimmte Umgebung gekettet, wird jede Veränderung teuer. Dann kann eine Organisation theoretisch kündigen, praktisch aber kaum wechseln.

Ein zentrales System verschwindet nicht nach zwei Jahren, nur weil sich die Produktstrategie eines Anbieters geändert hat. Es muss neue Anforderungen aushalten, mit anderen Systemen sprechen, Sicherheits- und Nachweispflichten erfüllen, Supportfälle überstehen und manchmal schlicht zehn Jahre zuverlässig funktionieren.

Infrastruktur ist deshalb mehr als technischer Unterbau. Sie ist ein strategischer Teil des Produkts.

Abhängigkeiten wachsen aus plausiblen Entscheidungen

Die gefährlichsten Abhängigkeiten gehen selten auf eine einzelne schlechte Entscheidung zurück. Meist wachsen sie aus vielen nachvollziehbaren Schritten, die im jeweiligen Moment vernünftig wirken.

Eine proprietäre Schnittstelle, weil sie schneller verfügbar ist. Ein spezieller Cloud-Dienst, weil er ein Problem elegant löst. Ein Datenexport, der für die Abnahme reicht, aber nicht für eine echte Migration. Eine Betriebsdokumentation, die im Projektendspurt liegen bleibt. Ein Vertrag, der Service-Level sauber regelt, aber keinen realistischen Exit. Eine Anpassung, die nur ein Dienstleister wirklich versteht.

Jeder einzelne Punkt lässt sich erklären. In der Summe entsteht ein System, das kaum noch veränderbar ist. Niemand muss eine Organisation absichtlich einschließen. Es genügt, wenn jede Bewegung zu teuer, zu riskant oder zu unklar geworden ist.

Abhängigkeit kündigt sich im Alltag selten dramatisch an. Oft beginnt sie mit Komfort, Geschwindigkeit und „das machen wir erst einmal pragmatisch“. Ob daraus eine Übergangslösung oder eine Sackgasse wird, zeigt sich erst später.

Recht, Betrieb und Vertrag gehören zusammen

Infrastrukturfragen lassen sich nicht mehr auf Serverstandort, Zertifizierung und Backups reduzieren. Der Rechtsraum eines Anbieters, seine Muttergesellschaft, Unterauftragnehmer, Administrationszugriffe und Supportwege gehören heute ebenfalls zur Architektur.

Der US-amerikanische CLOUD Act ist dafür ein bekanntes Beispiel: Er kann Anbieter elektronischer Kommunikations- und Cloud-Dienste verpflichten, Daten offenzulegen, die unter ihrer Kontrolle stehen, auch wenn diese Daten außerhalb der Vereinigten Staaten gespeichert sind. Daraus folgt kein automatischer und ungeprüfter Zugriff ausländischer Behörden auf jede Cloud-Instanz. Der physische Standort eines Rechenzentrums ist aber auch keine ausreichende Antwort mehr.

Auch die europäische Ebene bewegt sich in diese Richtung. Der Data Act der Europäischen Union, der seit dem 12. September 2025 gilt, stärkt unter anderem den Wechsel zwischen Cloud-Anbietern und den Zugang zu Daten. Die Europäische Kommission bewertet Cloud-Souveränität inzwischen anhand konkreter Ziele wie rechtlicher Kontrolle, Betrieb, Lieferkette, technologischer Offenheit, Sicherheit und Einhaltung europäischen Rechts. Das zeigt sich etwa am Cloud Sovereignty Framework für Institutionen der Europäischen Union.

In Deutschland verfolgen Initiativen wie der Deutschland-Stack und das ZenDiS, das Zentrum für Digitale Souveränität der öffentlichen Verwaltung, eine ähnliche Grundrichtung: Kriterien, Prüffragen und Nachweise sollen den Anspruch in überprüfbare Anforderungen übersetzen. Sonst wird digitale Souveränität leicht zur Beruhigungsformel. Ein europäischer Anbietername allein macht noch keine souveräne Lösung, lokale Datenhaltung ebenso wenig.

Für Organisationen heißt das: Infrastrukturentscheidungen müssen auch rechtlich und organisatorisch geprüft werden. Wer darf administrieren? Welche Unterauftragnehmer sind beteiligt? Wer kontrolliert Schlüssel? Welche Nachweise gibt es? Was passiert bei einem Eigentümerwechsel, einer Sanktion, einer Preiserhöhung oder einer geänderten Produktstrategie?

Viele dieser Rahmenbedingungen werden bereits mit der Beschaffung festgelegt, häufig ohne ausdrücklich als Souveränitätsfragen bezeichnet zu werden. Eine Ausschreibung bestimmt, welche Funktionen beschafft werden und ob spätere Wechsel realistisch bleiben. Fehlen Anforderungen an Datenexporte, Schnittstellen, Dokumentation, Betriebsübergabe und Exit-Szenarien, lassen sie sich später nur schwer nachverhandeln.

Eine souveränere Beschaffung fragt nicht nur: „Kann das System die benötigte Funktion?“ Sie fragt auch: „Können wir das System wieder verlassen?“

Das betrifft ganz praktische Punkte. Daten müssen vollständig, verständlich und regelmäßig exportierbar sein. Schnittstellen sollten dokumentiert und stabil sein. Protokolle und Sicherheitsnachweise müssen zugänglich sein. Betriebswissen darf nicht ausschließlich bei einem Anbieter liegen. Rollen, Unterauftragnehmer und Supportwege müssen klar sein. Für Cloud-Dienste können Standards wie der C5-Kriterienkatalog des Bundesamts für Sicherheit in der Informationstechnik helfen, Sicherheitsanforderungen vergleichbarer zu machen. Sie ersetzen aber nicht die eigene Risikoabwägung.

Der Europäische Datenschutzausschuss, das gemeinsame Gremium der europäischen Datenschutzaufsichtsbehörden, hat in seiner koordinierten Prüfung zum Cloud-Einsatz im öffentlichen Sektor gezeigt, wie stark Rollen, Verträge, Unterauftragnehmer, internationale Datenübermittlungen und Nachweise zusammenhängen. Datenschutz berührt damit unmittelbar die Frage, ob ein Dienst später noch verantwortbar betrieben werden kann.

Offenheit macht Optionen belastbarer

Offenheit ist einer der wichtigsten Hebel gegen festgefahrene Abhängigkeiten. Dazu gehören offener Quellcode, dokumentierte Schnittstellen, standardisierte Datenformate, nachvollziehbare Architekturentscheidungen, klare Betriebsdokumentation und die Möglichkeit, Wissen von einem Anbieter zu einem anderen zu übertragen.

Open Source spielt dabei eine wichtige Rolle. Wenn Quellcode offen verfügbar ist, können Systeme geprüft, angepasst und im Zweifel von anderen weiterbetrieben werden. Das verändert die Verhandlungsposition einer Organisation: Kompetenz, Betrieb und Weiterentwicklung lassen sich eher getrennt betrachten.

Trotzdem reicht Offenheit als Label nicht aus. Ein offener Export ist wenig wert, wenn niemand weiß, wie man ihn wieder einliest. Eine offene Schnittstelle hilft wenig, wenn sie nicht gepflegt wird. Offener Quellcode schafft noch keine Souveränität, wenn der Betrieb vollständig zur Blackbox wird oder die Weiterentwicklung nicht finanziert ist.

Ich würde Open Source deshalb als Teil einer breiteren Arbeitsweise verstehen: Systeme so beschaffen, bauen und betreiben, dass spätere Entscheidungen möglich bleiben. Was das konkret für die Verwaltung bedeutet, vertiefe ich im Artikel „Mehr Offenheit wagen: Wie Open Source die Verwaltung handlungsfähiger macht“. Offenheit bekommt ihren praktischen Wert in Verträgen, Schnittstellen, Dokumentation, Support und Betrieb.

Die Fragen sollten früher gestellt werden

In Projekten wünsche ich mir solche Fragen deutlich früher. Eine große Souveränitätsdebatte am Ende hilft wenig; am Anfang genügen einige unbequeme Fragen.

• Können wir unsere Daten vollständig und sinnvoll exportieren?
• Können wir den Betreiber oder Dienstleister wechseln, ohne das System neu zu bauen?
• Verstehen wir die kritischen Abhängigkeiten in Technik, Vertrag und Betrieb?
• Wissen wir, welche Teile wir selbst verantworten müssen und welche wir bewusst auslagern?
• Können wir Nutzer:innen, Mitarbeitenden und Kontrollinstanzen erklären, warum diese Infrastruktur vertrauenswürdig ist?

Die Antworten berühren Budget, Zeitplan und Zuständigkeiten. Manchmal nehmen sie auch eine bequeme technische Abkürzung vom Tisch. Wer das früh klärt, muss Handlungsfähigkeit nicht erst dann zum Thema machen, wenn sie bereits verloren gegangen ist.

Ruhe im Ernstfall

Digitale Souveränität wird oft sehr groß verhandelt: geopolitisch, europäisch, industriepolitisch. Diese Ebene ist wichtig. Europa braucht eigene Fähigkeiten, offene Standards, starke Anbieter und belastbare Infrastrukturen. Sonst bleibt vieles Regulierung ohne eigenes Fundament.

Im Alltag einer Organisation wird Souveränität an kleineren Situationen messbar: Ein Anbieter ändert seine Preise, eine Sicherheitslücke taucht auf, eine Kernanwendung muss erweitert werden, Vorgaben wechseln oder ein Dienstleister fällt aus.

Dann zeigt sich, was eine Souveränitätsstrategie im Alltag wert ist. Für mich liegt darin der praktische Kern: Eine Organisation kennt ihre Abhängigkeiten und kann ruhig entscheiden, wie es weitergeht.

Dann zeigt sich, wie beherrschbar das System wirklich ist.

Genau dort liegt für mich der eigentliche Wert von Open Source in der Verwaltung. Günstiger, schneller oder automatisch besser wird dadurch nichts. Entscheidend ist, ob eine Verwaltung auch nach Jahren noch handlungsfähig bleibt. Kann sie verstehen, was ihre Software tut? Kann sie Fehler nachvollziehen? Kann sie einen Dienstleister wechseln? Kann sie Anpassungen beauftragen, ohne wieder bei null anzufangen?

Open Source löst diese Aufgaben nicht von allein. Es kann Verwaltungen aber helfen, ihre Handlungsspielräume offenzuhalten.

Verwaltungssoftware bleibt lange im Einsatz

Verwaltungen kaufen Software nicht wie ein beliebiges Tool, das man bei Unzufriedenheit einfach gegen ein anderes Abo tauscht. Sie betreiben Verfahren, über die Menschen Leistungen beantragen, Nachweise erbringen, Zahlungen erhalten oder Bescheide bekommen. Hinter einem Formular stehen oft Fachverfahren, Register, Akten, Postfächer, Archivierung und rechtliche Prüfpflichten.

Das stellt besondere Anforderungen. Verwaltungssoftware muss funktionieren, erklärbar bleiben und sich an veränderte Zuständigkeiten, Haushalte und politische Entscheidungen anpassen lassen. Zugleich muss sie Menschen zuverlässig durch den Alltag bringen: Bürger:innen, denen interne Zuständigkeiten egal sein dürfen, und Sachbearbeiter:innen, die technische Abhängigkeiten nicht ausbaden sollten.

Am Anfang eines Projekts denkt man schnell in Funktionen, Terminen und der Frage, wann etwas abgenommen werden kann. Im Betrieb zählen Wartbarkeit, dokumentiertes Wissen, verlässliche Sicherheitsupdates und verständliche Schnittstellen. Ein Fehler sollte sich nicht nur feststellen, sondern auch eingrenzen lassen.

Hier wird Offenheit praktisch.

Handlungsfähig ist, wer Optionen hat

Digitale Souveränität ist inzwischen ein verbreitetes und entsprechend unscharfes Schlagwort. Für mich wird der Begriff brauchbar, wenn man ihn auf eine einfache Frage herunterbricht: Hat eine Organisation echte Optionen?

Technisch heißt das, dass Daten nicht in einem proprietären Format gefangen sind, Schnittstellen nachvollziehbar bleiben und Komponenten ersetzt werden können. Organisatorisch darf Wissen nicht ausschließlich im Kopf einzelner Personen oder bei einem Anbieter liegen. Wirtschaftlich muss ein Wechsel möglich bleiben, ohne ein komplettes System neu zu bauen.

Open Source kann dabei helfen, sofern mehr als der Quellcode offenliegt. Ohne Dokumentation entsteht keine Souveränität. Eine gute Lizenz nützt wenig ohne verlässlichen Betrieb. Unklare Architekturentscheidungen, Datenmodelle und Schnittstellen begrenzen den Handlungsspielraum weiterhin.

Open Source entfaltet seinen Wert erst als Teil einer nachhaltigen Arbeitsweise. Software muss so gebaut, beschafft und gepflegt werden, dass spätere Entscheidungen möglich bleiben. Daran entscheidet sich, ob die Verwaltung auch in fünf oder mehr Jahren noch handeln kann.

Abhängigkeiten entstehen selten mit Absicht

Der klassische Vendor-Lock-in, also die Abhängigkeit von einem Anbieter, die einen Wechsel technisch, organisatorisch oder wirtschaftlich erschwert, beginnt selten mit einer bewussten Fehlentscheidung. Meist entsteht er durch lauter kleine pragmatische Schritte. Eine proprietäre Schnittstelle, weil es schneller geht. Eine Sonderanpassung, die dauerhaft nur in einer einzelnen Installation steckt. Ein Updateprozess, den nur ein Dienstleister wirklich beherrscht. Ein Datenexport, der zwar theoretisch existiert, praktisch aber kaum nutzbar ist.

Jeder dieser Schritte kann für sich genommen nachvollziehbar und sinnvoll sein. Zusammengenommen erzeugen sie aber ein System, aus dem man nur noch schwer herauskommt. Dann ist ein Anbieterwechsel zwar nicht unmöglich, aber so teuer und riskant, dass er kaum noch als echte Option gilt. Unter Budgetdruck zieht ihn dann kaum jemand ernsthaft in Erwägung.

Open Source verschiebt diese Dynamik. Wenn Quellcode offen verfügbar ist, können Dritte ihn prüfen, erweitern und im Zweifel übernehmen. Wenn Änderungen sauber dokumentiert sind, kann Wissen transferiert werden. Wenn Anpassungen wieder in die gemeinsam gepflegte Version aufgenommen werden, müssen sie nicht bei jedem Update erneut mühsam nachgezogen werden.

Dienstleister werden dadurch nicht überflüssig. Ihr Wert liegt in einem solchen Modell in Kompetenz, Verlässlichkeit und guter Zusammenarbeit, nicht in exklusivem Wissen oder künstlicher Abschottung. Die Verwaltung kauft dann nicht nur Zugriff auf eine Software-Blackbox, sondern Entwicklungs- und Betriebskompetenz, die sich im besten Fall auch auf andere Organisationen oder Projekte übertragen lässt.

Offenheit muss praktikabel sein

Damit offene Software Abhängigkeiten wirklich reduziert, muss klar sein, welche Rechte mit ihr verbunden sind. Darf eine Kommune sie selbst betreiben? Darf ein IT-Dienstleister sie für mehrere öffentliche Stellen betreiben? Dürfen Anpassungen weitergegeben werden? Was passiert, wenn mehrere öffentliche Stellen ein Projekt gemeinsam finanzieren? Solche Fragen entscheidet nicht das persönliche Gefühl von Offenheit, sondern der konkrete Lizenztext.

Die Open Source Definition der Open Source Initiative liefert dafür einen anerkannten Referenzrahmen. Open Source meint demnach nicht nur sichtbaren Code, sondern Nutzungs-, Änderungs- und Weitergaberechte. Allgemeinere Begriffe wie „quelloffen“ oder „source-available“ können sinnvoll sein, brauchen aber dieselbe Klarheit: Welche Nutzung ist erlaubt und welche nicht?

Diese Rechte haben wirtschaftliche Folgen. Lizenzen, die mit den Kriterien der OSI vereinbar sind, erlauben auch die kommerzielle Nutzung durch Wettbewerber. Diese Offenheit liegt besonders nahe, wenn Software öffentlich finanziert wurde und andere öffentliche Stellen sie nachnutzen sollen. Bei privat vorfinanzierten Produkten muss zusätzlich klar sein, wie Pflege, Support und Weiterentwicklung getragen werden.

Sogenannte Copyleft-Lizenzen verpflichten bei Verbreitung dazu, dieselben Freiheiten weiterzugeben. Beispiele sind die GPL und die AGPL. Bei der AGPL gilt die Pflicht zur Bereitstellung des korrespondierenden Quellcodes zusätzlich für veränderte Software, mit der Nutzer:innen über ein Netzwerk interagieren. Solche Lizenzen schaffen innerhalb des OSI-Rahmens mehr Gegenseitigkeit, lösen aber nicht jedes Finanzierungsproblem.

Daneben gibt es Modelle mit einsehbarem Quellcode, die bestimmte kommerzielle Nutzungen einschränken. Bei Aivot nutzen wir zum Beispiel für bestimmte Komponenten die Sustainable Use License, die n8n 2022 geschaffen hat und selbst nutzt. Für unseren konkreten Anwendungsfall heißt das vereinfacht: Die Software darf unter den Lizenzbedingungen für eigene interne Zwecke genutzt und angepasst werden. Unter dieser Lizenz ist es jedoch nicht erlaubt, dass ein Dritter sie ohne gesonderte Vereinbarung als eigenes kommerzielles SaaS-Angebot, also als laufenden Online-Dienst, betreibt. Nach der OSI-Definition ist das keine Open-Source-Lizenz. Solche Modelle sollten deshalb klar bezeichnet und für den jeweiligen Einsatz geprüft werden.

Die Beschaffung entscheidet früh mit

Open Source war in der öffentlichen Beschaffung lange unnötig mühsam. Grundsätzlich beschaffbar war die Software, doch viele Routinen und Vertragsmuster waren auf proprietäre Produkte zugeschnitten. Wer offene Software wollte, musste oft mehr erklären, mehr individuell regeln und mehr Unsicherheit aushalten.

Die im März 2026 veröffentlichten EVB-IT-Vertragsmuster setzen an diesem Problem an. EVB-IT sind die ergänzenden Vertragsbedingungen, mit denen die öffentliche Hand IT-Leistungen beschafft. Die neuen Muster berücksichtigen Open-Source-Software und Open-Source-Dienstleistungen ausdrücklich.

Nach Angaben des ZenDiS, des Zentrums für Digitale Souveränität der Öffentlichen Verwaltung, wurden acht Vertragsmuster überarbeitet. Neue Softwareprojekte der öffentlichen Verwaltung können damit standardmäßig als Open-Source-Software entwickelt und leichter auf openCode veröffentlicht werden, einer Plattform für offenen Quellcode aus der Verwaltung. Die Muster enthalten außerdem Optionen für die Übergabe einer SBOM, also einer Art Zutatenliste der verwendeten Softwarebestandteile.

Die Form der Beschaffung entscheidet früh darüber, ob später Optionen entstehen oder verschwinden. Wird die Veröffentlichung mitgedacht? Werden Nutzungsrechte sauber geregelt? Gibt es Anforderungen an Dokumentation, Tests, Sicherheitsprozesse und Abhängigkeiten? Ist geregelt, wie Verbesserungen in die gemeinsam gepflegte, offizielle Version zurückkommen, statt ein Dasein als Sonderlösung zu fristen?

Eine gute Ausschreibung macht „Open Source“ noch nicht zu einem guten Produkt. Sie kann aber verhindern, dass Offenheit erst dann eingefordert wird, wenn das Projekt längst falsch aufgesetzt ist und in eine andere Richtung läuft.

Was große Umstellungen uns zeigen

Schleswig-Holstein zeigt derzeit, dass Open Source in der Verwaltung nicht nur aus Grundsatzpapieren bestehen muss. Das Land hat 2024 seine Open Innovation und Open Source Strategie veröffentlicht und arbeitet an einem digital souveränen Verwaltungsarbeitsplatz. Dazu gehören unter anderem LibreOffice, Open-Xchange, Thunderbird, Nextcloud, OpenTalk und die Erprobung von Linux.

Die Größenordnung ist bemerkenswert. Im Oktober 2025 meldete das Land, das Mailsystem der Landesverwaltung nach einem sechsmonatigen Prozess mit mehr als 40.000 Postfächern und deutlich mehr als 100 Millionen E-Mails und Kalendereinträgen auf Open-Xchange und Thunderbird umgestellt zu haben. Im Dezember 2025 folgte die Meldung, dass LibreOffice auf nahezu 80 Prozent der Arbeitsplätze außerhalb der Steuerverwaltung eingesetzt wird.

Ich würde daraus keine einfache Erfolgserzählung machen. Solche Migrationen sind anstrengend. Sie berühren Arbeitsabläufe, Fachverfahren, Schulungen, Gewohnheiten und Mitbestimmung. Wenn etwas nicht funktioniert, landet der Druck nicht in einer Strategiepräsentation, sondern bei den Mitarbeitenden. Der Wert dieser Beispiele liegt in ihrer organisatorischen Dimension. Open Source verändert auch, wie eine Organisation arbeitet: Wer geschult werden muss, wer Support übernimmt, welche Prozesse angepasst werden und wie viel Geduld eine Umstellung im Alltag wirklich braucht.

Auch München bleibt lehrreich. LiMux war das Münchner Projekt, mit dem die Stadtverwaltung ab den 2000er-Jahren viele Arbeitsplätze von Microsoft Windows und Office auf Linux und freie Software umstellen wollte. Später wurde diese Linie politisch teilweise zurückgedreht. LiMux diente danach lange als Symbol: mal für Open-Source-Erfolg, mal für Open-Source-Scheitern. Beides greift zu kurz. Die heutige Münchner Open-Source-Strategie formuliert wieder klar, dass selbst entwickelte Software unter passenden rechtlichen Bedingungen als Open Source umgesetzt und Open-Source-Lösungen bevorzugt beschafft werden sollen. Die Stadt nennt auf ihrer Seite München Open Source sehr nüchtern Gründe wie Herstellerunabhängigkeit, Wiederverwendung, Zusammenarbeit, Sicherheit und Vertrauen.

Diese Nüchternheit ist hilfreich. Sie nimmt Open Source aus der Symboldebatte und bringt es zurück zur Kernfrage, wie Verwaltung langfristig arbeitsfähig bleibt.

Der schwierige Teil ist Pflege und Weiterentwicklung

Mit der Veröffentlichung des Codes beginnt der schwierige Teil oft erst. Jemand muss Sicherheitsmeldungen bewerten, neue Versionen planen, Abhängigkeiten aktualisieren, Umstellungen vorbereiten, Fragen beantworten, Dokumentation schreiben und Prioritäten sortieren.

Gerade diese Arbeit erhält in Projekten oft zu wenig Budget und Aufmerksamkeit. Veröffentlichter Code ohne Pflege bleibt im Zweifel eine Ablage. Ein offenes Projekt ohne klare Verantwortung kann sogar zusätzliche Unsicherheit erzeugen, weil theoretisch alle etwas tun könnten, praktisch aber niemand zuständig ist.

Damit wird Open Source zu einer Produktfrage: Wer trägt langfristig Verantwortung? Wer bezahlt Wartung und Weiterentwicklung? Wer entscheidet, welche Anforderungen in die gemeinsame Version aufgenommen werden? Wer sorgt dafür, dass nicht jede Behörde ihren eigenen kleinen Sonderweg entwickelt?

Für Verwaltungen ist diese Sicht unbequem, aber hilfreich. Sie verlangt, Software als fortlaufend gepflegte Infrastruktur zu behandeln und nicht als einmalige Lieferung. Aus meiner Sicht ist das der Kern einer ernsthaften Open-Source-Strategie.

KI ändert das Tempo, nicht die Verantwortung

Auch KI verändert diese Debatte. Cloudflare zeigt mit EmDash und vinext, wie schnell sich umfangreiche Softwarekonzepte inzwischen mit KI-Unterstützung neu umsetzen lassen.

Technisch finde ich das super faszinierend. Für Verwaltungen sollte dennoch eine andere Frage im Vordergrund stehen: Wer pflegt so etwas in drei Jahren?

KI kann neue Alternativen erzeugen, aber auch Abspaltungen, Varianten und halbfertige Projekte vermehren. Damit werden Herkunft, Wartung, verlässliche Veröffentlichungen, Sicherheitsprozesse und klare Zuständigkeiten noch wichtiger.

Das gilt genauso für KI-Systeme selbst. In der Praxis begegnet KI der Verwaltung oft als Funktion in einem Fachverfahren, als Assistenzsystem oder als externer Dienst über eine Schnittstelle. Dann ist vieles nicht unmittelbar sichtbar: welches Modell genutzt wird, wohin Daten fließen, welche Schutzmechanismen greifen, wann ein Modell ausgetauscht wird und wie Fehler oder Verzerrungen geprüft wurden.

Die Folgen werden konkret, sobald ein KI-System Anträge vorsortiert, Texte erzeugt oder Mitarbeitende bei Entscheidungen unterstützt. Dann muss nachvollziehbar sein, wofür es geeignet ist, wo seine Grenzen liegen und wer Änderungen verantwortet. Sonst entsteht eine neue Form von Abhängigkeit: nicht nur vom Code, sondern von einem Modellverhalten, das sich kaum prüfen lässt.

Open-Weight-Modelle, also KI-Modelle, deren gelernte Parameter veröffentlicht sind, sind darauf eine mögliche Antwort, reichen allein aber nicht aus. Die gelernten Zahlen im Modell liegen dann offen; mit welchen Daten trainiert wurde, welche Inhalte herausgefiltert wurden und welche Tests es gab, sieht man daraus aber nicht zuverlässig. Die Open Source AI Definition 1.0 der OSI fasst Offenheit bei KI deshalb breiter: Es geht auch um Dateninformationen, Trainingscode und die Möglichkeit, ein System wirklich zu untersuchen, zu verändern und neu zu bauen.

Offenheit, die im Alltag trägt

Ich wünsche mir mehr Open Source in der Verwaltung. Entscheidend ist für mich, dass daraus weder Symbolpolitik noch eine reine Pflichtübung wird. Software muss langfristig betreibbar, prüfbar und austauschbar bleiben.

Mehr Offenheit wagen beginnt bei jeder relevanten Softwareentscheidung mit konkreten Fragen. Können wir das System verstehen? Können wir Daten mitnehmen? Können wir Anbieter wechseln? Können wir Verbesserungen teilen? Können wir Wartung finanzieren? Können wir gegenüber Bürger:innen und Mitarbeitenden erklären, warum ein System vertrauenswürdig ist?

Wer diese Fragen ernst nimmt, nutzt Open Source als Mittel für mehr Handlungsfähigkeit. Offene Software ist nicht automatisch besser, erhöht aber die Chance, später noch gute Entscheidungen treffen zu können.

Für die Verwaltung ist das vielleicht der wichtigste Punkt: Software muss dort nicht nur in Betrieb gehen. Sie muss bleiben können.

Das klingt ziemlich banal, ist in laufenden Projekten aber manchmal erstaunlich schwer zu akzeptieren. Vor allem dann, wenn die ursprüngliche Entscheidung gut war: fachlich sauber, nachvollziehbar begründet, gemeinsam getragen. Gerade solche Entscheidungen verteidigen wir gern zu lange, weil sie sich nicht wie Fehler anfühlen. Sie waren ja keine Fehler. Sie sind vielleicht nur einfach schlecht gealtert.

In digitalen Projekten passiert das ständig. Eine Architekturentscheidung wirkt am Anfang robust, bremst aber später die Produktentwicklung. Ein Formularablauf wird auf Basis plausibler Annahmen gebaut, nur um in Nutzertests an einer ganz anderen Stelle zu scheitern. Eine Schnittstelle wird für einen erwarteten Prozess optimiert, während die Sachbearbeitung längst anders arbeitet.

Zur Korrektur gehört dann ein unangenehmer Satz: Ich habe das damals vertreten. Professionelle Arbeit zeigt sich in diesem Moment an beidem: an den Gründen für die ursprüngliche Entscheidung und daran, ob wir erkennen, wann sie nicht mehr tragen.

Entscheidungen altern

Wir tun manchmal so, als wären Entscheidungen kleine Denkmäler. Man stellt sie auf, erklärt sie, verteidigt sie und hofft, dass niemand zu genau hinschaut, wenn die ersten Risse sichtbar werden. In der Praxis sind sie hingegen eher Momentaufnahmen.

Sie entstehen aus dem, was zu diesem Zeitpunkt bekannt ist: technische Einschränkungen, Budget, politische Erwartungen, Nutzerfeedback, Teamgröße, Zeitdruck und vorhandene Systeme. All das kann sich ändern. Wenn sich genug davon ändert, altert auch die Entscheidung. Schlecht wird sie dadurch nicht automatisch. Ihre Gültigkeit war schlicht an Annahmen gebunden.

Ich finde diesen Gedanken in der Produktarbeit sehr entlastend. Eine Entscheidung muss nicht für immer richtig sein, um damals professionell gewesen zu sein. Überprüfbar muss sie trotzdem bleiben. Wer entscheidet, sollte daher festhalten, was entschieden wurde und woran später zu erkennen ist, dass ein Update nötig wird.

In der Softwarearchitektur gibt es dafür ein schlichtes Werkzeug: Architecture Decision Records, kurz ADRs. Das muss keine große Sache sein. Oft reicht eine Seite mit Kontext, Annahmen, Entscheidung und Folgen. Der wichtigste Satz steht aus meiner Sicht am Ende: Welche Beobachtung würde uns dazu bringen, diese Entscheidung neu zu bewerten?

Ohne diese Frage wird Dokumentation schnell zur Ablage. Mit ihr wird sie zu einem Frühwarnsystem.

Sicherheit ist kein Zustand

Ein Grund, warum Meinungswechsel schwerfallen, liegt in unserem Verhältnis zu Sicherheit. Wir sagen gern: Ich bin mir sicher. Als wäre Sicherheit ein Schalter – an oder aus.

In Wirklichkeit ist Sicherheit meistens eine Skala. Bin ich zu 55 Prozent sicher? Zu 80 Prozent? Fast gar nicht, aber es klingt in der Runde besser, wenn ich entschlossen auftrete?

Gute Produktarbeit braucht diese Unterscheidung. Es macht einen großen Unterschied, ob ein Team sagt: „Wir wissen, dass Nutzer:innen diese Reihenfolge verstehen“ oder „Wir halten diese Reihenfolge für plausibel und prüfen sie im nächsten Test.“ Der zweite Satz wirkt weniger souverän, führt aber häufig zu besseren Ergebnissen.

Die Arbeit von Mellers, Tetlock und Kolleg:innen über Superforecasting zeigt, wie wichtig ein genauer Umgang mit der eigenen Sicherheit ist. Im Good Judgment Project untersuchten sie, warum manche Menschen bessere Vorhersagen treffen als andere. Ein wiederkehrendes Muster: Gute Urteile beruhen weniger auf einmaliger Genialität als auf der Bereitschaft, die eigene Einschätzung mit neuen Informationen zu korrigieren.

Für den Projektalltag heißt das: Wenn neue Nutzerdaten, Supportfälle oder Betriebserfahrungen auftauchen, sollte die erste Frage nicht lauten „Wer hatte recht?“, sondern „Wie stark verändert das unsere Einschätzung?“

Manchmal gar nicht. Manchmal ein bisschen. Und manchmal genug, um eine Entscheidung zu ändern.

Warum wir Updates vermeiden

Dass Teams an überholten Entscheidungen festhalten, hat selten nur mit Starrsinn zu tun. Meist stecken menschliche und organisatorische Gründe dahinter.

Da ist zunächst der Aufwand, der schon investiert wurde. Je mehr Zeit, Geld und Reputation in einer Richtung stecken, desto schwerer fällt der Rückweg. Der sogenannte Sunk-Cost-Effekt beschreibt genau dieses Muster: Vergangene Investitionen beeinflussen aktuelle Entscheidungen, obwohl sie nicht mehr zurückzuholen sind. In Projekten klingt das ungefähr so: Wir können doch jetzt nicht noch einmal alles anfassen.

Doch, manchmal müssen wir genau das.

Hinzu kommt der soziale Teil. Wer eine Entscheidung sichtbar vertreten hat, muss beim Umdenken nicht nur fachlich korrigieren, sondern auch das eigene Selbstbild sortieren. Aus „Ich habe eine gute Einschätzung“ wird plötzlich „Ich habe etwas übersehen“. Das ist unangenehm, besonders dort, wo Sicherheit belohnt und Zweifel als Schwäche gelesen werden.

Hier wird Führung konkret. Wo nur fertige Überzeugungen zählen, kommen Zweifel zu spät. Sind neue Erkenntnisse willkommen, melden Teams früher, wo etwas nicht stimmt. Amy Edmondson hat diesen Zusammenhang mit dem Begriff psychologische Sicherheit geprägt: Menschen müssen Risiken ansprechen können, ohne dafür sozial bestraft zu werden.

Psychologische Sicherheit ist damit auch ein Qualitätsthema. Gerade in der Verwaltungsdigitalisierung, wo Entscheidungen viele Menschen betreffen, ist frühes Korrigieren kein Luxus. Wenn ein Prozess für Bürger:innen unverständlich ist oder Sachbearbeiter:innen zusätzliche Arbeit macht, hilft es niemandem, dass die ursprüngliche Idee gut gemeint war.

Updatefähig entscheiden

Falsche Entscheidungen lassen sich nur begrenzt vermeiden. Entscheidend ist deshalb, sie so zu treffen, dass wir sie rechtzeitig aktualisieren können.

Ein hilfreicher erster Schritt ist die Unterscheidung zwischen Entscheidungen, die schwer rückgängig zu machen sind, und solchen, die man relativ leicht korrigieren kann. Jeff Bezos hat dafür das Bild von Einbahn- und Zwei-Wege-Türen genutzt. In seinem Shareholder Letter 2016 beschreibt er, warum reversible Entscheidungen schneller getroffen werden können.

Ich mag das Bild, weil es den Druck aus vielen Diskussionen nimmt. Es erinnert daran, dass nicht jede Entscheidung mit demselben Gewicht behandelt werden muss. Eine grundlegende Datenarchitektur, die später schwer migrierbar ist, verdient mehr Sorgfalt als die Reihenfolge zweier Zwischenschritte in einem Antragsdialog. Beides ist wichtig, aber nicht gleich riskant.

In Teams hat sich für mich bewährt, vor allem vier Dinge sichtbar zu machen:

• Welche Annahmen tragen diese Entscheidung?
• Welche Signale beobachten wir nach dem Start?
• Wer darf sagen, dass die Entscheidung wackelt?
• Wann schauen wir bewusst wieder darauf?

Diese vier Fragen helfen nur, wenn ihre Antworten auffindbar bleiben. Viele Entscheidungen verschwinden jedoch in Protokollen, Tickets oder alten Präsentationen. Später wirken sie wie Naturgesetze: Das ist eben so.

Dabei wäre es ehrlicher zu sagen: Das war unser letzter Stand.

Kurswechsel ohne Theater

Meinungswechsel werden oft zu groß erzählt. Als müsste man sich öffentlich läutern, weil man eine Entscheidung korrigiert. Meist reicht ehrliche Nüchternheit.

Ein guter Kurswechsel beantwortet drei Fragen: Was wussten wir damals? Was wissen wir heute? Was ändern wir deshalb?

Diese Struktur entwertet die alte Entscheidung nicht automatisch. Sie macht sichtbar, dass sich der Wissensstand verändert hat. Gerade gegenüber Stakeholdern ist das wichtig. Ein Satz wie „Wir lagen falsch“ kann ehrlich sein, erklärt aber wenig. Präziser ist: „Unter den damaligen Annahmen war die Lösung plausibel. In den ersten Nutzertests sehen wir aber, dass Schritt drei zu Abbrüchen führt. Deshalb vereinfachen wir den Ablauf und messen erneut.“

Die Begründung wird dadurch nicht weichgespült, sondern genauer.

Auch intern verändert diese Sprache etwas. Wenn eine Meinung als Hypothese formuliert wird, lässt sie sich leichter prüfen. „Ich glaube, dass diese Lösung für Gelegenheitsnutzer:innen verständlicher ist“ lädt eher zum Test ein als „Das ist die beste Lösung.“

Ich bin inzwischen vorsichtiger mit absolut klingenden Sätzen geworden. Eine klare Haltung bleibt wichtig, ist aber nicht dasselbe wie Starrheit. Man kann klar entscheiden und trotzdem offen bleiben für den Moment, in dem die Welt zurückmeldet: So einfach ist es nicht.

Kleine Routinen statt großer Prinzipien

Wirksam wird diese Haltung erst durch Routinen.

Vor größeren Vorhaben hilft ein Pre-Mortem: Das Team stellt sich vor, das Projekt sei gescheitert, und sammelt Gründe dafür. Gary Klein hat diese Methode in der Harvard Business Review beschrieben. Der Wert liegt darin, dass Zweifel früh ausgesprochen werden dürfen.

Nach dem Start reicht oft ein fester Blick auf die Annahmen. Was hat uns überrascht? Welche Supportanfragen häufen sich? Wo brauchen Nutzer:innen Hilfe? Welche Arbeitsschritte sind für Sachbearbeiter:innen umständlicher geworden? Das sind Signale, keine Nebengeräusche.

Auch technisch lassen sich Rückwege vorbereiten: mit Feature Flags, sauberen Migrationspfaden, beobachtbaren Fehlerraten und kleinen Releases statt großer Würfe. Sie ersetzen kein Urteilsvermögen, senken aber die Kosten des Umdenkens.

Ebenso wichtig ist, wer im Alltag tatsächlich widersprechen darf. Gute Signale kommen oft aus prozessnahen Bereichen wie Support, Sachbearbeitung, Entwicklung und Research. Wer diese Perspektiven spät einbindet, lernt zu spät.

Eine gute Entscheidung ist kein Endzustand

Wir sollten deshalb nicht weniger entschieden auftreten. Digitale Projekte brauchen Richtung, Verwaltung braucht Verbindlichkeit und Teams brauchen Klarheit.

Aber Klarheit ist nicht dasselbe wie Unveränderlichkeit.

Eine gute Entscheidung ist ein sauberer nächster Schritt unter den Annahmen, die wir gerade verantworten können. Sie verdient Umsetzung und Beobachtung, keine endlose Relativierung. Wenn neue Informationen auftauchen, ist es kein Zeichen von Schwäche, die eigene Meinung zu aktualisieren. Es zeigt, dass die Entscheidung mit der Wirklichkeit verbunden bleibt.

Vielleicht wäre viel gewonnen, wenn wir Entscheidungen häufiger mit einem gedanklichen Versionsstand versehen würden. Als Erinnerung, nicht als Ausrede: Das ist unser bester Stand von heute.

Und wenn morgen ein besserer Stand möglich ist, sollten wir nicht zu stolz sein, das Update einzuspielen.

„Können wir den Button vielleicht etwas prominenter machen?“

An dieser Frage ist für sich genommen nichts Manipulatives. Gute Gestaltung muss Aufmerksamkeit lenken. Ein primärer Button darf sichtbar sein, ein Prozess Menschen schneller zu einer passenden Entscheidung führen. Ohne diese Orientierung wären viele digitale Produkte kaum benutzbar.

Schwierig wird es, wenn aus „Was hilft der Person in dieser Situation?“ im Laufe der Zeit „Wie bekommen wir mehr Abschlüsse, mehr Einwilligungen, mehr Verweildauer oder weniger Kündigungen?“ wird.

Die Verschiebung bleibt oft fast unsichtbar. Ein Ablehnen-Button wird unauffälliger, eine Kündigung bekommt einen zusätzlichen Zwischenschritt, eine Gebühr taucht erst später auf. Eine Formulierung macht aus einer freien Entscheidung ein schlechtes Gewissen. Das Interface kann dabei weiterhin ordentlich aussehen, vielleicht sogar sehr gut. Nur arbeitet es inzwischen gegen die eigentliche Absicht der Nutzer:innen.

Der einzelne Button ist dabei nur das sichtbare Symptom. Dahinter verbirgt sich eine falsche Gewichtung der Produktziele.

Das Problem beginnt vor dem Interface

Der Begriff „Dark Patterns“ wurde 2010 durch den UX-Experten Harry Brignull bekannt. Sein Projekt heißt inzwischen Deceptive Patterns, also täuschende Gestaltungsmuster. Dieser Name beschreibt genauer, worum es geht: um Gestaltung, die Menschen in eine Richtung lenkt, die sie sonst vielleicht nicht gewählt hätten.

Die OECD spricht in ihrem Bericht zu Dark Commercial Patterns von Praktiken, die Menschen über digitale Oberflächen lenken, täuschen, drängen oder manipulieren und dadurch Entscheidungen begünstigen, die oft nicht in ihrem Interesse liegen. Die trockene Formulierung trifft den Kern ziemlich gut.

Überzeugung ist nicht automatisch Manipulation. Ein Shop darf ein Angebot hervorheben, eine Software eine empfohlene Einstellung vorschlagen und ein Produkt erklären, warum ein Upgrade sinnvoll sein könnte. Gestaltung ist nie neutral. Sie sortiert, gewichtet und führt.

Die Grenze ist überschritten, wenn relevante Informationen versteckt werden, der einfache Weg immer der für das Unternehmen bessere ist oder ein „Nein“ zwar technisch möglich, aber absichtlich mühsam wird. Solche Oberflächen bauen darauf, dass Menschen müde, abgelenkt, unsicher oder in Eile sind.

Dark Patterns nur als moralisches Fehlverhalten einzelner Designer:innen zu behandeln, greift deshalb zu kurz. Gestalter:innen tragen Verantwortung, ebenso Entwickler:innen und Produktverantwortliche. Die wichtigere Frage lautet: Welche Ziele bekommt ein Team, und woran wird sein Erfolg gemessen?

Wenn eine Metrik allein regiert

Metriken gehören zur Produktarbeit. Ohne sie entscheiden schnell Gefühl, interne Lautstärke oder persönliche Vorliebe. Conversion-Rate, Aktivierung, Wiederkehr, Abbrüche, Supportanfragen oder erfolgreiche Abschlüsse können wichtige Signale sein. Gefährlich wird es aber, wenn eines davon allein regiert.

Wenn nur die Einwilligungsrate zählt, wird das Cookie-Banner irgendwann nicht mehr auf Verständlichkeit optimiert, sondern auf Zustimmung. Wenn nur die Anzahl der gestarteten Testabos zählt, wird die automatische Verlängerung vielleicht sehr prominent verkauft, aber kaum erklärt. Wenn nur kurzfristige Retention zählt, wirkt eine komplizierte Kündigung plötzlich wie ein Erfolg, weil weniger Menschen abspringen. Zumindest auf dem Dashboard mit der Statistik.

An diesem Punkt kann Produktarbeit kippen. Dafür muss morgens niemand beschließen, Nutzer:innen auszutricksen. Es genügt, wenn die Organisation belohnt, was kurzfristig gut aussieht.

In A/B-Tests zeigt sich dieses Problem besonders deutlich. Variante B erzeugt mehr Klicks, Anmeldungen oder Zustimmungen und gewinnt. Der Test misst womöglich nicht, ob Menschen später enttäuscht sind, den Support kontaktieren, das Produkt schlechter bewerten oder sich merken: Bei diesem Anbieter muss ich aufpassen. So kann ein einzelner Schritt besser aussehen, während das Nutzungserlebnis insgesamt schlechter wird. Viele Dark Patterns entstehen in dieser Lücke zwischen kurzfristiger Messbarkeit und langfristiger Wirkung.

Der dunkle Teil ist selten der Button

Die bekannten Beispiele sind schnell erzählt: falsche Countdown-Timer, versteckte Zusatzkosten, vorangekreuzte Optionen, schwer auffindbare Kündigungen, verwirrende Datenschutzentscheidungen, irreführende Formulierungen oder sogenannte „Confirmshaming“-Texte, bei denen das Ablehnen wie eine dumme oder unsolidarische Entscheidung klingt.

Manches davon ist plump. Ein Timer, der nach Ablauf einfach wieder von vorne beginnt, ist nicht besonders subtil. Die Europäische Kommission hat bei einer koordinierten Überprüfung zu Dark Patterns 399 Webshops und Apps geprüft. Bei 148 davon fanden die Behörden mindestens eines von drei untersuchten Mustern: falsche Countdown-Timer, visuelle oder sprachliche Bevorzugung bestimmter Entscheidungen und versteckte Informationen. Von einem Randphänomen kann also keine Rede sein.

Andere Muster sind weniger offensichtlich. Ein Abo ist mit zwei Klicks abgeschlossen, aber die Kündigung liegt hinter Login, Menü, Rückfrage, Angebot, Warnhinweis und letzter Bestätigung. Eine App fragt so lange nach Zugriff auf Kontakte, Standort oder Benachrichtigungen, bis man irgendwann zustimmt. Ein Preis wirkt günstig, bis im letzten Schritt verpflichtende Gebühren auftauchen. Ein Datenschutzdialog gibt scheinbar Wahlfreiheit, aber die datensparsame Option wird sprachlich und visuell am schlechtesten dargestellt.

Der dunkle Teil steckt dabei selten in einem einzelnen UI-Element. Er steckt in der Asymmetrie.

Ein Weg ist kurz, farbig, positiv formuliert und jederzeit verfügbar. Der andere ist lang, blass, negativ gerahmt und mit Reibung versehen. Formal kann man dann behaupten, die Nutzer:innen hätten ja eine Wahl gehabt. Praktisch wurde diese Wahl aktiv beeinflusst.

Dark Patterns tarnen sich auf diese Weise als normale Gestaltung, Optimierung oder „Best Practice“. Was wie eine kleine, angeblich harmlose Reibung aussieht, verschiebt die Kontrolle vom Menschen zum System.

Warum solche Muster funktionieren

Dark Patterns funktionieren nicht, weil Nutzer:innen dumm wären. Sie funktionieren, weil Entscheidungen im Alltag unter Zeitdruck fallen und von Unsicherheit oder Gewohnheit geprägt sind.

Wir scannen, statt gründlich zu lesen, nehmen Voreinstellungen als Empfehlung an und vermeiden zusätzlichen Aufwand. Knappheit und die Sorge, eine Gelegenheit zu verpassen, beschleunigen Entscheidungen noch weiter. Auf dem Smartphone, zwischen zwei Terminen oder abends auf dem Sofa ist der unüberlegte Klick schnell passiert.

Gute Gestaltung arbeitet mit denselben Bedingungen. Sie reduziert Komplexität, setzt sinnvolle Defaults, formuliert klar und macht nächste Schritte sichtbar. Das macht digitale Angebote leichter nutzbar.

Entscheidend ist, wessen Absicht die Gestaltung unterstützt. Hilft sie einer Person, das eigene Ziel leichter zu erreichen? Oder nutzt sie typische Entscheidungsabkürzungen aus, damit eine fremde Absicht leichter durchgeht?

Diese Frage ist in der Praxis unbequem, denn manchmal sieht beides auf den ersten Blick ähnlich aus. Ein vorausgewählter Tarif kann hilfreich sein, wenn er wirklich der übliche, faire und passende Standard ist. Er kann aber manipulativ werden, wenn er teurer ist, mehr Daten erfasst oder schwerer zu kündigen ist und nur deshalb als Standard gesetzt wurde.

Auch Dringlichkeit ist nicht automatisch falsch. Wenn ein Zug in drei Minuten abfährt oder ein Platz in einem Kurs wirklich nur noch einmal frei ist, darf ein Interface das klar zeigen. Problematisch wird es, wenn Dringlichkeit simuliert wird, um Nachdenken zu verhindern.

Eine Liste bekannter Muster reicht deshalb nicht. Teams müssen die Absicht hinter einer Gestaltung prüfen. Was soll diese Entscheidungshilfe leisten? Welche Information bekommt die Person nicht? Welche Alternative wird erschwert? Und würden wir die Gestaltung noch gut finden, wenn wir sie der betroffenen Person ruhig erklären müssten?

Der Preis wird später fällig

Kurzfristig können Dark Patterns auf dem Dashboard beeindruckend wirken. Mehr Opt-ins. Weniger Kündigungen. Mehr Warenkorbwert. Mehr abgeschlossene Registrierungen. In einer Tabelle sieht das erst einmal gut aus.

Der Preis dafür steht aber meist auf einem anderen Blatt.

Er zeigt sich in Supportanfragen, Rückerstattungen, schlechten Bewertungen, öffentlicher Kritik, regulatorischem Risiko und einer Nutzerbasis, die beim nächsten Kontakt weniger Vertrauen mitbringt. Menschen erinnern sich vielleicht nicht an jedes Detail. Das Gefühl, in eine Entscheidung hineingedrückt worden zu sein, bleibt trotzdem hängen.

In meinem Artikel Designing for Trust beschreibe ich, wie Vertrauen in vielen kleinen Momenten entsteht. Dark Patterns kehren diese Wirkung um. Ein versteckter Kostenpunkt, eine unfair formulierte Abfrage oder eine Kündigung, die sich wie ein Hindernislauf anfühlt, kann genügen, um Misstrauen zu festigen.

Rechtlich ist das Thema inzwischen ebenfalls sichtbarer geworden. Der Digital Services Act der EU verbietet Online-Plattformen in Artikel 25, Oberflächen so zu gestalten, dass sie Menschen täuschen, manipulieren oder ihre Fähigkeit zu freien und informierten Entscheidungen wesentlich beeinträchtigen. Die EU bereitet mit dem Digital Fairness Act zudem weitere Regeln vor, die unter anderem Dark Patterns, süchtig machendes Design und unfaire Personalisierung adressieren sollen.

Auch Verfahren der FTC in den USA zeigen, wie ernst das Thema geworden ist. Epic Games musste 2023 im Zusammenhang mit Fortnite 245 Millionen US-Dollar für Rückerstattungen zahlen, nachdem die FTC unter anderem irreführende und verwirrende Kaufprozesse kritisiert hatte. 2025 verkündete die FTC außerdem einen Vergleich mit Amazon über 2,5 Milliarden US-Dollar wegen Prime-Anmeldungen und erschwerter Kündigung. Solche Fälle sind keine Blaupause für jede Rechtslage in Europa, aber sie zeigen: Manipulative Produktgestaltung ist längst kein reines Ethikthema mehr.

Das regulatorische Risiko ist nur ein Teil des Problems. Schon bevor eine rechtliche Grenze erreicht ist, gilt: Ein Produkt, das Nutzer:innen austricksen muss, hat ein Qualitätsproblem.

Ein faires Nein ist Teil guter Nutzerzentrierung

In meinem Text über Nutzerzentrierung habe ich geschrieben, dass gute Produktarbeit mit Misstrauen gegenüber der eigenen Idee beginnt. Bei Dark Patterns wird dieses Misstrauen besonders praktisch.

Ob ein Flow funktioniert, ist nur die erste Frage. Ebenso wichtig ist, für wen er funktioniert.

Kann eine Person ablehnen, ohne bestraft zu werden? Kann sie kündigen, ohne durch ein Labyrinth zu müssen? Versteht sie, was sie kauft, bevor sie bezahlt? Sieht sie den Gesamtpreis rechtzeitig? Ist eine Einwilligung wirklich freiwillig? Wird eine Voreinstellung gesetzt, weil sie für Nutzer:innen sinnvoll ist, oder weil sie für das Unternehmen bequem ist?

Ein faires Nein ist dabei kein nettes Extra. Es ist ein Qualitätsmerkmal.

Für manche Produktteams ist das erst einmal unbequem. Ein klar sichtbares Nein kann die Zustimmung senken. Eine einfache Kündigung macht den tatsächlichen Churn sichtbar, also die Abwanderung von Nutzer:innen, die ohne künstliche Hürden wirklich gehen würden. Transparente Preise können dazu führen, dass Menschen früher abbrechen.

Faire Gestaltung macht solche Reaktionen früh sichtbar. Vielleicht überzeugt das Angebot nicht, der Preis lässt sich nicht klar begründen oder das Abo-Modell passt nicht zur Nutzung. Dark Patterns unterdrücken diese Signale, ohne das zugrunde liegende Problem zu lösen.

Für mich ist das einer der wichtigsten Gründe, warum Dark Patterns langfristig so teuer sind. Sie liefern kurzfristig bessere Zahlen und verschlechtern gleichzeitig die Lernfähigkeit eines Produkts. Wer nur bleibt, weil der Ausgang schwer zu finden ist, wollte vielleicht längst gehen. Wer nur zustimmt, weil Ablehnen anstrengend ist, akzeptiert den Datenaustausch nicht wirklich. Wer kauft, weil die Kosten erst spät auftauchen, bestätigt nicht, dass der Preis tragfähig ist.

Das Produkt lernt dann aus manipulierten Signalen.

Wie Teams sich davor schützen können

Gute Absichten allein verhindern keine Dark Patterns. In echten Projekten gibt es Druck, Ziele, Deadlines, Umsatzfragen und manchmal auch schlichte Gewohnheit. Dagegen helfen ein paar sehr nüchterne Routinen.

Eine hilfreiche Frage lautet: Was würden wir messen, wenn wir nicht nur den nächsten Klick betrachten würden?

Bei einem Checkout gehören neben der Abschlussrate auch Rückerstattungen, Supportkontakte, Beschwerden, Wiederkäufe und das Verständnis des Gesamtpreises zum Bild. Ein Consent-Dialog muss sich ebenso an Klarheit, Widerrufbarkeit und Gleichwertigkeit der Auswahl messen lassen. Bei einer Kündigung sollte neben dem verhinderten Abbruch auch zählen, ob Menschen den Prozess als fair erleben und später vielleicht trotzdem zurückkommen.

In Reviews von Interfaces können ein paar einfache Prüffragen helfen:

• Ist der bevorzugte Weg auch aus Sicht der Nutzer:innen plausibel der beste Weg?
• Sind Kosten, Folgen und Bedingungen sichtbar, bevor entschieden wird?
• Ist Ablehnen, Pausieren oder Kündigen ähnlich einfach wie Zustimmen, Starten oder Kaufen?
• Würde diese Gestaltung noch vertretbar wirken, wenn eine Beschwerde öffentlich danebenstünde?
• Lernen wir aus echten Entscheidungen oder aus Entscheidungen, die wir durch Reibung verzerrt haben?

Diese Fragen ersetzen weder eine juristische Prüfung noch gute UX-Arbeit. Sie ergänzen die nächsten Prozentpunkte um eine zweite Perspektive: Welche Beziehung baut das Produkt mit dieser Entscheidung auf?

Überzeugen und Führen bleiben legitime Aufgaben der Produktgestaltung. Gute Teams zeigen, warum ein Angebot sinnvoll ist, und vereinfachen Entscheidungen, ohne die Entscheidungsfähigkeit der Menschen zu umgehen.

Das bessere Produkt hält ein Nein aus

Die Versuchung ist nachvollziehbar, weil Dark Patterns kurzfristig Ordnung in eine unbequeme Wirklichkeit bringen. Das Angebot überzeugt nicht genug? Dann machen wir Ablehnen schwerer. Die Kündigung ist zu einfach? Dann bauen wir Reibung ein. Die Datenschutzentscheidung fällt nicht wie gewünscht aus? Dann gestalten wir die Alternativen ungleich.

Das kann funktionieren. Für eine Weile.

Ein Produkt, das auf Vertrauen angewiesen ist, bezahlt diesen Erfolg später zurück: als rechtliches Risiko, mit schlechter Reputation oder durch einen internen Kulturwandel, bei dem niemand mehr genau sagen kann, wann aus Optimierung Manipulation geworden ist.

Nutzerzentrierung stellt an dieser Stelle eine ziemlich unromantische Frage: Ist das Ziel des Unternehmens mit dem Ziel der Nutzer:innen vereinbar?

Ein gutes Interface darf überzeugen, führen, reduzieren, empfehlen und priorisieren. Es sollte Menschen dabei nicht in Entscheidungen hineinschieben, die sie bei klarem Blick nicht getroffen hätten.

Vielleicht ist das der einfachste Test: Gute Gestaltung hilft Menschen, eine Entscheidung zu treffen. Manipulative Gestaltung hofft, dass sie nicht zu genau hinschauen.

Wenn Nutzer:innen abbrechen, bei der Hotline anrufen, Nachweise mehrfach einreichen oder parallel doch noch Papier schicken, gilt das schnell als mangelnde Digitalkompetenz. Manchmal stimmt das. Oft hat der digitale Prozess an entscheidenden Stellen aber schlicht nicht genug Sicherheit gegeben.

In den Projekten selbst geht es zunächst um sehr konkrete Fragen. Welche Daten müssen erfasst werden? Welche Nachweise sind notwendig? Welche Schnittstelle liefert welche Information? Welche rechtliche Formulierung muss ins Formular? All das ist nötig. Ohne diese Arbeit wird aus einem Onlinedienst schnell ein hübsch dargestelltes Missverständnis.

Für Nutzer:innen beginnt der Prozess jedoch an einer anderen Stelle. Sie fragen nicht zuerst nach Datenmodellen, Zuständigkeiten oder Fachverfahrensanbindungen. Sie wollen verstehen, ob sie hier richtig sind, was von ihnen erwartet wird und ob der Weg verlässlich ist. Spätestens bei Angaben zu Einkommen, Wohnsituation, Kindern oder Gesundheit wird aus Bedienbarkeit eine Vertrauensfrage.

Ich glaube, diese Verschiebung wird in Digitalprojekten der Verwaltung noch zu oft unterschätzt. Den Beteiligten ist Vertrauen nicht egal. Es wird nur schnell als etwas behandelt, das der Dienst bereits mitbringt: Die Behörde ist seriös, der Rechtsrahmen ist da, die Technik ist geprüft, also müsste auch das Vertrauen vorhanden sein. In der Nutzung muss sich diese Annahme erst bewähren.

Ob der Vertrauensvorschuss berechtigt war, entscheidet sich an den einzelnen Schritten des Prozesses. Dort setzt die Gestaltung an.

Nutzererfahrung ist mehr als Oberfläche

Wenn über User Experience, kurz UX, gesprochen wird, landen viele Gespräche schnell bei Farben, Buttons und Layouts. Das ist nicht völlig falsch. Eine veraltete, uneinheitliche oder fehlerhafte Benutzeroberfläche wirkt unseriös, und Menschen ziehen aus visuellen und sprachlichen Signalen sehr schnell Schlüsse über die Glaubwürdigkeit eines digitalen Angebots.

Die Stanford Web Credibility Guidelines sind dafür eine häufig zitierte Grundlage. Sie stammen aus einem Forschungsprojekt der Stanford University zur Glaubwürdigkeit von Websites und beruhen auf Untersuchungen mit mehr als 4.500 Personen. Die Guidelines kommen aus einer früheren Phase des Webs, lange vor heutigen Plattformen, Apps und Verwaltungsportalen. Viele Beobachtungen bleiben trotzdem relevant: Überprüfbare Informationen, ein klarer Absender, leicht auffindbare Kontaktmöglichkeiten, professionelle Gestaltung sowie ein nützliches und fehlerarmes Angebot stärken die Glaubwürdigkeit.

Ein ordentlich aussehendes Formular ist damit ein Anfang, mehr nicht.

UX beschreibt das gesamte Erlebnis von Anfang bis Ende: Wie finde ich den richtigen Einstieg? Verstehe ich, ob ich hier richtig bin? Kann ich eine Eingabe korrigieren? Wird erklärt, warum bestimmte Daten abgefragt werden? Bekomme ich nach dem Absenden eine Rückmeldung? Und wird das digitale Versprechen später tatsächlich eingelöst?

Ein Verwaltungsantrag ist selten ein isolierter Screen. Er ist ein Ausschnitt aus einem größeren Prozess mit Fachverfahren, Nachweisen, Zuständigkeiten, Fristen, Bescheiden, Rückfragen und manchmal auch Widersprüchen. Eine gute Oberfläche kann die Unsicherheit in diesem Prozess reduzieren. Einen unklaren Ablauf kann sie nur besser verpacken.

Designing for Trust soll Nutzer:innen nicht psychologisch beschwichtigen. Es nimmt berechtigte Unsicherheit ernst und stellt so viel Klarheit wie möglich her.

Verwaltung trägt eine besondere Vertrauenslast

Digitale Verwaltung ist nicht vergleichbar mit Online-Shopping. Das klingt naheliegend, ist aber für die Gestaltung ein wichtiger Unterschied.

Bei vielen privatwirtschaftlichen Angeboten kann ich auf Alternativen ausweichen. Wenn mir ein Shop komisch vorkommt, kaufe ich woanders. Wenn eine App schlecht ist, lösche ich sie. Bei Verwaltungsleistungen geht das meistens nicht. Die zuständige Stelle steht fest. Die Leistung ist oft an eine konkrete Lebenssituation gebunden. Und die Daten, die abgefragt werden, sind häufig sensibel.

Das verändert die Verantwortung. Wer Elterngeld beantragt, einen Wohnsitz ummeldet, Bürgergeld beantragt, einen Todesfall meldet oder eine Gewerbeanmeldung erledigt, bringt nicht nur Aufmerksamkeit und Zeit mit. An dem Vorgang hängt oft Druck: nichts falsch machen, keine Frist verpassen, die Folgen einer Angabe verstehen.

Der eGovernment MONITOR 2025 zeigt deutlich, warum das nicht nur eine Gestaltungsfrage im engeren Sinne ist. Das allgemeine Vertrauen in den Staat liegt dort bei 33 Prozent. Für 51 Prozent der Befragten nähren mangelhafte oder fehlende digitale Angebote Zweifel an der Modernität und Leistungsfähigkeit des Staates. Gleichzeitig sind die Erwartungen sehr konkret: Leistungen sollen einfach auffindbar sein, digital eingereichte Anträge schneller bearbeitet werden und Menschen wollen Daten nicht unnötig doppelt eingeben.

Die Zahlen verbinden Vertrauen sehr direkt mit Alltagserfahrung. Digitale Symbolpolitik reicht dafür nicht. Verwaltung muss funktionieren.

Auch die OECD betont in ihrer Vertrauensforschung die Bedeutung verlässlicher, reaktionsfähiger und fairer öffentlicher Dienste. Schnelligkeit und einfache Abwicklung sind dabei mehr als Komfortmerkmale. Sie prägen mit, ob Menschen Verwaltung als handlungsfähig erleben.

Die Vertrauenskette eines Antrags

In Projekten hilft mir ein konkreteres Bild: Vertrauen entsteht entlang einer Kette von Situationen, die es stärken oder beschädigen können.

Am Anfang stehen Auffindbarkeit und Absenderklarheit. Beides lässt sich kaum trennen. Wenn Menschen nicht sicher erkennen, welches Angebot offiziell ist, beginnt der Prozess mit Zweifel. Das betrifft Suchergebnisse, Domains, Portalstrukturen und Weiterleitungen. Auch der Name eines Dienstes kann helfen oder stören, je nachdem, ob er der Sprache der Nutzer:innen folgt oder der Logik der Verwaltung.

Dann folgt die Zuständigkeit: Bin ich bei meiner Kommune, beim Land, beim Bund oder bei einem Dienstleister? Ist das ein offizieller Onlinedienst oder nur eine Informationsseite? In einer digitalen Landschaft mit Portalen, Fachverfahren, EfA-Diensten und angebundenen Komponenten ist die Antwort nicht trivial. Für Nutzer:innen muss sie trotzdem einfach zu finden sein.

Wer schon einmal versucht hat, die richtige Stelle für eine Einreisegenehmigung nach Großbritannien zu finden, kennt das Problem vielleicht. Für viele Reisende aus Europa ist seit 2025 eine elektronische Reisegenehmigung nötig, die Electronic Travel Authorisation, kurz ETA.

Die offizielle Seite auf GOV.UK warnt ausdrücklich davor, dass andere Websites eine höhere Gebühr verlangen und staatliche Angebote imitieren können. Auf der Antragsseite steht außerdem, dass andere Websites oder Apps keine schnellere Entscheidung bringen. Wenn private Angebote in Suchergebnissen offiziell wirken, aber teurer sind oder falsche Sicherheit versprechen, entsteht Misstrauen schon vor dem ersten Klick auf den richtigen Dienst.

Wenn diese Grundsicherheit da ist, beginnt die eigentliche Führung durch den Prozess. Gute Nutzerführung nimmt Menschen nicht an die Hand, als wären sie unselbstständig. Sie räumt unnötige Stolperstellen aus dem Weg.

Ein vertrauenswürdiger Prozess beantwortet früh ein paar einfache Fragen:

• Bin ich beim offiziellen Angebot?
• Was brauche ich, bevor ich anfange?
• Warum wird diese Angabe verlangt?
• Kann ich speichern, korrigieren oder abbrechen?
• Was passiert nach dem Absenden?

Diese Fragen klingen nach Grundlagen, machen in echten Projekten aber einen großen Teil der Arbeit aus. Sie führen zu klaren Voraussetzungen, verständlichen Begriffen, sinnvollen Schritten und eindeutigen Fehlermeldungen. Nicht jedes juristische Detail gehört in den Formulartext.

Besonders sensibel wird es bei Daten. Menschen sollten verstehen, warum eine Angabe nötig ist, wofür sie verwendet wird und was passiert, wenn sie fehlt. Ein lapidarer Pflichtstern ersetzt keine Erklärung, ein langer Link macht Datenschutz noch nicht nachvollziehbar. Die Datennutzung muss im Prozess selbst verständlich werden.

Nach dem Absenden endet die Vertrauenskette nicht. Dieser Teil wird gerne vernachlässigt, vermutlich weil er außerhalb des Formulars liegt. Für Nutzer:innen ist er zentral: Wurde mein Antrag wirklich übermittelt? Habe ich eine Bestätigung? Wie lange dauert es ungefähr? Wo sehe ich den Status? Was passiert, wenn Unterlagen fehlen? Wie erreiche ich jemanden, ohne wieder bei null anzufangen?

Aus Sicht der Verwaltung mag ein Antrag nach dem Absenden in der Sachbearbeitung liegen. Aus Sicht der antragstellenden Person beginnt dann oft erst die Phase der Unsicherheit.

Eine gute Benutzeroberfläche kann schlechte Prozesse nicht retten

Im Prototyp lässt sich ein Verwaltungsprozess schnell sauber darstellen. Die Schritte sind logisch, die Hinweise sitzen, der Abschlussbildschirm sieht beruhigend aus. In der Praxis trifft dieser Ablauf auf unklare Zuständigkeiten, Fachverfahren ohne Schnittstelle, manuelle Nacharbeit, Medienbrüche, fehlende Statusdaten, nicht abgestimmte Briefe oder rechtliche Vorgaben, die niemand rechtzeitig hinterfragt hat.

Nutzererfahrung umfasst deshalb auch Servicedesign, Prozessarbeit und die mitunter trockene Abstimmung zwischen Fachlichkeit, Technik, Recht und Betrieb. Der glorreiche Alltag eben.

Diese Perspektive prägt das GOV.UK Service Manual, den öffentlich zugänglichen Leitfaden des britischen Government Digital Service für staatliche digitale Dienste. Ein Service wird dort vom ersten Bedarf bis zum abgeschlossenen Anliegen gedacht: über digitale und nicht-digitale Kontaktpunkte hinweg und einschließlich der internen Prozesse, Software, Daten und Regeln.

Besonders stark finde ich den Gedanken, dass interne Strukturen nicht einfach an Nutzer:innen weitergereicht werden dürfen. Menschen wollen nicht verstehen müssen, welche Behörde aus welchem historischen Grund welchen Teilprozess verantwortet. Sie wollen ihr Anliegen erledigen.

Mich interessiert daran kein pauschaler Vergleich mit dem Vereinigten Königreich. Entscheidend ist, wie konsequent das Service Manual die Anforderungen aus Sicht der Nutzer:innen beschreibt: Ein staatlicher Dienst muss auffindbar sein, Sackgassen vermeiden, menschliche Hilfe ermöglichen, Entscheidungen nachvollziehbar machen und über verschiedene Kanäle hinweg konsistent bleiben.

Nicht jede Komplexität kann dabei verschwinden. Verwaltung ist komplex, weil sie Rechtsstaatlichkeit, Gleichbehandlung, Nachweisbarkeit und Zuständigkeit sichern muss. Die Oberfläche sollte aber keine weitere hinzufügen. Gute Gestaltung übersetzt Verwaltung, ohne sie fachlich zu verfälschen.

Sicherheit muss sichtbar verständlich werden

Vertrauen in digitale Verwaltung hängt eng mit Sicherheit zusammen. Gleichzeitig ist Sicherheit ein schwieriges Gestaltungsthema. Wenn alles funktioniert, bleibt sie unsichtbar. Wenn etwas schiefgeht, ist sie sofort das Thema.

Der eGovernment MONITOR 2025 zeigt, dass 69 Prozent der Befragten befürchten, Cyberangriffe könnten die Funktionsfähigkeit des Staates beeinträchtigen. Bürger:innen erwarten zu Recht, dass staatliche digitale Angebote sicher sind. Sie müssen diese Sicherheit allerdings auch verstehen können.

Das bedeutet nicht, jede technische Maßnahme auszubuchstabieren. Niemandem ist geholfen, wenn ein Formular mit Kryptografiebegriffen um sich wirft. Sichtbare Sicherheit entsteht durch klare Signale: eine eindeutig offizielle Adresse, eine verständliche Anmeldung, nachvollziehbare Berechtigungen, transparente Datenabfragen, sichere Postfächer, belastbare Eingangsbestätigungen und Hilfe, wenn etwas nicht funktioniert.

Dabei braucht es Maß und Ehrlichkeit. Sicherheitstheater erzeugt Reibung, aber kein Vertrauen. Wer sich mehrfach anmelden und dieselben Daten wieder und wieder eingeben muss, ohne zu wissen, ob der Antrag angekommen ist, erlebt vor allem Systemstress.

Die bessere Frage lautet: Welche Sicherheitsmaßnahmen sind notwendig, und wie erklären wir sie so, dass sie als sinnvoller Teil des Prozesses erlebt werden?

Standards machen Vertrauen skalierbar

Ein einzelnes gutes Portal ist hilfreich. Vertrauen in den digitalen Staat braucht jedoch verlässliche Qualität über einzelne Projektteams, Budgets und glückliche Zufälle hinaus.

Standards schaffen dafür eine gemeinsame Grundlage. In Deutschland gibt es inzwischen wichtige Ansätze, die in älteren Diskussionen oft noch fehlten. Der KERN UX-Standard stellt ein offenes, technologieunabhängiges Design-System für digitale Verwaltungsangebote bereit. Er unterstützt barrierefreie, wiedererkennbare und nutzendenzentrierte Online-Dienste von der kommunalen bis zur Bundesebene.

Der Servicestandard mit der DIN SPEC 66336 beschreibt Qualitätsanforderungen für Onlineservices und Portale der öffentlichen Verwaltung. Dazu gehören Gestaltung und Nutzendenanalyse ebenso wie Wiederverwendung, Barrierefreiheit, Datenschutz, Sicherheit, Betrieb, Support und Weiterentwicklung.

Das klingt erst einmal nach Dokumenten, Gremien und sehr viel Verwaltung über Verwaltung. In der Praxis können solche Standards Arbeit sparen: weniger Neuerfindungen, Designbrüche und Sonderwege, dafür bessere Barrierefreiheit, klarere Erwartungen an Dienstleister und eine höhere Chance, dass sich digitale Verwaltungsangebote vertraut anfühlen.

Wiedererkennbarkeit ist mehr als Branding. Sie hilft Menschen einzuschätzen, ob sie einem Angebot trauen können. Wenn jeder digitale Dienst anders aussieht, spricht und funktioniert, muss Vertrauen jedes Mal neu aufgebaut werden. Zugleich wird es für fragwürdige Angebote leichter, offiziell zu wirken.

Akzeptanz wird nicht verordnet

Ich wäre vorsichtig mit der Vorstellung, man müsse Bürger:innen nur stärker zur digitalen Nutzung bewegen. Den analogen Weg schlechter zu machen oder Menschen auf eine angeblich unvermeidliche digitale Zukunft zu verweisen, schafft noch keine Akzeptanz.

Der digitale Weg muss sich im Alltag bewähren: als die bessere oder zumindest fairere, schnellere, verständlichere und verlässlichere Möglichkeit.

Das ist auch mit Blick auf „Digital Only“ wichtig. Viele Menschen sind offen für eine stärker digitale Verwaltung, knüpfen diese Offenheit aber an Bedingungen: Unterstützung, verständliche Formulare, schnellere Bearbeitung und persönliche Hilfe bei Problemen. Darin liegt keine Technikfeindlichkeit, sondern eine vernünftige Erwartung.

Ein guter digitaler Verwaltungsprozess lässt Menschen nicht allein. Er bietet Self-Service, wo er sinnvoll ist, und Hilfe, wenn sie gebraucht wird. Nicht jeder Mensch klickt in jeder Lebenslage souverän durch ein Formular. Barrierefreiheit, einfache Sprache, telefonische Unterstützung und klare Kontaktwege gehören deshalb zur Vertrauensarchitektur.

Vertrauen wird nicht behauptet, sondern erlebt

Vertrauen in digitale Verwaltungsprozesse entsteht aus vielen kleinen Belegen dafür, dass der Staat sorgfältig mit einem Anliegen umgeht:

• ein klarer Einstieg
• ein Formularfeld, das man versteht
• eine Fehlermeldung, die weiterhilft
• eine Datenabfrage, deren Zweck erkennbar ist
• eine zuverlässige Zwischenspeicherung
• eine Eingangsbestätigung, die mehr sagt als "Vielen Dank"
• ein Status, der stimmt
• ein Bescheid, den man versteht
• ein Mensch, den man erreichen kann, wenn der Prozess nicht reicht

Eine gute Nutzererfahrung kann Verwaltung nicht allein modernisieren. Sie ersetzt weder Registermodernisierung und Schnittstellen noch saubere Fachverfahren, ausreichende Ressourcen und klare Zuständigkeiten. Ohne gute Gestaltung bleibt vorhandene Leistungsfähigkeit für Nutzer:innen jedoch oft unsichtbar.

Vertrauen zu gestalten heißt deshalb, den ganzen Service an den entscheidenden Situationen zu messen. Eine neue Farbe auf einem alten Prozess reicht nicht. Digitale Verwaltung gewinnt Akzeptanz, wenn Menschen erleben: Ich bin hier richtig. Ich verstehe, was passiert. Ich behalte Kontrolle. Und mein Anliegen ist in guten Händen.

Ich nutze generative KI inzwischen regelmäßig beim Schreiben. Nicht für jeden Text und schon gar nicht als unsichtbare Ersatzautorin. Sie hilft mir, Gedanken zu sortieren, stellt gelegentlich eine Frage, auf die ich selbst nicht gekommen wäre, und zeigt mir Stellen, die gut klingen, aber wenig tragen. Gerade weil das so nützlich ist, muss ich genauer darauf achten, welche Arbeit ich an das Werkzeug abgebe.

Entscheidend ist für mich deshalb nicht, ob KI im Schreibprozess vorkommt, sondern an welcher Stelle. Hilft sie mir beim Denken? Oder übernimmt sie den Moment, in dem ich eigentlich entscheiden müsste, was ich sagen will?

Die beste KI-Arbeit passiert vor dem fertigen Satz

Am nützlichsten ist KI für mich meistens vor dem eigentlichen Text. Ich kann mit ihr ein Thema aufbrechen, Gegenpositionen suchen, eine Struktur prüfen oder blinde Flecken sichtbar machen. Das ist weniger spektakulär als ein fertiger Entwurf auf Knopfdruck, bringt mich aber oft weiter.

Wenn ich über ein digitales Verwaltungsthema schreibe, kenne ich meist meine Grundhaltung. Ich weiß, welche Erfahrung dahintersteht, wo mich etwas stört und welche Beobachtung ich teilen möchte. Trotzdem kann der erste Entwurf zu sehr in meiner eigenen Perspektive stecken bleiben. Dann nutze ich KI als Sparringspartner: Welche Fragen hätte eine Projektleitung? Wo wäre eine Kommune skeptisch? Welche Begriffe setze ich als selbstverständlich voraus? Und welche Gegenargumente sind berechtigt?

So erweitert das Werkzeug meinen Blick, ohne den Standpunkt zu liefern. Es kann sortieren, spiegeln und verdichten. Es weiß jedoch nicht, warum mir ein Thema wichtig ist. Ein Modell hat keine eigene Projekterfahrung und trägt keine Verantwortung gegenüber Leser:innen. Wenn ein Text diese Lücke nur sprachlich überspielt, wird die Unterstützung zum Problem.

Das Content-Fließband beginnt früher, als man denkt

Bei generativer KI wird gern zwischen reflektierter Nutzung und vollautomatischer Textfabrik unterschieden. In der Praxis verläuft die Grenze weniger deutlich. Das Content-Fließband beginnt nicht erst bei tausend SEO-Texten pro Woche. Es beginnt dort, wo die Frage nach Substanz allmählich hinter der Frage nach Output verschwindet.

Das lässt sich vielen Texten anmerken. Sie sind korrekt gebaut und fühlen sich dennoch leer an. Sie erklären ein Thema ohne eigene Beobachtung, sprechen von „Potenzial“, „Effizienz“ und „Innovation“, ohne erkennen zu lassen, wer hier eigentlich urteilt. Alles klingt ungefähr plausibel. Nur bleibt wenig bis nichts davon hängen.

Das ist mehr als eine Geschmacksfrage. Je mehr Texte formal Informationen anbieten, aber kaum eigene Prüfung oder Erfahrung enthalten, desto anstrengender wird die Suche nach etwas Belastbarem. Man muss mehr lesen, um weniger zu erfahren.

Google zieht eine ähnliche Linie. In der eigenen Guidance zu generativer KI in Webinhalten beschreibt das Unternehmen KI nicht pauschal als Problem, sondern betont Genauigkeit, Qualität und Relevanz. Kritisch wird es, wenn viele Seiten ohne echten Mehrwert für Nutzer:innen entstehen. In den Spam-Richtlinien heißt diese Praxis „scaled content abuse“.

Diese Unterscheidung finde ich hilfreicher als die Frage „KI oder nicht KI“. Entsteht ein Text, weil jemand etwas zu sagen hat? Oder nur, weil es technisch möglich ist, noch einen zu erzeugen?

Verantwortung lässt sich nicht auslagern

Je besser KI-Modelle formulieren, desto überzeugender vermitteln sie Gewissheit. Ein Text klingt sicher, eine Quelle echt und eine Erklärung fachlich. Ob etwas davon stimmt, lässt sich am Tonfall nicht erkennen.

Das bekannte Problem der Halluzinationen ist beim Schreiben besonders tückisch. Ich mag den Begriff nicht besonders, weil er beinahe harmlos klingt. Gemeint sind plausible Fehler: erfundene Quellen, falsche Zahlen, verdrehte Zusammenhänge oder Behauptungen mit zu viel Gewissheit. Das NIST, eine US-Behörde für Standards und Technologie, behandelt solche Risiken in seinem Profil zu generativer KI als Teil des Risikomanagements.

Für meine Arbeit folgt daraus eine einfache Aufteilung: Fakten müssen prüfbar sein, Einordnungen muss ich selbst tragen, und persönliche Erfahrung darf nicht aus einem Modell stammen.

Das ist mitunter mühsam. KI spart an einer Stelle Zeit und erzeugt an anderer neue Arbeit: Quellen prüfen, Aussagen zurückbauen, Formulierungen entglätten. Die Qualität entsteht nicht dadurch, dass ein erster Entwurf schnell vorliegt. Sie entsteht bei der Entscheidung, was davon bleiben darf.

Transparenz ist mehr als ein Label

Ich glaube nicht, dass jeder Text, bei dem irgendwo KI geholfen hat, ein großes Warnschild braucht. Das wäre im Alltag kaum sinnvoll. Eine variierte Überschrift oder ein gekürzter Absatz ist etwas anderes als ein vollautomatisch erzeugter Beitrag ohne redaktionelle Prüfung.

Trotzdem wird Transparenz wichtiger. Der AI Act der Europäischen Union sieht ab dem 2. August 2026 Transparenzpflichten für bestimmte KI-Systeme und KI-generierte Inhalte vor. Für veröffentlichte KI-Texte zu Angelegenheiten von öffentlichem Interesse nennt Artikel 50 eine wichtige Ausnahme, wenn die Inhalte menschlich überprüft oder redaktionell kontrolliert wurden und jemand die redaktionelle Verantwortung trägt.

Diese Ausnahme beschreibt im Grunde eine professionelle Selbstverständlichkeit. Für die Vertrauenswürdigkeit zählt nicht allein das Werkzeug, sondern der Prozess dahinter. Wer hat geprüft und ausgewählt? Und wer übernimmt die Verantwortung für das Ergebnis?

Ähnlich argumentiert das U.S. Copyright Office in seinem Bericht zu KI und Schutzfähigkeit. KI kann als unterstützendes Werkzeug Teil eines kreativen Prozesses sein. Reine maschinelle Erzeugung ohne ausreichende menschliche Kontrolle ist etwas anderes. Das US-Recht ist nicht eins zu eins auf Deutschland übertragbar, doch der zugrunde liegende Gedanke ist auch für meinen Schreibprozess interessant: Menschliche Autorschaft erschöpft sich nicht darin, am Ende einen Namen unter das Ergebnis zu setzen.

Meine Stimme ist nicht die effizienteste Variante

Was mich an vielen KI-Texten stört, sind nicht die einzelnen Sätze. Die funktionieren meist. Erst nach ein paar Absätzen fällt auf, wie zuverlässig jeder Übergang sitzt, jeder Einwand eingeräumt wird und jede Pointe an der erwarteten Stelle kommt. Der Text läuft vor sich hin, aber er entwickelt keinen eigenen Rhythmus.

Meine eigenen Texte haben Ecken. Ich wiederhole manchmal eine Beobachtung, weil sie mir wichtig ist, baue Sätze nicht immer maximal effizient und lasse eine kleine Irritation stehen, wenn sie den Gedanken ehrlicher macht. Ein Modell würde vieles davon begradigen. Wenn ich nicht aufpasse, klingt ein Text danach professioneller, aber weniger nach mir.

Für persönliche Texte ist das tatsächlich ein Risiko. Auf meiner eigenen Website möchte ich nicht bloß Informationen bereitstellen, sondern eine Haltung nachvollziehbar machen. Leser:innen sollen erkennen können, wie ich zu einer Einschätzung komme. Die kleinen Umwege eines Textes können dazu mehr beitragen als seine sprachliche Effizienz.

Deshalb gehört für mich zu jeder Überarbeitung mit KI die Frage: Wird der Text klarer oder nur glatter?

Klarer ist gut. Glatter allein ist verdächtig und klingt schnell nach niemandem.

Die Entscheidung bleibt bei mir

In meinem Alltag funktioniert KI am besten als Gegenüber. Ich lasse mir keine Haltung schreiben, sondern eine vorhandene Haltung prüfen.

Das ist mitunter praktisch. Ein Tool kann einen zu abstrakten Einstieg bemerken, eine ausufernde Argumentation straffen oder auf einen ungeklärten Begriff hinweisen. Auch bei der redaktionellen Prüfung ist es nützlich: Klingt eine Passage zu generisch? Dreht sich der Text im Kreis? Behaupte ich mehr, als ich belegen kann?

Die Antworten sind Vorschläge, keine Urteile. Ich muss entscheiden, welche Kritik ich annehme, und erkennen, wenn eine Formulierung sachlich richtig, aber stimmlich falsch ist. Gute Texte entstehen dadurch manchmal langsamer. Das gehört zur redaktionellen Arbeit.

Eine NBER-Studie zur ChatGPT-Nutzung aus dem Jahr 2025 zeigt, wie selbstverständlich Schreiben inzwischen zu den zentralen Einsatzfeldern solcher Systeme gehört. Das überrascht mich nicht: Das Ergebnis ist sofort auf dem Bildschirm sichtbar. Gerade diese Sichtbarkeit macht es leicht, Textproduktion mit Erkenntnisarbeit zu verwechseln.

Einen Text muss jemand vertreten

Generative KI ist für mich weder eine Bedrohung, die aus dem Schreibprozess verschwinden muss, noch ein Wunderwerkzeug, das mit den richtigen Prompts automatisch gute Texte liefert. Ich möchte auf ihre Hilfe nicht verzichten. Sie bringt mich schneller in ein Thema, stellt brauchbare Fragen und findet manche Schwäche früher als ich.

Mein Maßstab ist dabei schlicht: Am Ende muss ich jeden Satz prüfen und vertreten können. Wo das nicht gelingt, hat die KI mich nicht unterstützt, sondern eine Entscheidung übernommen, die bei mir liegen sollte.

Das Content-Fließband wird weiterlaufen. Es wird schneller und günstiger, vermutlich auch schwerer zu erkennen. Dagegen hilft keine romantische Vorstellung vom Schreiben ohne Werkzeuge. Entscheidend bleibt die Arbeit, die nach dem Erzeugen beginnt: auswählen, prüfen, streichen und für das Ergebnis einstehen.

Diese Verschiebung ist zunächst ein Fortschritt. Digitale Verwaltungsleistungen sind sichtbarer geworden. Viele Menschen erwarten inzwischen, dass sie Anträge online stellen, Termine digital buchen und Unterlagen hochladen können. Verwaltung im Browser ist nicht mehr automatisch etwas Besonderes.

Je selbstverständlicher das Angebot wird, desto deutlicher fallen allerdings seine Schwächen auf. Eine Leistung kann schwer auffindbar sein, unverständliche Sprache verwenden, bei Fehlern nicht weiterhelfen oder am Ende doch einen Ausdruck per Post verlangen. Sie ist dann zwar digital verfügbar, aber nur bedingt hilfreich.

Für mich liegt darin eine der wichtigsten UX-Fragen der öffentlichen Verwaltung. User Experience, kurz UX, meint nicht, ob ein Portal modern aussieht. Entscheidend ist, ob Menschen eine Aufgabe verständlich, verlässlich und ohne unnötige Hürden erledigen können. Bei Verwaltungsportalen kommt hinzu, dass Bürger:innen meist keine echte Alternative zum vorgesehenen Verfahren haben. Wer Elterngeld beantragt, einen Wohnsitz ummeldet, eine Erlaubnis braucht oder ein Unternehmen registriert, kann nicht einfach zu einem anderen Anbieter wechseln.

Digitale Verfügbarkeit ist unter diesen Bedingungen nur der Anfang.

Nutzerfreundlichkeit steht inzwischen im Gesetz

Der rechtliche Rahmen hat sich in den vergangenen Jahren weiterentwickelt. Das Onlinezugangsgesetz verpflichtet Bund und Länder, Verwaltungsleistungen elektronisch über Verwaltungsportale anzubieten. Seit der OZG-Änderung 2024 ist Nutzerfreundlichkeit ausdrücklich im Gesetz verankert. § 7 OZG nennt eine einfache und intuitive Bedienbarkeit, die Einbeziehung von Nutzer:innen in die Entwicklung neuer Angebote und die Barrierefreiheit.

Damit verändert sich der Maßstab. Ein Online-Dienst soll nicht nur technisch existieren, sondern benutzbar sein. Ein Gesetz kann diesen Anspruch formulieren, aber nicht dafür sorgen, dass ein konkreter Antrag verständlich ist, ein Hilfetext im richtigen Moment erscheint oder ein Pflichtfeld aus Sicht einer Bürgerin Sinn ergibt. Diese Übersetzungsarbeit passiert im Detail.

Die erste Hürde ist oft der Einstieg

Viele Probleme beginnen nicht im Formular, sondern davor. Menschen müssen die richtige Leistung finden, erkennen, ob sie zu ihrer Situation passt, und verstehen, welche Voraussetzungen gelten und welche Unterlagen benötigt werden.

Verwaltung sortiert Leistungen nach Zuständigkeiten, Rechtsgrundlagen und internen Begriffen. Bürger:innen denken eher in Situationen: Ich bin umgezogen. Mein Kind wurde geboren. Ich brauche einen Nachweis. Ich möchte ein Gewerbe anmelden. Ich habe einen Bescheid bekommen und weiß nicht, was jetzt zu tun ist.

Bildet ein Portal nur die Verwaltungslogik ab, verlieren Menschen Zeit und Vertrauen, bevor der eigentliche Antrag beginnt. Dann helfen auch gute Formularfelder nur begrenzt. Der eGovernment MONITOR 2025 nennt die unkomplizierte Auffindbarkeit von Leistungen, eine schnellere Bearbeitung digitaler Anträge und das Vermeiden doppelter Dateneingaben als zentrale Hebel für mehr Zufriedenheit und Vertrauen. Das sind keine exotischen Innovationswünsche, sondern Grundlagen.

Schon vor der ersten Formularseite sollte klar sein, ob ich hier richtig bin. Der entscheidende Hinweis darf weder in einem PDF noch in einer Formulierung versteckt sein, die nur Menschen verstehen, die die Leistung ohnehin kennen.

Ein guter Einstieg beantwortet dafür ein paar einfache Fragen:

• Gilt diese Leistung für meine Situation?
• Welche Stelle ist zuständig?
• Was brauche ich, bevor ich anfange?
• Wie lange dauert der Vorgang ungefähr?
• Was passiert nach dem Absenden?

Ein Beispiel für diese Denkrichtung ist das dänische Bürgerportal borger.dk. Dort stehen neben Themen und häufig genutzten Leistungen auch Lebenssituationen im Vordergrund: Umzug, Vollmacht, Trennung, Todesfall, neuer Job. Das löst nicht jedes Detailproblem, zeigt aber, wie sich das Angebot anders ordnen lässt. Ausgangspunkt ist nicht die zuständige Behörde, sondern die Situation, in der ein Mensch gerade Unterstützung braucht.

Bleiben die Fragen zum Einstieg offen, beginnt der Prozess mit Unsicherheit. Das kostet Konzentration, erzeugt Rückfragen und führt schnell dazu, dass Menschen abbrechen oder doch wieder zum Telefon greifen.

Verwaltungssprache ist mehr als ein Stilproblem

Über Amtsdeutsch wird gern gelästert – manchmal zu Recht. Verwaltungssprache entsteht aber nicht nur, weil jemand kompliziert schreiben möchte. Sie hängt an Gesetzen, Fachverfahren, Zuständigkeiten und Begriffen, die rechtlich etwas Bestimmtes bedeuten. Ein Fachbegriff kann nötig sein, weil er einen Anspruch, eine Ausnahme oder eine Frist präzise beschreibt.

Das entbindet ein Portal nicht von der Aufgabe, verständlich zu sein. Gute Verwaltungs-UX übersetzt, ohne fachlich falsch zu werden. Sie entscheidet, wo ein Rechtsbegriff stehen muss, wo er erklärt werden sollte und wo er im Interface gar nicht erst im Vordergrund stehen muss.

Ein Formularfeld ist schließlich nicht nur ein Datencontainer, sondern eine Frage an einen Menschen. Statt eine interne Kategorie unverändert als Feldlabel zu übernehmen, kann ein Portal erklären, welche Situation gemeint ist. Ein Nachweis lässt sich durch Beispiele einordnen. Eine komplizierte Ausnahmebedingung kann in kleinere, aufeinander aufbauende Fragen zerlegt werden.

Die eigentliche UX-Arbeit liegt oft in dieser Verteilung: Welche Information gehört in die Frage, welche in einen Hilfetext und welche in eine Vorprüfung? Was muss erst erscheinen, wenn es relevant wird? Und welche Frage lässt sich aus vorhandenen Angaben beantworten, ohne sie erneut zu stellen?

Im Formular zeigt sich die Qualität

Eine freundliche Startseite sagt noch wenig darüber aus, wie gut ein Verwaltungsportal tatsächlich funktioniert. Im Formular treffen Recht, Fachverfahren, Datenschutz, Identifizierung, Nachweise, Barrierefreiheit, mobile Nutzung und die Sorge aufeinander, etwas falsch zu machen. Diese Komplexität lässt sich nicht beseitigen. Sie muss aber so strukturiert werden, dass Menschen handlungsfähig bleiben.

Aus meiner Sicht sind dabei vier Dinge besonders wichtig:

1. Fragen sollten nur gestellt werden, wenn sie wirklich nötig sind. Jede zusätzliche Angabe erzeugt Aufwand und die berechtigte Frage: Warum will die Verwaltung das wissen?
2. Der Ablauf sollte zur Aufgabe passen. Nicht jedes Verfahren braucht einen langen Assistenten, und nicht jede Leistung passt auf eine einzelne Seite. Ein kurzer Antrag darf schnell sein. Ein komplexer Antrag braucht Orientierung, Zwischenspeicherung, eine Zusammenfassung und klare Abschnitte.
3. Fehler müssen reparierbar sein. Eine Fehlermeldung sollte erklären, was nicht passt, wo der Fehler liegt und wie er behoben werden kann. Gerade bei Uploads, Datumsfeldern, Postleitzahlen, IBANs oder Pflichtnachweisen entscheidet sich hier oft, ob Menschen weiterkommen.
4. Ein Formular muss den Alltag aushalten. Menschen nutzen Verwaltungsportale auf Smartphones, mit schlechter Verbindung, unvollständigen Unterlagen, Assistenztechnologien oder unter Zeitdruck. Verlorene Eingaben, überraschend endende Sitzungen und unbrauchbare Funktionen auf kleinen Bildschirmen schaffen vermeidbare Barrieren.

An Mein ELSTER lässt sich erkennen, wie viel Entlastung selbst bei naturgemäß komplexen Steuerformularen möglich ist: Daten aus dem Vorjahr übernehmen, Bescheinigungen abrufen, Plausibilitäten prüfen, Steuerberechnungen anzeigen und digitale Bescheide bereitstellen. Solche Funktionen reduzieren Wiederholungen, machen Fehler früher sichtbar und den Vorgang nachvollziehbarer.

Das sind keine Details für den Feinschliff kurz vor dem Launch, sondern Kernanforderungen an einen öffentlichen digitalen Dienst.

Barrierefreiheit ist Teil der Nutzbarkeit

Bei Verwaltungsportalen ist Barrierefreiheit kein Sonderthema. Öffentliche Leistungen müssen für Menschen zugänglich sein, die einen Screenreader, die Tastatur, Vergrößerung, Sprachsteuerung oder andere Hilfsmittel nutzen. Ein robuster Service muss außerdem verständlich bleiben, wenn Menschen wenig Verwaltungserfahrung haben, ihnen das Lesen schwerfällt, sie mit dem deutschen Behördenvokabular nicht vertraut sind oder gerade schlicht überfordert sind.

Viele Maßnahmen helfen in unterschiedlichen Situationen. Eine klare Überschriftenstruktur unterstützt Screenreader-Nutzer:innen und Menschen, die eine Seite überfliegen. Gute Kontraste helfen bei einer Sehbeeinträchtigung ebenso wie bei der Nutzung draußen in der Sonne. Verständliche Fehlermeldungen unterstützen Menschen mit kognitiven Einschränkungen und alle, die gerade genervt vor einem Pflichtfeld hängen.

Ausführlicher habe ich das im Artikel Barrierefreiheit im Web: Vom Sonderfall zur besseren Nutzererfahrung beschrieben. Für Verwaltungsportale gilt der Anspruch besonders deutlich: Wird ein staatlicher Dienst digital angeboten, darf seine Nutzbarkeit nicht vom Idealfall ausgehen. Ein Portal, das nur für gut vorbereitete, technisch sichere, deutschsprachige Desktop-Nutzer:innen funktioniert, ist lediglich unter günstigen Bedingungen bedienbar.

Der Service endet nicht mit dem Absenden

Viele digitale Verwaltungsleistungen sind auf den Absenden-Button ausgerichtet. Er ist der sichtbare Abschluss des Formulars, aus Sicht der Nutzer:innen aber selten das Ende des Vorgangs.

Danach entstehen neue Fragen: Ist der Antrag eingegangen? Muss ich noch etwas tun? Wie lange dauert die Bearbeitung? Kommt eine Nachricht im Postfach, per E-Mail oder per Brief? Was passiert, wenn ein Nachweis fehlt?

Eine Eingangsbestätigung, ein Aktenzeichen, die Zusammenfassung der übermittelten Daten und realistische Hinweise zu den nächsten Schritten gehören deshalb zum Service. Das ist besonders wichtig, weil es bei Verwaltungsprozessen um Fristen, Geld, Ansprüche, Genehmigungen oder persönliche Daten gehen kann. Eine generische Erfolgsmeldung beendet zwar technisch das Formular, beseitigt aber nicht unbedingt die Unsicherheit.

Qualität muss organisiert werden

Ob ein Portal gut nutzbar ist, sollte nicht allein vom Geschmack des jeweiligen Projektteams abhängen. Standards schaffen gemeinsame Erwartungen und Kriterien, an denen sich Entscheidungen ausrichten lassen.

Die DIN SPEC 66336 zum Servicestandard betrachtet gute Nutzung nicht als Interface-Kosmetik. Sie behandelt unter anderem Nutzenden- und Prozessanalyse, Barrierefreiheit, kontinuierliche Tests, Support, Feedback, Wirkungsmessung, Betrieb und Weiterentwicklung. Nutzerfreundlichkeit wird damit zu einer Aufgabe, die geplant, geprüft und dauerhaft verantwortet werden muss.

Der Digitalcheck setzt noch früher an. Mit diesem Werkzeug der Bundesregierung sollen neue Regelungsvorhaben darauf geprüft werden, ob sie digitaltauglich und später praktikabel vollziehbar sind. Manche UX-Probleme entstehen schließlich schon durch Vorschriften, die unnötige Nachweise, persönliche Vorsprachen, Schriftformerfordernisse oder uneinheitliche Begriffe erzeugen. Ein gutes Interface kann ihre Folgen abfedern, die Ursachen aber nicht beseitigen.

Schlechte UX in Verwaltungsportalen ist deshalb selten nur ein Designproblem. Gute UX-Arbeit macht jedoch sichtbar, wo die eigentlichen Hürden liegen.

Woran ich gute Verwaltungs-UX messen würde

Wenn ich ein Verwaltungsportal fachlich prüfe, interessiert mich nicht zuerst, ob es besonders modern wirkt. Entscheidend ist, ob es in einer realen Nutzungssituation funktioniert. Dafür helfen mir folgende Fragen:

• Findet jemand die Leistung mit den eigenen Begriffen?
• Klärt der Einstieg, ob die Leistung zur eigenen Situation passt?
• Werden Voraussetzungen, Fristen, Kosten und Nachweise früh genug erklärt?
• Sind Fragen im Formular aus Nutzerperspektive verständlich formuliert?
• Erscheinen Hilfen genau dort, wo Unsicherheit entsteht?
• Werden nur Daten abgefragt, die wirklich nötig sind?
• Lassen sich längere Vorgänge speichern und später fortsetzen?
• Bleiben Eingaben erhalten, wenn etwas schiefgeht?
• Sind Fehlermeldungen konkret, auffindbar und handlungsorientiert?
• Funktioniert der Vorgang auf mobilen Geräten und mit Tastaturbedienung?
• Gibt es einen klaren Kontaktweg, wenn man nicht weiterkommt?
• Versteht man nach dem Absenden, was als Nächstes passiert?
• Wird gemessen, wo Menschen abbrechen, Fehler machen oder unzufrieden sind?

Die Fragen holen UX aus der Geschmacksdiskussion heraus. Es geht nicht darum, ob jemand eine Farbe mag oder ein Button rund genug ist, sondern ob Menschen ihr Ziel erreichen. Davon profitiert auch die Verwaltung: Verständliche Anträge, klare Nachweisanforderungen, hilfreiche Fehlermeldungen und ein nachvollziehbarer Status können Rückfragen, Nachforderungen und falsch eingereichte Anträge reduzieren. Nutzerfreundlichkeit ist kein Komfortthema für den Fall, dass noch Budget übrig ist. Sie ist Teil eines funktionierenden Verwaltungsprozesses.

Der nächste Schritt ist Qualität

Digitale Verfügbarkeit war ein notwendiger Schritt, aber sie ist nicht das Ziel. Verwaltung darf nüchtern und rechtlich präzise sein. Sie muss einen Antrag nicht wie ein Einkaufserlebnis inszenieren. Sie sollte Menschen jedoch verständlich führen, Fehler auffangen und auch dann funktionieren, wenn die Nutzungssituation nicht ideal ist.

Für mich ist das der Kern guter UX in Verwaltungsportalen: Sie nimmt die Komplexität der Verwaltung ernst, reicht sie aber nicht ungefiltert an Bürger:innen weiter.

Ein digitales Formular ist schnell gebaut. Ein guter digitaler Verwaltungsdienst braucht mehr: klare Sprache, eine saubere Struktur, robuste Technik, echte Tests, Barrierefreiheit und eine klare Verantwortung für die Weiterentwicklung.

Dass digitale Verfügbarkeit allein nicht mehr genügt, ist keine schlechte Nachricht. Es zeigt, dass sich der Maßstab verschiebt. Die entscheidende Frage lautet nicht mehr nur, ob etwas online ist, sondern ob es Menschen im Alltag wirklich hilft.

Ich habe in Projekten oft erlebt, dass diese Fragen am Anfang kleiner wirken, als sie sind. Ein Online-Dienst fragt nach einer Anschrift, das Fachverfahren erwartet eine Anschrift, ein Register führt ebenfalls Anschriften. Auf dem Papier scheint alles klar zu sein. In der Umsetzung merkt man dann: Die Systeme meinen nicht zwingend dasselbe.

Ist der Straßenname ein eigenes Feld oder steckt er in einer Freitextzeile? Wie werden Hausnummernzusätze behandelt? Welche Zeichen sind in Namen erlaubt? Wird eine ausländische Adresse überhaupt sauber abgebildet? Und was passiert, wenn ein Feld im Formular freiwillig ist, im Fachverfahren aber als Pflichtangabe geführt wird?

Solche Fragen wirken klein, fast pedantisch. In realen Projekten entscheiden sie aber darüber, ob digitale Verwaltung wirklich digital bleibt oder am Ende doch wieder jemand Daten abschreibt, nachtelefoniert oder eine PDF-Datei ausdruckt. Offene Standards sind deshalb für mich weniger ein technisches Ideal als eine praktische Voraussetzung: Sie helfen dabei, dass Verwaltungssysteme dieselbe Sprache sprechen.

Ein Feld ist nie nur ein Feld

Wenn über offene Standards gesprochen wird, geht es schnell um Dateiformate, Schnittstellen und Protokolle. Diese Ebene gehört dazu, erklärt aber nur einen Teil des Problems. Ein Standard klärt nicht nur, wie Daten technisch übertragen werden. Er klärt auch, was diese Daten bedeuten.

Das ist in der Verwaltung besonders wichtig, weil sie mit rechtlich geprägten Begriffen arbeitet. Ein „Antragsteller“ ist nicht einfach ein Nutzerkonto. Eine „zuständige Stelle“ ist nicht bloß eine Adresse in einer Datenbank. Ein „Nachweis“ kann ein Dokument, ein Registerabruf oder eine Bescheinigung sein. Und je nach Leistung, Fachrecht und Vollzugsebene kann derselbe Begriff unterschiedliche Folgen haben.

Gute Standards übersetzen diese Fachlichkeit in eine Form, die Systeme verarbeiten können, ohne die Bedeutung plattzubügeln. Genau darin liegt die Schwierigkeit. Man muss nah genug am Recht und an der Verwaltungspraxis bleiben, aber konkret genug werden, damit Entwickler:innen, Fachverfahrenshersteller und Betreiber damit arbeiten können.

Das Föderale Informationsmanagement, kurz FIM, ist ein gutes Beispiel dafür. Es soll Rechtssprache in verständliche Leistungsbeschreibungen, Prozesse und Datenfelder übertragen. Die FITKO, also die Föderale IT-Kooperation von Bund und Ländern, koordiniert und vernetzt zentrale Vorhaben der Verwaltungsdigitalisierung für den IT-Planungsrat. Sie beschreibt FIM als standardisierte Übersetzung der Rechtssprache in eine bürger:innen- und unternehmensfreundliche Sprache und verweist auf die Nachnutzung qualitätsgesicherter Leistungsbeschreibungen und Datenfelder.

Der praktische Nutzen liegt in dieser Nachnutzung. Wenn jede Stelle dieselbe Leistung neu beschreibt, entstehen zwangsläufig Abweichungen. Manche sind fachlich nötig. Viele sind einfach nur teuer.

Mit XDatenfelder wurde dieser Gedanke in einen Interoperabilitätsstandard überführt. Der IT-Planungsrat hat 2019 die verbindliche Nutzung von XDatenfelder für den standardisierten Austausch von Stamminformationen des FIM-Bausteins „Datenfelder“ zwischen den Redaktionssystemen von Bund und Ländern beschlossen. Solche Beschlüsse klingen unspektakulär, machen aus einer guten Absicht aber eine belastbare Arbeitsgrundlage.

Merkmale offener Standards

Offenheit ist bei Standards kein Etikett, sondern ein Arbeitsversprechen. Eine Spezifikation hilft erst dann, wenn unterschiedliche Verwaltungen, Hersteller und Betreiber sie verstehen, implementieren und überprüfen können. Deshalb reicht es nicht, wenn irgendwo ein Dokument zum Download liegt.

Ich verstehe offene Standards hier als Spezifikationen, die öffentlich zugänglich, nachvollziehbar gepflegt und unabhängig von einzelnen Anbietern implementierbar sind. Sie sind nicht dasselbe wie Open Source: Ein offener Standard kann unabhängig davon umgesetzt werden, ob die Software selbst quelloffen oder proprietär ist. Entscheidend ist die gemeinsame Grundlage, nicht das Lizenzmodell der konkreten Anwendung.

Für die Praxis heißt das: Kann ein Fachverfahrenshersteller den Standard implementieren, ohne Sonderwissen eines Konkurrenten zu brauchen? Gibt es Versionen, Codelisten, Schemata, Beispiele und klare Zuständigkeiten? Ist erkennbar, wer über Änderungen entscheidet und wie lange alte Versionen unterstützt werden? Lässt sich prüfen, ob eine Implementierung wirklich konform ist?

Standardisierung besteht deshalb auch aus Dokumentation, Gremien, Testfällen, Fehlermeldungen und Übergangsfristen. Fehlt diese Arbeit, merkt man es später an jeder Ecke.

Das XÖV-Rahmenwerk zeigt diese Betriebsdimension recht gut. XÖV steht für „XML in der öffentlichen Verwaltung“. Das Rahmenwerk stellt praxiserprobte Methoden und Produkte für die Entwicklung und den Betrieb von IT-Standards für den Datenaustausch zwischen Fachverfahren bereit. Die XÖV-Zertifizierung prüft Standardisierungsvorhaben anhand der Bewertungs- und Qualitätskriterien des XÖV-Handbuchs auf XÖV-Konformität.

Noch greifbarer wird das beim XRepository. Dort werden XÖV-Standards, Codelisten und weitere Artefakte bereitgestellt. Für Menschen außerhalb dieser Welt klingt das vielleicht nach Ablage. In der Praxis ist es aber ein wichtiger Teil der Infrastruktur. Standards müssen gefunden, abonniert, versioniert und im Betrieb genutzt werden können. Ein Standard, den niemand zuverlässig findet oder dessen Codelisten in alten Excel-Dateien herumliegen, kann fachlich noch so gut sein: Operativ bleibt er kaum benutzbar.

Interoperabilität ist mehr als eine Schnittstelle

In Projekten wird „Schnittstelle“ manchmal so verwendet, als sei damit das Problem erledigt. Zwei Systeme können Daten austauschen, also sind sie verbunden. Doch eine sauber dokumentierte API klärt noch nicht, welche Fachlogik hinter einem Statuswert steckt. Selbst ein valider Datensatz kann im falschen Prozessschritt ankommen. Und ein vollständig ausgefülltes Formular kann manuelle Nacharbeit erzeugen, wenn Nachweise nicht eindeutig zugeordnet sind.

Auch auf europäischer Ebene wird Interoperabilität breiter gefasst. Der Interoperable Europe Act, der seit dem 11. April 2024 in Kraft ist, stärkt die grenzüberschreitende Zusammenarbeit im öffentlichen Sektor und die Wiederverwendung gemeinsamer Lösungen. Seit dem 12. Januar 2025 sind außerdem Interoperabilitätsbewertungen vorgeschrieben, bevor neue oder wesentlich geänderte verbindliche Anforderungen an transeuropäische digitale öffentliche Dienste beschlossen werden, sofern diese Anforderungen die grenzüberschreitende Interoperabilität betreffen.

Für die Praxis ist dieses Zusammenspiel entscheidend. Bleibt eine Ebene ungeklärt, landet das Problem meist bei den Menschen im Verfahren: Sachbearbeiter:innen interpretieren, was Systeme nicht sauber ausdrücken. Bürger:innen liefern Informationen erneut.

Der Weg vom Onlinedienst ins Fachverfahren

Gemeinsame Begriffe und Datenmodelle sorgen noch nicht dafür, dass ein digitaler Antrag im richtigen Fachverfahren ankommt. Ein Datenschema kann seinen Inhalt festlegen. Es regelt aber nicht, wie der Antrag sicher zur zuständigen Behörde gelangt, wie der Empfang bestätigt und das Fachverfahren angebunden wird. Dafür braucht es Infrastruktur und klare Schnittstellen.

FIT-Connect setzt an dieser Stelle an. Die FITKO beschreibt FIT-Connect als Möglichkeit, Online-Antragsdienste und Fachverfahren über einheitliche Schnittstellen und Standards zu verbinden. Es geht um maschinenlesbare, verschlüsselte Kommunikation zwischen Antragsteller:innen, Onlinediensten und den zuständigen Fachbehörden.

An diesem Übergang stellen sich in vielen Digitalisierungsprojekten dieselben Fragen: Wie gelangt der Antrag sicher ins richtige Fachverfahren? Wie wird eine zentrale Lösung in vielen Kommunen nutzbar, ohne für jede Stelle eine Sonderintegration zu bauen?

Ohne verlässliche Anbindung landet ein eigentlich digitaler Antrag schnell wieder als PDF in einem Postfach. Er ist dann zwar online gestellt worden, aber im Fachverfahren beginnt die Arbeit fast von vorn.

FIT-Connect beantwortet damit vor allem Fragen des Transports. Die fachliche Standardisierung ersetzt es nicht. Wenn die Fachdaten unklar modelliert sind, transportiert auch die beste Anbindung diese Unklarheit nur zuverlässig weiter. Umgekehrt nützt das beste Datenmodell wenig, wenn jede Integration individuell gebaut werden muss. Nachhaltige Digitalisierung braucht beides: gemeinsame Bedeutung und verlässlichen Transport.

Standards entlasten nur, wenn sie gepflegt werden

In der Theorie klingt Standardisierung manchmal, als müsse man nur einmal sauber definieren, wie etwas funktioniert. Danach halten sich alle daran und die Welt wird einfacher.

So läuft es natürlich nicht. Recht ändert sich. Fachverfahren ändern sich. Neue Nachweise kommen hinzu. Alte Prozessschritte fallen weg. Begriffe werden präziser. Ein Standard ist deshalb kein abgeschlossenes Dokument, sondern ein eigenes Produkt mit Lebenszyklus.

Das wird besonders deutlich, wenn Codelisten im Spiel sind. Über sie möchte niemand sprechen, solange sie funktionieren. Sobald sie es nicht tun, sprechen plötzlich alle darüber. Codelisten legen fest, welche Werte ein Feld annehmen darf: Status, Kategorien, Behördenkennungen, Arten von Nachweisen, Staaten, Rollen, Gründe. Werden sie nicht gepflegt, entstehen Workarounds. Freitextfelder kommen zurück. Systeme akzeptieren „Sonstiges“. Ausnahmen werden per E-Mail geklärt. Und irgendwann ist kaum noch nachvollziehbar, warum der digitale Prozess so viel manuelle Nacharbeit erzeugt.

Auch Migration gehört dazu. Standards entwickeln sich weiter, aber Verwaltungen arbeiten mit bestehenden Systemen, Verträgen und Datenbeständen. Man kann nicht jede neue Version sofort überall ausrollen. Es braucht Übergänge, Kompatibilität und klare Kommunikation. Sonst wird Standardisierung selbst zur Belastung.

Das ist einer der Punkte, an denen ich in Projekten vorsichtig geworden bin. Ein Standard ist nicht automatisch gut, nur weil er offen ist. Er kann zu groß, zu abstrakt, zu langsam oder zu weit weg von der Umsetzung sein. Er kann mehr versprechen, als die beteiligten Organisationen tragen können. Und manchmal ist eine kleine, gut dokumentierte Vereinbarung für einen begrenzten Zweck besser als ein großer Standard, der niemandem wirklich gehört.

Was offene Standards im Alltag verändern

Trotz dieser Einschränkungen verhindern offene Standards, dass jedes Projekt bei null beginnt. Verwaltungen können in Ausschreibungen konkrete Standards, Versionen und Konformitätsanforderungen benennen. Hersteller müssen nicht für jede Kommune eine neue Sonderlogik bauen, sondern können auf einer stabileren Grundlage arbeiten. Das macht Angebote vergleichbarer und kann gerade für kleinere Anbieter Eintrittshürden senken.

Im Arbeitsalltag zeigt sich der Nutzen indirekt: Sachbearbeiter:innen übertragen weniger Daten von Hand und müssen seltener nachfragen, weil Informationen strukturierter ankommen. Bürger:innen und Unternehmen müssen die innere Komplexität der Verwaltung seltener ausbaden. Ein Antrag darf fachlich kompliziert sein, wenn das Recht kompliziert ist. Er sollte aber nicht zusätzlich dadurch kompliziert werden, dass Systeme keine gemeinsame Sprache haben.

Die Registermodernisierung und das Nationale Once-Only-Technical-System, kurz NOOTS, zeigen, wie groß dieser Anspruch wird. Auf der NOOTS-Wissensplattform wird das Once-Only-Prinzip so beschrieben, dass der Verwaltung bereits vorliegende Nachweisdaten auf Wunsch von Bürger:innen und Unternehmen automatisiert abgerufen werden können, statt erneut erhoben zu werden. Dafür müssen Register und Onlinedienste sicher und digital Daten austauschen können. Die Registerübersicht führt die gemäß IDNrG anzuschließenden Registertypen nach Fachdomänen auf und macht sichtbar, welche Zuständigkeiten daran hängen.

Gerade deshalb sollte man Once Only nicht als Zauberwort behandeln. Es funktioniert nur, wenn Daten fachlich verstanden, rechtlich zulässig, technisch sicher und organisatorisch verantwortet ausgetauscht werden. Offene Standards sind dafür keine hinreichende Bedingung. Ohne sie wird es aber sehr schwer.

Die gemeinsame Sprache muss gelernt werden

Standards gehören deshalb früh in ein Projekt, bevor die Oberfläche fertig ist oder der Dienst produktiv gehen soll. Als Anhang in einem technischen Konzept, den am Ende niemand liest, entfalten sie kaum Wirkung.

Ich würde sie wie Architekturentscheidungen behandeln: Welche Begriffe und Datenmodelle übernehmen wir? Wo weichen wir bewusst ab? Welche Schnittstellen sind verbindlich, und wie gehen wir mit neuen Versionen um?

Diese Entscheidungen bestimmen, wie beweglich ein System später ist und wie viel Arbeit sich bei der nächsten Leistung, der nächsten Kommune oder dem nächsten Fachverfahren wiederverwenden lässt.

Offene Standards versprechen keinen schnellen Aha-Moment. Ihr Nutzen zeigt sich eher darin, dass bestimmte Probleme gar nicht erst entstehen. Gute Standardisierung ist im besten Fall unsichtbar. Der Antrag kommt an. Die Daten passen. Das Fachverfahren versteht sie. Die zuständige Stelle kann weiterarbeiten.

Nachhaltige Digitalisierung beginnt lange vor der nächsten Oberfläche: bei Begriffen, Datenmodellen, Schnittstellen und der Frage, ob andere darauf verlässlich aufbauen können.

Offene Standards nehmen diese Arbeit niemandem ab. Sie geben ihr aber eine Form, auf die sich viele einigen können. Darin liegt ihr Wert: Sie schaffen die gemeinsame Grundlage, auf der Verwaltungen Stück für Stück besser zusammenarbeiten können.

Genau diese breite Zustimmung macht den Begriff so furchtbar bequem. Er passt auf Präsentationsfolien, in Ausschreibungen, in Produktstrategien und in fast jede gut gemeinte Diskussion über digitale Angebote. Offen bleibt dabei jedoch häufig, wie ein Team herausfindet, was Menschen wirklich brauchen, und welche Konsequenzen es aus diesen Erkenntnissen zieht.

Im Projektalltag wird dieser Anspruch konkret: Wen beziehen wir ein? Welche Annahmen überprüfen wir? Und was passiert, wenn Rückmeldungen unserer ersten Idee widersprechen?

Je länger ich an digitalen Produkten arbeite, desto wichtiger erscheint mir dabei ein unbequemer Gedanke: Unsere erste Idee kann plausibel sein und trotzdem an der Realität anderer Menschen vorbeigehen. Sie ist nicht zwingend schlecht, entsteht aber zwangsläufig aus unserer eigenen Perspektive.

Für mich beginnt Nutzerzentrierung deshalb weder mit möglichst viel Empathie noch mit einem Workshop voller bunter Zettel. Am Anfang steht ein professionelles Misstrauen gegenüber der eigenen Idee. Gemeint ist damit eine nüchterne Arbeitsdisziplin: Auch eine gute Idee muss überprüft werden, bevor sie sich allzu selbstverständlich richtig anfühlt.

Die eigene Perspektive ist nie neutral

Wir gestalten selten aus dem Nichts. Wir bringen Fachwissen mit, technische Erfahrung, persönliche Vorlieben, interne Begriffe, organisatorische Zwänge und manchmal auch eine ziemlich klare Vorstellung davon, wie Menschen sich verhalten sollten.

Menschen benutzen Software allerdings nicht so, wie wir es uns in der Konzeption wünschen. Sie tun das in Pausen zwischen zwei Terminen, auf kleinen Bildschirmen, mit unvollständigen Unterlagen, unter Zeitdruck oder mit schlechter Verbindung. Manche verwenden Assistenztechnologien oder haben schlicht andere Begriffe im Kopf als das Team.

Eine Oberfläche kann aus Sicht des Teams völlig logisch aufgebaut sein und für Nutzer:innen trotzdem verwirrend wirken. Ein Button kann technisch korrekt beschriftet sein und trotzdem nicht die Handlung auslösen, die Menschen erwarten. Ein Hilfetext kann fachlich sauber formuliert sein und genau in dem Moment fehlen, in dem jemand ihn braucht.

Solche Fehleinschätzungen sind normal und kein moralisches Versagen des Teams. Sie entstehen, weil die eigene Perspektive eben nicht neutral ist.

Barrierefreiheit macht diese Grenzen der eigenen Perspektive besonders sichtbar. Wer bei der Gestaltung nur an Mausbedienung, einen großen Bildschirm, gutes Sehvermögen und volle Konzentration denkt, legt ein sehr enges Nutzungsszenario zugrunde. Für Menschen mit Behinderungen ist Zugänglichkeit oft die Voraussetzung, ein digitales Angebot überhaupt nutzen zu können. Eine verlässliche Tastaturbedienung und verständliche Fehlermeldungen helfen auch in anderen Situationen. Die technischen, rechtlichen und praktischen Fragen dazu behandle ich ausführlicher in meinem Artikel Barrierefreiheit im Web: Vom Sonderfall zur besseren Nutzererfahrung.

Nutzerzentrierung nimmt solche blinden Flecken methodisch ernst.

Was Nutzerzentrierung fachlich meint

Fachlich ist Nutzerzentrierung eng mit User Experience und menschzentrierter Gestaltung verbunden. User Experience, meist als UX abgekürzt, bezeichnet die gesamte Erfahrung, die Menschen vor, während und nach der Nutzung eines Produkts, Services oder Prozesses machen. Menschzentrierte Gestaltung oder Human-Centered Design beschreibt die Arbeitsweise dahinter. Die ISO 9241-210 fasst sie in konkrete Prinzipien: Teams sollen Nutzer:innen, Aufgaben und Nutzungskontexte verstehen, Nutzer:innen im Entwicklungsprozess einbeziehen, Lösungen anhand echter Nutzung bewerten, iterativ arbeiten und die gesamte Nutzungserfahrung betrachten.

Entscheidend ist, wann die Perspektive der Nutzer:innen in die Arbeit einfließt. Ein Usability-Test kurz vor der Fertigstellung kann zeigen, wo eine bestehende Lösung hakt. Stellt sich dabei heraus, dass das Team die falsche Aufgabe löst, sind grundlegende Korrekturen zu diesem Zeitpunkt bereits aufwendig.

Nutzerzentrierung setzt deshalb früher an und verändert die Reihenfolge der Fragen: Welche Aufgabe versucht ein Mensch zu erledigen? In welcher Situation geschieht das? Welche Hürden gibt es dabei? Erst auf dieser Grundlage lässt sich entscheiden, welche Lösung wirklich hilft.

Wer nutzerzentriert gestaltet, prüft nicht nur, ob ein Interface verständlich ist. Ebenso wichtig ist, ob das richtige Problem gelöst wird, der Weg zum Ziel passt, die Sprache trägt und der Aufwand gerechtfertigt ist. Die Lösung muss auch dann funktionieren, wenn jemand müde, technisch unsicher oder schlecht vorbereitet ist.

Eine gute Nutzungserfahrung endet daher nicht bei einem auffindbaren Button. Menschen müssen ihr Ziel erreichen können, ohne unnötig über das System nachzudenken.

Empathie reicht nicht

Ich mag den Begriff Empathie in diesem Zusammenhang nur eingeschränkt. Empathie ist wichtig. Der Begriff klingt hier jedoch fast so, als müssten wir uns nur stark genug in Nutzer:innen hineinversetzen, um zu guten Entscheidungen zu kommen.

Überraschung: Das reicht nicht.

Wir können uns irren, auch wenn wir es gut meinen. Gerade bei digitalen Produkten überschätzen wir häufig, wie eindeutig unsere Begriffe sind, wie linear Menschen denken und wie viel Geduld sie für unsere interne Logik aufbringen. Gute Absichten verhindern keine schlechten Nutzungserfahrungen.

Deshalb braucht Nutzerzentrierung Belege. Dahinter müssen nicht immer große Studien oder wochenlange Forschung mit Nutzer:innen stehen. Entscheidend sind Einblicke in die tatsächliche Nutzung: Gespräche, Beobachtungen, Support-Rückfragen, Suchanfragen, Prototypen, kurze Tests oder Nutzungsdaten. Je nach Projekt werden diese Einblicke in einem kleinen, pragmatischen Rahmen oder umfassender und systematischer gewonnen.

Feedback ist dabei nicht dazu da, eine fast fertige Idee abzunicken. Es soll zeigen, wo unsere Annahmen nicht stimmen.

Die britische Verwaltung formuliert das in ihrem Service Manual sehr klar: Teams sollen das Problem verstehen, das Nutzer:innen lösen wollen, statt sich zu früh an eine bestimmte Lösung zu klammern. Das ist nicht nur für staatliche Services richtig. Es ist für fast jedes digitale Produkt eine hilfreiche Erinnerung.

Bedürfnisse sind keine Wunschliste

Ein Missverständnis begegnet mir immer wieder: Nutzerzentrierung werde so verstanden, als müsse man einfach bauen, was Nutzer:innen fordern.

Das wäre aber viel zu kurz gegriffen.

Wenn jemand sagt: „Ich brauche einen Excel-Export“, kann dahinter vieles stecken. Vielleicht muss die Person Daten mit einem anderen System abgleichen oder braucht eine Übersicht für die eigene Ablage. Vielleicht muss sie einer Berichtspflicht nachkommen, für die sich eine bessere Lösung finden ließe. Der Export kann tatsächlich die richtige Lösung sein, aber auch nur der naheliegendste Workaround, den die Person aus ihrer aktuellen Situation heraus beschreiben kann.

Ähnlich ist es mit Wünschen nach zusätzlichen Hinweisen, mehr Optionen oder weiteren Bestätigungsschritten. Sie können sinnvoll sein oder darauf hindeuten, dass der eigentliche Ablauf nicht klar genug ist.

Wer Nutzer:innen ernst nimmt, setzt daher nicht jede konkrete Wunschlösung um. Ein Wunsch ist zunächst ein Hinweis: Was versucht die Person zu erreichen? Wo entsteht Unsicherheit? Welche Einschränkung prägt die Situation? Welche Aufgabe steckt hinter der geäußerten Lösung?

Das ist auch der Punkt, an dem User Experience und Produktverantwortung zusammenkommen. Nutzerzentrierung nimmt Teams nicht die Entscheidung ab. Sie macht Entscheidungen besser begründbar.

Der Kontext entscheidet

Eine Funktion ist nicht einfach gut oder schlecht. Ihre Wirkung hängt vom Kontext ab.

Ein freundlicher Erfolgstext kann in einem Produkt sehr passend sein. Eine kleine Animation nach einem abgeschlossenen Vorgang kann Freude auslösen. Ein lockerer Ton kann ein digitales Erlebnis menschlicher machen. In vielen Situationen ist das genau richtig.

Und dann gibt es Situationen, in denen dieselbe Idee plötzlich falsch wirkt.

In einer Antragssoftware, an der mein Team arbeitet, gab es nach dem Absenden eines Antrags eine kleine Belohnung: freundliche Worte, einen klaren Abschluss, in manchen Konstellationen sogar virtuelles Konfetti. Technisch war das sauber umgesetzt. In Demos kam das gut an. Es war ein sympathischer Abschluss in einem sonst eher nüchternen Prozess.

Bis klar wurde, dass nicht jeder erfolgreiche Antrag ein Anlass zur Freude ist.

Spätestens bei der Beantragung einer Sterbeurkunde fühlt sich Konfetti nicht mehr charmant an. Die Komponente ist nicht an sich falsch, ignoriert in diesem Fall aber den emotionalen Kontext.

Das ist mein liebstes Beispiel dafür, warum Nutzerzentrierung mehr ist als Bedienbarkeit. Niemand scheitert an dieser Stelle technisch. Der Antrag ist abgeschickt. Der Prozess funktioniert. Und trotzdem ist die Nutzungserfahrung nicht stimmig.

Wir haben die Rückmeldung zum Anlass genommen, Texte und Verhalten neutraler und konfigurierbarer zu machen. Das war keine große Produktvision, aber die richtige Korrektur: den Kontext ernst nehmen, statt unsere Idee zu verteidigen.

Wenn Forschung nichts ändern darf, ist sie Dekoration

Nutzerzentrierung wird oft über Methoden sichtbar. Interviews, Tests, Prototypen und Nutzungsdaten geben Einblick in die tatsächliche Nutzung. Personas und Journey Maps helfen dabei, diese Erkenntnisse für die weitere Arbeit zu ordnen: Eine Persona bündelt Ziele, Aufgaben, Einschränkungen und Nutzungssituation einer typischen Nutzergruppe. Eine Journey Map zeichnet den Weg nach, den Menschen durch einen Prozess oder Service nehmen. Keine dieser Methoden ist Selbstzweck.

Entscheidend ist, ob die gewonnenen Erkenntnisse etwas verändern. Eine Persona kann sehr hübsch aussehen und trotzdem keine einzige Produktentscheidung beeinflussen. Ein Usability-Test kann professionell durchgeführt sein und am Ende in einer Ablage verschwinden. Ein Workshop kann viele Erkenntnisse produzieren und trotzdem an der Roadmap abprallen, weil die wichtigen Entscheidungen längst getroffen wurden. Dann bleibt Forschung mit Nutzer:innen Dekoration.

Die Folgen müssen nicht spektakulär sein. Vielleicht wird ein Begriff geändert, obwohl er intern beliebt ist. Ein Feature wird kleiner, weil sich die Aufgabe einfacher lösen lässt. Eine Idee wird nicht gebaut, weil sich kein tragfähiger Bedarf zeigt. Oder eine Kennzahl misst künftig nicht nur Klicks, sondern ob Menschen ihr Ziel erreichen.

In meinem Alltag helfen dafür ein paar einfache Fragen:

• Für wen genau ist diese Lösung gedacht?
• Welche Aufgabe versucht diese Person in diesem Moment zu erledigen?
• Was weiß sie nicht, was wir längst wissen?
• Woran würden wir erkennen, dass unsere Idee falsch ist?
• Was würden wir streichen, wenn es zwar schön ist, aber nicht hilft?

Diese Fragen sind schlicht, verändern aber unsere Diskussionen: weg vom persönlichen Geschmack, hin zu überprüfbaren Annahmen.

Die bessere Idee hält eine Prüfung aus

Das Misstrauen gegenüber der eigenen Idee ist kein Plädoyer gegen Intuition. Erfahrung, Fachwissen und gestalterische Qualität bleiben wichtig und sind die Essenz menschlicher Arbeit. Teams sollen nicht jede Entscheidung endlos relativieren.

Aber gute Ideen werden besser, wenn man sie der Realität aussetzt.

Ein früher Prototyp, der scheitert, ist kein Rückschritt. Er ist oft das Günstigste, was einem Projekt passieren kann. Ein verwirrter Blick im Test ist unangenehm, aber wertvoll. Eine Support-Mail kann mehr über ein Interface erzählen als drei interne Abstimmungen. Eine Funktion, die im falschen Kontext schief wirkt, weist auf eine präzisere Lösung hin.

Nutzerzentrierung ist deshalb für mich weniger ein freundliches Etikett als eine Arbeitsweise mit Konsequenzen. Sie zwingt uns, Annahmen sichtbar zu machen. Sie schützt uns davor, interne Logik mit echter Verständlichkeit zu verwechseln. Und sie erinnert daran, dass Menschen Produkte nicht in unseren Konzeptpapieren benutzen, sondern in ihrem Alltag.

Vielleicht ist das der wichtigste Punkt: Nutzerzentrierung heißt nicht, dass wir keine eigenen Ideen haben dürfen. Sie heißt nur, dass wir ihnen nicht zu früh glauben sollten.

Dann fühlt sich Barrierefreiheit schnell wie eine Zusatzaufgabe an. Wie etwas, das man noch irgendwie erfüllen muss, obwohl das eigentliche Produkt schon fertig gedacht ist. In der Praxis zeigt das Thema aber oft erst, ob ein digitales Angebot überhaupt robust genug für die tatsächliche Nutzung ist.

Das Problem liegt nicht bei den Menschen, die ein digitales Angebot unter Bedingungen nutzen, mit denen im Projekt nicht gerechnet wurde. Es liegt in der Projektlogik, die ihre Bedürfnisse als spätes Sonderthema behandelt. Der Idealfall, für den viele digitale Angebote entworfen werden, kommt im Alltag erstaunlich selten vor.

Der Idealfall kommt selten vorbei

Viele digitale Angebote wirken so, als hätten sie eine ziemlich genaue Vorstellung von ihrem Gegenüber: gute Augen, ruhige Umgebung, großer Bildschirm, sichere Mausführung, schnelles Internet, volle Konzentration, vertraute Begriffe und genug Zeit. Diese Nutzungssituation gibt es natürlich. Aber sie ist nur eine von vielen.

In echten Projekten sieht es meistens chaotischer aus. Jemand füllt ein Formular am Smartphone aus, weil kein Laptop greifbar ist. Jemand versteht einen Fachbegriff nicht, weil die Verwaltungssprache unnötig dicht ist. Jemand kann ein Video gerade nicht hören. Jemand erkennt hellgrauen Text auf weißem Hintergrund nicht gut. Und manche Menschen sind dauerhaft auf Screenreader, Vergrößerung, Sprachsteuerung, Tastaturbedienung oder andere assistive Technologien angewiesen.

Barrierefreiheit muss sich allerdings nicht erst dadurch rechtfertigen, dass sie vielen Menschen im Alltag hilft. Für Menschen mit Behinderungen ist sie oft die Voraussetzung, überhaupt teilnehmen zu können. Zugleich machen viele Anforderungen, die für einige Menschen unverzichtbar sind, digitale Angebote auch für andere spürbar besser. Gute Kontraste sind auch draußen in der Sonne nützlich. Klare Beschriftungen lassen sich unter Zeitdruck leichter erfassen. Eine saubere Tastaturbedienung hilft Menschen, die viel ohne Maus arbeiten. Verständliche Fehlermeldungen geben Orientierung, wenn etwas schiefgeht.

Der Blick auf Barrierefreiheit als Sonderthema greift deshalb in jedem Fall zu kurz. Sie ist vielmehr ein Stresstest für Annahmen, die wir über unsere Nutzer:innen treffen.

Die Pflicht ist wichtig, löst allein aber nicht das Problem

Seit dem 28. Juni 2025 gelten in Deutschland die Anforderungen des Barrierefreiheitsstärkungsgesetzes für ausgewählte Produkte und Dienstleistungen. Das Gesetz setzt den European Accessibility Act um und betrifft unter anderem E-Commerce, Bankdienstleistungen, E-Books, bestimmte Selbstbedienungsterminals und weitere verbrauchernahe Angebote. Für öffentliche Stellen sind Barrierefreiheitsanforderungen durch Behindertengleichstellungsgesetz und BITV 2.0 ohnehin seit Jahren Teil der digitalen Realität.

Ich halte diese rechtlichen Vorgaben für wichtig. Ohne verbindliche Regeln würden viele Organisationen Barrierefreiheit weiter vertagen. Nicht aus böser Absicht, sondern weil Projekte fast immer unter Zeitdruck stehen und alles, was nicht hart eingefordert wird, schnell nach hinten rutscht.

Trotzdem reicht die Pflicht allein nicht aus. Man kann eine Website auf einzelne Prüfkriterien hin optimieren und trotzdem ein Angebot bauen, das sich mühsam oder unverständlich anfühlt. Ein Audit kann Probleme sichtbar machen. Es ersetzt aber nicht die grundlegende Frage, ob ein Mensch mit einem konkreten Anliegen wirklich erfolgreich ist.

Die Web Content Accessibility Guidelines des W3C sind dafür ein zentraler Standard. WCAG 2.2 beschreibt Anforderungen entlang der Prinzipien wahrnehmbar, bedienbar, verständlich und robust. Das klingt erst einmal technisch, ist aber eigentlich ein praktischer Denkansatz: Können Menschen Inhalte erfassen, die Oberfläche bedienen, verstehen, was passiert, und das Ganze mit verschiedenen Geräten, Browsern und Hilfsmitteln nutzen?

Wenn man diese Fragen früh stellt, entstehen fast zwangsläufig bessere Produkte. Wenn man sie erst stellt, wenn Design, Text, Komponenten und technische Architektur schon feststehen, wird Barrierefreiheit schnell zur teuren Nachbesserung.

Viele Barrieren sind erstaunlich gewöhnlich

Viele Barrieren in Webprojekten sind keine hochkomplexen Spezialfälle. Sie entstehen durch Dinge, die man jeden Tag sieht. Sie sind so häufig, dass sie einem gar nicht mehr richtig auffallen.

Zu wenig Kontrast. Links, die nur „mehr“ heißen. Icons ohne verständlichen Namen. Überschriften, die visuell schön aussehen, aber semantisch keine Struktur ergeben. Modale Fenster, aus denen man mit der Tastatur nicht sinnvoll herauskommt. Fehlermeldungen, die irgendwo oben auf der Seite stehen, während der Fokus unten im Formular bleibt.

Der WebAIM Million Report 2025 hat auf 94,8 Prozent der untersuchten Startseiten automatisch erkennbare WCAG-Fehler gefunden. Solche Tests finden längst nicht alles, eher im Gegenteil. Interessant ist aber, welche Fehler immer wieder auftauchen: schwache Kontraste, fehlende Alternativtexte, fehlende Formularbeschriftungen, leere Links, leere Buttons und fehlende Sprachangaben. Das sind keine exotischen Randthemen. Das sind Grundlagen.

Hinter diesen Fehlern steckt nicht immer fehlendes Spezialwissen. Oft wird an ihnen sichtbar, wo Design, Inhalt und Technik zu getrennt gedacht wurden.

Schwer wird es, weil diese Grundlagen an vielen Stellen gleichzeitig entstehen: im Designsystem, in Texten, im Komponenten-Code, im Content-Management, in Tests und in der späteren Pflege. Wenn dort niemand bewusst darauf achtet, finden sich kleine Barrieren schnell im Ergebnis wieder.

Saubere Grundlagen schlagen barrierefreie Kosmetik

Ich habe inzwischen eine gewisse Skepsis gegenüber Lösungen entwickelt, die Barrierefreiheit wie eine Schicht behandeln, die man nachträglich über ein Produkt legt. Besonders deutlich wird das bei Barrierefreiheits-Widgets oder Overlays, also nachträglich eingebundenen Bedienfeldern und Skripten, die bessere Kontraste, größere Schrift, Vorlesefunktionen oder Tastaturhilfen versprechen.

Solche Werkzeuge können im Einzelfall nützlich sein. Was sie aber nicht seriös leisten können, ist eine pauschale Garantie: Script einbinden, Anforderungen erfüllt. Die W3C Web Accessibility Initiative weist ausdrücklich darauf hin, dass kein Tool allein feststellen kann, ob eine Website barrierefrei ist. Viele Prüfungen brauchen menschliche Bewertung. Außerdem bezieht sich WCAG-Konformität auf vollständige Seiten und Prozesse, nicht nur auf einzelne Bedienelemente oder ein zusätzliches Bedienfeld, das über einer ansonsten problematischen Oberfläche liegt.

Wenn ein Checkout nicht mit Tastatur funktioniert, wenn ein Formular semantisch kaputt ist oder wenn Fehlermeldungen nicht sinnvoll mit den betroffenen Feldern verbunden sind, löst ein Overlay das Grundproblem nicht zuverlässig. Es kann sogar neue Reibung erzeugen, weil es in die Oberfläche eingreift, ohne deren fachliche und technische Logik wirklich zu verstehen.

Im Web beginnt vieles mit unspektakulär guter Technik. Native HTML-Elemente wie button, input oder a bringen Semantik und Bedienbarkeit mit, die man bei selbstgebauten Komponenten erst wieder herstellen muss. Die Tab-Reihenfolge sollte der sichtbaren und logischen Reihenfolge entsprechen. Wenn sich ein Dialog öffnet, muss klar sein, wo der Fokus ist und wie man wieder herauskommt.

Das ist kein nostalgisches Plädoyer für „früher war HTML besser“. Moderne Webanwendungen brauchen manchmal komplexe Komponenten. Aber je stärker eine Oberfläche vom nativen Verhalten des Browsers abweicht, desto mehr Verantwortung übernimmt das Team selbst. Wer aus einem div einen Button baut, muss anschließend alles nachbauen, was ein echter Button schon mitbringt: Tastaturbedienung, Fokus, Name, Rolle, Zustände und verlässliches Verhalten für assistive Technologien.

An dieser Stelle taucht in Projekten häufig ARIA auf. Die Abkürzung steht für Accessible Rich Internet Applications. Der Standard ermöglicht es Weboberflächen, zusätzliche Informationen an assistive Technologien weiterzugeben. Im HTML geschieht das über Attribute wie aria-expanded, aria-label oder role="dialog". Gedacht ist das vor allem für komplexe UI-Pattern, also wiederkehrende Interaktionsmuster wie Dialoge, Akkordeons, Menüs oder Tab-Navigationen. Ist ein ausklappbarer Bereich gerade offen? Welche Rolle hat ein Dialogfenster? Wie heißt ein Icon-Button, wenn im Button nur ein Symbol steht?

Das ist wertvoll, wenn es für eine Komponente kein passendes natives HTML-Element gibt oder native Elemente ergänzt werden müssen. ARIA ersetzt aber keine klare Oberfläche. Es beschreibt Rollen, Zustände und Beziehungen; es sorgt nicht von allein für Tastaturbedienung, gute Fokusführung oder verständliche Interaktion.

Der WebAIM-Report zeigt seit Jahren eine auffällige Verbindung zwischen viel ARIA und mehr erkennbaren Fehlern. Das heißt nicht automatisch, dass ARIA die Fehler verursacht. Komplexere Seiten nutzen häufiger ARIA. Aber es ist ein gutes Warnsignal: Komplexität macht Zugänglichkeit nicht leichter.

Aus meiner Sicht ist eine der wirksamsten Entscheidungen deshalb oft, weniger clever zu bauen. Sonderverhalten, visuelle Tricks ohne semantische Bedeutung und Komponenten für den Idealfall machen ein Angebot unnötig fragil. Klare Struktur, robuste Interaktion und Inhalte, die nicht gegen das Medium arbeiten, sind in vielen Fällen die bessere Grundlage.

Formulare zeigen uns die Wahrheit

Besonders deutlich wird das bei Formularen. Wahrscheinlich, weil Formulare der Ort sind, an dem digitale Angebote ihre Versprechen einlösen müssen. Eine Startseite kann freundlich wirken. Ein Serviceportal kann modern aussehen. Aber wenn ein Mensch am Ende an einem Pflichtfeld, einer Fehlermeldung oder einem unverständlichen Zwischenschritt scheitert, zählt der Rest wenig.

In Verwaltungsprojekten ist das noch einmal eine Ecke heikler. Bürger:innen suchen sich den Prozess nicht freiwillig aus. Wer einen Antrag stellen muss, eine Leistung braucht oder eine Frist einhalten soll, kann nicht einfach sagen: Dann nehme ich eben einen anderen Anbieter. Gerade deshalb reicht es nicht, digitale Verwaltungsleistungen formal online zu stellen. Sie müssen verständlich, bedienbar und verlässlich sein.

Ein gutes Formular erklärt, was gebraucht wird. Es verwendet nachvollziehbare Begriffe oder erklärt Fachbegriffe dort, wo sie unvermeidbar sind. Es markiert Fehler so, dass sie wahrnehmbar und korrigierbar sind. Es erhält Eingaben, wenn etwas schiefgeht. Es funktioniert auf kleinen Bildschirmen und zwingt Menschen nicht unnötig in Zeitdruck.

Nichts davon ist außergewöhnlich oder spektakulär. Darin liegt jedoch die Qualität: Der Prozess lässt Menschen nicht im falschen Moment allein.

Barrierefreiheit gehört in die laufende Arbeit

Der schwierigste Schritt ist selten, ein einzelnes Problem zu beheben. Der schwierigste Schritt ist, Barrierefreiheit aus der Nacharbeitslogik herauszubekommen.

Wenn ein Team erst kurz vor Veröffentlichung testet, findet es Probleme zu einem Zeitpunkt, an dem Änderungen teuer und unangenehm sind. Dann wird verhandelt: Muss das wirklich noch sein? Reicht das für den Launch? Können wir das in Phase zwei machen? Diese Gespräche kenne ich aus Projekten gut genug. Sie sind selten böse gemeint, aber sie zeigen, dass Barrierefreiheit nicht Teil der normalen Qualitätsdefinition war.

Besser wird es, wenn Zugänglichkeit in den Alltag rutscht: in Designsysteme mit semantisch und interaktiv sauberen Komponenten, in Redaktionsprozesse für Alternativtexte, Linktexte und verständliche Sprache, in Akzeptanzkriterien für die Bedienung jenseits von Maus und großem Bildschirm. Auch Tests gehören in diesen Alltag. Automatisierte Prüfungen sind hilfreich, ersetzen aber weder Tastaturtests und Screenreader-Checks noch echte Nutzungsszenarien.

Das muss nicht heißen, dass jedes Projekt sofort perfekt ist. Perfektion ist ohnehin ein schlechter Maßstab, wenn sie dazu führt, dass niemand anfängt. Aber es macht einen großen Unterschied, ob Barrierefreiheit als gelegentlicher Sondertermin behandelt wird oder als normale Eigenschaft guter Produktarbeit.

Gute Nutzererfahrung muss etwas aushalten

Für mich ist Barrierefreiheit weniger ein separates Fachthema als ein Realitätsabgleich. Sie fragt: Funktioniert unser Angebot auch dann, wenn nicht alle Umstände ideal sind? Wenn jemand anders sieht, hört, liest, navigiert, versteht oder eingibt, als wir es beim Entwerfen angenommen haben?

Diese Frage ist unbequem, weil sie viele Entscheidungen berührt: Gestaltung, Sprache, Code, Komponenten, Content-Management, Beschaffung, Tests, Betrieb. Barrierefreiheit lässt sich nicht vollständig an eine Person im Team delegieren. Das macht sie im Projektalltag manchmal mühsam.

Aber sie ist auch eine der verlässlichsten Methoden, um digitale Angebote besser zu machen: zugänglicher, klarer, stabiler, verständlicher.

Die Pflicht ist dabei kein Gegensatz zur Chance. Sie sorgt dafür, dass das Thema nicht beliebig bleibt. Bessere Nutzererfahrung entsteht im Alltag der Produktarbeit: in Entscheidungen über Sprache, Gestaltung, Komponenten, Tests und Pflege.

Barrierefreiheit gehört deshalb in dieselbe Qualitätsdefinition wie Verständlichkeit, Stabilität und Sicherheit. Dann muss ein Team kurz vor dem Launch nicht mehr fragen, ob dafür noch Zeit ist. Zugänglichkeit ist von Anfang an Teil der Arbeit und eine gemeinsame Aufgabe.

Ich selbst habe seit meinem 15. Lebensjahr eine eigene Website. Damals war sie ein Ort für persönliche Interessen und später auch für Bewerbungen um einen Ausbildungsplatz. Heute bin ich vermutlich bei der sechsten oder siebten Version angekommen. Aus einem jugendlichen „Ich stelle mal etwas ins Netz“ ist über die Jahre ein Ort geworden, der berufliche Arbeit, Projekte, Gedanken und ein bisschen Alltag zusammenhält.

Bei einem Profil scrolle ich durch einen vorgegebenen Ausschnitt. Bei einer Website betrete ich eher einen Ort. Manchmal ist er aufgeräumt, manchmal etwas schräg, manchmal technisch beeindruckend und manchmal super schlicht. Aber fast immer merkt man, dass dort jemand selbst entschieden hat, wie dieser Ort aussehen und funktionieren soll.

Bei meiner eigenen Website ist das ähnlich. Sie ist kein Neuanfang, sondern eher die nächste Renovierung eines Ortes, der mich schon lange begleitet. Früher mit anderen Inhalten, anderen Zielen und sicher auch anderen ästhetischen Entscheidungen. Zum Glück.

Nicht nur ein Profil

Ich habe nichts Grundsätzliches gegen soziale Netzwerke. LinkedIn ist für mich beruflich nützlich. Ich finde dort Menschen, Projekte, Diskussionen und manchmal auch gute Impulse, die ich sonst nicht gesehen hätte. Aber ein Social-Media-Profil ist für mich kein eigener Ort. Es ist eher ein angemieteter Stand auf einem großen Marktplatz.

Das hat Vorteile: Laufkundschaft, Infrastruktur, Suchfunktionen, Reichweite. Aber es gibt eben auch Regeln, die ich nicht gemacht habe. Layout, Sichtbarkeit, Sortierung und Aufmerksamkeit werden stark von der Plattform geprägt. Selbst wenn ich dort etwas Eigenes schreibe, lebt es in einer Umgebung, die auf Bewegung, Reaktion und Nächstes ausgelegt ist.

Eine Website funktioniert anders. Sie muss nicht ständig senden und nicht jeden Tag beweisen, dass sie noch relevant ist. Jemand kann heute auf einen Text stoßen, ihn in drei Monaten wiederfinden und in zwei Jahren immer noch verlinken. Das ist eine andere Art von digitaler Präsenz.

Ein eigener Ort ist auch eine Haltung

Eine wichtige Inspiration für diesen Gedanken war Naz Hamids Artikel Your Site is a Home. Ich mag das Bild, weil es etwas beschreibt, das man technisch leicht übersehen kann: Eine Website ist nicht nur ein Publikationskanal. Sie ist ein Raum, den man gestalten kann.

Für mich ist dieser Raum vielleicht weniger Wohnzimmer und mehr Arbeitszimmer. Ein Ort mit Schreibtisch, Notizen, ein paar Büchern im Regal und Dingen, die noch nicht ganz fertig sind. Nicht alles muss dort präsentiert werden wie auf einer Bühne. Manches darf einfach vorhanden sein, weil es für mich wichtig ist oder weil ich glaube, dass es für andere nützlich sein könnte.

In der IndieWeb-Community gibt es dafür den einfachen, aber starken Gedanken "own your data": Die eigenen Inhalte, die eigene Identität und die eigene Adresse im Netz sollten nicht vollständig von externen Plattformen abhängen. Das klingt schnell wesentlich größer, als es im Alltag sein muss. Für mich heißt es erst einmal nur: Wenn ich einen Gedanken ausformuliere, soll er an einem Ort liegen, den ich kontrollieren kann.

Es macht einen Unterschied, ob die eigene Website der Ausgangspunkt für solche Gedanken ist oder nur ein weiterer Link in einer Bio.

Mehr als eine digitale Visitenkarte

Diese meine Website hat natürlich auch die klassischen Seiten, die man auf einer persönlichen Website erwartet. Es gibt eine Über-mich-Seite, auf der ich knapp erzähle, wer ich bin und woran ich arbeite. Es gibt eine Projektübersicht, weil Projekte oft konkreter erklären, was jemand tut, als jede sauber formulierte Selbstbeschreibung. Und es gibt den Bereich für Artikel, in dem längere Gedanken einen festen Platz bekommen. Und hey, du liest sogar gerade einen davon.

Neu hinzugekommen ist außerdem eine Werkzeuge-Seite, also eine klassische /uses-Page. Solche Seiten schaue ich mir selbst bei anderen gern an, weil Werkzeuge immer auch Arbeitsweisen verraten: Geräte, Software, Infrastruktur, kleine Vorlieben und pragmatische Kompromisse. Meine Liste ist genau so gemeint: als kuratierter Blick auf die Dinge, die mich im Alltag begleiten und sich über die Zeit bewährt haben.

Weltbewegend ist das natürlich nicht. Aber ich finde solche Listen sympathisch. Sie erzählen oft mehr über Arbeitsweisen und Vorlieben, als man auf den ersten Blick erwarten würde.

Schreiben ohne Content-Maschine

Der neue Artikelbereich ist für mich der wichtigste Teil der Website. Ich möchte dort wieder regelmäßiger Gedanken teilen, aber nicht im Sinne eines klassischen Blogs mit festem Redaktionsplan. Es geht mir auch nicht darum, möglichst viele suchmaschinenoptimierte Texte zu produzieren. Dafür habe ich weder die richtige Motivation noch den Wunsch, meine Website in eine Content-Maschine zu verwandeln.

Ein wenig Content-Marketing spielt trotzdem eine Rolle. Wenn jemand durch einen Text besser versteht, wie ich über digitale Produkte, Softwaredesign oder Verwaltung denke, ist das hilfreich. Der Ausgangspunkt ist aber eine andere Frage: Welcher Gedanke ist es wert, ordentlich aufgeschrieben zu werden?

Deshalb erhebe ich auch keine Besucherstatistiken. Das hat mit Datenschutz und Datensparsamkeit zu tun, aber nicht ausschließlich. Ich möchte mich gar nicht erst daran gewöhnen, Themen nach Zahlen auszuwählen oder Texte danach zu beurteilen, wie oft sie geklickt wurden. Für diese Website ist mir wichtiger, dass ein Gedanke stimmt und zu mir passt, als dass er gut performt.

Mich interessieren eher persönliche Praxis-Essays: Texte, die aus Erfahrungen, Beobachtungen und wiederkehrenden Fragen entstehen. Themen wie Softwaredesign, Unternehmerkultur oder digitale Verwaltung sind oft zu komplex für einen kurzen Beitrag in einem Feed. Sie brauchen manchmal ein bisschen Raum. Nicht unbedingt 20 Seiten, aber genug Platz, um einen Gedanken nicht nach dem zweiten Absatz schon wieder abzuwürgen.

Ich habe in Projekten oft erlebt, dass bestimmte Themen immer wieder auftauchen. Warum gute digitale Prozesse nicht nur eine Frage der Technik sind. Warum Nutzerfreundlichkeit in Verwaltungsportalen kein dekorativer Zusatz ist. Warum Entscheidungen, die einmal richtig waren, später trotzdem ein Update brauchen können. Solche Gedanken erkläre ich gerne im Gespräch. Aber irgendwann ist es auch angenehm, sie einmal sauber aufzuschreiben und später einfach sagen zu können: Hier, dazu habe ich mal etwas geschrieben.

Das ist nicht sonderlich glamourös, aber ziemlich praktisch.

Gedanken dürfen wachsen

Eine persönliche Website muss für mich nicht nur aus fertigen, endgültigen Texten bestehen. Maggie Appleton beschreibt in ihrem Text über Digital Gardens Websites als Orte, an denen Ideen wachsen, überarbeitet und miteinander verbunden werden können. Das passt gut zu dem, was ich mit meinen Artikeln vorhabe, auch wenn ich hier keinen vollständigen digitalen Garten baue.

Nicht jeder Text muss der abschließende Stand meiner Meinung sein. Positionen verändern sich durch Projekte, Gespräche oder schlicht durch Zeit. Deshalb möchte ich Texte später ergänzen, verlinken oder einordnen können. Ein Plattformbeitrag wirkt oft wie ein Moment; hier kann ein Text ein Dokument bleiben, an dem ich bei Bedarf noch einmal vorbeigehe.

Erst hier, dann anderswo

Ein weiterer hilfreicher Gedanke aus dem IndieWeb ist POSSE: Publish on your Own Site, Syndicate Elsewhere. Also: zuerst auf der eigenen Website veröffentlichen und danach an anderen Orten teilen.

Das ist für mich ein guter Umgang mit Plattformen. Menschen lesen nun mal dort, wo sie ohnehin sind. Wenn ich einen neuen Artikel auf LinkedIn teile, ist das völlig in Ordnung. Aber der eigentliche Text liegt hier. Die Plattform ist dann ein Verteiler und kein Archiv. Hinweis – nicht Heimat.

Das nimmt etwas Druck raus: Ein Text muss hier nicht nach den Regeln eines Feeds funktionieren. Er darf ruhiger anfangen, einen Umweg nehmen und für Menschen geschrieben sein, die wirklich etwas lesen wollen. Wer nur eine schnelle Antwort sucht, fragt heute ohnehin oft eine KI.

Pragmatisch gebaut

Als Webentwickler ist diese Website für mich auch ein technisches Projekt. Ich habe mich für Next.js und Tailwind CSS entschieden, weil beide Werkzeuge gut zu meiner Arbeitsweise passen: modern, performant, gut pflegbar. Kein schweres CMS, kein Baukasten, aber auch kein selbst gebautes System, nur weil ich es könnte.

Als Startpunkt habe ich das Spotlight-Template von Tailwind Plus genutzt. Das ist ein Template für persönliche Websites auf Basis von Next.js, Tailwind CSS, React und MDX. Ich hatte es schon länger auf meiner Liste, weil es sauber gebaut ist und eine gute Mischung aus Struktur, Zurückhaltung und Anpassbarkeit mitbringt. Von dort aus habe ich die Website zu meinem eigenen Ort weitergebaut: angepasst, erweitert, um eigene Komponenten ergänzt und mit nützlichen Funktionen versehen. So ist aus einer guten Vorlage nach und nach etwas Eigenes geworden.

Hätte ich alles komplett neu gestalten und entwickeln können? Klar. Hätte ich mich dabei vermutlich in Details verloren, die für den eigentlichen Zweck dieser Website zweitrangig sind? Ebenfalls klar. Ich habe auch noch einen Job und ein echtes Leben, das nicht komplett für ein persönliches Website-Redesign reserviert ist. Und glaub mir: Das alles hat auch so schon mehr als genug Zeit verschlungen. Meinem perfektionistischen Kopf sei Dank. Manchmal ist die pragmatische Lösung schlicht die bessere.

Hosting, das zur Idee passt

Gehostet wird die Seite bei Uberspace. Das passt für mich gut zur Grundidee dieser Website. Uberspace richtet sich an Menschen, die gerne selbst etwas betreiben, eine Shell nicht als Zumutung empfinden und ein gewisses Maß an technischer Kontrolle schätzen. Auf der Website beschreibt sich Uberspace unter anderem als Hosting für Selbermacher:innen, Kommandozeilenliebhaber:innen und Menschen, die Kontrolle behalten wollen. Das ist natürlich charmant formuliert, trifft den Punkt aber ganz gut.

Die Seite wird aus dem Git-Repository auf den Uberspace gezogen und dort gebaut. Über Web Backends kann ich einen nativen Next.js-Server laufen lassen, statt nur einen statischen Export abzulegen. Das ist nicht an jeder Stelle zwingend nötig, gibt mir aber Flexibilität für später, ohne direkt in die Logik einer großen Hosting-Plattform einzuziehen.

Vercel, Netlify und andere Plattformen können für viele Projekte die richtige Wahl sein. Für diese Website wollte ich bewusst weniger Plattform-Magie und mehr eigenes Verständnis. Dazu kommt, dass mir digitale Souveränität wichtig ist und Uberspace in Deutschland hostet. Für dieses Projekt und für meine persönlichen Daten, die ich in einer eigenen Nextcloud verwalte, ist Uberspace eine gute Wahl.

Was daraus werden soll

Diese Website soll kein großes Manifest sein. Sie soll ein Ort sein, den ich gerne pflege und auf den ich gerne verweise. Ein Ort für meine Arbeit, meine Projekte, meine Gedanken und ein paar Beobachtungen aus dem Alltag zwischen Code, Produktentwicklung, Unternehmertum und öffentlicher Verwaltung.

Vielleicht wird dieser Ort mit der Zeit ordentlicher. Vielleicht auch an manchen Stellen absichtlich chaotischer. Ich möchte ihn nicht zu eng planen, weil darin für mich ein Teil des Reizes liegt. Eine persönliche Website darf sich verändern. Sie darf wachsen, Dinge ausprobieren, alte Entscheidungen überdenken und neue Formen finden.

Wenn du das hier liest und den Weg zu mir gefunden hast: Schön, dass du da bist.

Und wenn du selbst eine persönliche Website hast, schick sie mir gerne. Am besten dort, wo wir uns wahrscheinlich ohnehin begegnen: auf LinkedIn. Ich sehe mir solche Orte immer noch lieber an als fast jedes Profil.