Ein praktischer Leitfaden zur Planung, Gestaltung und Einführung eines staatlichen oder öffentlichen Service‑Portals: Barrierefreiheit, Inhalte, Sicherheit, Hosting und Wartung.
Ein Portal für öffentliche Dienste kann nicht am ersten Tag „alles für alle“ sein. Beginnen Sie damit, eine klare Zweckbeschreibung zu schreiben, die auf eine Seite passt und von Beschaffung, Führung und Mitarbeiterinnen und Mitarbeitern lesbar ist.
Entscheiden Sie, ob das Portal in erster Linie:
Diese Entscheidung beeinflusst alles Weitere – von der Inhaltsstruktur bis zur Identitätsprüfung und Unterstützung.
Listen Sie Ihre wichtigsten Gruppen und die Top-Aufgaben, die sie erledigen müssen:
Bleiben Sie praktisch: Zielgruppen werden durch das definiert, was sie zu tun versuchen, nicht durch demografische Merkmale.
Einigen Sie sich auf eine kleine Anzahl messbarer Ergebnisse, wie zum Beispiel:
Planen Sie, wie Sie diese messen (Analytics, kurze Feedback‑Prompts, Callcenter‑Tagging).
Schreiben Sie die realen Rahmenbedingungen auf, die den Umfang beeinflussen:
Ein einfaches Goals‑and‑Metrics‑Briefing wird zur Referenz, wenn Prioritäten später konkurrieren – und hält das Projekt auf den öffentlichen Nutzen fokussiert.
Gute Regierungsportale beginnen mit Klarheit: Was versuchen Nutzerinnen und Nutzer tatsächlich zu erreichen, wenn sie ankommen? Wenn Sie um interne Abteilungsstrukturen herum designen, zwingen Sie Bewohner dazu, Bürokratie in verständliche Absichten zu übersetzen. Forschung hilft dabei, das umzudrehen.
Sammeln Sie „Top‑Aufgaben“ aus Quellen, die Sie bereits haben:
Achten Sie auf Muster wie „verlängern“, „beantragen“, „bezahlen“, „melden“ und „Status prüfen“. Diese Verben prägen später Navigationsbezeichnungen, Einstiegsseiten und Formularflüsse.
Wählen Sie eine Handvoll priorisierter Dienste (z. B. Genehmigungen, Leistungen, Zahlungen) und kartieren Sie die Reise aus Sicht der Nutzerin/des Nutzers. Beziehen Sie ein:
So verhindern Sie ein Portal, das nur Richtlinien erklärt, aber Menschen nicht zum Abschluss führt.
Halten Sie Personas einfach und praktisch: „Jemand, der zum ersten Mal Unterstützung beantragt“, „Ein Kleinunternehmer, der eine Gebühr zahlt“, „Ein Einwohner mit eingeschränkten Deutschkenntnissen“. Konzentrieren Sie sich auf Einschränkungen (Zeit, Stress, Gerät, Leseverständnis, Barrierefreiheitsbedürfnisse) statt auf Demografie.
Führen Sie kurze Interviews oder leichte Usability‑Tests mit Prototypen oder sogar Skizzen durch. Bitten Sie Teilnehmer, Schlüsselaufgaben zu erledigen und zu beschreiben, was sie zu finden erwarten. Sie werden frühzeitig verwirrende Begriffe, fehlende Schritte und Vertrauensprobleme entdecken – bevor Inhalte und Build in teure Nacharbeit übergehen.
Ein Portal für öffentliche Dienste ist dann erfolgreich, wenn Menschen schnell finden, was sie brauchen – selbst wenn sie nicht wissen, welche Behörde zuständig ist. Informationsarchitektur (IA) ist die „Karte“ Ihrer Seite: welche Inhalte existieren, wie sie gruppiert sind und wie Nutzer sich bewegen.
Bevor Sie Menüs entwerfen, sammeln Sie, was Sie bereits haben:
Taggen Sie jedes Element mit grundlegenden Metadaten (Thema, Zielgruppe, Servicetyp, zuletzt aktualisiert, verantwortliches Team). Das verhindert, dass Sie bereits vorhandene Seiten neu erstellen – und zeigt, wo Inhalte veraltet oder dupliziert sind.
Die meisten Menschen kommen mit einer Absicht: „Lizenz verlängern“, „Leistung beantragen“, „Problem melden“. Strukturieren Sie Kategorien um diese Aufgaben, nicht um Agenturnamen. Ein einfacher Test: Wenn jemand ohne Kenntnis der Behördenstruktur das Menü nicht erraten kann, muss die Gruppierung überarbeitet werden.
Wenn mehrere Behörden zu einer Journey beitragen, behandeln Sie sie als einen Service mit klaren Schritten. Verlinken Sie unterstützende Seiten (Voraussetzungen, benötigte Dokumente, Kontakte) von einer einzigen Service‑Hub‑Seite.
Zielen Sie darauf ab, Schlüsselservices in 2–3 Klicks von der Startseite erreichbar zu machen. Verwenden Sie eine kleine Menge an Top‑Level‑Kategorien sowie prominente Shortcuts für stark nachgefragte Aufgaben. Vermeiden Sie „Mega‑Menüs“ voller interner Begriffe; nutzen Sie klare, laut aussprechbare Labels.
Suche wird oft zur primären Navigation. Planen Sie sie bewusst:
Gut gestaltete IA und Navigation reduzieren Anrufe, Beschwerden und Abbrüche – und lassen das Portal ruhig und vertrauenswürdig wirken.
Barrierefreiheit ist kein „Nice‑to‑have“ für eine Regierungswebsite – sie ist Teil des gleichberechtigten Zugangs zu Diensten. Streben Sie die Einhaltung von WCAG (typischerweise WCAG 2.2 AA) an und behandeln Sie Barrierefreiheit als Designvorgabe, nicht als abschließende Prüfung.
Verwenden Sie eine klare Seitenstruktur: eine Hauptüberschrift (H1), logische Unterüberschriften (H2/H3) und beschreibende Linktexte (vermeiden Sie „hier klicken“). Konsistente Navigation und vorhersehbare Seitenlayouts helfen allen, einschließlich Menschen mit kognitiven Einschränkungen und Screenreader‑Nutzern.
Machen Sie Lesbarkeit mühelos: wählen Sie kontraststarke Farbkombinationen, angenehme Zeilenlängen und vermeiden Sie winzige Schrift. Interaktive Elemente sollten konsistente Fokus‑Zustände haben, damit Tastaturnutzer immer sehen, wo sie sich befinden.
Automatische Prüfungen sind nützlich, fangen aber nicht alles ein. Führen Sie manuelle Tests als Teil Ihrer „Definition of Done“ durch:
Inklusives Design betrifft auch Worte. Verwenden Sie einfache Sprache, erklären Sie erforderliche Schritte und vermeiden Sie Jargon und nicht erklärte Abkürzungen. Muss ein Begriff verwendet werden (z. B. ein rechtlicher Begriff), definieren Sie ihn dort, wo er erscheint.
Formulare sind oft die Stelle, an der Nutzer stecken bleiben. Sorgen Sie dafür, dass jedes Feld ein sichtbares Label hat, an Stellen mit möglicher Verwirrung Hilfetexte erscheint und Fehlernachrichten spezifisch und für Hilfstechnologien ankündigbar sind (z. B. „Geben Sie Ihre Sozialversicherungsnummer ein“ statt „Ungültige Eingabe“). Verlassen Sie sich nicht ausschließlich auf Farbe zur Fehleranzeige.
Fügen Sie eine Barrierefreiheits‑Erklärung hinzu, die den Compliance‑Status, bekannte Probleme und Kontaktmöglichkeiten zur Meldung von Problemen beschreibt. Setzen Sie sie in einen konsistenten Footer‑Link (z. B. /accessibility) und stellen Sie sicher, dass Rückmeldungen überwacht und beantwortet werden.
Ein Portal für öffentliche Dienste steht und fällt damit, ob Informationen aktuell bleiben. Content‑Governance ist das praktische System, das beantwortet: was veröffentlicht wird, von wem, wie es geprüft wird und wie es aktuell bleibt. Ohne Governance werden Seiten veraltet, Antworten duplizieren sich und Vertrauen schwindet.
Bevor Sie Aufgaben zuteilen, definieren Sie die Haupt‑„Dinge“, die Ihre Seite veröffentlicht, damit alle Informationen gleich strukturiert werden. Ein einfaches Modell umfasst oft: Services (Schritt‑für‑Schritt‑Anleitungen), News, Alerts, Standorte und Kontakte. Für jeden Typ legen Sie Pflichtfelder fest (z. B. Anspruchsvoraussetzungen, Gebühren, Bearbeitungszeit, benötigte Dokumente, Öffnungszeiten), sodass Inhalte abteilungsübergreifend konsistent sind.
Governance funktioniert, wenn Verantwortlichkeiten explizit sind. Definieren Sie, wer:
Dokumentieren Sie auch Durchlaufzeiten und einen „Dringend‑Änderung“‑Pfad für Notfallmeldungen und zeitkritische Updates.
Ein Portal braucht klare, konsistente Sprache. Ihr Stilguide sollte Ton und Lesbarkeit, genehmigte Terminologie (und verbotene Synonyme), Formatregeln für Datum, Uhrzeit, Adressen und Nummerierung sowie Regeln für Links (z. B. kein „hier klicken“) festlegen. Legen Sie ihn an einer zentralen Stelle ab und verlinken Sie ihn in internen Workflow‑Dokumenten.
Jede Seite sollte ein Überprüfungsdatum haben und einen Mechanismus, um „Verantwortlicher hat die Organisation verlassen“ zu kennzeichnen. Definieren Sie, wann Inhalte archiviert werden, wie Versionen gespeichert werden und was in einer Änderungsnotiz protokolliert werden muss. Versionierung ist keine Bürokratie – sie ist der Beleg dafür, was sich wann und warum geändert hat.
Ein Portal für öffentliche Dienste sollte sich für Bewohner unabhängig von ihrer Sprache gleich nutzbar anfühlen. Mehrsprachigkeit ist nicht nur Übersetzung – es geht darum sicherzustellen, dass Menschen dieselben Top‑Aufgaben mit gleicher Zuversicht erledigen können.
Versuchen Sie nicht, alles am ersten Tag zu übersetzen. Priorisieren Sie Seiten, die direkt beeinflussen, ob jemand Hilfe erhält oder eine Anforderung erfüllt:
Der Ansatz „Top‑Aufgaben zuerst“ liefert schnellen Nutzen und verringert das Risiko partieller oder veralteter Übersetzungen für kritische Dienste.
Maschinelle Übersetzung kann für Entdeckungsinhalte nützlich sein, ist aber riskant bei rechtlichen, sicherheitsrelevanten, finanziellen oder compliance‑relevanten Anweisungen. Für alles, was dazu führen könnte, dass jemand eine Frist verpasst oder das falsche Formular einreicht, nutzen Sie professionelle Übersetzung und eine Review‑Stufe.
Wenn Sie automatische Übersetzung für nicht‑kritische Seiten anbieten, kennzeichnen Sie sie deutlich und halten Sie die Originalsprache mit einem Klick erreichbar.
Ein Sprachumschalter sollte den Kontext erhalten: Wenn jemand die Sprache wechselt, sollte er auf derselben Seite (und idealerweise demselben Abschnitt) bleiben, nicht auf der Startseite landen.
Machen Sie den Schalter auffindbar und vorhersehbar:
Kulturelle Klarheit umfasst kleine Details, auf die Menschen achten:
Wenn Formulare Teil Ihres Portals sind, testen Sie sie in jeder Sprache, damit Platzhalter, Validierungs‑ und Hilfetexte ebenfalls übersetzt und kulturell verständlich sind.
Mehrsprachige Seiten scheitern, wenn Übersetzungen hinter den Aktualisierungen zurückbleiben. Fügen Sie Governance‑Regeln hinzu, damit Inhalte synchron bleiben:
Stellen Sie bei Plattformentscheidungen sicher, dass Ihre IA und Ihr CMS Versionierung und sprachspezifische Inhaltsbeziehungen unterstützen, damit Aktualisierungen nicht verloren gehen.
Ein Regierungsportal steht und fällt damit, wie zuverlässig es Informationen in großem Maßstab veröffentlichen kann. Das CMS sollte den „sicheren Weg“ für Redakteurinnen und Redakteure so einfach wie möglich machen und zugleich Inhalte so strukturieren, dass sie wiederverwendbar sind.
Suchen Sie ein CMS, das klare Berechtigungen und Rechenschaftspflichten unterstützt. Mindestens sollte es rollenbasierte Zugriffe (Autor, Prüfer, Freigeber, Admin), Freigabe‑Workflows und einen vollständigen Audit‑Trail bieten, damit Sie ohne Rätselraten beantworten können: „Wer hat was wann geändert?“
Versionshistorie und einfache Rollbacks sind ebenso wichtig. Wenn sich Richtlinien schnell ändern, müssen Teams Seiten sicher aktualisieren können, in dem Wissen, dass eine vorherige Revision wiederherstellbar ist.
Vermeiden Sie es, wichtige Informationen in Einzelseiten‑Designs zu vergraben. Nutzen Sie strukturierte Felder (Titel, Zusammenfassungen, Anspruchsvoraussetzungen, benötigte Dokumente, Gebühren, Bearbeitungszeiten, Kontaktkanäle), damit dieselben Inhalte konsistent in erscheinen:
Dieser Ansatz hilft auch bei mehrsprachigen Inhalten, weil Übersetzungen feldweise statt seitenweise ausgerichtet werden.
Definieren Sie eine kleine Menge an Seitentemplates, sodass Nutzer wissen, was sie erwarten können:
Kartieren Sie die Systeme, mit denen Ihr Portal verbunden sein muss: Online‑Formulare, Zahlungsanbieter, Fallmanagement, Karten/Standortdienste, Terminbuchung und Analytics. Entscheiden Sie, welche Inhalte im CMS leben und welche aus externen Systemen gezogen werden.
Wenn Sie Journeys prototypen oder validieren möchten, bevor Sie sich auf einen vollständigen Build festlegen, kann ein vibe‑coding‑Ansatz Teams helfen, schneller voranzukommen, ohne Governance zu überspringen. Zum Beispiel erlaubt Koder.ai Teams, bürgerorientierte Flows per Chat zu entwerfen, eine funktionierende Web‑App (React) und Backend (Go + PostgreSQL) zu generieren und im „Planungsmodus“ zu iterieren, bevor Implementierungsdetails festgelegt werden. Wenn der Ansatz validiert ist, kann man den Quellcode exportieren, um ihn in Sicherheitsprüfungen und Beschaffungsprozesse einzubinden.
Schreiben Sie ein kurzes „Editor‑Playbook“, das Benennungsregeln, Prüfprozesse, Accessibility‑Checks und den Umgang mit dringenden Updates abdeckt. Machen Sie es zum Teil des Onboardings und halten Sie es an einem zentralen Ort aktuell (z. B. /content-guidelines).
Sicherheit und Datenschutz sind keine Extras für eine Regierungswebsite – sie sind Teil der Servicequalität. Menschen nutzen ein Portal nur, wenn es sicher wirkt, sich klar erklärt und persönliche Daten sorgsam behandelt.
Beginnen Sie mit Datenminimierung. Für jedes Formularfeld sollten Sie in einfacher Sprache zwei Fragen beantworten können: Warum brauchen wir das? und Was passiert, wenn der Nutzer es nicht angibt? Wenn ein Feld „schön zu haben“ ist, entfernen Sie es oder machen es optional.
Wo Sie Daten erheben, fügen Sie kurzen Hilfetext direkt neben dem Feld hinzu (nicht irgendwo anders versteckt). Das verringert Abbrüche und stärkt das Vertrauen.
Verwenden Sie durchgehend HTTPS – ohne Ausnahmen – und leiten Sie HTTP automatisch um. Sichern Sie Admin‑Zugänge:
Öffentliche Formulare ziehen automatisierten Missbrauch an und können gerade dann ausfallen, wenn sie gebraucht werden. Kombinieren Sie mehrere Schutzmaßnahmen statt sich auf ein Einzeltool zu verlassen:
Veröffentlichen Sie eine Datenschutzerklärung, die lokale Regeln erfüllt und für Bewohner verständlich formuliert ist. Geben Sie an, was Sie sammeln, warum, wer Zugriff hat und wie lange Daten aufbewahrt werden. Verwenden Sie für Cookies einen klaren Zustimmungsmechanismus und vermeiden Sie unnötige Tracker.
Wenn Sie Anhänge akzeptieren (Ausweise, Zertifikate), behandeln Sie diese als hohes Risiko: Beschränken Sie Dateitypen, scannen Sie Uploads, speichern Sie sie sicher und begrenzen Sie, wer Zugriff hat. Definieren Sie Löschprozesse und testen Sie sie – Datenschutz bedeutet auch, Daten auf Verlangen löschen zu können.
Menschen nutzen ein Portal oft, wenn sie schnelle Antworten brauchen – häufig auf älteren Handys, mit begrenzten Daten oder schlechten Netzen. Wenn Seiten schwer oder die Seite nicht erreichbar ist, schwindet sofort das Vertrauen.
Betrachten Sie „langsam, aber nutzbar“ als Basis. Halten Sie das Seitengewicht niedrig: Bilder komprimieren, Autoplay‑Medien vermeiden und nur Skripte laden, die direkt für die Aufgabe auf der Seite nötig sind.
Eine praktische Regel: Wenn eine Seite nicht hilft, eine Bürger‑Journey abzuschließen, sollte sie die Journey nicht verlangsamen.
Für Inhalte, die für alle gleich sind (Leitfäden, Anspruchsregeln, Standorte), kann Caching die Ladezeiten deutlich reduzieren und Serverlast abfangen. Ein CDN liefert Assets näher an die Nutzenden und hilft, plötzliche Nachfrage zu puffern. Achten Sie darauf, dass Caching‑Regeln die Privatsphäre respektieren (z. B. keine personalisierten Seiten cachen).
Legen Sie einfache, messbare Budgets früh fest und halten Sie sie bei Design‑ und Inhaltsupdates ein:
Veröffentlichen Sie diese Ziele intern, damit Content‑ und Design‑Teams die Kompromisse kennen.
Fristen, Leistungsverlängerungen, Unwetter und Notfälle können große Lastspitzen verursachen. Bereiten Sie sich mit Lasttests, skalierbarem Hosting und einem „reduzierten, aber funktionalen“ Modus vor, der Kernaufgaben verfügbar hält (Status‑Updates, Schlüssel‑Formulare, Kontaktoptionen), selbst wenn nicht‑essentielle Features pausiert werden.
Richten Sie Uptime‑Monitoring, Performance‑Tracking und Alerting vor dem Launch ein. Messen Sie Real‑User‑Performance (nicht nur Laborwerte), legen Sie On‑Call‑Erwartungen fest und dokumentieren Sie Reaktionsschritte, damit Probleme schnell und konsistent behoben werden können.
Die meisten Menschen besuchen ein Portal, um etwas zu tun: beantragen, verlängern, melden, anfordern oder bezahlen. Die Aufgabe eines Formulars ist, sie mit minimalem Aufwand und maximaler Sicherheit durch den Prozess zu bringen.
Gestalten Sie die Journey als kleine, klare Schritte (z. B. Anspruch → Angaben → Dokumente → Überprüfung → Absenden). Zeigen Sie mit einem einfachen Fortschrittsindikator, wo der Nutzer steht, und verwenden Sie klare Sprache, sodass jeder Schritt die Frage beantwortet: „Was muss ich jetzt tun?“
Validieren Sie Eingaben inline, während Nutzer tippen oder das Feld verlassen – besonders bei häufigen Problemen wie Datumsformaten, Ausweisnummern, Dateigrößen und Pflichtfeldern. Wenn etwas falsch ist, zeigen Sie eine umsetzbare Meldung neben dem Feld (z. B. „Geben Sie Ihr Geburtsdatum als TT/MM/JJJJ ein“) und behalten Sie bereits eingegebene Daten. Vermeiden Sie vage Hinweise wie „Ungültige Eingabe“.
Ermöglichen Sie, wo möglich, das Speichern von Entwürfen und späteres Fortsetzen, besonders bei längeren Anträgen. Nach dem Absenden geben Sie eine klare Quittung: Referenznummer, was eingereicht wurde und wie der Status verfolgt wird. Senden Sie ggf. eine Bestätigungs‑E‑Mail/SMS und sagen Sie, was zu tun ist, wenn sie nicht eintrifft.
Wenn ein PDF nötig ist, bieten Sie eine zugängliche HTML‑Version als primäre Option an und stellen Sie sicher, dass herunterladbare Dokumente barrierefrei sind. Das unterstützt Mobilgeräte und Screenreader (siehe /accessibility).
Setzen Sie Erwartungen direkt nach dem Absenden: typische Zeitrahmen, Prüfungsphasen, wie Entscheidungen kommuniziert werden und wie Fehler korrigiert oder Widerspruch eingelegt werden kann. Klare nächste Schritte reduzieren wiederholte Anrufe und stärken das Vertrauen.
Ein Portal für öffentliche Dienste ist nie „fertig“. Bedürfnisse ändern sich, Richtlinien ändern sich, und kleine Usability‑Probleme können schnell zu großen Problemen werden. Eine kontinuierliche Mess‑ und Verbesserungsroutine hilft, das Wichtigste zu beheben, Verantwortung zu zeigen und öffentliches Vertrauen zu schützen.
Beginnen Sie mit Signalen, die an reale Ergebnisse gebunden sind, nicht an Vanity‑Metriken. Konzentrieren Sie sich auf:
Regierungsseiten sollten nur die minimal notwendigen Daten sammeln, um Services zu verbessern. Bevorzugen Sie aggregierte Reports, kürzere Aufbewahrungsfristen und vermeiden Sie das Erfassen sensibler Daten in URLs, Suchprotokollen oder Event‑Namen. Wenn Sie Session‑Aufzeichnungen oder Heatmaps einsetzen, dokumentieren Sie den öffentlichen Nutzen klar und stellen Sie strenge Kontrollen ein – oder verzichten Sie ganz darauf.
Erstellen Sie einfache Dashboards für Content‑Owner und Service‑Teams: „Welche Seiten versagen?“, „Welche Inhalte sind veraltet?“, „Welche Formulare verursachen Support‑Anrufe?“ Dashboards sollten zu Entscheidungen führen, nicht nur berichten.
Führen Sie vierteljährlich leichte Usability‑Tests zu den meistgenutzten Aufgaben durch. Priorisieren Sie Fixes, die Fehler, Verwirrung und wiederholte Kontakte (Anrufe, E‑Mails, persönliche Besuche) reduzieren.
Bieten Sie auf Schlüsselseiten einen Feedback‑Kanal an (z. B. „War diese Seite hilfreich?“ plus optionale Kommentare). Definieren Sie, wer Rückmeldungen liest, wie Probleme kategorisiert werden (Inhaltsfehler, technischer Fehler, Policy‑Frage) und Zielantwortzeiten – damit Feedback in Verbesserungen mündet und nicht in eine Blackbox.
Der Launch eines öffentlichen Service‑Portals ist nicht das Ende – er ist der Moment, in dem echte Nutzung beginnt. Ein reibungsloser Start reduziert Supportaufkommen, schützt Vertrauen und gibt Ihrem Team Raum, die Seite sicher zu verbessern.
Erstellen Sie eine Checkliste, die eine nicht‑technische Launch‑Verantwortliche/r ablaufen kann, mit klaren „Bestehen/Nicht bestehen“‑Kriterien. Mindestens sollte sie beinhalten:
Planen Sie Schulungen vor dem Launch, nicht danach. Bieten Sie kurze, rollenbasierte Sessions an:
Koppeln Sie Trainings an ein einfaches Handbuch, das dort abgelegt ist, wo Menschen es tatsächlich finden (z. B. im Intranet und verlinkt von /help).
Definieren Sie wiederkehrende Aufgaben und Verantwortliche:
Schreiben Sie ein einseitiges Runbook für Ausfälle oder Sicherheitsvorfälle: wer ist on‑call, wie werden öffentliche Updates veröffentlicht, welche Daten werden erfasst und wann ist Recht/Kommunikation einzubeziehen. Üben Sie es einmal vor dem Launch.
Reservieren Sie Zeit und Mittel für Post‑Launch‑Fixes, nutzergeforderte Verbesserungen und Barrierefreiheits‑Optimierungen. Ein kleines, stetiges Verbesserungsbudget schlägt einen großen Neubau alle paar Jahre.
Beginnen Sie damit, zu entscheiden, ob das Portal in erster Linie Informationen, Transaktionen oder beides mit einer kleinen Auswahl an Startdiensten bietet. Schreiben Sie dann eine einseitige Zweckbeschreibung und einigen wenigen messbaren Ergebnissen (z. B. Abschlussraten für Aufgaben, weniger Anrufe, Zeit bis zur Veröffentlichung von Updates).
Das hält den Umfang realistisch und gibt Ihnen eine Bezugnahme, wenn Prioritäten konkurrieren.
Benennen Sie Zielgruppen nach den Aufgaben, die sie erledigen müssen, und nicht nach demografischen Merkmalen. Typische Gruppen sind Bewohner, Besucher, Unternehmen und internes Personal.
Listen Sie für jede Gruppe die wichtigsten Aufgaben auf, z. B. „beantragen“, „verlängern“, „bezahlen“, „melden“ oder „Status prüfen“, und verwenden Sie diese Aufgaben zur Steuerung von Navigation und inhaltlichen Prioritäten.
Verwenden Sie Metriken, die reale Serviceergebnisse widerspiegeln und leicht verfolgt werden können:
Legen Sie im Voraus fest, wie Sie diese messen (Analytics, Feedback-Prompts, Anruf-Tagging).
Beginnen Sie mit vorhandenen Nachfrage-Signalen:
Suchen Sie nach wiederkehrenden Verben („beantragen“, „verlängern“, „bezahlen“) und validieren Sie die Vermutungen mit kurzen Interviews oder Usability-Tests, bevor Sie sich auf einen vollständigen Build festlegen.
Kartieren Sie die Reise für einige hochprioritäre Dienste aus Sicht des Nutzers:
So vermeiden Sie ein Portal, das nur Richtlinien erklärt, aber Menschen nicht dabei hilft, Aufgaben abzuschließen.
Führen Sie zunächst ein ehrliches Inhaltsinventar durch (Seiten, PDFs, Formulare, Microsites) und taggen Sie Elemente mit Metadaten wie Thema, Verantwortlichem und letztem Update.
Organisieren Sie die Navigation dann nach Nutzeraufgaben (z. B. „Beantragen“, „Bezahlen“, „Melden“), mit dem Ziel, wichtige Dienste in 2–3 Klicks von der Startseite erreichbar zu machen.
Behandeln Sie Barrierefreiheit als Gestaltungsanforderung und als Teil der Definition von „Done“. Wichtige Praktiken sind:
Veröffentlichen Sie eine Barrierefreiheits-Erklärung unter einem konsistenten Pfad wie /accessibility und bieten Sie einen überwachten Rückmeldekanal an.
Definieren Sie ein einfaches System dafür, wer schreibt, wer prüft, wer freigibt, wer veröffentlicht und wer aktualisiert Inhalte — mit namentlich genannten Rollen, nicht „dem Fachbereich“.
Fügen Sie Lifecycle-Regeln hinzu (Überprüfungsdaten, Archivierung) und einen Stilleitfaden, der Terminologie, Formatierung (Datum/Uhrzeit/Adressen) und Linkschreibweisen standardisiert. So bleiben Informationen langfristig zuverlässig und konsistent.
Priorisieren Sie Übersetzungen für Seiten, die beeinflussen, ob jemand eine wichtige Aufgabe erledigen kann:
Vermeiden Sie maschinelle Übersetzungen für kritische rechtliche/sicherheitsrelevante/finanzielle Anweisungen. Stellen Sie sicher, dass der Sprachumschalter die Nutzer auf derselben Seite hält, und bauen Sie Übersetzungsstatus und Review‑Zyklen in den redaktionellen Workflow ein.
Wählen Sie ein CMS mit rollenbasierten Berechtigungen, Freigabe-Workflows, Audit-Trails und Versionsverlauf mit unkomplizierten Rollbacks. Strukturieren Sie Inhalte in Felder (Anspruchsvoraussetzungen, Gebühren, Bearbeitungszeiten, Dokumente), damit sie in Suchergebnissen und verwandten Blöcken wiederverwendet werden können.
Planen Sie Integrationen (Formulare, Zahlungen, Fallmanagement, Terminbuchung) frühzeitig und setzen Sie nicht verhandelbare Regeln wie HTTPS, MFA für Mitarbeitende, Datenminimierung, Caching/CDN für öffentliche Seiten und Monitoring von Tag eins an.
